Need help configuring Active Directory for User Authentication WITH SSL
On our F5 BIG-IP LTM (running 10.2.1) We are able to get Active Directory user authentication without SSL to work, but are having trouble getting it to work correctly with SSL. I have a suspicion that this has to do with the keys. I've entered them and even imported them as trusted device certificates, but I am still unable to get them working correctly. Is there a specific format that they should be in? I've tried PKCS12, PKCS7, and DER. auth ldap system-auth { bind-dn "cn=\"LDAP Account\",ou=\"Service ACC\",dc=my,dc=lovely,dc=com" bind-pw ******** login-attribute samaccountname port ldaps search-base-dn dc=my,dc=lovely,dc=com servers { MYDC03.my.lovely.com } ssl enabled ssl-ca-cert-file /etc/keys/ca.cer ssl-client-cert /etc/keys/ldaps.crt ssl-client-key /etc/keys/ldaps.key user-template %s@my.lovely.com } *Names, passwords, and domains have been changed for security.
Error When Executing LDAP iApp - Need Assistance
When running the built-in LDAP iApp on a cluster running 11.4.1 I receive the error below. I am creating a new LDAP/s virtual server where SSL is terminated on the F5, then plain text to the domain controllers. I have an existing regular LDAP pool with an existing LDAP monitor associated to it. I have the options in the new LDAP config use that existing pool and the same associated health monitor. This should be possible should it not? Any help is appreciated. script did not successfully complete: (can't read "::app_health__monitor": no such variable while executing "subst $substa_out" invoked from within "if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] set substa_out [subst $substa_out] } else { ..." ("uplevel" body line 3) invoked from within "uplevel { append ::substa_debug "\n$substa_in" if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] ..." (procedure "iapp::substa" line 9) invoked from within "iapp::substa monitor($create_new_monitor)" invoked from within "iapp::conf create ltm pool ${app}_pool [iapp::substa pool_lb_method($advanced,$is_edge)] [iapp::pool_members $::vs_pool__pool_members -fields {conn..." invoked from within "subst $substa_out" invoked from within "if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] set substa_out [subst $substa_out] } else { ..." ("uplevel" body line 3) invoked from within "uplevel { append ::substa_debug "\n$substa_in" if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] ..." (procedure "iapp::substa" line 9) invoked from within "iapp::substa pool($create_new_pool)" (procedure "configure_ldap_deployment" line 178) invoked from within "configure_ldap_deployment" invoked from within "subst $substa_out" invoked from within "if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] set substa_out [subst $substa_out] } else { ..." ("uplevel" body line 3) invoked from within "uplevel { append ::substa_debug "\n$substa_in" if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] ..." (procedure "iapp::substa" line 9) invoked from within "iapp::substa main($do_v11_3,$upgrade,$downgrade)" line:446)
F5 APM - Active Directory AAA profile and port 636 w/ SSL
As you probably already know, Microsoft is enforcing all LDAP binds to require a secure channel binding or LDAPS in March 2020. This means port 389 for LDAP queries will fail after the March Windows patch is deployed. Our ActiveSync and OWA Exchange VIPs were deployed using the Exchange iApp and have Active Directory AAA profiles for access through the APM. I've looked through the profile settings and do not see where to change the port from 389 to 636. How do we force the Active Directory AAA profiles to use 636 with SSL? https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-update/ba-p/921536 Edit: Did see another post regarding this and found this article that states no changes are necessary for Active Directory profiles? https://support.f5.com/csp/article/K30054212
LDAPS LTM - SSL Offloading and Re-Encrypt not working
Hi All, I received the question to make a VIP for LDAPS traffic but i stumble on some issues which i don't know how to solve. VIP is listening on port 636 with client SSL profile assigned to it and we have as well a server SSL profile assigned for re-encypting to the backend servers. After some test runs with the users and doing some dumps we can't seem to get it working and i am not sure if i missed something on my end or something missing on the backend servers (i don't have control/access on those servers). Clients --> VIP (no SSL) --> BACKEND --> OK Clients --> VIP (client-ssl) --> BACKEND --> NOK Clients --> VIP (client-ssl + server-ssl) --> BACKEND --> NOK The content of the certificate is just the URL name of the VIP (client-ssl profile) and for the other server-ssl we used both option with NO certificate and the same certificate content as in the client-ssl profile. TCPDUMP shows that the SSL negotiation on clients side is OK but as soon as the re-encryption is initiated at the "client-hello" we see RST ACK from one of the backend servers. So i am not sure if the content of the certificate is the problem here (but then it's the same result with server-ssl profile without cert. content) or something wrong on the backend server(s). Googling did not really help me on this topic as everything i found was either OLD or did not contain the useful information. Cipher strings are all set to DEFAULT to avoid compatibility issues and we even forced TLS1.0 only as well to exclude an issue on the protocol. BIG-IP 13.1.0.8 Build 0.0.3 Point Release 8
LDAPS VIP not working
Hi all, Recently after upgrading our f5 vcmp guest from 11.2.1 to 11.4.1 HF3, the ldap virtual server stopped working. Although the VS is showing as UP & traffic flow is shown as fine, Application teams got the error of "LDAPS Handshake not completed" in their error logs. After we rolled back to 11.2.1, it started working again. Has any one faced this type of issue earlier in 11.4.1..? Is it a kind of bug.? Or working difference in 11.4.1..? Regards Narendra