Forum Discussion

Slayer001's avatar
Slayer001
Icon for Cirrus rankCirrus
Jan 06, 2020
Solved

AD authentication with LDAPS

Is it possible to create a layered Virtual Server to intercept the LDAP request towards the AD DC's and use LDAPS for the connection?

We need to have LDAPS (TCP-636) for the AD auth instead of the default LDAP (TCP-389) as an upcoming Microsoft patch will disable simple/unsigned AD queries. We can't use LDAP Authentication as we need the PW reset option that comes with the AD auth/query.

 

Anyone found a workaround for this?

  • Been some time but didn't have time to test it out. I tried with Pool but same result.

    Logged a support case and they confirmed it's not possible with AD auth. They said they know the security patch is coming and are working on something. It should be there before the Microsoft security patch is released.

14 Replies

  • Hello,

     

    That's what I was trying but the traffic is not being send to that "internal" VS with serverssl profile but it's trying to find the IP of that VS somewhere else on the network via it's routing table and doesn't use the internal virtual address with ARP turned off.

     

    First it tries to connect on port 88 for Kerberos but that fails as it can't find the IP of the VS and hence the traffic is not send towards the pool members (the real AD servers).

     

    Is there anything special that needs to be done to send the traffic towards the internal VS? Or is it not possible to use a internal VS in the Direct AD auth settings? If it's possible with AD auth based on a pool. I can create a pool with the internal VS as it's only member?

     

    I know these articles exist for HTTPS authentication but never found anything similar for AD so I'm wondering if it is even possible.

    • Mitheor's avatar
      Mitheor
      Icon for Cirrus rankCirrus

      Hi,

       

      just in case, are these auth request being processed in any way by the F5 (fe APM users) or only packets that the F5 is balancing/forwarding?

  • This is used for authenticating users in an APM policy. So the internal VS is defined in the settings of a new object under Access --> Authentication --> AD

    • Mitheor's avatar
      Mitheor
      Icon for Cirrus rankCirrus

      Hi,

       

      so, let me see if i understand it correctly.

       

      You´ve created an access policy that uses an AAA (AD) object that points to a Virtual Server but the packet is not being processed by that same VS?

       

      If that´s the case, have you collected any logs of any AAA request?

  • There is a VS1 that has an APM policy that uses an AAA (AD) object to authenticate users.

     

    I created a separate internal VS2 with ARP off on the virtual address (Layered VS in F5 terms). This layered VS is setup with a server ssl profile and contains a pool with the real AD servers as members.

     

    In the APM AAA (AD) object used in the APM policy on VS1 I used the IP address of VS2 in order to be able to do LDAPS requests to the backend AD servers.

     

    Then when I test with adtest tool or even by trying to authenticate to VS1 I see the packets being sent towards the MAC address of the next hop and not towards VS2? Why isn't it sent to the internal VS2?

     

    In the logs it's shown that the F5 tried to reach the AD server but not KDC principal name was found

     

    Can you understand the setup now?

  • At the moment it is set to "Direct".

     

    The article you linked is for LDAP authentication with an LDAP AAA object, not AD AAA object. We want to be able to use the password change option which is only available with the AD auth/query that needs the AD AAA object.

    As a sidenote with LDAP AAA object : In newer versions you don't even need the extra VS for doing LDAPS. It works by selecting LDAPS in the AAA object.

     

    I tried with LDAP AAA object but then the password change page doesn't come up if the authenticating user wants to change his/her password.

    • Mitheor's avatar
      Mitheor
      Icon for Cirrus rankCirrus

      Hi,

       

      "The article you linked is for LDAP authentication, not AD"

       

      Yeah, i know. I just think it should be almost the same scenario (configuration wise).

       

      If possible i´d try to config the IP via pool instead of Direct.

       

      Other than that, i´m sorry but i don´t understand why it´s not happening.

       

      As said, i´ll try to test it if i have time later.

       

      Br

  • I had this same issue in the past. The issue was resolved by creating SRV TCP & UDP records for Kerberos to point to the VIP I needed.

    -Does the AD test tool statically point to an IP? Secondly, is the workstation that you are testing with joined to a domain? If so, the group policy assigns which AD server / IP you will perform AAA queries against.

     

    Based on your "Realm" error, have you tried configuring the krb5.conf("keytab") file?

    Link: https://support.f5.com/csp/article/K17976428

  •  Are you referring to the SPN records on the AD with SRV TCP & UDP? Or separate VS'es on the F5?

    I thought you only needed to adapt the crontab file if you want F5 to be able to do SSO with kerberos to the backend servers.

    AD auth is still working at the moment but it's using LDAP instead of LDAPS. We need to have LDAPS as LDAP will not work anymore after an upcoming update on our domain controllers .

     

     I'll try with a pool instead of direct and post the outcome here

  • Been some time but didn't have time to test it out. I tried with Pool but same result.

    Logged a support case and they confirmed it's not possible with AD auth. They said they know the security patch is coming and are working on something. It should be there before the Microsoft security patch is released.

    • rduque481's avatar
      rduque481
      Icon for Nimbostratus rankNimbostratus

        Did you hear any update from microsoft about this?

      I currently have an ldap vip (using the ldap iapp) using port 386. Can i just stand up another virtual server using hte vip but using port 636? and if so how do i assign our CA cert to it?