Question

Problem Summary

When run in batch mode, my user identity is lost but (like a really good cliffhanger) not until the very last moment.

Problem Details

I have a PowerShell script running on WinXpSp3 that runs a script block (via Invoke-Command) on a remote machine as a particular test user (via -Session parameter) in the background (via -AsJob parameter). The session is created with this:

New-PSSession -computername $myServer -credential $myCredential

The script block performs a number of actions, culminating in running the NUnit test framework. The C# code under test records the “myTestUser” username (via Environment.UserName) so the credentials provided by PowerShell are properly received that far. This is further confirmed by Process Explorer: examining properties of nunit-console running the batch tests shows it is owned by myTestUser.

The test includes accessing a Sql Server 2008 R2 database; the connection string is set via a new SqlConnection(connectionString) call. The connection string is set up for Windows Authentication and uses this form:

Data Source=<my_db_server_name>;Initial Catalog=<my_db_name>;Integrated Security=True;Persist Security Info=True

Even though I have conclusively pushed the myTestUser credentials all the way to the C# code under test, the DB access attempt is not seeing these credentials, resulting in this error: Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’

Some supplemental info:

1. I have confirmed that the test user (myTestUser) has DB permissions and the NUnit test is capable of accessing the DB: When I run the NUnit test manually (via NUnit GUI) logged in as myTestUser, the test works properly and SqlProfiler clearly shows this activity with myTestUser appearing in the NTUserName column.
2. The same error occurs if I run locally rather than on a remote machine.
3. The same error occurs if I run as myself on my local machine (i.e. omitting the -credential parameter).

Question

How can I rescue myTestUser from the brink of doom and get him DB access?

---

2011.05.16 Update

Here is a simplified example exhibiting the same problem.

First, my test program DBFetchVersion that prints the name of the current user and the results of a simple query:

class Program
{
    const string connString = ...your connection string here... ;
    const string query = "SELECT getdate() [Date], substring(@@version,1,charindex('-',@@version)-1) +convert(varchar(100),SERVERPROPERTY('edition'))+ ' ' +convert(varchar(100),SERVERPROPERTY('productlevel')) [SQL Server Version], @@servicename [Service Name], @@servername [Server Host], db_name() [Database], user_name() [User], host_name() [Client]";

    static void Main(string[] args)
    {
        DataView dataView;
        using (var connection = new SqlConnection(connString))
        {
            Console.WriteLine("user = " + Environment.UserName);
            using (var dataAdapter = new SqlDataAdapter(query, connection))
            {
                var dataSet = new DataSet();
                try
                {
                    connection.Open();
                    dataAdapter.SelectCommand.CommandType = CommandType.Text;
                    dataAdapter.Fill(dataSet, query);
                }
                finally { if (connection.State == ConnectionState.Open) connection.Close(); }
                dataView = dataSet.Tables[0].DefaultView;
            }
            foreach (var item in dataView.Table.Rows[0].ItemArray)
                Console.WriteLine(item);
        }
    }
}

And here is the Powershell script that calls the above program.

$scriptBlock = {
    & "...path to my executable...\DBFetchVersion\bin\Debug\DBFetchVersion.exe"
}

$serverName = ... my server name ...
$username = "testuser"
$password = ... my user password ...
$adjPwd = $password | ConvertTo-SecureString -asPlainText -Force
$testCred = (New-Object System.Management.Automation.PSCredential($username,$adjPwd))    
$mySession = New-PSSession -computername $serverName  -credential $testCred 

# Test Scenarios:
Invoke-Command $scriptBlock 
#Invoke-Command $scriptBlock -computername $serverName 
#Invoke-Command $scriptBlock -computername $serverName  -credential $testCred 
#Invoke-Command $scriptBlock -Session $mySession 

In the list of four test scenarios at the end, the uncommented one works, printing my user name and the results of the query.
DBFetchVersion still reports I am the user with the second line, but the DB connection fails with the ” Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’ ” error.
The remaining two lines report the “testuser” user name, but both report the same login failure for the DB connection.

What this isolated example tells me is not that I think there is anything buggy about Powershell, .NET, or my code, but there is something with the authentication mechanism that I do not yet understand, since specifying another computer or a session both involve a path that should, in some sense, have stronger protection.

2011.08.03 Update – Eureka!

Well, Matt was correct in identifying the double-hop issue as the culprit and CredSSP authentication as the solution. Unfortunately, as I quickly found out, CredSSP requires Windows 7, so I went about setting up a couple VMs as a sandbox. CredSSP, however, was not one to easily relinquish its secrets (at least to me) as I detailed in this post on ServerFault: Cannot get CredSSP authentication to work in PowerShell

I finally was able to get CredSSP authentication to work so I could then come back to the problem I posed here in this thread. As a test, I used these 3 script blocks plugged into the PowerShell script I provided above:

$scriptBlockA = {
    Write-Host ("hello, world: {0}, {1}" -f $env:USERNAME, (hostname))
}

# Simple DB test, but requires SqlServer installed!
$scriptBlockB = {
    if (! (Get-PSSnapin | ? { $_.name -eq "SqlServerCmdletSnapin100" } ) )
    { Add-PSSnapin SqlServerCmdletSnapin100; }
    Invoke-Sqlcmd -Query "SELECT getdate() as [Now]" -ServerInstance CinDevDB5
}

# Indirect DB test; requires .NET but not SqlServer,
# plus DBFetchVersion in home dir for targeted user.
$scriptBlockC = {
    & ".\DBFetchVersion.exe"
}

Block A worked with or without CredSSP, since there is no double-hop. Blocks B and C would only work with CredSSP because they both attempt to access a remote database. QED.

Answer 1

Initially i read this and thought of the “double hop” issue, but the supplemental info maybe me question that though.

When you run it locally (as yourself or the testuser) what commands do you use? this:

& "...path to my executable...\DBFetchVersion\bin\Debug\DBFetchVersion.exe"

also does this work from your local machine (as either yourself or the user):

Add-PSSnapin SqlServerCmdletSnapin100;
Invoke-Sqlcmd -Query "SELECT getdate()" -ServerInstance Server

Also what OS are you using? If it is Windows 2008 and the issue is double hop you may be able to us CredSSP to avoid it.