kerberos and ntlm authentication using APM

Okay, to start with let's clarify that the Kerberos AAA is a client side config. If you have to use Kerberos on the server side, that's a completely different set of options. Here are some things to look at as you troubleshoot APM Kerberos AAA:

 

 

1. The first thing you should do is set up a capture. If you can get Wireshark on the DC, that tends to be the best vantage point. You'll be looking specifically for Kerberos (and potentially DNS) traffic.

 

 

2. There are a few places client side Kerberos can go wrong, so to rule out issues on the client itself, add some message boxes inline with the 401 and Kerberos auth agents. You want to see a message before the 401 (initial request), after the 401 (browser returning with a Kerberos ticket), and then after the Kerberos auth agent (good auth). If it never makes it past the 401 agent, then your browser is likely not making a Kerberos request. If an IE browser, you need to add the VIP's host name to your Trusted Intranet Sites list. If you've done that and now failing at the Kerberos auth agent, continue the steps below.

 

 

3. I've have very limited success with AD service accounts that are not all lowercase. I know it doesn't make sense, but that is a pretty consistent observation.

 

 

4. Once you've created the service account, you don't have to manually create the SPN with SETSPN as the KTPASS command will do that for you. And although there are a few references to using a ptype of KRB5_NT_SRV_HOST, you're tying this SPN to a user account, so it's more semantically correct to use KRB5_NT_PRINCIPAL. When you're done you can verify the SPN creation in the service account.

 

 

5. Delegation settings are absolutely NOT required for client side Kerberos.

 

 

6. Verify of course that you have good A and PTR records for the VIP's host name and that the clocks of all involved parties are fairly close if not in sync. Also check for duplicate SPNs. There's nothing more frustrating than a week of troubleshooting to find out someone else created the same SPN somewhere else.

 

 

7. Between testing it's a good idea to clear caches. On the APM side, issue the following command in the shell:

 

 

bigstart restart rba

 

 

On the client side (Windows), issue the following command in the shell:

 

 

klist purge

 

 

8. You can increase logging with the following TMSH command:

 

 

tmsh modify sys db log.rba.level value debug

 

 

Make sure to set it back to "notice" when you're done troubleshooting.

 

 

9. If you're still not getting past the Kerberos auth agent, take a closer look at DNS traffic in the captures. On some systems I've seen APM attempt to resolve AAAA records in AD and then fail if they don't exist. Just make sure whatever APM is asking for exists and is resolvable.

 

 

10. Finally, and this is a stretch, but if you've been at this troubleshooting for awhile, there's a good possibility that you could have mismatched KVNO values. On your DC, issue the following command (modify as required):

 

 

ldifde -f c:\spn_out.txt -d "DC=mydomain,DC=com" -l *,msDS-KeyVersionNumber -r "(serviceprincipalname=HTTP/webtest*)" -p subtree

 

 

The ldifde command comes in a resource pack I believe. Look for the "msDS-KeyVersionNumber" string in the output file. On the BIG-IP:

 

 

klist -ekt

 

 

If the KVNO values don't match, delete and recreate the AD service account, rerun KTPASS, and reimport the keytab to the AAA config.

 

 

The above steps usually resolve most of my client side Kerberos issues. If you're still not getting it to work, please reply back and submit a sample of the captures if you can.