AD authentication with LDAPS

Hi,

shouldn´t this be solved by redirecting this traffic to a VS with SSL server termination?

There are some docs about this:

https://techdocs.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-11-5-0/4.html

https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-11-6-0/12.html

https://support.f5.com/csp/article/K11761

Hope this helps.

Br

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.

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

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.

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

Same boat and trying to figure this out. Any updates please?