Forum Discussion

Josh_Becigneul_'s avatar
Josh_Becigneul_
Icon for Nimbostratus rankNimbostratus
Feb 27, 2014

APM AD auth and multi-domain forest

Hi All, Let me preface this by saying that I am a Linux guy who pokes at Active Directory once in a blue moon.

I've been trying to work through this problem but so far have not had any great results. I have a client whose AD environment has multiple domains that belong to the same forest. Each domain has its own set of AD servers, and the client wants users from any domain to be able to authenticate to APM protected services. Unfortunately, if I use tools such as ldapsearch to query for users from a particular domain against a server for "my" domain (the one the F5 has credentials in), I get a referral. The F5 seems unable to chase the referral.

A potential complication is that this system is also running route domains and the customer's environment is not in RD 0. For single domain clients this works just fine, so I do not know if this is a factor.

What is the best way to teach the F5 about multiple AD domains/realms?

This is a sample error:

AD module: Domain Controller is not specified for domain 'FOO.BAR.COM', KDCs will be discovered using DNS
AD agent: Auth (logon attempt:0): authenticate with 'svc_f5' failed
Session variable 'session.ad.last.errmsg' set to 'Realm not local to KDC, principal name: svc_f5@FOO.BAR.COM@BAR.COM. Realm not found. Please verify Domain Name configured.'

Some detail about the setup:

Split domain from username is enabled in the Logon Page object. Cross domain authentication is enabled in the AD Auth object.

Example domains:

bar.com

foo.bar.com

My F5's admin account is "svc_f5.foo.bar.com". This account seems to have rights to query any of the domain controllers that I have tried to use.

Server A knows about "bar.com". Server B knows about "foo.bar.com". Either server seems unwilling to answer queries for the other domain.

Since I can only select one domain in an AD AAA resource, my thinking now is to do a match in the VPE based on the domain provided by the client and then present the appropriate AD Auth config, but this adds much complexity.

Any advice is greatly appreciated!!

Thanks, Josh

4 Replies

  • Check your DNS. Each domain needs to be reverse resolvable. If you can't configure that you can specify the Kdc Servers in /etc/krb5.conf

     

    Then is the userprincipalname ad attribute configured correctly? Should be host/svc_f5.foo.bar.com@foo.bar.com

     

    Setting it up that will then Kerberos delegation will work with all trusted forests and constrained delegation within the bar.com forest

     

  • I'll double check DNS. This device is multi-tenant so getting the management partition/RD talking to the customer environment may be a bit tricky.

    I don't think constrained delegation comes into play here. The VPE only has:

    Login Page -> AD Auth -> Assign Resources -> Allow
                         \->                     Deny
    
  • Talked this over with my friendly neighborhood AD expert, and he helped me figure out a working solution.

     

    Since the various domains/realms won't answer queries for other domains, I have used a empty object in my VPE with a branch for each domain that inspects session.logon.last.domain to get the domain provided by the end user (Split domain from username is enabled). This then feeds into a bunch of AD auth objects, tailored for each realm required. I use a macro after that for the resource assignment.

     

    HTH

     

    Josh

     

  • Thanks for sharing the solution Josh!

     

    I was wondering if there could be a way to somehow script the VPE Access Policy to only have single branch for the Logon Page --> AD Auth --> ... but to somehow dynamically set the AAA AD server to be used on the AD Auth box based on a pre-defined list of which domain uses which AD Server (actually this info is already defined on the AD AAA server definitions). This way there would be a single AD Auth box on the VPE so it would simplify a lot the policy as you don't have to have own branches for every AD server.

     

    -Turo