Hi All,
First off, I am a beginner with OpenLDAP, so please bear with me as I try to explain what I am trying to achieve.
1) There are 2 Active Directory servers that I need to connect to. Both of these are NOT under my control. We shall call them AD1 and AD2 here.
2) I can connect to AD1 via testsaslauthd using both simple bind and saslbind using DIGEST-MD5.
2a) For simple bind, I know of an adminstrative read-only account that I use to perform the initial LDAP bind request in order to allow an LDAP searchRequest to authenticate any user with AD1. Below is a sample /etc/saslauthd.conf ( ldap_bind_dn and ldap_bind_pw altered slightly to protect the identity )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: sAMAccountName=%u ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
... and what was captured by tshark ( I included port 53 for DNS queries as it was essential for finding out why digest-uri was only IP addresses instead of the hostname later on ):
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 81336.300597 172.21.17.193 -> 172.21.128.49 TCP 76 44477 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50014473 TSecr=0 WS=128 81336.301498 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44477 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 81336.301626 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50014474 TSecr=0 81336.301840 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1) "CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple 81336.304464 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 81336.304559 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=74 Ack=23 Win=14720 Len=0 TSval=50014474 TSecr=5446546 81336.304930 172.21.17.193 -> 172.21.128.49 LDAP 139 searchRequest(2) "DC=ad1,DC=priv" wholeSubtree 81336.305702 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" | searchResDone(2) success 81336.305972 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(3) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" simple 81336.308982 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(3) success 81336.349661 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=231 Ack=152 Win=14720 Len=0 TSval=50014486 TSecr=5446547
2b) For saslbind using DIGEST-MD5, I have no need for the administrative read-only account, as shown below by my /etc/saslauthd.conf: ( saslauthd was restarted in each case when saslauthd.conf was changed )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 7.488292 172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 7.489163 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 7.489258 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 7.489757 172.21.17.193 -> 172.21.10.24 DNS 88 Standard query PTR 49.128.21.172.in-addr.arpa 7.490577 172.21.10.24 -> 172.21.17.193 DNS 120 Standard query response PTR aassydc01.ad1.priv 7.492610 172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>" sasl 7.493828 172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1) saslBindInProgress 7.493928 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 7.494828 172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>" sasl 7.498503 172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success 7.536572 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
All good so far with simple bind and saslauthd to AD1.
3) I can only connect to AD2, the second active directory server, via testsaslauthd using only sasl bind.
That is because I do not know of an adminstrative read-only account in AD2 that I can use to perform the initial LDAP bindRequest in order to allow an LDAP searchRequest. Here is the /etc/saslauthd.conf for saslbind to AD2:
################################################################### #/etc/saslauthd.conf # Your AD server adress # NOTE: This will only work IFF there is also a reverse DNS entry for this A record # Otherwise, the digest-uri in the LDAP SASL bind request will only contain the IP address instead of the hostname # which will result in "The digest-uri does not match any LDAP SPN's registered for this server" ldap_servers: ldap://ad2idcdc11.au.ad2.corp:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_start_tls: no ldap_version: 3 ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u anotheruser -p otherpassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 321.883648 172.21.17.193 -> 10.3.90.55 TCP 76 49226 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50161583 TSecr=0 WS=128 321.884343 10.3.90.55 -> 172.21.17.193 TCP 80 msft-gc > 49226 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 321.884541 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50161583 TSecr=0 321.886323 172.21.17.193 -> 10.3.90.55 LDAP 94 bindRequest(1) "<ROOT>" sasl 321.887247 10.3.90.55 -> 172.21.17.193 LDAP 329 bindResponse(1) saslBindInProgress 321.887336 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=27 Ack=262 Win=15744 Len=0 TSval=50161584 TSecr=65953794 321.888296 172.21.17.193 -> 10.3.90.55 LDAP 447 bindRequest(2) "<ROOT>" sasl 321.892567 10.3.90.55 -> 172.21.17.193 LDAP 132 bindResponse(2) success 321.933533 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=406 Ack=326 Win=15744 Len=0 TSval=50161596 TSecr=65953794
4) I am using SASL because I currently have Subversion 1.8 configured to use SASL to authenticate users to AD1, but currently using simple bind. I will be changing this later on so that saslauthd will use sasl bind to AD1.
$ cat /etc/sasl2/svn.conf pwcheck_method: saslauthd mech_list: PLAIN
----------------------------------------------------- Now here is what I am trying to achieve with OpenLDAP:
I am using slapd.conf. I am also using the meta backend, as my instance of OpenLDAP will not really have its own LDAP database as I intended to use OpenLDAP for pass-through authentication.
5) I am able to use OpenLDAP as a proxy to AD1 for pass-through authentication via the meta backend, but only if OpenLDAP is configured to use simplebind to AD1. That is: testsaslauthd ( simple bind ) -> OpenLDAP ( simple bind ) -> AD1.
Here is my /etc/ldap/slapd.conf:
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 #########################################################################
.. and here is my /etc/saslauthd.conf for this specific test: ( The only difference between this and [2a] is the ldap_servers entry, which now points to OpenLDAP, and the ldap_filter, which now has an OR condition )
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: (|(uid=%U)(sAMAccountName=%U)) ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 1310.330189 127.0.0.1 -> 127.0.0.1 TCP 76 50279 > ldap [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128 1310.330234 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50279 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695 TSecr=50408695 WS=128 1310.330262 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSval=50408695 TSecr=50408695 1310.330612 127.0.0.1 -> 127.0.0.1 LDAP 141 bindRequest(1) "CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple 1310.330640 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50279 [ACK] Seq=1 Ack=74 Win=32768 Len=0 TSval=50408695 TSecr=50408695 1310.331106 172.21.17.193 -> 172.21.128.49 TCP 76 44485 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128 1310.332041 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44485 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 1310.332129 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50408695 TSecr=0 1310.332239 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1) "cn=administrativero,ou=Service_Accounts,dc=ad1,dc=priv" simple 1310.335445 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 1310.335575 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=74 Ack=23 Win=14720 Len=0 TSval=50408696 TSecr=5462316 1310.336554 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(1) success 1310.336634 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=74 Ack=15 Win=32896 Len=0 TSval=50408697 TSecr=50408697 1310.336863 127.0.0.1 -> 127.0.0.1 LDAP 157 searchRequest(2) "DC=ad1,DC=priv" wholeSubtree 1310.337809 172.21.17.193 -> 172.21.128.49 LDAP 157 searchRequest(2) "dc=ad1,dc=priv" wholeSubtree 1310.339277 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" | searchResDone(2) success 1310.339581 127.0.0.1 -> 127.0.0.1 LDAP 141 searchResEntry(2) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" 1310.339871 127.0.0.1 -> 127.0.0.1 LDAP 82 searchResDone(2) success 1310.339966 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=163 Ack=102 Win=32896 Len=0 TSval=50408697 TSecr=50408697 1310.340053 127.0.0.1 -> 127.0.0.1 LDAP 154 bindRequest(3) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple 1310.340698 172.21.17.193 -> 172.21.128.49 TCP 76 44486 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408698 TSecr=0 WS=128 1310.341883 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44486 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 1310.341977 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50408698 TSecr=0 1310.342157 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(1) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple 1310.345643 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 1310.345733 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK] Seq=87 Ack=23 Win=14720 Len=0 TSval=50408699 TSecr=5462316 1310.346198 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(3) success 1310.377558 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=163 Ack=130 Win=14720 Len=0 TSval=50408707 TSecr=5462316 1310.384549 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=249 Ack=116 Win=32896 Len=0 TSval=50408709 TSecr=50408699
You can see from the above that: * The initial administrative simple bind to OpenLDAP was delegated by OpenLDAP to AD1. * The searchRequest to OpenLDAp was delegated by OpenLDAP to AD1. * The second bindRequest ( that is authenticating the user that I specified with testsaslauthd ) to OpenLDAP was delegated by OpenLDAP to AD1.
That is, on all 3 cases above, OpenLDAP only returned success back to testsaslauthd only if AD1 only returned success. So far so good.
6) I am unable to use ... or rather confused on how to use .. OpenLDAP as a proxy to AD1 so that OpenLDAP will use sasl bind to AD1.
This is where I am stuck. Here is my /etc/saslauthd.conf for this test: The only difference between this and saslauthd.conf in [2b] is the ldap_servers entry, which is now pointing to OpenLDAP.
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
Here is my /etc/ldap/slapd.conf for this test: ( The only difference between this file and the slapd.conf file in [5] is the addition of the idassert-bind line )
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 idassert-bind bindmethod=sasl saslmech=DIGEST-MD5 mode=none #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: NO "authentication failed"
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 401.111261 127.0.0.1 -> 127.0.0.1 TCP 76 50299 > ldap [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330 TSecr=0 WS=128 401.111304 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50299 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330 TSecr=51388330 WS=128 401.111332 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSval=51388330 TSecr=51388330 401.113332 127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl 401.113419 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50299 [ACK] Seq=1 Ack=27 Win=32768 Len=0 TSval=51388330 TSecr=51388330 401.113806 127.0.0.1 -> 127.0.0.1 LDAP 304 bindResponse(1) saslBindInProgress (SASL(0): successful result: ) 401.114023 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=27 Ack=237 Win=32768 Len=0 TSval=51388331 TSecr=51388330 401.114362 127.0.0.1 -> 127.0.0.1 LDAP 393 bindRequest(2) "<ROOT>" sasl 401.114671 127.0.0.1 -> 127.0.0.1 LDAP 130 bindResponse(2) invalidCredentials (SASL(-13): user not found: no secret in database) 401.153939 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=352 Ack=299 Win=32768 Len=0 TSval=51388341 TSecr=51388331
As you can see from the above tshark, OpenLDAP did not even try to communicate at all to AD1 ! What should I have in slapd.conf ? Maybe the problem is that, I am using testsaslauthd, which uses saslauthd to connect to OpenLDAP, but also need OpenLDAP to use saslauthd to AD1 ( e.g. It is using the same saslauthd daemon ) ?
I also read about at ( Section 14.5 ):
http://www.openldap.org/doc/admin24/security.html ... about setting the userPassword attribute to something of the form:
userPassword: {SASL}user@realm ... but:
*) I am using a meta backend, and thus I have no internal users, so I cannot set the userPassword attribute .... or is this saying that I need a "copy" of the DN name of the users from AD1 to my local OpenLDAP ?
It also says:
"Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate **PROCESS** ( emphasis mine ). This uses the sasl_checkpass(3) function so it can use any back-end server that Cyrus SASL supports for checking passwords." .. but:
*) How was OpenLDAP able to delegate password verification in the simple-bind proxy as I have demonstrated above WITHOUT going through a separate proccess but going straight through a TCP/IP connection ? *) Is the statement saying that OpenLDAP will use saslauthd to connect to a remote LDAP/AD ? If so, since I am using testsaslauthd and I am already using saslauthd to connect to OpenLDAP, and saslauthd.conf is configured to point to the local OpenLDAP, does this mean I need another instance of saslauthd with its own unix socket and its own saslauthd.conf ? If so, what's the point of having the uri in slapd.conf when the separate instance of saslauthd.conf will have its own entry of the remote ldap / AD1 anyway ?
Anyway, as you can see .. I am confused on how to do item [6] above. All I really need to happen is ( from a tcp capture / wireshark perspective ), something like ( similar to the simple bind PTA ):
127.0.0.1 -> 127.0.0.1 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 127.0.0.1 -> 127.0.0.1 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl 172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>" sasl 172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1) saslBindInProgress 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 326 bindResponse(1) saslBindInProgress 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 442 bindRequest(2) "<ROOT>" sasl 172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>" sasl 172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 132 bindResponse(2) success 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
7) If I can find out how to do item [6] above with help from this list, then I will try to do the same for AD2.
8) The end goal therefore is to use OpenLDAP as a dumb proxy that will authenticate users to either AD1 or AD2.
Any help / hints appreciated,
Jesus Salvo
2013/10/19 Jesus Jr M Salvo jesus.m.salvo@gmail.com
Hi All,
First off, I am a beginner with OpenLDAP, so please bear with me as I try to explain what I am trying to achieve.
- There are 2 Active Directory servers that I need to connect to. Both of
these are NOT under my control. We shall call them AD1 and AD2 here.
- I can connect to AD1 via testsaslauthd using both simple bind and
saslbind using DIGEST-MD5.
2a) For simple bind, I know of an adminstrative read-only account that I use to perform the initial LDAP bind request in order to allow an LDAP searchRequest to authenticate any user with AD1. Below is a sample /etc/saslauthd.conf ( ldap_bind_dn and ldap_bind_pw altered slightly to protect the identity )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: sAMAccountName=%u ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
... and what was captured by tshark ( I included port 53 for DNS queries as it was essential for finding out why digest-uri was only IP addresses instead of the hostname later on ):
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 81336.300597 172.21.17.193 -> 172.21.128.49 TCP 76 44477 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50014473 TSecr=0 WS=128 81336.301498 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44477 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 81336.301626 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50014474 TSecr=0 81336.301840 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1) "CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple 81336.304464 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 81336.304559 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=74 Ack=23 Win=14720 Len=0 TSval=50014474 TSecr=5446546 81336.304930 172.21.17.193 -> 172.21.128.49 LDAP 139 searchRequest(2) "DC=ad1,DC=priv" wholeSubtree 81336.305702 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" | searchResDone(2) success 81336.305972 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(3) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" simple 81336.308982 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(3) success 81336.349661 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=231 Ack=152 Win=14720 Len=0 TSval=50014486 TSecr=5446547
2b) For saslbind using DIGEST-MD5, I have no need for the administrative read-only account, as shown below by my /etc/saslauthd.conf: ( saslauthd was restarted in each case when saslauthd.conf was changed )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 7.488292 172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 7.489163 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 7.489258 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 7.489757 172.21.17.193 -> 172.21.10.24 DNS 88 Standard query PTR 49.128.21.172.in-addr.arpa 7.490577 172.21.10.24 -> 172.21.17.193 DNS 120 Standard query response PTR aassydc01.ad1.priv 7.492610 172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>" sasl 7.493828 172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1) saslBindInProgress 7.493928 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 7.494828 172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>" sasl 7.498503 172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success 7.536572 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
All good so far with simple bind and saslauthd to AD1.
- I can only connect to AD2, the second active directory server, via
testsaslauthd using only sasl bind.
That is because I do not know of an adminstrative read-only account in AD2 that I can use to perform the initial LDAP bindRequest in order to allow an LDAP searchRequest. Here is the /etc/saslauthd.conf for saslbind to AD2:
################################################################### #/etc/saslauthd.conf # Your AD server adress # NOTE: This will only work IFF there is also a reverse DNS entry for this A record # Otherwise, the digest-uri in the LDAP SASL bind request will only contain the IP address instead of the hostname # which will result in "The digest-uri does not match any LDAP SPN's registered for this server" ldap_servers: ldap://ad2idcdc11.au.ad2.corp:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_start_tls: no ldap_version: 3 ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u anotheruser -p otherpassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 321.883648 172.21.17.193 -> 10.3.90.55 TCP 76 49226 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50161583 TSecr=0 WS=128 321.884343 10.3.90.55 -> 172.21.17.193 TCP 80 msft-gc > 49226 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 321.884541 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50161583 TSecr=0 321.886323 172.21.17.193 -> 10.3.90.55 LDAP 94 bindRequest(1) "<ROOT>" sasl 321.887247 10.3.90.55 -> 172.21.17.193 LDAP 329 bindResponse(1) saslBindInProgress 321.887336 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=27 Ack=262 Win=15744 Len=0 TSval=50161584 TSecr=65953794 321.888296 172.21.17.193 -> 10.3.90.55 LDAP 447 bindRequest(2) "<ROOT>" sasl 321.892567 10.3.90.55 -> 172.21.17.193 LDAP 132 bindResponse(2) success 321.933533 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=406 Ack=326 Win=15744 Len=0 TSval=50161596 TSecr=65953794
- I am using SASL because I currently have Subversion 1.8 configured to
use SASL to authenticate users to AD1, but currently using simple bind. I will be changing this later on so that saslauthd will use sasl bind to AD1.
$ cat /etc/sasl2/svn.conf pwcheck_method: saslauthd mech_list: PLAIN
Now here is what I am trying to achieve with OpenLDAP:
I am using slapd.conf. I am also using the meta backend, as my instance of OpenLDAP will not really have its own LDAP database as I intended to use OpenLDAP for pass-through authentication.
- I am able to use OpenLDAP as a proxy to AD1 for pass-through
authentication via the meta backend, but only if OpenLDAP is configured to use simplebind to AD1. That is: testsaslauthd ( simple bind ) -> OpenLDAP ( simple bind ) -> AD1.
Here is my /etc/ldap/slapd.conf:
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 #########################################################################
.. and here is my /etc/saslauthd.conf for this specific test: ( The only difference between this and [2a] is the ldap_servers entry, which now points to OpenLDAP, and the ldap_filter, which now has an OR condition )
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: (|(uid=%U)(sAMAccountName=%U)) ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 1310.330189 127.0.0.1 -> 127.0.0.1 TCP 76 50279 > ldap [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128 1310.330234 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50279 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695 TSecr=50408695 WS=128 1310.330262 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSval=50408695 TSecr=50408695 1310.330612 127.0.0.1 -> 127.0.0.1 LDAP 141 bindRequest(1) "CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple 1310.330640 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50279 [ACK] Seq=1 Ack=74 Win=32768 Len=0 TSval=50408695 TSecr=50408695 1310.331106 172.21.17.193 -> 172.21.128.49 TCP 76 44485 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128 1310.332041 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44485 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 1310.332129 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50408695 TSecr=0 1310.332239 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1) "cn=administrativero,ou=Service_Accounts,dc=ad1,dc=priv" simple 1310.335445 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 1310.335575 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=74 Ack=23 Win=14720 Len=0 TSval=50408696 TSecr=5462316 1310.336554 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(1) success 1310.336634 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=74 Ack=15 Win=32896 Len=0 TSval=50408697 TSecr=50408697 1310.336863 127.0.0.1 -> 127.0.0.1 LDAP 157 searchRequest(2) "DC=ad1,DC=priv" wholeSubtree 1310.337809 172.21.17.193 -> 172.21.128.49 LDAP 157 searchRequest(2) "dc=ad1,dc=priv" wholeSubtree 1310.339277 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" | searchResDone(2) success 1310.339581 127.0.0.1 -> 127.0.0.1 LDAP 141 searchResEntry(2) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" 1310.339871 127.0.0.1 -> 127.0.0.1 LDAP 82 searchResDone(2) success 1310.339966 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=163 Ack=102 Win=32896 Len=0 TSval=50408697 TSecr=50408697 1310.340053 127.0.0.1 -> 127.0.0.1 LDAP 154 bindRequest(3) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple 1310.340698 172.21.17.193 -> 172.21.128.49 TCP 76 44486 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408698 TSecr=0 WS=128 1310.341883 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44486 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 1310.341977 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50408698 TSecr=0 1310.342157 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(1) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple 1310.345643 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 1310.345733 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK] Seq=87 Ack=23 Win=14720 Len=0 TSval=50408699 TSecr=5462316 1310.346198 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(3) success 1310.377558 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=163 Ack=130 Win=14720 Len=0 TSval=50408707 TSecr=5462316 1310.384549 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=249 Ack=116 Win=32896 Len=0 TSval=50408709 TSecr=50408699
You can see from the above that:
- The initial administrative simple bind to OpenLDAP was delegated by
OpenLDAP to AD1.
- The searchRequest to OpenLDAp was delegated by OpenLDAP to AD1.
- The second bindRequest ( that is authenticating the user that I
specified with testsaslauthd ) to OpenLDAP was delegated by OpenLDAP to AD1.
That is, on all 3 cases above, OpenLDAP only returned success back to testsaslauthd only if AD1 only returned success. So far so good.
- I am unable to use ... or rather confused on how to use .. OpenLDAP as
a proxy to AD1 so that OpenLDAP will use sasl bind to AD1.
This is where I am stuck. Here is my /etc/saslauthd.conf for this test: The only difference between this and saslauthd.conf in [2b] is the ldap_servers entry, which is now pointing to OpenLDAP.
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
Here is my /etc/ldap/slapd.conf for this test: ( The only difference between this file and the slapd.conf file in [5] is the addition of the idassert-bind line )
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 idassert-bind bindmethod=sasl saslmech=DIGEST-MD5 mode=none #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: NO "authentication failed"
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 401.111261 127.0.0.1 -> 127.0.0.1 TCP 76 50299 > ldap [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330 TSecr=0 WS=128 401.111304 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50299 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330 TSecr=51388330 WS=128 401.111332 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSval=51388330 TSecr=51388330 401.113332 127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl 401.113419 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50299 [ACK] Seq=1 Ack=27 Win=32768 Len=0 TSval=51388330 TSecr=51388330 401.113806 127.0.0.1 -> 127.0.0.1 LDAP 304 bindResponse(1) saslBindInProgress (SASL(0): successful result: ) 401.114023 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=27 Ack=237 Win=32768 Len=0 TSval=51388331 TSecr=51388330 401.114362 127.0.0.1 -> 127.0.0.1 LDAP 393 bindRequest(2) "<ROOT>" sasl 401.114671 127.0.0.1 -> 127.0.0.1 LDAP 130 bindResponse(2) invalidCredentials (SASL(-13): user not found: no secret in database) 401.153939 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=352 Ack=299 Win=32768 Len=0 TSval=51388341 TSecr=51388331
As you can see from the above tshark, OpenLDAP did not even try to communicate at all to AD1 ! What should I have in slapd.conf ? Maybe the problem is that, I am using testsaslauthd, which uses saslauthd to connect to OpenLDAP, but also need OpenLDAP to use saslauthd to AD1 ( e.g. It is using the same saslauthd daemon ) ?
I also read about at ( Section 14.5 ):
http://www.openldap.org/doc/admin24/security.html ... about setting the userPassword attribute to something of the form:
userPassword: {SASL}user@realm ... but:
*) I am using a meta backend, and thus I have no internal users, so I cannot set the userPassword attribute .... or is this saying that I need a "copy" of the DN name of the users from AD1 to my local OpenLDAP ?
It also says:
"Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate **PROCESS** ( emphasis mine ). This uses the sasl_checkpass(3) function so it can use any back-end server that Cyrus SASL supports for checking passwords." .. but:
*) How was OpenLDAP able to delegate password verification in the simple-bind proxy as I have demonstrated above WITHOUT going through a separate proccess but going straight through a TCP/IP connection ? *) Is the statement saying that OpenLDAP will use saslauthd to connect to a remote LDAP/AD ? If so, since I am using testsaslauthd and I am already using saslauthd to connect to OpenLDAP, and saslauthd.conf is configured to point to the local OpenLDAP, does this mean I need another instance of saslauthd with its own unix socket and its own saslauthd.conf ? If so, what's the point of having the uri in slapd.conf when the separate instance of saslauthd.conf will have its own entry of the remote ldap / AD1 anyway ?
Anyway, as you can see .. I am confused on how to do item [6] above. All I really need to happen is ( from a tcp capture / wireshark perspective ), something like ( similar to the simple bind PTA ):
127.0.0.1 -> 127.0.0.1 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 127.0.0.1 -> 127.0.0.1 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl 172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>" sasl 172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1) saslBindInProgress 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 326 bindResponse(1) saslBindInProgress 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 442 bindRequest(2) "<ROOT>" sasl 172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>" sasl 172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 132 bindResponse(2) success 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
- If I can find out how to do item [6] above with help from this list,
then I will try to do the same for AD2.
- The end goal therefore is to use OpenLDAP as a dumb proxy that will
authenticate users to either AD1 or AD2.
Any help / hints appreciated,
Hello,
A possible process is: LDAP Client ---BIND--> OpenLDAP ---sasl---> saslauthd ---BIND--> AD
You can find a how to here: http://ltb-project.org/wiki/documentation/general/sasl_delegation
Clément.
On 20 October 2013 00:00, Clément OUDOT clem.oudot@gmail.com wrote:
2013/10/19 Jesus Jr M Salvo jesus.m.salvo@gmail.com
Hi All,
First off, I am a beginner with OpenLDAP, so please bear with me as I try to explain what I am trying to achieve.
- There are 2 Active Directory servers that I need to connect to. Both
of these are NOT under my control. We shall call them AD1 and AD2 here.
- I can connect to AD1 via testsaslauthd using both simple bind and
saslbind using DIGEST-MD5.
2a) For simple bind, I know of an adminstrative read-only account that I use to perform the initial LDAP bind request in order to allow an LDAP searchRequest to authenticate any user with AD1. Below is a sample /etc/saslauthd.conf ( ldap_bind_dn and ldap_bind_pw altered slightly to protect the identity )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: sAMAccountName=%u ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
... and what was captured by tshark ( I included port 53 for DNS queries as it was essential for finding out why digest-uri was only IP addresses instead of the hostname later on ):
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 81336.300597 172.21.17.193 -> 172.21.128.49 TCP 76 44477 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50014473 TSecr=0 WS=128 81336.301498 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44477 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 81336.301626 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50014474 TSecr=0 81336.301840 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1) "CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple 81336.304464 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 81336.304559 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=74 Ack=23 Win=14720 Len=0 TSval=50014474 TSecr=5446546 81336.304930 172.21.17.193 -> 172.21.128.49 LDAP 139 searchRequest(2) "DC=ad1,DC=priv" wholeSubtree 81336.305702 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" | searchResDone(2) success 81336.305972 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(3) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" simple 81336.308982 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(3) success 81336.349661 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK] Seq=231 Ack=152 Win=14720 Len=0 TSval=50014486 TSecr=5446547
2b) For saslbind using DIGEST-MD5, I have no need for the administrative read-only account, as shown below by my /etc/saslauthd.conf: ( saslauthd was restarted in each case when saslauthd.conf was changed )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 7.488292 172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 7.489163 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 7.489258 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 7.489757 172.21.17.193 -> 172.21.10.24 DNS 88 Standard query PTR 49.128.21.172.in-addr.arpa 7.490577 172.21.10.24 -> 172.21.17.193 DNS 120 Standard query response PTR aassydc01.ad1.priv 7.492610 172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>" sasl 7.493828 172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1) saslBindInProgress 7.493928 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 7.494828 172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>" sasl 7.498503 172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success 7.536572 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
All good so far with simple bind and saslauthd to AD1.
- I can only connect to AD2, the second active directory server, via
testsaslauthd using only sasl bind.
That is because I do not know of an adminstrative read-only account in AD2 that I can use to perform the initial LDAP bindRequest in order to allow an LDAP searchRequest. Here is the /etc/saslauthd.conf for saslbind to AD2:
################################################################### #/etc/saslauthd.conf # Your AD server adress # NOTE: This will only work IFF there is also a reverse DNS entry for this A record # Otherwise, the digest-uri in the LDAP SASL bind request will only contain the IP address instead of the hostname # which will result in "The digest-uri does not match any LDAP SPN's registered for this server" ldap_servers: ldap://ad2idcdc11.au.ad2.corp:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_start_tls: no ldap_version: 3 ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u anotheruser -p otherpassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 321.883648 172.21.17.193 -> 10.3.90.55 TCP 76 49226 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50161583 TSecr=0 WS=128 321.884343 10.3.90.55 -> 172.21.17.193 TCP 80 msft-gc > 49226 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 321.884541 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50161583 TSecr=0 321.886323 172.21.17.193 -> 10.3.90.55 LDAP 94 bindRequest(1) "<ROOT>" sasl 321.887247 10.3.90.55 -> 172.21.17.193 LDAP 329 bindResponse(1) saslBindInProgress 321.887336 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=27 Ack=262 Win=15744 Len=0 TSval=50161584 TSecr=65953794 321.888296 172.21.17.193 -> 10.3.90.55 LDAP 447 bindRequest(2) "<ROOT>" sasl 321.892567 10.3.90.55 -> 172.21.17.193 LDAP 132 bindResponse(2) success 321.933533 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=406 Ack=326 Win=15744 Len=0 TSval=50161596 TSecr=65953794
- I am using SASL because I currently have Subversion 1.8 configured to
use SASL to authenticate users to AD1, but currently using simple bind. I will be changing this later on so that saslauthd will use sasl bind to AD1.
$ cat /etc/sasl2/svn.conf pwcheck_method: saslauthd mech_list: PLAIN
Now here is what I am trying to achieve with OpenLDAP:
I am using slapd.conf. I am also using the meta backend, as my instance of OpenLDAP will not really have its own LDAP database as I intended to use OpenLDAP for pass-through authentication.
- I am able to use OpenLDAP as a proxy to AD1 for pass-through
authentication via the meta backend, but only if OpenLDAP is configured to use simplebind to AD1. That is: testsaslauthd ( simple bind ) -> OpenLDAP ( simple bind ) -> AD1.
Here is my /etc/ldap/slapd.conf:
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 #########################################################################
.. and here is my /etc/saslauthd.conf for this specific test: ( The only difference between this and [2a] is the ldap_servers entry, which now points to OpenLDAP, and the ldap_filter, which now has an OR condition )
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: (|(uid=%U)(sAMAccountName=%U)) ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 1310.330189 127.0.0.1 -> 127.0.0.1 TCP 76 50279 > ldap [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128 1310.330234 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50279 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695 TSecr=50408695 WS=128 1310.330262 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSval=50408695 TSecr=50408695 1310.330612 127.0.0.1 -> 127.0.0.1 LDAP 141 bindRequest(1) "CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple 1310.330640 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50279 [ACK] Seq=1 Ack=74 Win=32768 Len=0 TSval=50408695 TSecr=50408695 1310.331106 172.21.17.193 -> 172.21.128.49 TCP 76 44485 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128 1310.332041 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44485 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 1310.332129 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50408695 TSecr=0 1310.332239 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1) "cn=administrativero,ou=Service_Accounts,dc=ad1,dc=priv" simple 1310.335445 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 1310.335575 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=74 Ack=23 Win=14720 Len=0 TSval=50408696 TSecr=5462316 1310.336554 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(1) success 1310.336634 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=74 Ack=15 Win=32896 Len=0 TSval=50408697 TSecr=50408697 1310.336863 127.0.0.1 -> 127.0.0.1 LDAP 157 searchRequest(2) "DC=ad1,DC=priv" wholeSubtree 1310.337809 172.21.17.193 -> 172.21.128.49 LDAP 157 searchRequest(2) "dc=ad1,dc=priv" wholeSubtree 1310.339277 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2) "CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" | searchResDone(2) success 1310.339581 127.0.0.1 -> 127.0.0.1 LDAP 141 searchResEntry(2) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" 1310.339871 127.0.0.1 -> 127.0.0.1 LDAP 82 searchResDone(2) success 1310.339966 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=163 Ack=102 Win=32896 Len=0 TSval=50408697 TSecr=50408697 1310.340053 127.0.0.1 -> 127.0.0.1 LDAP 154 bindRequest(3) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple 1310.340698 172.21.17.193 -> 172.21.128.49 TCP 76 44486 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408698 TSecr=0 WS=128 1310.341883 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44486 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 1310.341977 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50408698 TSecr=0 1310.342157 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(1) "cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple 1310.345643 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success 1310.345733 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK] Seq=87 Ack=23 Win=14720 Len=0 TSval=50408699 TSecr=5462316 1310.346198 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(3) success 1310.377558 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK] Seq=163 Ack=130 Win=14720 Len=0 TSval=50408707 TSecr=5462316 1310.384549 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=249 Ack=116 Win=32896 Len=0 TSval=50408709 TSecr=50408699
You can see from the above that:
- The initial administrative simple bind to OpenLDAP was delegated by
OpenLDAP to AD1.
- The searchRequest to OpenLDAp was delegated by OpenLDAP to AD1.
- The second bindRequest ( that is authenticating the user that I
specified with testsaslauthd ) to OpenLDAP was delegated by OpenLDAP to AD1.
That is, on all 3 cases above, OpenLDAP only returned success back to testsaslauthd only if AD1 only returned success. So far so good.
- I am unable to use ... or rather confused on how to use .. OpenLDAP as
a proxy to AD1 so that OpenLDAP will use sasl bind to AD1.
This is where I am stuck. Here is my /etc/saslauthd.conf for this test: The only difference between this and saslauthd.conf in [2b] is the ldap_servers entry, which is now pointing to OpenLDAP.
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
Here is my /etc/ldap/slapd.conf for this test: ( The only difference between this file and the slapd.conf file in [5] is the addition of the idassert-bind line )
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 idassert-bind bindmethod=sasl saslmech=DIGEST-MD5 mode=none #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: NO "authentication failed"
$ sudo tshark -i any port 3268 or port 53 or port 389 <...time elapsed .. snipped..> 401.111261 127.0.0.1 -> 127.0.0.1 TCP 76 50299 > ldap [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330 TSecr=0 WS=128 401.111304 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50299 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330 TSecr=51388330 WS=128 401.111332 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSval=51388330 TSecr=51388330 401.113332 127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl 401.113419 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50299 [ACK] Seq=1 Ack=27 Win=32768 Len=0 TSval=51388330 TSecr=51388330 401.113806 127.0.0.1 -> 127.0.0.1 LDAP 304 bindResponse(1) saslBindInProgress (SASL(0): successful result: ) 401.114023 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=27 Ack=237 Win=32768 Len=0 TSval=51388331 TSecr=51388330 401.114362 127.0.0.1 -> 127.0.0.1 LDAP 393 bindRequest(2) "<ROOT>" sasl 401.114671 127.0.0.1 -> 127.0.0.1 LDAP 130 bindResponse(2) invalidCredentials (SASL(-13): user not found: no secret in database) 401.153939 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=352 Ack=299 Win=32768 Len=0 TSval=51388341 TSecr=51388331
As you can see from the above tshark, OpenLDAP did not even try to communicate at all to AD1 ! What should I have in slapd.conf ? Maybe the problem is that, I am using testsaslauthd, which uses saslauthd to connect to OpenLDAP, but also need OpenLDAP to use saslauthd to AD1 ( e.g. It is using the same saslauthd daemon ) ?
I also read about at ( Section 14.5 ):
http://www.openldap.org/doc/admin24/security.html ... about setting the userPassword attribute to something of the form:
userPassword: {SASL}user@realm ... but:
*) I am using a meta backend, and thus I have no internal users, so I cannot set the userPassword attribute .... or is this saying that I need a "copy" of the DN name of the users from AD1 to my local OpenLDAP ?
It also says:
"Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate **PROCESS** ( emphasis mine ). This uses the sasl_checkpass(3) function so it can use any back-end server that Cyrus SASL supports for checking passwords." .. but:
*) How was OpenLDAP able to delegate password verification in the simple-bind proxy as I have demonstrated above WITHOUT going through a separate proccess but going straight through a TCP/IP connection ? *) Is the statement saying that OpenLDAP will use saslauthd to connect to a remote LDAP/AD ? If so, since I am using testsaslauthd and I am already using saslauthd to connect to OpenLDAP, and saslauthd.conf is configured to point to the local OpenLDAP, does this mean I need another instance of saslauthd with its own unix socket and its own saslauthd.conf ? If so, what's the point of having the uri in slapd.conf when the separate instance of saslauthd.conf will have its own entry of the remote ldap / AD1 anyway ?
Anyway, as you can see .. I am confused on how to do item [6] above. All I really need to happen is ( from a tcp capture / wireshark perspective ), something like ( similar to the simple bind PTA ):
127.0.0.1 -> 127.0.0.1 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 127.0.0.1 -> 127.0.0.1 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl 172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0 172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>" sasl 172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1) saslBindInProgress 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 326 bindResponse(1) saslBindInProgress 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 442 bindRequest(2) "<ROOT>" sasl 172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>" sasl 172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287 127.0.0.1 -> 127.0.0.1 LDAP 132 bindResponse(2) success 127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
- If I can find out how to do item [6] above with help from this list,
then I will try to do the same for AD2.
- The end goal therefore is to use OpenLDAP as a dumb proxy that will
authenticate users to either AD1 or AD2.
Any help / hints appreciated,
Hello,
A possible process is: LDAP Client ---BIND--> OpenLDAP ---sasl---> saslauthd ---BIND--> AD
You can find a how to here: http://ltb-project.org/wiki/documentation/general/sasl_delegation
Clément.
Hi there,
I actually used that link / your example as the basis for my tests. Thanks for the info you published.
From what I can summarise in your work, you have:
1) Pass-through authentication on one LDAP directory:
LDAP Client ---simple BIND--> OpenLDAP ---sasl---> saslauthd ---simple BIND--> AD
2) PTA on several LDAP directories --- with meta backend
LDAP Client ---sasl --- saslauthd --- simple BIND --> OpenLDAP ----simple BIND--> AD
3) PTA on several LDAP directories --- with ldap backend
LDAP Client ---sasl --- saslauthd --- simple BIND --> OpenLDAP ----simple BIND--> AD
However, the scenario that I want to achieve is that the client connecting to OpenLDAP must also use saslauthd, because that is the only way svnserve ( Subversion ) can talk to an LDAP directory. Also, because I can only talk to AD2 using sasl bind and NOT simple bind, I also have to use saslauthd to talk to AD2.
So what I really want to achieve is, using ASCII art / fixed width fonts:
LDAP Client ( e.g. svnserve / testsaslauthd ) ---sasl ---> saslauthd -> OpenLDAP
|------- sasl ---> saslauthd ---SASL BIND--> AD1
------- sasl ---> saslauthd ---SASL BIND--> AD2
The user that needs to be authenticated from the LDAP client ( e.g. svnserve / testsaslauthd ) is on either AD1 or AD2.
From what I can summarise, I will actually need three ( 3 ) saslauthd
processes, with different unix sockets, and with diference saslauthd.conf.
Is there a way for OpenLDAP to talk to another LDAP directory using SASL / DIGEST-MD5 without having to use saslauthd ?? So that, I only need one (1) saslauthd ( from svnserve to OpenLDAP ) ?
On 20 October 2013 09:26, Jesus Jr M Salvo jesus.m.salvo@gmail.com wrote:
Hi there,
I actually used that link / your example as the basis for my tests. Thanks for the info you published. From what I can summarise in your work, you have:
- Pass-through authentication on one LDAP directory:
LDAP Client ---simple BIND--> OpenLDAP ---sasl---> saslauthd ---simple BIND--> AD
- PTA on several LDAP directories --- with meta backend
LDAP Client ---sasl --- saslauthd --- simple BIND --> OpenLDAP ----simple BIND--> AD
- PTA on several LDAP directories --- with ldap backend
LDAP Client ---sasl --- saslauthd --- simple BIND --> OpenLDAP ----simple BIND--> AD
However, the scenario that I want to achieve is that the client connecting to OpenLDAP must also use saslauthd, because that is the only way svnserve ( Subversion ) can talk to an LDAP directory. Also, because I can only talk to AD2 using sasl bind and NOT simple bind, I also have to use saslauthd to talk to AD2.
So what I really want to achieve is, using ASCII art / fixed width fonts:
LDAP Client ( e.g. svnserve / testsaslauthd ) ---sasl ---> saslauthd -> OpenLDAP
|------- sasl ---> saslauthd ---SASL BIND--> AD1
------- sasl ---> saslauthd ---SASL BIND--> AD2
The user that needs to be authenticated from the LDAP client ( e.g. svnserve / testsaslauthd ) is on either AD1 or AD2.
From what I can summarise, I will actually need three ( 3 ) saslauthd processes, with different unix sockets, and with diference saslauthd.conf.
Is there a way for OpenLDAP to talk to another LDAP directory using SASL / DIGEST-MD5 without having to use saslauthd ?? So that, I only need one (1) saslauthd ( from svnserve to OpenLDAP ) ?
Sorry to the people list on the list ... I did not realise that gmail was NOT sending plain/text until I read my message in the list archive! ... I thought selecting "Remove Formatting" would send it as plain/text, but I have to select "More Options" and select "Plain text mode". Been a while since I used gmail to send to a mailing list.
Anyway, what I hope to achieve may not actually be possible ( PTA with SASL bind ). That is because, the first thing that happens with SASL bind, at least with DIGEST-MD5, is that:
1) LDAP client send bindRequest with mechanism ( no user or password or realm is sent yet ) 2) LDAP server returns the NONCE to the client ( bindInProgress ) 3) LDAP client sends another bindRequest with the credentials ( username, realm, and the NONCE ) -- bindInProgress 4) LDAP server returns either a success or invalidCredentials
Therefore, the proxy will not know what backend the client really wants to connect to until the [3] above.
Oh well.
On 10/19/13 20:46 +1100, Jesus Jr M Salvo wrote:
- There are 2 Active Directory servers that I need to connect to. Both of
these are NOT under my control. We shall call them AD1 and AD2 here.
- I can connect to AD1 via testsaslauthd using both simple bind and
saslbind using DIGEST-MD5.
2b) For saslbind using DIGEST-MD5, I have no need for the administrative read-only account, as shown below by my /etc/saslauthd.conf: ( saslauthd was restarted in each case when saslauthd.conf was changed )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
All good so far with simple bind and saslauthd to AD1.
- I can only connect to AD2, the second active directory server, via
testsaslauthd using only sasl bind.
That is because I do not know of an adminstrative read-only account in AD2 that I can use to perform the initial LDAP bindRequest in order to allow an LDAP searchRequest. Here is the /etc/saslauthd.conf for saslbind to AD2:
################################################################### #/etc/saslauthd.conf # Your AD server adress # NOTE: This will only work IFF there is also a reverse DNS entry for this A record # Otherwise, the digest-uri in the LDAP SASL bind request will only contain the IP address instead of the hostname # which will result in "The digest-uri does not match any LDAP SPN's registered for this server" ldap_servers: ldap://ad2idcdc11.au.ad2.corp:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_start_tls: no ldap_version: 3 ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u anotheruser -p otherpassword 0: OK "Success."
- I am using SASL because I currently have Subversion 1.8 configured to
use SASL to authenticate users to AD1, but currently using simple bind. I will be changing this later on so that saslauthd will use sasl bind to AD1.
$ cat /etc/sasl2/svn.conf pwcheck_method: saslauthd mech_list: PLAIN
Now here is what I am trying to achieve with OpenLDAP:
I am using slapd.conf. I am also using the meta backend, as my instance of OpenLDAP will not really have its own LDAP database as I intended to use OpenLDAP for pass-through authentication.
pass-through authentication will require you to have a specially formated userPassword entry, which you're not going to get from Active Directory. See:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
You'll need a local database which contains those entries.
If you don't really need pass-through authentication (if you don't need to perform simple binds), then that would simplify things for you.
- I am able to use OpenLDAP as a proxy to AD1 for pass-through
authentication via the meta backend, but only if OpenLDAP is configured to use simplebind to AD1. That is: testsaslauthd ( simple bind ) -> OpenLDAP ( simple bind ) -> AD1.
Why not have saslauthd communicate directly with AD1, instead of OpenLDAP?
Here is my /etc/ldap/slapd.conf:
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 #########################################################################
.. and here is my /etc/saslauthd.conf for this specific test: ( The only difference between this and [2a] is the ldap_servers entry, which now points to OpenLDAP, and the ldap_filter, which now has an OR condition )
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: (|(uid=%U)(sAMAccountName=%U)) ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
You can see from the above that:
- The initial administrative simple bind to OpenLDAP was delegated by
OpenLDAP to AD1.
- The searchRequest to OpenLDAp was delegated by OpenLDAP to AD1.
- The second bindRequest ( that is authenticating the user that I specified
with testsaslauthd ) to OpenLDAP was delegated by OpenLDAP to AD1.
That is, on all 3 cases above, OpenLDAP only returned success back to testsaslauthd only if AD1 only returned success. So far so good.
- I am unable to use ... or rather confused on how to use .. OpenLDAP as a
proxy to AD1 so that OpenLDAP will use sasl bind to AD1.
Use PLAIN sasl binds, and direct saslauthd to connect directly to AD1. Or use GSSAPI.
This is where I am stuck. Here is my /etc/saslauthd.conf for this test: The only difference between this and saslauthd.conf in [2b] is the ldap_servers entry, which is now pointing to OpenLDAP.
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
I'm dizzy. It appears you want pass-through authentication to speak with saslauthd, which in turn connects back to your slapd instance using DIGEST-MD5, which then proxies to AD. DIGEST-MD5 is going to fail because it's a shared secret mechanism, and slapd does not have access to the password.
See:
http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/components.php
Here is my /etc/ldap/slapd.conf for this test: ( The only difference between this file and the slapd.conf file in [5] is the addition of the idassert-bind line )
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 idassert-bind bindmethod=sasl saslmech=DIGEST-MD5 mode=none #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: NO "authentication failed"
As you can see from the above tshark, OpenLDAP did not even try to communicate at all to AD1 ! What should I have in slapd.conf ? Maybe the problem is that, I am using testsaslauthd, which uses saslauthd to connect to OpenLDAP, but also need OpenLDAP to use saslauthd to AD1 ( e.g. It is using the same saslauthd daemon ) ?
I also read about at ( Section 14.5 ):
http://www.openldap.org/doc/admin24/security.html ... about setting the userPassword attribute to something of the form:
userPassword: {SASL}user@realm ... but:
*) I am using a meta backend, and thus I have no internal users, so I cannot set the userPassword attribute .... or is this saying that I need a "copy" of the DN name of the users from AD1 to my local OpenLDAP ?
Yes, if you require pass-through authentication.
It also says:
"Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate **PROCESS** ( emphasis mine ). This uses the sasl_checkpass(3) function so it can use any back-end server that Cyrus SASL supports for checking passwords."
This is referring to your configured pwcheck_method.
.. but:
*) How was OpenLDAP able to delegate password verification in the simple-bind proxy as I have demonstrated above WITHOUT going through a separate proccess but going straight through a TCP/IP connection ?
If you mean this one:
ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
You are not actually performing a SASL authentication here. You are using the sasl_checkpass(3) call indirectly by calling testsaslauthd. saslauthd is performing a simple bind against AD.
The separate process in this case is saslauthd (prior to speaking with slapd). Think of pass-through authentication and testsaslauthd as performing similar functions in this visual picture (in that they call sasl_checkpass(3)).
*) Is the statement saying that OpenLDAP will use saslauthd to connect to a remote LDAP/AD ? If so, since I am using testsaslauthd and I am already using saslauthd to connect to OpenLDAP, and saslauthd.conf is configured to point to the local OpenLDAP, does this mean I need another instance of saslauthd with its own unix socket and its own saslauthd.conf ? If so, what's the point of having the uri in slapd.conf when the separate instance of saslauthd.conf will have its own entry of the remote ldap / AD1 anyway ?
Anyway, as you can see .. I am confused on how to do item [6] above. All I really need to happen is ( from a tcp capture / wireshark perspective ), something like ( similar to the simple bind PTA ):
- If I can find out how to do item [6] above with help from this list,
then I will try to do the same for AD2.
- The end goal therefore is to use OpenLDAP as a dumb proxy that will
authenticate users to either AD1 or AD2.
Using the krb5 backend to saslauthd may be more productive. It will require you to use PLAIN SASL authentication, as DIGEST-MD5 won't work. Or as mentioned above, you can perform GSSAPI SASL authentication and disregard saslauthd/pass-through authentication altogether.
Also take a look at slapo-pbind (5).
On 22 October 2013 02:05, Dan White dwhite@olp.net wrote:
On 10/19/13 20:46 +1100, Jesus Jr M Salvo wrote:
- There are 2 Active Directory servers that I need to connect to. Both of
these are NOT under my control. We shall call them AD1 and AD2 here.
- I can connect to AD1 via testsaslauthd using both simple bind and
saslbind using DIGEST-MD5.
2b) For saslbind using DIGEST-MD5, I have no need for the administrative read-only account, as shown below by my /etc/saslauthd.conf: ( saslauthd was restarted in each case when saslauthd.conf was changed )
################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
All good so far with simple bind and saslauthd to AD1.
- I can only connect to AD2, the second active directory server, via
testsaslauthd using only sasl bind.
That is because I do not know of an adminstrative read-only account in AD2 that I can use to perform the initial LDAP bindRequest in order to allow an LDAP searchRequest. Here is the /etc/saslauthd.conf for saslbind to AD2:
################################################################### #/etc/saslauthd.conf # Your AD server adress # NOTE: This will only work IFF there is also a reverse DNS entry for this A record # Otherwise, the digest-uri in the LDAP SASL bind request will only contain the IP address instead of the hostname # which will result in "The digest-uri does not match any LDAP SPN's registered for this server" ldap_servers: ldap://ad2idcdc11.au.ad2.corp:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_start_tls: no ldap_version: 3 ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u anotheruser -p otherpassword 0: OK "Success."
- I am using SASL because I currently have Subversion 1.8 configured to
use SASL to authenticate users to AD1, but currently using simple bind. I will be changing this later on so that saslauthd will use sasl bind to AD1.
$ cat /etc/sasl2/svn.conf pwcheck_method: saslauthd mech_list: PLAIN
Now here is what I am trying to achieve with OpenLDAP:
I am using slapd.conf. I am also using the meta backend, as my instance of OpenLDAP will not really have its own LDAP database as I intended to use OpenLDAP for pass-through authentication.
pass-through authentication will require you to have a specially formated userPassword entry, which you're not going to get from Active Directory. See:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
You'll need a local database which contains those entries.
If you don't really need pass-through authentication (if you don't need to perform simple binds), then that would simplify things for you.
- I am able to use OpenLDAP as a proxy to AD1 for pass-through
authentication via the meta backend, but only if OpenLDAP is configured to use simplebind to AD1. That is: testsaslauthd ( simple bind ) -> OpenLDAP ( simple bind ) -> AD1.
Why not have saslauthd communicate directly with AD1, instead of OpenLDAP?
Here is my /etc/ldap/slapd.conf:
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 #########################################################################
.. and here is my /etc/saslauthd.conf for this specific test: ( The only difference between this and [2a] is the ldap_servers entry, which now points to OpenLDAP, and the ldap_filter, which now has an OR condition )
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: (|(uid=%U)(sAMAccountName=%U)) ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
You can see from the above that:
- The initial administrative simple bind to OpenLDAP was delegated by
OpenLDAP to AD1.
- The searchRequest to OpenLDAp was delegated by OpenLDAP to AD1.
- The second bindRequest ( that is authenticating the user that I specified
with testsaslauthd ) to OpenLDAP was delegated by OpenLDAP to AD1.
That is, on all 3 cases above, OpenLDAP only returned success back to testsaslauthd only if AD1 only returned success. So far so good.
- I am unable to use ... or rather confused on how to use .. OpenLDAP as a
proxy to AD1 so that OpenLDAP will use sasl bind to AD1.
Use PLAIN sasl binds, and direct saslauthd to connect directly to AD1. Or use GSSAPI.
This is where I am stuck. Here is my /etc/saslauthd.conf for this test: The only difference between this and saslauthd.conf in [2b] is the ldap_servers entry, which is now pointing to OpenLDAP.
################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################
I'm dizzy. It appears you want pass-through authentication to speak with saslauthd, which in turn connects back to your slapd instance using DIGEST-MD5, which then proxies to AD. DIGEST-MD5 is going to fail because it's a shared secret mechanism, and slapd does not have access to the password.
See:
http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/components.php
Here is my /etc/ldap/slapd.conf for this test: ( The only difference between this file and the slapd.conf file in [5] is the addition of the idassert-bind line )
######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 idassert-bind bindmethod=sasl saslmech=DIGEST-MD5 mode=none #########################################################################
$ testsaslauthd -u salvojo -p mypassword 0: NO "authentication failed"
As you can see from the above tshark, OpenLDAP did not even try to communicate at all to AD1 ! What should I have in slapd.conf ? Maybe the problem is that, I am using testsaslauthd, which uses saslauthd to connect to OpenLDAP, but also need OpenLDAP to use saslauthd to AD1 ( e.g. It is using the same saslauthd daemon ) ?
I also read about at ( Section 14.5 ):
http://www.openldap.org/doc/admin24/security.html ... about setting the userPassword attribute to something of the form:
userPassword: {SASL}user@realm ... but:
*) I am using a meta backend, and thus I have no internal users, so I cannot set the userPassword attribute .... or is this saying that I need a "copy" of the DN name of the users from AD1 to my local OpenLDAP ?
Yes, if you require pass-through authentication.
It also says:
"Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate **PROCESS** ( emphasis mine ). This uses the sasl_checkpass(3) function so it can use any back-end server that Cyrus SASL supports for checking passwords."
This is referring to your configured pwcheck_method.
.. but:
*) How was OpenLDAP able to delegate password verification in the simple-bind proxy as I have demonstrated above WITHOUT going through a separate proccess but going straight through a TCP/IP connection ?
If you mean this one:
ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv
$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."
You are not actually performing a SASL authentication here. You are using the sasl_checkpass(3) call indirectly by calling testsaslauthd. saslauthd is performing a simple bind against AD.
The separate process in this case is saslauthd (prior to speaking with slapd). Think of pass-through authentication and testsaslauthd as performing similar functions in this visual picture (in that they call sasl_checkpass(3)).
*) Is the statement saying that OpenLDAP will use saslauthd to connect to a remote LDAP/AD ? If so, since I am using testsaslauthd and I am already using saslauthd to connect to OpenLDAP, and saslauthd.conf is configured to point to the local OpenLDAP, does this mean I need another instance of saslauthd with its own unix socket and its own saslauthd.conf ? If so, what's the point of having the uri in slapd.conf when the separate instance of saslauthd.conf will have its own entry of the remote ldap / AD1 anyway ?
Anyway, as you can see .. I am confused on how to do item [6] above. All I really need to happen is ( from a tcp capture / wireshark perspective ), something like ( similar to the simple bind PTA ):
- If I can find out how to do item [6] above with help from this list,
then I will try to do the same for AD2.
- The end goal therefore is to use OpenLDAP as a dumb proxy that will
authenticate users to either AD1 or AD2.
Using the krb5 backend to saslauthd may be more productive. It will require you to use PLAIN SASL authentication, as DIGEST-MD5 won't work. Or as mentioned above, you can perform GSSAPI SASL authentication and disregard saslauthd/pass-through authentication altogether.
Also take a look at slapo-pbind (5).
-- Dan White
I have decided to forego with PTA + saslbind and simply do PTA + simplebind, which works OK so long as I have an administrative LDAP account on both AD1 and AD2 that can do the initial bind and perform an LDAP searchRequest to find the LDAP entry for the user being authenticated.
So:
testsaslauthd --> saslauthd --> OpenLDAP --> simplebind --> AD1 / AD2
Amazing what OpenLDAP does ( Well, amazing to me ) ! Using the userPrincipalName as the ldap_filter in saslauthd.conf, it binds to both AD1 and AD2, does a searchRequest on both AD1 and AD2, and whichever AD responds with a searchResEntry ( e.g. whichever AD found the LDAP entry of the user to be authenticated ), it then binds to that AD using the DN from the searchResEntry and the password supplied on the command line. Of course, all of this with the correct suffixmassage to make it all work.
Apart from the two uris in slapd.conf for the meta backend / database, all I need is the rootdn and rootpw for testsaslauthd to bind to OpenLDAP. Thus, I now have OpenLDAP proxy to both AD1 /AD2.
All I need next is ldaps.
openldap-technical@openldap.org
-
Clément OUDOT -
Dan White -
Jesus Jr M Salvo