Hi all...I am setting up a new BIG-IP environment (v.11.5.1) to front multiple backend services. What is the simplest way to have multiple services (i.e. webservice1.company.com, webservice2.complany.com, etc) that are completely separate fron one another, utilize kerberos from a single domain? Do I need to create a seperate keytab files for each service? If so, do these each need to utilize a differente service account?
I think you might need to create 2 virtual servers with 2 different surrogate accounts. And you may have to close the browser(IE) before accessing the second virtual server.
28-Jul-201411:43 - last edited on 05-Jun-202322:15 by JimmyPackets
There are actually a few ways to go about this, but first it's important to distinguish client side and server APM Kerberos as two completely separate things. I mention this because only client side (AAA) APM Kerberos requires a keytab, while server side (SSO) APM Kerberos does not. So with that aside, let's run through some of the options:
Create separate SSO profiles for each - as I'm sure you're aware, Kerberos is dependent on a unique servicePrincipalName (SPN) for each service. This unique SPN maps to an encryption key in the KDC's database, and that encryption key is used to encrypt and decrypt messages to/from the entity that owns that SPN. So for example, let's say you have a Kerberos-enabled web server. That web server service must be associated with a SPN. In IIS that is the SPN assigned to the account that owns a particular application pool (that is then assigned to a website). When a client requests a ticket for a service, it does so by name (SPN). The KDC validates the client's request, generates a ticket, encrypts that ticket with the requested service's key, and then encrypts it all again with the client's key. The client decrypts the outer "shell" and sends the rest to the service. If the client asked for the right service by the right name, the service should have the key necessary to decrypt the inner shell and expose the ticket. If each of your web applications are completely separate in the sense that they cannot share a single Kerberos SPN, then you could create a separate APM Kerberos SSL profile for each and either assign to a respective VIP, or use the WEBSSO::select command in an iRule to switch between the SSO profiles based on some request value (host name, URI pattern, cookie value, etc.).
Create a single SSO profile for all - if, however, the web servers can all share a single service account and corresponding SPN, then you could create a single APM Kerberos SSO profile and use for all of the services.
It's also worth taking a moment to discuss the "SPN Pattern" option in the Kerberos SSO profile. By default, and without this setting defined, the APM Kerberos SSO profile "builds" the SPN dynamically by first performing a reverse DNS lookup of the load balanced IP address, then adding "http/" to the front, and "@REALM_NAME" to the end (the actual uppercase name of the domain realm) to create a SPN (ie. http/server1.domain.com@DOMAIN.COM). It uses this SPN to request a ticket for the downstream service. If, however, that name doesn't match the actual SPN (owner) of the web server, then this process would obviously fail. To get around this, the SPN Pattern field in the profile allows you to specify a static SPN value. Populating this field overrides the reverse DNS process and uses the specified string as the SPN for the ticket request. Now here's where it gets really interesting. That SPN Pattern field can take "wildcard" parameters. The %s wildcard will take the load balanced IP address and query the local Hosts file on the BIG-IP. You can use this option if a DNS lookup isn't going to return the correct SPN host name.
http/%s@DOMAIN.COM
The %h option takes the Host header from the request to generate the SPN (an admittedly less used option). What this means is that you could also, as a third option, create a single Kerberos SSO profile, and either use reverse DNS or the %s wildcard and Hosts entries to dynamically generate the SPN for the ticket request. The AD service delegation account that you create to bind to the APM Kerberos SSO profile can be configured to delegate to all of the web server SPNs.
Yes.... that is a current limitation of APM Kerberos SSO. It basically means that if all of your services are in a single domain realm, you can only have one Kerberos SSO profile and AD delegation account. If the services are in different realms, this shouldn't apply. The alternative is to create a single Kerberos SSO profile, and then use either reverse DNS or SPN patterns and %s wildcards to dynamically generate the SPNs to be used.
Cross-realm limitations don't apply as long as the delegation account (used by APM) is in the same realm as the target service. Cross-realm constrained delegation does, however, require the users to be in a transitively trusted realm.
The only other issue is that APM doesn't support cross-realm referrals. It's something that would happen if a user was in a different realm and the current realm sent a referral to that realm (or at least the next realm closest to this realm). So since APM doesn't understand referrals, you have to tell it which realm the user is in. That may be an LDAP query up front in the access policy, either nested queries or a single GC query. Once you know which the realm the user belongs to, you need to use the user's sAMAccountName in that realm as the SSO username source, and the user's realm realm name as the SSO domain source.
14-Dec-201610:50 - last edited on 03-Jun-202323:33 by JimmyPackets
In a multi-domain configuration, you MUST use the user's sAMAccountName as the SSO username source, and the user's real domain as the SSO domain name source. APM Kerberos SSO doesn't support referrals, so users in domain1 work because no referrals are needed there. So for example:
15-Dec-201606:34 - last edited on 03-Jun-202323:33 by JimmyPackets
Okay, just to be clear, the delegation account (used by APM) and the web service MUST be in the same domain. You don't need, and should not use multiple SSO profiles. You just need the one SSO profile.
If it still fails after removing the second SSO profile, take a tcpdump from the BIG-IP
tcpdump -lnni [vlan between APM and KDC] -Xs0 -w [write to file.pcap]
Or run a wireshark capture from the KDC directly and observe the Kerberos traffic. The error you see there will be more descriptive than the APM log.
I don't have my Kerberos testing lab up and running, so can't say specifically if that is an issue. The bad match error does indicate that the target KDC doesn't like something in the ticket though. I'd check the following things:
That transitive (two-way) trust is correctly established
That you're actually talking to the correct target domain KDC
That your delegation account is identified by a userPrincipalName and not a sAMAccountName. I didn't mention this earlier, but it's imperative that the Kerberos SSO delegation account is specified using a UPN format account@domain' versus 'domain\account' or simply 'account'.
We have a similar setup (users need to be authenticated to multiple back end applications), we are trying to do KCD but here is my confusion. We use lots of "easy to remember" aliases for sites not their computer names for users to access. For example - time recording site is "timekeeping.ourdomain.com" instead of the server name which is siteabbrfunctionnumber .int.ourdomain.com. So when reading about this in provisioning the service account and adding spns, I did select their computer names from AD and added to the account. However upon further reading, it would seem I need to set the spn's for the aliases as well, but cant do that through the gui so need to add them command line? Before I do that, this is the error I am getting:
Dec 14 17:50:53 nmnbig02 err websso.5[14574]: 014d0024:3: /Common/int-wso-idp:Common:a2baa8d5: Kerberos: Failed to get ticket for user @INT.OURDOMAIN.COM
Dec 14 17:50:53 nmnbig02 err websso.5[14574]: 014d0048:3: /Common/int-wso-idp:Common:a2baa8d5: failure occurred when processing the work item
So if it couldnt get a ticket its because there wasnt a match for the spn right? Please forgive my ignorance I am new to Kerb. Also is there a good primer for Kerb that you would recommend?
Consider that the KDC stores encryption keys in its database based on the name of the services - its "principal name". When a client (or service) requests a ticket from the KDC, it must specify the correct principal name target, so that the KDC can retrieve the correct value. Since APM SSO is the delegate client in this scenario, it doesn't really matter what the DNS name is on the outside, as long as APM knows the real principal name. The APM Kerberos SSO config allows you a few ways to do that:
With the SPN Pattern field left blank, SSO uses a reverse DNS lookup of the pool member IP. If DNS returns "siteabbrfunctionnumber.int.ourdomain.com" and "HTTP/siteabbrfunctionnumber.int.ourdomain.com@INT.OURDOMAIN.COM" is the correct SPN for this service, then that should be enough.
If the service principal name is the same as the client-requested HTTP Host (which it isn't in your case), you can use the %h option in the SPN Pattern field. Example: "HTTP/%h@INT.OURDOMAIN.COM".
If the service principal is something completely different, and unique per server, you can use a local Hosts entry on the F5 and the %s option in the SPN Pattern field. So for example, "HTTP/%s@INT.OURDOMAIN.COM", where %s resolves the pool member IP to an entry in the Hosts file.
And if all services use the same principal name (because they use the same service account), you can simply type in a static SPN in the SPN Pattern field. Example, "HTTP/myservice.int.ourdomain.com@INT.OURDOMAIN.COM".
Most important though, the correct service principal name for the service isn't necessarily the name of the box. It depends on the account that owns the application service you're trying to authenticate to. If these are Windows servers, and the application service is owned by the machine account, the the SPN would indeed be based on the name of the box. If the application service is owned by a separate account, then the SPN for the service is that account's SPN.
Thanks so much! That explains alot! All of these services are running as the "App pool" I believe not a particular service account. However if we did this same practice to say Sharepoint which uses host names for site rendering and its running under a service account, is that where I would need to configure that account for delegation and add a SPN for it in particular? Is there a good Kerb reference you would recommend? I have a feeling this could get really complicated, and I do not want to unknowingly do something that would end up passing out "golden tickets" LOL! Many thanks for your help so far!!
However if we did this same practice to say Sharepoint which uses host names for site rendering and its running under a service account, is that where I would need to configure that account for delegation and add a SPN for it in particular?
Yes. You just have to make sure that APM is requesting a ticket for the correct service principal name.
Is there a good Kerb reference you would recommend?
The Kerberos RFCs (1510 and 4120) are a great (albeit dry) place to start, plus there a few books on Amazon that give it decent coverage.
