Directory Programming .NET

OK, monday morning everyone.  I sit down, bring up my browser to see where I left off and... wah la!  It is now working.

So the application that Jim had made for delegation on Friday was giving me the IUSR account.  But this morning it gives me my EXT\nate account that I just logged in as on ADFS.

So it would appear that I was battling some caching issues, but I'm not sure where it would be.

Any ideas on caching areas to check in a scenario like this and how to reset them?

Edit: OK, it is back to IUSR, so somewhere something is happening either caching, or something is crossed.  I'll keep trying, but any pointers would help.

Are you seeing the IUSR_ account in Context.User.Identity or somewhere else?  Typically when the IUSR account is used, Context.User will be null and no authentication happened at all.  That sounds like a configuration problem with the ADFS agent.

System.Security.Principal.WindowsIdentity.GetCurrent().Name

This is the code I'm using, from Jim's sample app for delegation. 

I find it very odd that when I logged on this morning it said EXT\nate, what I had wanted, now everytime I log in, zero changes, it now is back to IUSR for my web server machine.

I removed IUSR's rights and of course I got the denied message as expected.

I am just really baffled as to why it would work sporatically.

Edit: I have changed the Web Agent's user it is running under, as per Jim's article.

In ASP.NET, Context.User represents the identity of the use who was authenticated by the web server.  If that is null, the ADFS agent is not running.  If it is a GenericPrincipal that contains a SingleSignOnIdentity, you are using the claims agent instead of the token agent and will not get the behavior you want.

WindowsIdentity.GetCurrent represents the identity the current thread is running under.  When you use impersonation in conjunction with some type of Windows authentication (such as IWA or the ADFS token agent), then Context.User.Identity and WindowsIdentity.GetCurrent will return the same user token.  Otherwise, they will not.

The value of WindowsIdentity.GetCurrent is the ID Windows will TRY to use to access remote resources when Windows authentication is used with them (such as in your case with SQL Server).

My guess is that you still have the claims agent running here instead of the token agent, but I don't know.

well I am getting back a windowsidentity from Context.User, but it appears empty.  I'll see what I can find from it.

here is the event I see on the web server (which is the FS-P for the EXT domain)

Event Type: Warning
Event Source: ADFS ISAPI Extension
Event Category: None
Event ID: 107
Date:  7/28/2008
Time:  2:59:41 PM
User:  N/A
Computer: ADFS-FS-P
Description:
The ADFS Web Agent Internet Server Application Programming Interface (ISAPI) Extension was unable to obtain a Windows NT token from the authentication service.

An anonymous token will be generated for this request.

User Action
Ensure that this application is configured as a Windows NT token-based application in the Federation Service trust policy.

If the user comes from an account partner where Windows Trust may be applicable, ensure that Windows Trust is enabled for the account partner and that the account partner has enabled Windows Trust for this resource partner.

If you are using shadow accounts:
 - Ensure that a shadow account exists for this user.
 - Ensure that user principal name (UPN) claims or e-mail claims are enabled for this application.
 - Ensure that UPN claims or e-mail claims are being produced for this user by the account store or the account partner.

Additional Data
Look for additional events in the security log that may contain more details. Consider enabling failure auditing on this Web server if auditing is not already enabled.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

It is a Token app in the trust policy.

The user I'm logging in as isn't from a partner, it is from the same domain, so the user is from the account store (AD) that is setup on the FS-R for the web site.

I'm not using shadow accounts because I shouldn't have to, everyone is on the same domain here (user, servers)

does my user account have to have an SPN?  if so, what format?

No, SPNs are for services, not users.  Users have UPNs.  :)

You may need to dig into the logs and figure out why your token app is failing.  At least it is showing an error. 

First, make sure the ADFS token service is actually running.  It should be, but maybe it is off.

You might also want to check the security event logs to see if you are getting any interesting audit failures that provide more details.  You can also enable debug level logging for the service.

I also assume your AD forest is 2003 native FFL instead of mixed mode.

is there any special format the SPNs for the service accounts need to be in?

my domain is 2k3, but the FFL is 2000, so I'll upgrade that

the ADFS token service is running

is there a specific UPN format I need to use for the user account?  right now I just put in 'somespn' should I change that?

here is the ifsap.log:

440.484> WebSsoAp-Config: Jul 28 08 20:32:52 Configuration change callback completed.
440.2964> WebSsoAp-Cache: Jul 28 08 20:35:24 Performing cache(1) scavenge.
440.2964> WebSsoAp-Cache: Jul 28 08 20:35:24 Performing cache(2) scavenge.
440.528> WebSsoAp-Trace: Jul 28 08 20:37:47 WebSsopRelocateAdfsApLogon: Relocated TokenGroups in ProtocolSubmitBuffer.
440.528> WebSsoAp-Trace: Jul 28 08 20:37:47 WebSsopRelocateAdfsApLogon: Unmarshalled ClientIdentity - somespn
440.528> WebSsoAp-Trace: Jul 28 08 20:37:47 WebSsopRelocateAdfsApLogon: Unmarshalled AuthAuthority - urn:federation:orgname
440.528> WebSsoAp-Cache: Jul 28 08 20:37:47 Cache miss for somespn
440.528> WebSsoAp-Error: Jul 28 08 20:37:49 WebSsopHandleUpnLogon: First LookupAccountNameW failed with 0x6fc
440.528> WebSsoAp-Warn: Jul 28 08 20:37:49 Unable to map Win32 error code 1788
440.528> WebSsoAp-Error: Jul 28 08 20:37:49 WebSsopHandleUpnLogon failed for urn:federation:orgname\somespn. Status 0xc00000e5

In order to make the delegation stuff work, you have to have 2003 native FFL because ADFS delegation requires protocol transition logon and that requires constrained delegation.  Both of those features require 2003 FFL.

It also looks like ADFS is using the Win2K auth package to log you in instead of Kerberos S4U and it is failing. We could try to fix that, but it is probably easier if we instead get you over to 2003 FFL first and see if the problems go away.

UPNs are in the format user@domain.com.  You can either set this explicitly in AD when you create accounts or use the implicit UPN, which is just <sAMAccountName>@<DNS name of domain>.

SPNs are different.  They look like <service type>/<service name>:<port> unless you are using 3 part SPNs which I confess to not even understanding.  :)  2 part is usually fine.  The port is usually optional.

SPN for a web app would be HTTP/somewebserver.com and an SPN for SQL would be MSSqlSvc/somesqlserver.com:1433.  You'll see them in AD on the servicePrincipalName attribute.  Use a tool like LDP or ADSI Edit to see the low level details.  All your computer accounts will have them.

Your user accounts don't need SPNs unless they also run services that accept Kerberos auth.

finally fixed it

I had promoted my domain to 2k3 before, but the forest functional level was 2k, so I promoted that to 2k3, but it still didn't work.

my UPN on my user was wrong.  Once set to user@domain it worked fine.

I think Jim's article is great, it just assumes a lot of information.  I agree with you Joe, this delegation stuff can be tricky for people learning it.

Now that was just getting the delegation/impersonation working.  I now need to make sure that it gets passed along to the SQL server and that my login for the Windows group works.

Edit: don't ask me why I missed the UPN thing, ADFS uses that! duh, I knew that is what it should have been.

OK, well SQL doesn't work yet.  Still getting the error: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Which means that the delegation to the sql server is not happening?

sds.ConnectionString = "Data Source=<IP address>;Initial Catalog=db1;integrated security=sspi";

Should I use a DNS name instead of IP?

I think my SPNs need to be corrected.

for the webservice account I am using these two:

HTTP/computername

HTTP/FQDN

not sure what to use for the ifs_account, or if the webservice SPNs are correct.

If you use an IP address in your connection string, you won't get Kerb auth, so don't do that.  :)  You can use either the NetBIOS name or the FQDN.  There are two important things:

• Whatever name you use must resolve properly to the SQL server (duh :))
• There MUST be an SPN for the SQL service type matching the name that you use in the connection string associated with the account that is running SQL

These are the two basic rules of Kerberos authentication.  In order to make delegation work, the leg from the front end web service to the back end MUST be Kerb even though the front end in this case uses ADFS/NT token agent.

If SQL runs as SYSTEM or Network Service, the service account in AD is the computer account for the machine, so the SPN must be on that object.  It will be of the form

MSSqlSvc/hostname:1433

If you originally installed SQL to run as Network Service or System, it probably already has those SPNs set, but othewise you may need to set them manually.

I like to use the ldp.exe tool for checking this and setting the SPNs, but I'm an LDAP geek and that tool is very familiar to me.

The SPNs for the web app are not really that important here since you aren't doing Kerb auth to the web app, you are doing ADFS.  They would be important if you were had the web app configured for IWA instead.