remote powershell script executed by anonymous user

Question

We are running deployment scripts using pstrami. Part of the deployment is to execute database migrations. The migrations are using an connection string with Integrated Security.

When the script executes on the remote machine the migrations fail with a sql error saying Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

The person executing the script is a domain administrator. Other deployments that we run execute the remote scripts with the user who started the process.

Answer 1

This is the scenario:
You run the pstrami(deployment) script from desktopA. The script pushes your installation files to serverA. Then on serverA the scripts are run remotely as the person inititating the script from desktopA. One of the steps is to run a sql database upate with fluentmigrator using a connection string paramter using "integrated security" and the database is on serverB.

Connection string example:

$migration_db_connection = Data Source=serverB;Initial Catalog=PropertyDb;Integrated Security=SSPI; 
.\migrate.exe /conn "$migration_db_connection" /db SqlServer /a $migration_assembly /profile DEBUG

Pstrami uses the powershell command invoke-command which uses the account you are running the script under as the default user. So, what happens is that when you run the script from desktopA as "jonDoe" it then authenticates on serverA. So your pstrami scripts run under "jonDoe" on serverA. When you execute the fluentmigrator script on serverA as "jonDoe", fluentmigrator returns an error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. In IIS, you run into an interesting situation when you need to access another resource off of the IIS server and certain fairly common situations occur. When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a Windows security measure kicks in and doesn't allow your site to access resources on any network servers. (http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx)

This is how I got around the Windows Authentication and the Double Hop problem I ran into. Run your migration scripts directly on your sql database server and include it as a server target in your pstrami environments.

Example:

Environment "dev" -servers @(
    Server "serverA" @("InstallWeb") 
    Server "serverB" @("RunMigrations")
    ) 

More on Double Hop

• http://www.spdoctor.net/Pages/message.aspx?name=login-failed-for-user-bdc
• http://www.sqlservercentral.com/blogs/sqlsandwiches/2011/06/20/double-hop-of-doom/

Answer 2

The problem is that the credentials are not hopping to SQL Server for integrated security. You need to do the following:

On the server (the one that is making the SQL Server connection, as administrator run:

Enable-WSManCredSSP -Role server

On the client machine, as administrator run:

Enable-WSManCredSSP -Role client -DelegateComputer YOUR_SERVER_NAME

To open this up to all servers, you can run:

Enable-WSManCredSSP -Role client -DelegateComputer *

Finally, your invoke command make sure you run -authentication credssp. An example:

invoke-command -computername $remoteServer -authentication credssp -scriptblock { write-host "hello!" } -credential $credentials