Note: You must be registered in order to post a reply. To register, click here. Registration is FREE!
T O P I C R E V I E W
Posted - 06/30/2010 : 03:27:54 AM Hello guys,
I developed a web application that uses impersonation to query the AD and connect to SMS/SCCM. This application works fine on the server A on which it is currently hosted but we need to move it to a big infrastructure (server B).
When I say it works fine I mean impersonation works, wireshark shows that a Kerberos ticket is negociated and klist displays it as well. Server A is trusted for delegation in AD so no SPN was required.
Now on the second server (server B) the web app is throwing errors because impersonation doesn't work. The server is not trusted for delegation in AD, the IIS App pool and website have been configured exactly the same as on server A (maybe there is an issue with NTAuthenticationProviders) but I don't see any Kerberos ticket negotiation. On server B we set an SPN on a CNAME (the one of the website). After having seen Mark's Cracking Open Kerberos video, I understand it will not work. There is an SPN for both the hostname of the server and the FQDN though. That should help.
[edit1] The website's authenticated access on server A and B is only set to Integrated Windows authentication. [/edit1]
[edit2] Using Wireshark shows that the first GET on server A doesn't say anything about NTLM or Kerberos, then server sends back WWW-Authenticate: Negotiate. The first GET on server B shows NTLMSSP_NEGOTIATE in the header and packet from server says NTLM as well. [/edit2]
Anyone has an idea ?
Thank you for your time, I appreciate it!
2 L A T E S T R E P L I E S (Newest First)
Posted - 07/07/2010 : 3:11:38 PM The SPN is important, because it's a attribute of the machine object. Very good on the app.
Posted - 07/07/2010 : 09:57:34 AM Well the CNAME has been replaced by a A, we kept the SPN and it seems that fixed it!