kerberos and ntlm authentication using APM

That's a decent document, though I would add a few thoughts:

 

 

1. You can add and remove branches from the 401 agent, so you could strip out the Basic auth and just do Negotiate. To do that, go to the Branch Rules tab and remove the Basic condition, then go back to the Properties tab and select negotiate as the HTTP Auth Level.

 

 

2. Negotiate applies to both NTLM and Kerberos on the client side.

 

 

3. I would recommend using the KRB5_NT_PRINCIPAL PTYPE when exporting the keytab. It shouldn't break it to use another type, but this is, in my opinion, more semantically correct. You also shouldn't have to specify the -crypto version if using Win2008, though it may come in handy with different OS versions. Your setspn would then look something like this:

 

setspn -princ HTTP/www.example.com@EXAMPLE.COM -mapuser example\joe.user -ptype KRB5_NT_PRINCIPAL -pass password -out c:\temp\www.example.com.keytab

 

 

So from an APM traffic flow perspective:

 

1. The user accesses the VIP for the first time and does not send a session cookie - APM redirects the user to /my.policy with a new session cookie

 

2. The user accesses the /my.policy URI, sends the new session cookie, signaling the beginning of the access policy evaluation

 

3. The 401 agent sees that the user is not sending an Authorization header and returns a 401 response with the configured options (Basic or Negotiate)

 

4. The user, in the case of Negotiate, communicates with the KDC (domain controller) to get a ticket for the service (as specified in the URL - so for example "http/www.example.com@EXAMPLE.COM")

 

5. The KDC validates the user's TGT (a long-life ticket they received when they first authenticated to the domain), generates a ticket (nonce, time stamp, client and service information, PAC data, one copy of short-lived session encryption key, other stuff), encrypts that value in the service's Kerberos encryption key (that it shares with the service), adds the other copy of the short-lived session encryption key and wraps it again in the user's encryption key (that is shares with the user), and then passes it back to the user.

 

6. The user decrypts the outer shell and extracts a session encryption key and an encrypted blob that it cannot decrypt, and passes that blob to the service. This binary data is base64-encoded and placed into an Authorization: Negotiate HTTP header.

 

7. The APM 401 agent sees the Authorization header, that it is of the type Negotiate, and then sends it down its Negotiate branch, to the Kerberos Auth agent.

 

8. The Kerberos auth agent should posses a keytab file, as defined in the Kerberos AAA, that contains the encryption of the service (ie. http/www.example.com@EXAMPLE.COM). If it does, then it should be able to decrypt the remaining layer and expose the Kerberos ticket data and the second session encryption key. If that succeeds then APM client side Kerberos authentication is COMPLETE. The Kerberos auth fills the session.logon.last.username session variable with the UPN of the user (ex. joe.user@example.com). You can then use this value however you like to do SSO on the server side.

 

 

And now a few last thoughts.

 

1. The 401 agent will pass the traffic through a specified branch if it sees the Authorization header.

 

2. The SSO Credential Mapping agent is only needed with certain types of SSO profiles, and has nothing to do with client side authentication. It is there to format user/pass/domain values as required for the SSO. For client side Kerberos you only need the 401 and Kerberos Auth agents.