Forum Discussion

writemike's avatar
writemike
Icon for Nimbostratus rankNimbostratus
Oct 04, 2016

Kerberos AAA with multiple domains/realms

Hello, I have successfully setup Clientside Kerberos Authentication for an SWG lab by merging 5 keytab files into one (1 keytab per domain). Security wants to change the password of the 5x Kerberos Delegation Service Accounts which will require that a new keytab file be built.

 

Is there a way to replicate this configuration with only a single keytab entry to validate users tickets from all 5 domains/realms?

 

It is my understanding that the APM just matched the SPN in the keytab with the SPN in the ticket before trying to decrypt it. If the SPN doesn't match then the ticket can not be validated. Users could be coming from any of the 5 domains so their realm may or may not match the single SPN keytab when they all try to access the same resource (http/proxy.domain.com@REALM).

 

Thanks!

 

5 Replies

  • If you have APM configured with the multiple AAA's and SPN's I think you can have an APM policy built that won't need keytab files. That is quick off the top of my head, not having access to an example.

     

    But...I don't think needing a keytab was totally done away with.. I think there is a place in the GUI you can import your keytab??

     

    I will do a little research and get back to you.

     

  • Take a look at this Tech Article: https://devcentral.f5.com/articles/apm-cookbook-multiple-domain-authentication-part-1

     

    --Maybe this will give you some incite?

     

  • Thanks for your help Shaun. We are configured with just one Kerberos AAA object which contains a merged keytab file with SPNs for 5x domains. We definitely need a keytab file as it maps the SPN to a key which is used to decrypt the TGS provided by the client. The keytab is imported into the Kerberos AAA Object which is used by the Kerberos Auth Action in the VPE.

     

  • After doing a bit more research (ie, I asked an AD guy!), it appears that if a two-way trust exists between domains/forests, then when a client joined to domain1 asks the domain1 KDC for a TGS for a service in domain2, the domain1 KDC will refer you to the domain2 KDC to complete your request. In the end the klist command, on the client machine should have 2 TGT (domain1 and domain2) and a TGS for the service you are trying to access. This can all be done with a single SPN in the Keytab file as long as there is two-way trust between the domains/realms.

     

    That is my non-windows guy understanding. Please let me know where I'm incorrect because I would really like to understand this better.

     

    Thanks

     

  • Bare with me LOL... I'm pulling this from memory. -The way I am explaining this, should work for keytab and if one had APM.

     

    Your AD dude is right. Both domains have to trust each other.

     

    TGT = Ticket Granting Ticket SPN=Service Principle Name KDC=Domain Controller

     

    The F5 will be delegated the rights to grant TGT's on behalf of the Domain Controller for both domain via Username of Domain 1 and SPN from Domain 2.

     

    The application servers will have to have a service account configured (same as the F5 AAA account name or a unique); having a unique will help with password resets and fat finger mistakes by your application guys, when they stand up a new box. The SPN of the F5 account(I think) has to be specified in the Delegation of the Application service account under the "Delegation" tab in AD(if a unique account is used). All you have to specify is "HTTP" when it is one layer. F5 -> Application server if the Application server has to reach out to SQL servers or anything else that needs SSO(Single Sign on), you will have to specify those SPN's(Delegation Tab) as well on the Application service account.

     

    Keytab: F5 service account HTTP/SPNusername(can be the same as the service account name or unique) --Primary domain HTTP/SPNusername (of an account from the Second Domain that has TGT account rights -"Domain Admin" type rights)--Secondary Domain

     

    krb5.conf -- /etc/krb5.conf -https://support.f5.com/kb/en-us/solutions/public/13000/300/sol13399 **Has to be configured as well using the above URL as a reference. ( *Not used if one has APM )