Forum Discussion

Adrian_Ilias_33's avatar
Adrian_Ilias_33
Icon for Nimbostratus rankNimbostratus
Oct 05, 2017

Alternate realm for a real domain in BIG-IP

We have an interesting problem after we implemented BIG-IP in our organization.

 

Situation: we have an AD forest with one top level domain (mycompany.local) and 10 child sub-domains (one is com.mycompany.local). We have an integration of our Exchange server with Microsoft Office 365 using the users UPN in the form firstname.lastname@anothername.com. The "anothername.com" is defined in AD as an UPN Suffix, but, in the same time, we have the AD domain anothername.com as a real AD domain and it have "Forest-Transitive-Two way" trust with mycompany.local domain.

 

The problem rise for our external users that have Microsoft Outlook on their laptops. When they are outside of our network and Outlook try to connect to our internal Exchange through BIG-IP appliance the request come with anothername.com realm. So, the kerberos authentication fails because the BIG-IP send the authentication request to the PDC of anothername.com AD domain (the error is "wrong realm" in Wireshark).

 

If we try a testing kerberos authentication session using mycompany.local realm, the request is redirected to the anothername.com (maybe because of the AD trust?) and then arrive again on the same PDC as above.

 

If instead, we try the authentication using the sub-domain com.mycompany.local as realm, the request finish with success (even if the AD user account is not from the com.mycompany.local domain, the request is redirected to the correct sub-domain and after that is accepted).

 

Because we can't change the way Outlook send the request (the "anothername.com" realm is needed by Office 365 integration), it is possible to "tell" to BIG-IP to send the received request using this realm to the com.mycompany.local alternate realm? Or what other solution do we have?

 

3 Replies

  • Hi Adrian,

     

    If on your F5 you have the APM and a VPE with "Kerberos Auth" you can choose which Kerberos Server should manage the authentication.

     

    So I think it is possbile (never tested), you only need to create two AAA Kerberos objects one with the Auth Realm "com.mycompany.local" and another one for "anothername.com".

     

    Then from the VPE you can select which AAA server will handle requests.

     

    Hope it helps

     

    Regards

     

  • Hi,

    I don't understand the issue...

    when working with kerberos, 2 informations are used:

    • sAMAccountName
    • REALM

    these information are sent with a format like UPN but not UPN:

    sAMAccountName@REALM
    

    when working with Kerberos Auth:

    • the client requests the web site
    • the server requests a kerberos auth
    • the client requests to the KDC to get kerberos ticket.
    • the client requests the web site including the token
    • the server (here the F5) decrypt the token. if decryption successful, user is authenticated. there is no communication to the KDC from the server.