On 20 October 2013 00:00, Clément OUDOT <[email protected]> wrote:
> > > > 2013/10/19 Jesus Jr M Salvo <[email protected]> > >> 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, >> >> >> > > > 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 ) ?
