How do http requests work with Active Directory?

2
votes

I have an ASP.NET MVC application that authenticates users against Active Directory.

As I understand this is the process happens when a user logs on to his computer:

  1. User enters credentials on the local machine.

  2. Local machine checks if it already has an authentication ticket for these credentials.

  3. If not, it contacts the first ADS server it can find that offers kerberos authentication functions

  4. The ADS machine checks the credentials against the LDAP database.

  5. If they check out, kerberos returns a TGT (ticket-granting-ticket) to the client machine

  6. For a certain duration set in AD (usually 8~10 hours) this TGT will bypass any credential checking in case the local machine user wishes to connect to resources that require permissions not present in his bare user account (i.e. group memberships, additional machine and share access, etc.)

My question is how does IIS know about the TGT when the browser is making a request to it for my app? Does the operating system send it out on every outbound http request to every single website?

1
iisactive-directory
It is super clear if you know a tool like Fiddler or Wireshark, blogs.technet.microsoft.com/mist/2018/02/14/… The credentials are passed as part of the HTTP header. - Lex Li

1 Answers

4
votes

The server (IIS) will indicate to the client (browser) that it needs to authenticate by returning an HTTP 401 error code with a WWW-Authenticate header. The client detects this and determines if it can correctly authenticate. The way this works is as follows:

  1. Determine who the requestor is by checking it's Service Principal Name. It exists as {type}/{fully.qualified.domain}, e.g. HTTP/resource.domain.com. This SPN is mapped to a machine or service account in AD. If this SPN isn't registered, the client falls back to a lesser protocol like NTLM.
  2. Local machine uses the TGT to request a service ticket from AD. AD validates the TGT and looks up the SPN in the request and if found creates a service ticket encrypted against the password of the account associated to the SPN.
  3. Client sends the service ticket to the server via Authorization: Negotiate YII... header.
  4. Server decrypts the service ticket using the password it's been provided, either through a domain join, Windows Service Run As config, or keytab.
  5. Server transforms the contents of the decrypted service ticket into a Windows identity.
  6. Identity is presented to the application.

This flow isn't inherently web-specific. This is how all services authenticate themselves when using Kerberos.