Minimalistic LDAP(S) proxy (via Simple-Bind) with Base-DN rewrite
Problem this snippet solves: The outlined iRule can be used to access independent LDAP(S) instances behind a single Virtual Server using a single Base-DN. The iRule, will forward LDAP(S) requests to an additional LDAP(S) pool, if the Simple-Bind user account name matches the $static::other_domains list. The iRule would then translate the original Base-DN to the Base-DN matching the additional LDAP(S) instance. Note1: The iRule doesn't adjust ASN.1/BER structures. So the original and changed Base-DN MUST have the same length. You may have to add SPACE paddings to allign the lenght of the Base-DNs. Note2: The iRule wouldn't change the traffic for the default LDAP(S) instance. The traffic is passed through after the Simple-Bind request is completed. Note3: The iRule would translates just the LDAP requests destined to the Base-DN of the additional LDAP(S) instance. The retrived results could then be accessed using their original DNs. Cheers, Kai How to use this snippet: Setup a standard Virtual Server for TCP:636. Apply SNAT and TCP profiles as needed. Apply client and server side SSL profiles. The server side SSL profile has to support both instances. Assign the default LDAP(S) instance as default_pool. Tweak the RULE_INIT event to match your environment. Code : when RULE_INIT { # # Minimalistic LDAP(S) proxy (via Simple-Bind) with Base-DN rewrite # # Configuration of the other LDAP(S) instance username prefix/suffixes set static::other_domains [list "itacs\\" "@itacs.de"];# List of lower case domain strings # Configuration of the other LDAP(S) instance pool name set static::other_ldaps_poolname OTHER_LDAPS_POOL_NAME;# Value of the other pool name # Configuration of the Base-DN translation strings # # Important: The Base-DNs MUST have the same lenght. # You have to pad SPACES to match the length # binary scan "OU=xyz,DC=your-domain,DC=tld" H* temp(dn_default) ;# This is the default Base-DN binary scan "OU=f5-team, DC=itacs, DC=de" H* temp(dn_other);# This is the other Base-DN. Pad SPACES to match the length set static::other_base_dn_map [list $temp(dn_default) $temp(dn_other)] unset -nocomplain temp } when CLIENTSSL_HANDSHAKE { # SSL session init set session_binding_ldap 1 set session_other_active 0 # Collecting SSL data SSL::collect } when CLIENTSSL_DATA { if { $session_binding_ldap } then { # Searching for simple Bind request to the other LDAP(S) instance set session_binding_ldap 0 foreach temp(domain_string) $static::other_domains { if { [string tolower [SSL::payload]] contains $temp(domain_string) } then { # Forwarding the request to the other LDAP(S) instance set session_other_active 1 pool $static::other_ldaps_poolname log -noname local0.debug "Bind request for other LDAP(S) instance detected. Forwarding the connection to pool [LB::server pool]" break } } if { $session_other_active == 0 } then { # Forwarding the request to the default LDAP(S) instance log -noname local0.debug "LDAPS request for default LDAP(S) instance detected. Forwarding the connection to pool [LB::server pool]" # Releasing SSL data SSL::release unset -nocomplain temp } } if { $session_other_active } then { # Translating Base-DNs for the other LDAP(S) instance binary scan [SSL::payload] H* temp(hex_ssl_payload) set temp(new_ssl_payload) [binary format H* [string map $static::other_base_dn_map $temp(hex_ssl_payload)]] SSL::payload replace 0 [string length [SSL::payload]] $temp(new_ssl_payload) # Releasing SSL data SSL::release # Collecting further SSL data SSL::collect unset -nocomplain temp } } Tested this on version: 12.0LDAP StartTLS Extension to LDAPS Proxy
Problem this snippet solves: The outlined iRule implements a LDAP StartTLS-Extension (see RFC2830) to traditional LDAPS proxy. The iRule can be used to add StartTLS-Extension support to LDAP instances, which do not support the StartTLS extension. The iRule will inspect the first TCP datagram for the LDAP-StartTLS request OID. If a StartTLS request is identified, the iRule will parse the ASN.1/BER structure of the LDAP request to extract the LDAP MessageID. Once the MessageID is extracted, the iRule will respond on behalf of the LDAP server with a LDAP response containing the request MessageID and StartTLS OID and then forward the remaining server side connection to a traditional LDAPS pool. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_ACCEPTED>: Client 172.21.92.28%1 is Connected to VS 172.21.17.211%1:389 Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_ACCEPTED>: Starting to collect LDAP TCP data. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Received LDAP TCP data. Searching for LDAP STARTTLS request OID. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Parsing 1st BER encoded message envelope (type and length). Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Checking 1st BER encoded message type = sequence (0x30). Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: 1st BER encoded message type is sequence (0x30). Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Checking if 1st BER encoded length value is a Multi-Byte length field. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Multi-Byte length field detected. Parsing the Multi-Byte length field value. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Adding the Multi-Byte length to scan offset. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Parsing 2nd BER encoded message envelope (type and length). Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Checking 2nd BER encoded message type = integer (0x02) Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: 1st BER encoded message type is integer (0x02). Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Checking if 1st BER encoded length value is a Multi-Byte length field. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Extracting 2nd BER encoded message value = MessageId. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Sending STARTTLS reply with matching LDAP MessageID to client. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Selecting LDAPS:683 pool. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Clearing the collected payload buffer. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Unset temporary array variable. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <CLIENT_DATA>: Releasing the connection. Mon Feb 29 09:41:42 CET 2016 debug f5-02 tmm1[2649] Rule /Common/LDAP_STARTTLS <SERVER_CONNECTED>: Client 172.21.92.28%1 is forwarded to 172.21.91.20%1:636 Cheers, Kai How to use this snippet: Usage: Create a new iRule and copy/paste the provided iRule into it. Modify the $static::ldaps_pool variable to match your LDAPS:636 pool name. Attach the iRule to your LDAP:386 Vitual Server. Test the iRule with an StartTLS aware LDAP client pointing to the LDAP:386 Vitual Server. Code : when RULE_INIT { set static::ldaps_pool "INSERT_YOUR_LDAPS_POOL_NAME" array set static::hex_filler { 1 "0000000" 2 "000000" 3 "00000" 4 "0000" 5 "000" 6 "00" 7 "0" 8 "" } } when CLIENT_ACCEPTED { log local0.debug "Client [IP::client_addr] is Connected to VS [IP::local_addr]:[TCP::local_port]" # log local0.debug "Starting to collect LDAP TCP data." TCP::collect } when CLIENT_DATA { # log local0.debug "Received LDAP TCP data. Searching for LDAP STARTTLS request OID." if { [TCP::payload] contains "1.3.6.1.4.1.1466.20037" } then { if { [catch { # log local0.debug "Parsing 1st BER encoded message envelope (type and length)." binary scan [TCP::payload] H2c temp(ber_1_type) temp(ber_1_length) set temp(scan_offset) 2 # log local0.debug "Checking 1st BER encoded message type = sequence (0x30)." if { $temp(ber_1_type) eq "30" } then { # log local0.debug "1st BER encoded message type is sequence (0x30)." # log local0.debug "Checking if 1st BER encoded length value is a Multi-Byte length field." if { [expr { $temp(ber_1_length) & 0x80 }] } then { # log local0.debug "Multi-Byte length field detected. Parsing the Multi-Byte length field value." # Diabled: binary scan [TCP::payload] x$temp(scan_offset)H[expr { ($temp(ber_1_length) & 0x7F) * 2 }] temp(ber_1_mlength) # log local0.debug "Adding the Multi-Byte length to scan offset." incr temp(scan_offset) [expr { $temp(ber_1_length) & 0x7F }] # Diabled: log local0.debug "Formating the received HEX string to numeric value." # Diabled: set temp(ber_1_length) [expr { [subst "0x$temp(ber_1_mlength)"] }] } # Diabled: log local0.debug "Extracting 1nd BER encoded message value = XXX." # Diabled: binary scan [TCP::payload] x$temp(scan_offset)H[expr { $temp(ber_2_length) * 2 }] temp(ber_2_value) # log local0.debug "Parsing 2nd BER encoded message envelope (type and length)." binary scan [TCP::payload] x$temp(scan_offset)H2c temp(ber_2_type) temp(ber_2_length) incr temp(scan_offset) 2 # log local0.debug "Checking 2nd BER encoded message type = integer (0x02)" if { $temp(ber_2_type) eq "02" } then { # log local0.debug "1st BER encoded message type is integer (0x02)." # log local0.debug "Checking if 1st BER encoded length value is a Multi-Byte length field." if { [expr { $temp(ber_2_length) & 0x80 }] } then { # log local0.debug "Multi-Byte length field detected. Parsing the Multi-Byte length field value." binary scan [TCP::payload] x$temp(scan_offset)H[expr { ($temp(ber_2_length) & 0x7F) * 2 }] temp(ber_2_mlength) # log local0.debug "Adding the Multi-Byte length to scan offset." incr temp(scan_offset) [expr { $temp(ber_2_length) & 0x7F }] # log local0.debug "Formating the received HEX string to numeric value." set temp(ber_2_length) [expr { [subst "0x$temp(ber_2_mlength)"] }] } # log local0.debug "Extracting 2nd BER encoded message value = MessageId." binary scan [TCP::payload] x$temp(scan_offset)H[expr { $temp(ber_2_length) * 2 }] temp(ber_2_value) # log local0.debug "Sending STARTTLS reply with matching LDAP MessageID to client." TCP::respond [binary format H* "30840000002B0204$static::hex_filler([string length $temp(ber_2_value)])$temp(ber_2_value)78840000001f0a0100040004008a16312e332e362e312e342e312e313436362e3230303337"] # log local0.debug "Selecting LDAPS:683 pool $static::ldaps_pool." pool $static::ldaps_pool # log local0.debug "Clearing the collected payload buffer." TCP::payload replace 0 [TCP::payload length] "" } } }]} then { log local0.debug "Parsing of BER encoded message envelope raised an error." log local0.debug "Extended ErrorInfo = [subst "\$::errorInfo"]" } # log local0.debug "Unset temporary array variable." unset -nocomplain temp } # log local0.debug "Releasing the connection." TCP::release } when SERVER_CONNECTED { log local0.debug "Client [IP::client_addr] is forwarded to [LB::server addr]:[LB::server port]" } Tested this on version: 12.0
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
