so we have this old asp site (that just won't die).
It's currently sitting on win2k12, it's setup with spn's and kerberos delegation. It uses a Com+ object that runs a .vbs that does a lot of talking with active directory.
We are starting to roll out our windows 10 implementation.
In our dev environment, it works with win7/IE11 and win10/IE11 In our production environment, win7/IE11 has worked (and still does) but win10/IE11 is not working.
Some of the error messages are
Active Directory error '80040e37'
The specified directory service attribute or value does not exist.
Error getting attribute max range
Attribute: [givenName]
Error description: [-2147463153] The attempted action violates the DS schema rules.
Normally these would point to the website not being configured properly but it's working fine for everyone on win7.
So that would point the finger towards the win10 implementation.
What in windows 10 would be causing this issue? (Maybe a specific misconfigured gpo?) I'm stumped.
Update 1-.
GPOs don't seem to the problem. It's the same gpo set regardless if it's win7 or win10 (no filtering by wmi).
So the site works in Windows8/ie11 and it also works in Chrome on win7 (after a few tweaks to enable kerberos)
I've managed to create a little test page that cause the issue.
Dim oSysInfo
dim user
'on error resume next
'Get the Current Users information. This information is just the currently logged on user
' Set oSysInfo = Server.CreateObject("ADSystemInfo")
'Get Current User Object
sURL= "LDAP://AUsersDistinguishedName"
response.write(sURL & "<br />")
on error resume next
Set user = GetObject(sURL)
pAttribute = "givenName"
'response.write(user.get(pAttribute))
Dim cl, sc, pr, pr2, pAttribute
Set cl = GetObject(user.Schema)
'Test(user)
Set sc = GetObject(cl.Parent)
Set pr = sc.GetObject("Property", pAttribute)
response.write(pr.MaxRange)
Set cl = Nothing
Set sc = Nothing
Set pr = Nothing
'-2147463155: Not found in directory cache, that means the MaxRange property is empty or not set, so there is no error
if err.number <> 0 and err.number <> -2147463155 then
Response.Write "<br>Error description: [" & err.number & "] " & err.Description
End If
--- Update 2.
I'll add more information about the IIS server.
- Server has 2 spn that point from the URL to the server
- The server is setup for delegation.
- The application pool is run on a specific domain account. It is set to 32bit.
- Windows Authentication is the only enabled authentication. (Extended Protection is off and enable Kernel-mode authentication is enabled). Negociate is the first enabled provider. Ntlm is the second.
Update 3: I've gotten Microsoft involved with one of my msdn incident. When we did a network monitoring trace, there seems to be an issue with kerberos.
Working - dev with windows10 Ticket: Realm: ourRealm, Sname: ldap/DomainControllerFQN
Working - Prod with windows7 Ticket: Realm: ourRealm, Sname: ldap/DomainControllerFQN
Not working - Prod with windows10 Ticket: Realm: ourRealm, Sname: Name of account running the website. all the request falls to NLMP ( ntlm) and not using kerberos
As for spn, they are the same between both environments. When we do setspn -l Webserver, this is a subset of them.
- http/WebsiteFQN -- We added this when we deployed to win2k12, 3 years ago
- http/websiteName -- We added this when we deployed to win2k12, 3 years ago
- TERMSRV/ServerName
- TERMSRV/WebserverFqn
- WSMAN/WebServerFqn
- WSMAN/WebServer
- RestrictedKrbHost/WebServer
- HOST/WebServer
- RestrictedKrbHost/WebServerFqn
- HOST/WebServerFqn
On the delegation tab for the webserver, it's set to
"Trust this computer for delegation to any service (Kerberos only)"
Here are screenshots of the IIS Authentication section
-- Update 4
here are the output of the Klist information after hitting the website in both environments (I did a klist purge on the workstation before hand)
Windows 10 - dev - working
Cached Tickets: (4)
#0> Client: MyUser @ DomainFqn
Server: krbtgt/DomainFqn @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
Start Time: 11/28/2017 10:27:10 (local)
End Time: 11/28/2017 20:27:10 (local)
Renew Time: 12/5/2017 10:27:10 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x2 -> DELEGATION
Kdc Called: DomainControllerFqn
#1> Client: MyUser @ DomainFqn
Server: krbtgt/DomainFqn @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 11/28/2017 10:27:10 (local)
End Time: 11/28/2017 20:27:10 (local)
Renew Time: 12/5/2017 10:27:10 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DomainControllerFqn
#2> Client: MyUser @ DomainFqn
Server: cifs/resourceServer @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 11/28/2017 10:27:11 (local)
End Time: 11/28/2017 20:27:10 (local)
Renew Time: 12/5/2017 10:27:10 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DomainControllerFqn
#3> Client: admlareaua @ DomainFqn
Server: HTTP/webserverFQN @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 11/28/2017 10:27:10 (local)
End Time: 11/28/2017 20:27:10 (local)
Renew Time: 12/5/2017 10:27:10 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DomainControllerFqn
Windows 10 - Prod- Not working
#0> Client: MyUser @ DomainFqn
Server: krbtgt/DomainFqn @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 11/28/2017 9:14:10 (local)
End Time: 11/28/2017 19:14:10 (local)
Renew Time: 12/5/2017 9:14:10 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DomainControllerFqn
#1> Client: admhqlareaua @ DomainFqn
Server: HTTP/WebServerFQN @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 11/28/2017 9:14:10 (local)
End Time: 11/28/2017 19:14:10 (local)
Renew Time: 12/5/2017 9:14:10 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DomainControllerFqn
Windows 7 - Prod- Working
Cached Tickets: (3)
#0> Client: MyUser @ DomainFqn
Server: krbtgt/DomainFqn @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
Start Time: 11/28/2017 9:17:24 (local)
End Time: 11/28/2017 19:17:24 (local)
Renew Time: 12/5/2017 9:17:24 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#1> Client: MyUser @ DomainFqn
Server: krbtgt/DomainFqn @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 11/28/2017 9:17:24 (local)
End Time: 11/28/2017 19:17:24 (local)
Renew Time: 12/5/2017 9:17:24 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#2> Client: MyUser @ DomainFqn
Server: HTTP/WebServerFQN @ DomainFqn
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 11/28/2017 9:17:24 (local)
End Time: 11/28/2017 19:17:24 (local)
Renew Time: 12/5/2017 9:17:24 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Update 5 -
So for run, i created a quick mvc site and put it as a sub site to the non working site.
I made the following controller.
public JsonResult GetList2()
{
var st = new List<string>();
var currSchema = ActiveDirectorySchema.GetCurrentSchema();
st.Add(currSchema.Name);
foreach (ActiveDirectorySchemaProperty property in currSchema.FindAllProperties())
{
st.Add($"{property.Name} - {property.RangeUpper}");
}
return Json(st, JsonRequestBehavior.AllowGet);
}
It seems to work fine and gives me the maxlength values I want. So I think i'm going to throw in the towel on this issue and continue with the re-write to c# of the application.
Update - 6 (6 months later).
It turns out that the issue is with Credential guard. (another old application was starting to get the same type of issue)
We turned off credential guard in the registry and the application worked fine.
(from the link)
Kerberos Considerations
When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process. Use constrained or resource-based Kerberos delegation instead
So I'll have to look into I guess constrained or resource-based Kerberos