How to invoke-sqlcmd (or sqlcmd.exe) with AAD+MultiFactorAuth - powershell

All the docs and help threads I can find reference connection strings with Authentication=ActiveDirectoryIntegrated to hit SQL with AAD integration. If I'm using SSMS I can also choose "Active Directory Universal" which gives a prompt if MultiFactorAuth (MFA) is required.
I want to use powershell to invoke-sqlcmd, or even sqlcmd.exe directly -- do either support an MFA flow? How else can I get commandline queries against an AAD-enabled MFA-enabled SQLAzure instance?
invoke-sqlcmd : Failed to authenticate the user NT Authority\Anonymous Logon in Active Directory
(Authentication=ActiveDirectoryIntegrated).
Error code 0xCAA2000C; state 10
AADSTS50079: The user is required to use multi-factor authentication.
Trace ID: 54f0cb31-2f0f-4137-b142-b312a6cd441b
Correlation ID: 70204904-576c-4db5-9c3b-6ccd7fe6b409
Timestamp: 2017-02-09 22:56:39Z
I've seen https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication, and everything was working fine right up until MFA either was applied, or when it realized it was time to re-auth and prompt.
If there is a way for me to cache creds so ActiveDirectoryIntegrated generally works, and I just need to re-auth and re-cache when it decides it is time to force an MFA prompt I'm also open to that.

I want to use powershell to invoke-sqlcmd, or even sqlcmd.exe directly -- do either support an MFA flow?
No. As far as I know, the SSMS is the only tool currently enabled for MFA through Active Directory Universal Authentication.( refer here)
If you have any idea or suggestion about Azure SQL database, you can submit them from here.

Beginning with version 15.0.1, sqlcmd utility and bcp utility support Active Directory Interactive authentication with MFA.

Related

Create Event Log source and write to it without administrative privileges

I'm running a Powershell logon script which sets users' Outlook signatures.
For debugging purposes, I'd like to log information in the client's Windows event log.
Using the New-Eventlog -LogName "Application" -Source $ParentScript command gives me a security error, "Access denied".
The users don't have administrative privileges so PowerShell is struggling to create a new source. I don't really understand this because most techy guides for the Event Log appear to indicate that any level of user can write to the Application log. Perhaps any user can write to this log, just not create a source within it?
I've looked online and one author appeared to suggest (unless I have misinterpreted) that creating an event log in registry could be an option: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/00a043ae-9ea1-4a55-8b7c-d088a4b08f09/how-do-i-create-an-event-log-source-under-vista?forum=windowsgeneraldevelopmentissues
Unfortunately the code is not in PowerShell and I'm struggling to follow it.
My three-questions-in-one therefore are:
Can I create a new EventLog source in the registry using PowerShell?
If so, what commands should I be looking at and are permissions relevant (e.g. do I need to create a registry key then add perms to it?)
If so, can I write to this source in PowerShell without administrative privileges?
You can create a new Event Log souce with with the built-in cmelt New-EventLog something like there is a nice (even if somehow dated) post here
Full documentation for the cmdlet can be found here
Generally speaking yes you, well your user, should be able to write to the event log if memory serves a non local admin user should already be able to do so but I cannot test it right now anyhow you can red more here or read on server fault
Hope this can help a bit.

Running PowerShell as different user and credentials

I am working on a project using PowerShell, and the challenge that I have now is how to run PowerShell itself.
I have access to a domain credential that has login capability on the server I am running it from, and I am planning on using WQL queries as triggers to run the script at different times.
Is there a way to do this without leaving the credential information as plaintext? I have and use stored domain credentials within the script, but I cannot find a way to use those credentials to run the script itself.
Any idea how to do this, or creative ways to get around the issue? I cannot use Task Scheduler for this project.

How to store user credentials for script

I am required to utilize an old version of ClearQuest 7, and the only APIs that are enabled in our installation are for VBA (Excel) and RatlPERL. (The REST API isn't an option for us - although it suffers the same cleartext credential problem.)
I've written a ratlperl script that executes queries into the defect database, and produces csv output. Note that ratlperl requires cleartext user credentials for authentication.
ratlperl query.cqpl -u %userid% -p %password% -q "%query%" -c %outfile%
That script is called from a Windows Batch file. When run from the Windows command line with no parameters, the batch file requests user credentials, but they can also be provided as parameters.
query.bat %userid% %password%
I trigger daily queries, with the user credentials passed as parameters for the batch file.
This all works well, but I'd rather not store the cleartext password in this way. The registry would be one possibility, but anyone with access to the machine would have access to those credentials.
How can I store these credentials in a somewhat secure way?
There's two things to watch out for. One is having your process list "show up" the auth credentials.
Particularly on Unix - if you run ps it'll show you the arguments, which might include a username and password. The way of handling this is mostly 'read from a file, not the arg list'. On Unix, you can also amend $0 to change how you show in ps (but that doesn't help command history, and it's also not perfect as there'll be a short period before it's applied).
The other is - storing the data at rest.
This is a bit more difficult. Pretty fundamentally, there aren't many solution that let your script access the credentials that wouldn't allow a malicious user to do so.
After all, by the simple expedient of inserting a print $password into your script... they bypass pretty much any control you could put on it. Especially if they have admin access on your box, at which point... there's really nothing you can do.
Solutions I'd offer though:
Create a file with (plaintext) username and password. Set minimum permissions on it. Run the script as a user that has privileges, but don't let anyone else access that user account.
That way other people can 'see' your script (and may need to to run it) but can't copy it/hack it/run it themselves.
I would suggest sudo for this on Unix. For Windows, I'm not sure how much granularity you have over RunAs - that's worth a look, or alternatively have a scheduled task that runs as your service account, and picks up 'request files' for processing that can be generated by anyone.
As the level of security doesn't need to be so high, perhaps consider to create a simple exe? The password could possibly be read out of the memory somehow, but I guess this way creates a big enough barrier.
Or something like this could be helpful?
http://www.battoexeconverter.com/
HTH

Azure powershell cmdlets with certificate authentication not working

All,
I am trying to use a certificate to authenticate against azure instead of using the Azure-AddAccount. So I did the following in an administrator powershell console, i followed the instruction located at http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/ :
Get-AzurePublishSettingsFile
This prompted me to login and download the publishsettings file. I placed the file in the same folder as the powershell console is.
Import-AzurePublishSettingsFile "D:\Dev\Powershell\azure.publishsettings"
This command doesn't return anything. I am not sure if it worked, but if I put an invalid name it blows up so I assume it works.
Get-AzureStorageAccount
I get the error "Get-AzureStorageAccount : Your credentials have expired. Please use Add-AzureAccount to log in again." At this point I thought I imported my certificate and this should work, but it doesn't. Am I missing a step? I have multiple subscriptions, maybe thats the problem?
You still need to use Add-Account in addition to importing the publish settings file. Add-Account will prompt you for the user you wish to authenicate with when running certain commands.
Add-Account utilises a different authentication mechanism to the cert-based setup with the PublishSettings File and it necessary to use both in certain scenarios (such as yours).

How secure is a powershell runspace/session

If i create a powershell runspace, either programatically with .NET or just by launching the powershell console; How secure are the scripts/commands that are run?
I'm not speaking about signing scripts, but the actually memory space that the scripts are run in.
I'm worried that if sensitive information is gathered as part of the script (a sql query into a salary database for example) that someone could hack this data out.
I know most people are thinking SecureString at this point, i know about SecureString.... I'm wanting to know specifically about the powershell runspace, not how to store strings securely inside a runspace (lets hope that last sentence didn't just answer my own question).
Specifically :
Are other applications/scripts/whatever able to peer into the runspace and see the commands i'm running?
Powershell script security works by controlling whether or not a script is "allowed" to run on your machine. If you have a machine running an execution policy of "AllSigned", that machine will require the Powershell script to be signed by a trusted certificate.
Scott Hanselman has a really good article on it here.
To my knowledge, your command history isn't permanently saved. You can do a "get-history" to see the commands you've entered in your current session, but it's not like linux/unix where "history" will contain all of the commands you've ever run on the system. As far as other applications being able to "peer into" or query your session, I have no idea.