0

I am currently setting up an IIS Web Application. For Authentication I use integrated Windows Authentication with Kerberos. But i am kinda new to all that AD, Windows Authentication and Kerberos stuff. I got my application going as i want it, but there is one thing i don't understand.

How does IIS know, which Active Directory Server to use when validating Kerberos tickets? In my development environment its clear: It probably uses the AD of the domain i am logged in. But when i deploy the software to the customer, no one will log in, the computer will just boot and the IIS starts the web app. How does it know where to verify Kerberos tickets? No one is logged in on the server computer, therefore no account domain.

Does the client transmit its domain information? Does the IIS have its own domain account? Does the server machine know its domain also without a user login?

TostMaster
  • 3
  • 3
  • `How does IIS know, which Active Directory Server to use when validating Kerberos tickets?`. It doesn't validate. That's one of the main points with using Kerberos. When you have a ticket that ticket may be presented to other entities and they grant access. Everything IIS needs to grant or deny access is in the WWW-Authorization header. – Greg Askew Oct 15 '20 at 17:27
  • IIS doesn't know that, so it asks Windows directly. The Windows installed should know which primary domain controller to talk to, as that's determined when it joins the domain. Such doesn't require any user account to log in, as Windows has its own account (machine account) to work with active directory. – Lex Li Oct 15 '20 at 23:55
  • Thanks, that makes thinks a little clearer now, but raises another question on my side: If the server and Kerberos don't communicate during the authorization process, do they do it at all? I mean, somehow the server has to know whether the presented ticket from the client is valid. Do they (Server & Kerberos) exchange some kind of key whenever IIS starts up? – TostMaster Oct 16 '20 at 06:18

1 Answers1

0

somehow the server has to know whether the presented ticket from the client is valid.

Not necessarily.

In the Microsoft Active Directory implementation of Kerberos, the privileges and roles (group memberships) are stored in a part of the Kerberos token called the Privileged Attribute Certificate (PAC). When a token is presented to another system or process, the PAC is evaluated to determine if they have access, usually by group membership.

It is possible for Windows to validate the PAC. This is typically performed as an integrity check to ensure that it isn't forged. However, PAC validation is intended to occur in specific circumstances, such as when an application which is trusted for delegation attempts to reuse a Kerberos ticket from an impersonated or delegated user which it has already locally cached.

If validation of the PAC were performed, the Windows Netlogon service simply sends a PAC validation request to the local domain controller as described here:

4.2 Kerberos PAC Validation
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-apds/1d1f2b0c-8e8a-4d2a-8665-508d04976f84

PAC Validation

However, if a process has Act As Part of the Operating System privilege, PAC validation may not occur. Note that if IIS is using integrated authentication and performing delegation-level impersonation of authenticated users, it may be required to have Act As Part of the Operating System privilege.

Also, if you are only authenticating users and using their token groups to grant access and not impersonating their token, a PAC validation may not occur.

More information:

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/why-won-t-pac-validation-turn-off/ba-p/243144

https://web.archive.org/web/20081201072315/http://blogs.technet.com/ad/archive/2008/01/21/dude-where-s-my-pac.aspx

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • In fact PAC validation *will not* occur in most cases. PAC validation only happens when the machine itself doesn't trust the calling credential context as SYSTEM. It's only there to prevent EOP. In practice this means when the server is NOT running as SYSTEM or as a local service. – Steve Oct 20 '20 at 21:12
  • And also this is slightly backwards. It's not a question of whether a ticket is valid because it contacted a DC and the DC said yeah, it's because the machine was able to decrypt the incoming ticket as issued *by* a KDC. If an attacker has the service principal key they can mint a ticket and the machine won't be the wiser. That key is the machine account password, created when the machine is joined to the domain. – Steve Oct 20 '20 at 21:15