For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Dec 18, 2013

Would it be safe to say the host name of the web site doesn't match the AD domain name? Ex. a web server named www.example.com in the MYDOMAIN.COM domain.

 

Normally, when a user in a domain is talking to a web server in the same domain, the servicePrincipalName of that web server will reflect the host name that the browser used in its request. With a proxy in place, however, that's not necessarily important any more. Ultimately, the Kerberos AAA just needs to be able to identify the web server by its SPN. When the SSO profile starts, it'll take the IP address of the chosen web server, reverse resolve its name from the DC, and then derive the SPN from that value. If the host name of the web server computer and the SPN of the web server aren't the same, this process will obviously not work. That then is when you would use an SPN pattern in the Kerberos SSO profile. SSO will disregard the PTR lookup and use the SPN specified in this field. It doesn't matter that the realm name in the SPN is different than the domain realm for two reasons:

 

  1. An SPN is just a name. A browser will derive its Kerberos request from that name, but otherwise it's just an identifier to an account.

     

  2. Assuming the realm name of the web server was from some other trusted domain, KCD's cross-domain policy would prevent this from working at all. Kerberos constrained delegation, per RFC, does not allow SPNs to cross domain boundaries. We can do cross domain authentication as long as the Kerberos SSO service account and the web server are in the same domain (the user can be in a different domain).

     

Using the SPN Pattern field in the Kerberos SSO profile has another implication though. The normal PTR lookup allows for multiple web services with their own SPNs. If you use an SPN pattern, all of the web servers would need to be "owned" by that one SPN. If that's not the case, or you can't configure it to be that way, then you need to makes sure that a PTR lookup for that server's IP address returns the correct SPN (not necessarily the host name of the machine).

 

As for the SSO service account, there are generally two options:

 

  1. Specify and use the Pre-Windows 2000 NETBIOS name of the account in the account name field. You'll still need to give it an SPN so that you can configure delegation though.

     

  2. Specify and use an arbitrary SPN. For this to work, you must enter the SAME SPN value in both the User Logon Name field of the account, and its servicePrincipalName field (ie. host/arbitary-sso-account.domain.com). You then specify this SAME SPN value in the Kerberos SSO account name field. The "host/" portion is not explicitly required, except 1) it's traditional best practice and 2) you need some service identifier (ex. http/, foo/, bar/, blah/, etc.) to make it a valid SPN-formatted string. You also don't have to add the domain realm to the SPN, but that to is traditional best practice and also helps resolve ambiguity in a true cross-domain environment.

     

Related Content