openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Syncrepl with subordinate databases
by Robert Minsk 24 Oct '13

24 Oct '13

I have multiple sites that I am trying to sync up to a global server. Each site is configured (striped down) as: ############################################################################ # mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=chi01,ou=studios,dc=methodstudios,dc=net" # Save the time that the entry gets modified lastmod on # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 ############################################################################ # mdb database for ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "ou=studios,dc=methodstudios,dc=net" The above is my configuration for Chicago. I have similar ones for New York (ny01) and Los Angeles (la01) On my global server I am trying to use sync replication to clone each site. The global server is configured (striped down) as: ############################################################################ # mdb database for o=global,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=global,ou=studios,dc=methodstudios,dc=net" # Save the time that the entry gets modified lastmod on # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 ############################################################################ # mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=chi01,ou=studios,dc=methodstudios,dc=net" # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise syncrepl rid=1 provider=ldap://chi01.methodstudios.com type=refreshOnly retry="60 10 300 +" interval=00:00:10:00 searchbase="o=chi01,ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="****" credentials=**** schemachecking=off ############################################################################ # mdb database for o=ny01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=ny01,ou=studios,dc=methodstudios,dc=net" # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise syncrepl rid=2 provider=ldap://ny01.methodstudios.com type=refreshOnly retry="60 10 300 +" interval=00:00:10:00 searchbase="o=ny01,ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="****" credentials=**** schemachecking=off ############################################################################ # mdb database for ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "ou=studios,dc=methodstudios,dc=net" overlay glue overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 Now that I have the configuration out of the way. Syncrepl on the global server is failing on chi01. The chi01 server syslog has Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH base="o=chi01,ou=studios,dc=methodstudios,dc=net" scope=2 deref=0 filter="(objectClass=*)" Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH attr=* + Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=3 UNBIND Looking at the ny01 server (ldapsearch -x -h ny01 -b o=ny01,ou=studios,dc=methodstudios,dc=net -s base +) where syncrepl is working # ny01, studios, methodstudios.net dn: o=ny01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: 257c5408-717c-1032-9b24-31eddc101779 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20130625004432Z entryCSN: 20130625004432.932104Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20130625004432Z contextCSN: 20131023210335.999443Z#000000#000#000000 entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: TRUE Looking at the global server (ldapsearch -x -h global -b o=ny01,ou=studios,dc=methodstudios,dc=net -s base +): # ny01, studios, methodstudios.net dn: o=ny01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: ccbe6442-d084-1032-8149-e14ce02952dd creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.982220Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE Notice no contextCSN. Looking at the chi01 server (ldapsearch -x -h chi01 -b o=chi01,ou=studios,dc=methodstudios,dc=net -s base +): # chi01, studios, methodstudios.net dn: o=chi01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: 4b4f63f6-81bb-1032-97d3-7d320a684bf1 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20130715165653Z entryCSN: 20130715165653.289427Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20130715165653Z contextCSN: 20131018000127.430328Z#000000#000#000000 entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: TRUE Looking at the global server (ldapsearch -x -h global -b o=chi01,ou=studios,dc=methodstudios,dc=net -s base +): # chi01, studios, methodstudios.net dn: o=chi01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: cc675698-d084-1032-8eb1-f1b765ca1756 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.411641Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE Notice no contextCSN. Looking at the global server root of the glued database (ldapsearch -x -h global -b ou=studios,dc=methodstudios,dc=net -s base +): # studios, methodstudios.net dn: ou=studios,dc=methodstudios,dc=net structuralObjectClass: organizationalUnit entryUUID: cc769b12-d084-1032-86fe-a1b1821abdab creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.511823Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z contextCSN: 20131024000524.348070Z#000000#000#000000 entryDN: ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE So after all that. Is the syncrepl from chi01 using the contextCSN from the root of the glued database? It seems all the syncrepl from all the sites fail unless they have the latest change. How do you handle syncrepl on glued databases? -- Robert Minsk Systems and Software Engineer WWW.METHODSTUDIOS.COM <http://www.methodstudios.com> 730 Arizona Ave, Santa Monica, CA 90401 O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501 <tel:+13104346501> Los Angeles <http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles> This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.

3 6

Re: RE24 testing call (OpenLDAP 2.4.37)
by Marco Pizzoli 24 Oct '13

24 Oct '13

All tests fine even here. Compiled HDB and MDB on RHEL6.4 64bit with gperftool. Regards Marco On Tue, Oct 22, 2013 at 10:27 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > If you know how to build OpenLDAP manually, and would like to participate > in testing the next set of code for the 2.4.37 release, please do so. > > Generally, get the code for RE24: > > <http://www.openldap.org/**devel/gitweb.cgi?p=openldap.** > git;a=snapshot;h=refs/heads/**OPENLDAP_REL_ENG_2_4;sf=tgz<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> > > > > Configure & build. > > Execute the test suite (via make test) after it is built. > > Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

Re: LDAP: error code 69 - structural object class modification
by Artur Nike 24 Oct '13

24 Oct '13

Thank you for your help. Yes I did, the extension of such objects STRUCTURAL, Auxiliary facilities (including the new attributes.) It works :). Regards Mariusz 2013/10/23 Quanah Gibson-Mount <quanah(a)zimbra.com> > --On Wednesday, October 23, 2013 12:44 PM +0200 Artur Nike < > opalsie(a)gmail.com> wrote: > > > The only thing that works is: >> -export facility to ldif >> -swapping of a new class (which inherits old) >> -Remove the item from the tree, >> -add the ldif (with swapped class) >> >> >> Maybe I do not understand something, ask for help, how to expand objects >> > > An object can only be of one structural type. I.e., you cannot simply > make an apple become an orange. You may wish to look at using an AUXILIARY > objectClass to "add-on" attributes to an existing object. > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: Re: OpenLDAP 2.3.4 TLS negotiation failure
by Tian Zhiying 23 Oct '13

23 Oct '13

Hi Dieter： Thanks for your quick reply. I have changed 'TLS_REQCERT try' and check the commonName of the host certificate, the common name is LDAP Server hostname "auth.server.com", the following is the query results: [root@auth cacerts]# openssl s_client -connect localhost:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddress=tianzy(a)server.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddress=tianzy(a)server.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A Now, the /etc/openldap/ldap.conf file: URI ldap://ldap.server.com/ BASE dc=server,dc=com TLS_CACERT /etc/openldap/cacerts/cacert.pem #SSL ON TLS_REQCERT try But, run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I also get the following error: [root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11) Tian Zhiying From: DieterKlünter Date: 2013-10-23 17:35 To: openldap-technical CC: tianzy1225 Subject: Re: OpenLDAP 2.3.4 TLS negotiation failure Am Wed, 23 Oct 2013 16:47:25 +0800 schrieb "Tian Zhiying" <tianzy1225(a)thundersoft.com>: > Hi > > On the LDAP Server , I run following command is ok: > #ldapsearch -x -H ldap://ldap.server.com -ZZ > #ldapsearch -x -H ldap://ldap.server.com > > But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com", > is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the > following error: [root@client cacerts]# ldapsearch -x -H > ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11) > > On LDAP Server log file, I get the following error messages: > Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from > IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth > slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]: > conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth > slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure) > > My client ldap configuration: > /etc/openldap/ldap.conf file: > URI ldap://ldap.server.com/ > BASE dc=server,dc=com > TLS_CACERT /etc/openldap/cacerts/ca.crt > SSL ON > TLS_REQCERT demand Set 'TLS_REQCERT try' and check the commonName of the host certificate. SSL ON is not an openldap configuration parameter. The /etc/ldap.conf file is not a openldap client configuration file, but of nss_ldap. > /etc/ldap.conf file: > BASE dc=server,dc=com > URI ldap://ldap.server.com > SSL ON > TLS_CACERT /etc/openldap/cacert/ca.crt > TLS_REQCERT demand > > Any suggestion what cause TLS negotiation failure? -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

2 2

slapo-nssov and authz2dn
by btb＠bitrate.net 23 Oct '13

23 Oct '13

i'm experimenting with the authz2dn setting for olcnsspam: dn: olcOverlay={7}nssov,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcNssOvConfig objectClass: olcOverlayConfig olcOverlay: {7}nssov olcNssMap: group uniquemember member olcNssPam: authz2dn hostservice olcNssPamSession: login olcNssPamSession: sshd it seems to work, but only if i have no olcauthzregexp attributes, and i see no references to cn=<service>+uid=<user>,cn=<hostname>,cn=pam,cn=auth in the slapd log [using -d -1]. if i add an olcauthzregexp [for example: uid=([^,]*),cn=plain,cn=auth uid=$1,ou=people,ou=accounts,dc=example,dc=com, this seems to break nssov, and i'm unable to login [ssh], with pam denying me: Oct 19 19:55:23 dsa1 sshd[30458]: pam_ldap(sshd:account): nslcd authorisation; user=jdoe Oct 19 19:55:23 dsa1 sshd[30458]: pam_ldap(sshd:account): Access denied for this service; user=jdoe Oct 19 19:55:23 dsa1 sshd[30458]: fatal: Access denied for user jdoe by PAM account configuration [preauth] i don't understand why a seemingly unrelated olcauthzregexp is breaking this, but i'm also not confident i'm using authz2dn properly. man 5 slapo-nssov says "If no mapping is found for this authentication DN, then this mapping will be ignored.", but i don't think i understand that clearly. is that saying that failure to find a match via an olcauthzregexp mapping is not considered a failure to find a dn? if i remove authz2dn [and thus use uid2dn] then presence of the above olcauthzregexp value doesn't break nssov. when using -d -1, should i see references to cn=<service>+uid=<user>,cn=<hostname>,cn=pam,cn=auth? what am i doing wrong? thanks -ben

1 1

LDAP: error code 69 - structural object class modification
by Artur Nike 23 Oct '13

23 Oct '13

Good day, Can anyone know how to update the ldap objects in ver 2.4.31. I have an object: * dn: cn=crit3,ou=criteria,o=n1,dc=nodomain* * objectClass: top* * objectClass: n1criterion* * cn: crit3* * n1asn: 1004* * n1cc: US* * n1fqdn: nask.pl* * n1iprange: 4000,4004* * * *with def: * * attributetype ( 1.5.2.6.6.6.1 * * NAME 'n1asn' * * DESC 'number Autonomous System' * * SUP cn * * )* * * * attributetype ( 1.5.2.6.6.6.2 * * NAME 'n1cc' * * DESC 'country code' * * SUP cn * * )* * * * attributetype ( 1.5.2.6.6.6.3 * * NAME 'n1fqdn' * * DESC 'domain' * * SUP cn * * )* * * * attributetype ( 1.5.2.6.6.6.4 * * NAME 'n1iprange' * * DESC 'ip range' * * SUP cn * * )* * * * objectclass ( 1.5.2.6.6.7.1 * * NAME 'n1criterion' * * DESC 'criterion' * * SUP top * * STRUCTURAL * * MUST cn * * MAY ( n1asn $ n1cc $ n1fqdn $ n1iprange ) * * )* and I want to add another attribute, say n1yyy * attributetype ( 1.3.6.1.4.1.111111.99.7 * * NAME 'n1yyy' * * DESC 'vvvv' * * SUP n1cc * * )* * * * objectclass ( 1.3.6.1.4.1.111111.99.8 * * NAME 'n1CNEWcollect' * * DESC 'cvcxvcxvxc' * * SUP n1criterion * * STRUCTURAL * * MAY n1yyy * * )* So creating new atrubut, and class it uses, adding to the schema I want to add to the object dn, a new class, or replace existing it gets the error: * #!RESULT ERROR* * #!CONNECTION ldap://deb:389* * #!DATE 2013-10-23T10:14:34.751* * #!ERROR [LDAP: error code 69 - structural object class modification from 'n1criterion' to 'n1CNEWcollect' not allowed]* * dn: cn=crit3,ou=criteria,o=n1,dc=nodomain* * changetype: modify* * add: objectClass* * objectClass: n1CNEWcollect* * -* * * * #!RESULT ERROR* * #!CONNECTION ldap://deb:389* * #!DATE 2013-10-23T10:17:33.763* * #!ERROR [LDAP: error code 69 - structural object class modification from 'n1criterion' to 'n1CNEWcollect' not allowed]* * dn: cn=crit3,ou=criteria,o=n1,dc=nodomain* * changetype: modify* * add: n1yyy* * n1yyy: SS* * -* * add: objectClass* * objectClass: n1CNEWcollect* * -* * * * #!RESULT ERROR* * #!CONNECTION ldap://deb:389* * #!DATE 2013-10-23T10:18:15.412* * #!ERROR [LDAP: error code 69 - structural object class modification from 'n1criterion' to 'n1CNEWcollect' not allowed]* * dn: cn=crit3,ou=criteria,o=n1,dc=nodomain* * changetype: modify* * add: cn* * cn: dddd* * -* * add: objectClass* * objectClass: n1CNEWcollect* The only thing that works is: -export facility to ldif -swapping of a new class (which inherits old) -Remove the item from the tree, -add the ldif (with swapped class) Maybe I do not understand something, ask for help, how to expand objects Mariusz

2 1

OpenLDAP 2.3.4 TLS negotiation failure
by Tian Zhiying 23 Oct '13

23 Oct '13

Hi On the LDAP Server , I run following command is ok: #ldapsearch -x -H ldap://ldap.server.com -ZZ #ldapsearch -x -H ldap://ldap.server.com But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com", is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the following error: [root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11) On LDAP Server log file, I get the following error messages: Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]: conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure) My client ldap configuration: /etc/openldap/ldap.conf file: URI ldap://ldap.server.com/ BASE dc=server,dc=com TLS_CACERT /etc/openldap/cacerts/ca.crt SSL ON TLS_REQCERT demand /etc/ldap.conf file: BASE dc=server,dc=com URI ldap://ldap.server.com SSL ON TLS_CACERT /etc/openldap/cacert/ca.crt TLS_REQCERT demand Any suggestion what cause TLS negotiation failure? Thanks! Tian Zhiying

1 0

Pass-through authentication to Active Directory when using saslbind
by Jesus Jr M Salvo 22 Oct '13

22 Oct '13

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

3 5

Subject Alternative Name in TLS - does this work?
by lejeczek 21 Oct '13

21 Oct '13

dear all I'm trying to set a seeminglysimple setup having a box with openldap I want it to use TLS on both internal and external hostnames/IPs openldap was set up earlier and was/is working I generate TLS certificate with SAN everything seems working fine but when I ldapsearch on external fqdn/IP (which in the certificate is the subjectAltName) search fails whereas it succeeds on internal fqdn(which is the hostname/ CN in the certificate) error is: additional info: TLS error -8157:Certificate extension not found. is such a scenario even possible? having very same DN being served on more than one name via TLS? best wishes

9 20

prevent mail loops using constraint overlay
by Ole 21 Oct '13

21 Oct '13

Hi, some user always try to build mail loops, creating a mailForwadingAddress attribute with the value of one of their mail attribute. according to the manpage SLAPO-CONSTRAINT(5): [...] constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" [...] it requires the values of the attribute cn to be constructed by pairing values of the attributes sn and givenName, separated by a space, [...] I understand the syntax of the constraint overlay in that way, that the expression after the "set" command has to be true. But if I try to use constraint_attribute mail,mailForwardingAddress set "this/mail | this/mailForwardingAddress" it takes no effect. It should require that there can be a attribute mail with value X OR a value mailForwardingAddress with value X. Is it not valid to use the | operator? Regards Ole

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical