openldap-technical December 2010

openldap-technical@openldap.org

82 participants
96 discussions

Is attribute options supported?
by Angel L. Mateo 30 Dec '10

30 Dec '10

Hello, Is attribute options supported in openldap (version 2.4.21)? In RFC 2251 (LDAPv3) the attributes in search could be specified as attribute_name;options, so you could indicate options in the return of the attributes. Specifically, what I want to do is: I have attributes wich value is a URN, so I want to get just a special part of the URN, that is: Traditional search: Ldap filter: (mail=user(a)mydomain.com) Atributos: mail, schacPersonalUniqueID Result: mail: user(a)mydomain.com schacPersonalUniqueID: urn:mace:terena.org:schac:personalUniqueID:es:12345678Q Search with options: Ldap filter: (mail=user(a)mydomain.com) Atributos: mail, schacPersonalUniqueID;x-urn-7 Result: mail: user(a)mydomain.com schacPersonalUniqueID: 12345678Q I have tried this with a standard configuration, but it isn't working: amateo@joshua:~$ /usr/bin/ldapsearch ... mail=user(a)mydomain.com schacPersonalUniqueID;x-urn-7 # extended LDIF # # LDAPv3 # base <dc=Telematica> with scope subtree # filter: uid=amateo # requesting: irisClassifCode # # amateo, Usuarios, telematica dn: uid=user,ou=People,dc=mydomain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 x-urn-1: orden no encontrada Is it supported? Do I have to configure anything in the slapd server? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

3 2

ldapsearch from server does not work but works from client
by Seau Yeen Su 30 Dec '10

30 Dec '10

Hi all, I have managed to install OpenLdap 2.4 on a RHEL 5.2 workstation. The basic openldap without TLS/SSL works fine. On the server itself and from the client I was able to do ldapsearch. However, after I created a server.pem by going through this : [url= http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch31_:_Cent… : Ch31 : Centralized Logins Using LDAP and RADIUS - Linux Home Networking[/url] ldapsearch on the ldap server itself does not work anymore. The summary of the configuration is as below: server.pem is created in /usr/local/etc/openldalp/cacerts and client.pem is in /etc/openldap/cacerts. client.pem is also moved to clients and ldapsearch works fine from client workstation. However, in the ldap server itself it does not. THe output of /etc/ldap.conf looks like below: uri ldaps://syna-ldap-02.synamatix.com/ tls_cacertdir /etc/openldap/cacerts pam_password md5 My /usr/local/etc/openldap/slapd.conf TLS portion looks like below: TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3:RSA TLSCACertificateFile /usr/local/etc/openldap/cacerts/server.pem TLSCertificateFile /usr/local/etc/openldap/cacerts/server.pem TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/server.pem TLSVerifyClient allow The error from ldapsearch x -H ldaps://syna-ldap-02.synamatix.com -d127 in the server itself is as below: TLS ceritficate verification: depth: 0, err: 18, subject: /C=MY/ST=KL/L=MV/O=MGRC/OU=IT/CN= syna-ldap-02.synamatix.com/emailAddress=seauyeen@mgrc.com.my, issuer: /C=MY/ST=KL/L=MV/O=MGRC/OU=IT/CN= syna-ldap-02.synamatix.com/emailAddress=seauyeen@mgrc.com.my TLS certificate verification: Error, self signed certificate tls_write: want=7, write=7 0000: 15 03 01 00 02 02 30 TLS trace: SSL3 alert write:fata:unknown CA TLS trace: SSL connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) On the server end, as I started with debug mode, I get errors below: TLS trace: SSL3 alert read: fatal: unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: erro: 14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(13): TLS accept failure error=-1 id=1010,closing ..... Why is that ldapsearch from client workstation works fine but not in the ldap server itself? It is osoo baffling. It is fine without TLS activated. I have been working on this for 1 week! The information online does not seem to cater to this weird incident of mine. Hope to receive some assistance really soon. If you need files and attachments, please inform me. Thanks and Happy new year guys!!!! -- ------------------------------ MGRC - Accelerating Your Journey of Discovery *Su Seau Yeen Assistant Manager IT Operations * * * *Malaysian Genomics Resource Centre Berhad (MGRC)* T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | www.mgrc.com.my ------------------------------ This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient, is strictly prohibited. If you receive this e-mail in error, please contact us immediately by return e-mail and delete the original message(s).

1 0

one system won't authenticate
by Christ Schlacta 28 Dec '10

28 Dec '10

I've got two systems authenticating against an openldap directory, and one that refuses. I'm attempting to debug why this system won't authenticate, but there's nothing useful in auth.log, and I can't decipher the voluminous output that -d 255 provides. Iv'e checkeced all my configs and my passwords repeatedly. can anyone suggest a next step from here? PS: the system that won't auth is also the system hosting the ldap directory. TIA!!

1 0

ldap server failover on Kerberos servers?
by Kevin Longfellow 28 Dec '10

28 Dec '10

Hi, Using LDAP as the back end for Kerberos principals and openldap 2.3.43 as the client on the Kerberos servers, I see it's possible to add some failover with ldap_servers in /etc/krb5.conf and URI in /etc/openldap/ldap.conf. For example: /etc/krb5.conf: ldap_servers = ldaps://hostname1:636 ldaps://hostname2:636 /etc/openldap/ldap.conf: URI ldaps://hostname1:636 ldaps://hostname2:636 In our situation, the ldap servers are behind a BigIP so only a single hostname can be entered. I'm curious if it makes any sense to add the BigIP hostname twice? Once the initial connection is made by the Kerberos server to the first ldap server are there any failure scenarios that the below would make any sense? /etc/krb5.conf: ldap_servers = ldaps://<bigip hostname>:636 ldaps://<bigip hostname>:636 /etc/openldap/ldap.conf: URI ldaps://<bigip hostname>:636 ldaps://<bigip hostname>:636 Hopefully it makes sense what I'm asking and thanks for your time. Regards, Kevin

2 1

Problem with ACL in 2.4.22
by Nick Milas 28 Dec '10

28 Dec '10

Hi, I have upgraded from 2.3.43 to 2.4.22 on CentOS 5.5. Everything works fine, except my ACLs don't work on the new version. Strange results occur. Has anything changed significantly in v2.4 ACLs in comparison to v2.3 ACLs? For example, the following piece of code works as expected in v2.3 but not in v2.4. If some user logs in and is a member of a GroupXAdmins (where X = 1-6), he can't see the branch at all. # Allow access to entries of the subtree # access to dn.sub="dc=12.11.10.in-addr.arpa,ou=dns1,dc=example,dc=com" attrs="children,entry" by group.exact="cn=Group1Admins,ou=Groups,dc=example,dc=com" write by group.exact="cn=Group2Admins,ou=Groups,dc=example,dc=com" read by group.exact="cn=Group3Admins,ou=Groups,dc=example,dc=com" read by group.exact="cn=Group4Admins,ou=Groups,dc=example,dc=com" write by group.exact="cn=Group5Admins,ou=Groups,dc=example,dc=com" read by group.exact="cn=Group6Admins,ou=Groups,dc=example,dc=com" read by dn.exact="uid=dnsauthusr,ou=System,dc=example,dc=gr" read by * break # Allow access to all attributes of the subtree # access to dn.sub="dc=12.11.10.in-addr.arpa,ou=dns1,dc=example,dc=com" by group.exact="cn=Group1Admins,ou=Groups,dc=example,dc=com" write by group.exact="cn=Group2Admins,ou=Groups,dc=example,dc=com" read by group.exact="cn=Group3Admins,ou=Groups,dc=example,dc=com" read by group.exact="cn=Group4Admins,ou=Groups,dc=example,dc=com" write by group.exact="cn=Group5Admins,ou=Groups,dc=example,dc=com" read by group.exact="cn=Group6Admins,ou=Groups,dc=example,dc=com" read by dn.exact="uid=dnsauthusr,ou=System,dc=example,dc=com" read where Groups are of the form: dn: cn=Group1Admins,ou=Groups,dc=example,dc=com objectClass: groupOfNames cn: Group1Admins member: uid=userx,ou=people,dc=example,dc=com Please, help. Nick

3 3

Re: Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra 28 Dec '10

28 Dec '10

Hi, El 28/12/10 12:00, openldap-technical-request(a)OpenLDAP.org escribió: > Hi, > Am Mon, 27 Dec 2010 15:15:21 +0000 > schrieb Ubay Dorta Guerra <udorta(a)iac.es>: > > >> The simple bind under TLS worked but when i try to use cert-based >> SASL EXTERNAL authentication i get no success. >> >> In the proxy server configuration i add the following directive >> >> idassert-bind bindmethod=sasl >> saslmech=EXTERNAL >> binddn="CN=proxy-server1.example.com,O=Internet >> > the binddn should be empty or just don't configure a binddn. > > Thank you very much. I have deleted the binddn in proxy configuration: idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem tls_key=/etc/ssl/private/proxy-server1.example.com.key tls_cacertdir=/etc/ssl/cacerts/ tls_reqcert=demand mode=self Now when i make a password change: ldapmodify -x -H ldaps://proxy-server1.example.com -f pass2_user.ldif -D 'uid=user_w_pass,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user_w_pass,ou=people,dc=example,dc=com" I get the following messages in syslog: ldap-proxy[16709]: conn=1054 fd=8 TLS established tls_ssf=256 ssf=256 ldap-proxy[16709]: conn=1054 op=0 BIND dn="uid=user_w_pass,ou=people,dc=example,dc=com" method=128 ldap-master[16879]: conn=1022 fd=20 TLS established tls_ssf=256 ssf=256 ldap-master[16879]: conn=1022 op=0 BIND dn="uid=user_w_pass,ou=people,dc=example,dc=com" method=128 ldap-master[16879]: conn=1022 op=0 BIND dn="uid=user_w_pass,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-master[16879]: conn=1022 op=0 RESULT tag=97 err=0 text= ldap-proxy[16709]: conn=1054 op=0 BIND dn="uid=user_w_pass,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-proxy[16709]: conn=1054 op=0 RESULT tag=97 err=0 text= ldap-proxy[16709]: conn=1054 op=1 MOD dn="uid=user_w_pass,ou=people,dc=example,dc=com" ldap-proxy[16709]: conn=1054 op=1 MOD attr=userPassword ldap-master[16879]: conn=1002 op=7 PROXYAUTHZ dn="uid=user_w_pass,ou=people,dc=example,dc=com" ldap-master[16879]: conn=1002 op=7 MOD dn="uid=user_w_pass,ou=people,dc=example,dc=com" ldap-master[16879]: conn=1002 op=7 MOD attr=userPassword ldap-master[16879]: conn=1002 op=7 RESULT tag=103 err=0 text= ldap-proxy[16709]: conn=1054 op=1 RESULT tag=103 err=0 text= ldap-proxy[16709]: conn=1054 op=2 UNBIND ldap-proxy[16709]: conn=1054 fd=8 closed Regards. --------------------------------------------------------------------------------------------- ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en

2 1

Index Usage
by Paul 27 Dec '10

27 Dec '10

Hi all, When I started at this job I acquired OpenLDAP based authentication infrastructure, which I've pretty much been able to leave to its own devices without looking under the hood at what's going on. Recently I've been noticing that a few minor performance problems I'm having seem to be linked to LDAP so I've started looking at how it's set up and it's got some quirks, e.g. # Indices to maintain index entryUUID eq index cn,sn,uid,displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index sambaGroupType eq index sambaSIDList eq index sudoUser eq index uniqueMember,member eq index objectClass pres,eq index mail,mailAlternateAddress eq,sub index accountStatus eq index mailHost,deliveryMode eq index Status,HostGroup eq index default sub There are only around 600 users in the ldap tree, hardly anything. It seems a bit excessive to have that many indexes set up for the tree. Is there any way to identify which indexes are being used and how frequently? I'm pretty certain some of those entries probably get checked once in a blue moon. I'm also seeing odd entries in the ldap logs: Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates: (objectClass) index_param failed (18) Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates: (objectClass) index_param failed (18) Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates: (gidNumber) index_param failed (18) Which seems bizarre given those entries are in the list of indexes. I've tried running slapindex and restarting to no avail. Those items still seem to throw up those alerts, as does the sudoUser entry. On a separate note I've found the slapcat doesn't produce an LDIF file that slapadd will use, even keeping to the same version of software (2.3.37), or importing into newer (2.3.43). It always errors after the first entry because it seems to be trying to add a user to an ou that doesn't exist yet, which disturbs me slightly because the backup infrastructure has been relying on that mechanism for recovery. To create another ldap slave I ended up having to use Apache Directory Studio to create the LDIF for import, which slapadd was perfectly happy to work with. I'm not sure if that may be a known bug that I'm running up against. I see a few entries in archives relating to it but not much by way of response other than suggests it should work. Paul

3 5

Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra 27 Dec '10

27 Dec '10

Hi, We have some problems with certificate authentication when the master server is behind a back-ldap proxy. We have openldap 2.4.21 on Suse Linux Enterprise Server 10 SP3 and these are the details of our scenario: The master server: server1.example.com has the following slapd.conf file: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by dn.exact="CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU" read by * auth access to attrs=shadowLastChange by self write by * read access to * by * read # # Security SSL # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /etc/ssl/certs/server1.example.com.pem TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key TLSCACertificatePath /etc/ssl/cacerts/ TLSVerifyClient demand # #Log level # loglevel 256 # Require authentication require authc ####################################################################### # HDB database definitions ####################################################################### database hdb suffix "dc=example,dc=com" checkpoint 1024 5 cachesize 10000 rootdn "cn=Manager,dc=example,dc=com" rootpw secret # Indices to maintain index objectClass eq # Overlay ppolicy overlay ppolicy ---------------------- Authentication is required, and we give access to the user passwords for the dn of a certificate. When we search for passwords using the certificate we get the following: root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://server1.example.com userPassword SASL/EXTERNAL authentication started SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU SASL SSF: 0 dn: uid=user_w_pass,ou=people,dc=example,dc=com userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0= ----------------------- The root user (ldap client) has a ~/.ldaprc file with: TLS_CACERTDIR /etc/ssl/cacerts/ TLS_CERT /etc/ssl/certs/admin_w_cert.pem TLS_KEY /etc/ssl/private/admin_w_cert.key TLS_REQCERT demand SASL_MECH EXTERNAL In /var/log/messages we get: ldap-master[22358]: conn=1000 fd=11 ACCEPT from IP=server1.example.com:40899 (IP=server1.example.com:636) ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256 ldap-master[22358]: conn=1000 op=0 BIND dn="" method=163 ldap-master[22358]: conn=1000 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-master[22358]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-master[22358]: conn=1000 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-master[22358]: conn=1000 op=2 UNBIND ldap-master[22358]: conn=1000 fd=11 closed This is the correct behavior for us. The problem appears when we introduce a back-ldap proxy between the client and the master. The proxy server (proxy-server1.example.com) is listening in port 1636 and its slapd.conf file is: # # Security SSL # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificatePath /etc/ssl/cacerts/ TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key TLSVerifyClient demand # Log level loglevel 256 ####################################################################### # Database definitions ####################################################################### database ldap rebind-as-user true suffix "dc=example,dc=com" uri "ldaps://server1.example.com" tls ldaps tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem tls_key=/etc/ssl/private/proxy-server1.example.com.key tls_cacertdir=/etc/ssl/cacerts/ ---------------------- If we search for passwords through the proxy we get: root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://proxy-server1.example.com:1636 userPassword SASL/EXTERNAL authentication started SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU SASL SSF: 0 Server is unwilling to perform (53) Additional information: authentication required In the /var/log/messages the following messages appear: ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636) ldap-proxy[22802]: conn=1001 fd=8 TLS established tls_ssf=256 ssf=256 ldap-proxy[22802]: conn=1001 op=0 BIND dn="" method=163 ldap-proxy[22802]: conn=1001 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[22802]: conn=1001 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-proxy[22802]: conn=1001 op=0 RESULT tag=97 err=0 text= ldap-proxy[22802]: conn=1001 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-proxy[22802]: conn=1001 op=1 SRCH attr=userPassword ldap-master[22358]: conn=1008 op=2 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-master[22358]: conn=1008 op=2 SRCH attr=userPassword ldap-master[22358]: conn=1008 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required ldap-proxy[22802]: conn=1001 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required ldap-proxy[22802]: conn=1001 op=2 UNBIND ldap-proxy[22802]: conn=1001 fd=8 closed The /root/.ldaprc file is the same than the previous one. When we increase the logging level we discover this: .... ldap-proxy[23008]: conn=1000 op=0 do_bind ldap-proxy[23008]: >>> dnPrettyNormal: <> ldap-proxy[23008]: <<< dnPrettyNormal: <>, <> ldap-proxy[23008]: conn=1000 op=0 BIND dn="" method=163 ldap-proxy[23008]: do_bind: dn () SASL mech EXTERNAL ldap-proxy[23008]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 ldap-proxy[23008]: SASL Canonicalize [conn=1000]: authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: slap_sasl_getdn: conn 1000 id=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au [len=61] ldap-proxy[23008]: ==>slap_sasl2dn: converting SASL name cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au to a DN ldap-proxy[23008]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[23008]: SASL Canonicalize [conn=1000]: slapAuthcDN="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: SASL proxy authorize [conn=1000]: authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: conn=1000 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" ldap-proxy[23008]: send_ldap_sasl: err=0 len=-1 ldap-proxy[23008]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-proxy[23008]: do_bind: SASL/EXTERNAL bind: dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" sasl_ssf=0 ldap-proxy[23008]: send_ldap_response: msgid=1 tag=97 err=0 ldap-proxy[23008]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[23008]: <== slap_sasl_bind: rc=0 .... ldap-proxy[23008]: conn=1000 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-proxy[23008]: conn=1000 op=1 SRCH attr=userPassword ldap-proxy[23008]: ==> limits_get: conn=1000 op=1 self="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" this="uid=user_w_pass,ou=people,dc=example,dc=com" ldap-master[22983]: daemon: activity on 1 descriptor ldap-master[22983]: daemon: activity on: ldap-master[22983]: ldap-master[22983]: slap_listener_activate(7): ldap-master[22983]: daemon: epoll: listen=7 busy ldap-master[22983]: >>> slap_listener(ldaps://server1.example.com) ..... ldap-master[22983]: conn=1000 op=0 do_bind ldap-master[22983]: >>> dnPrettyNormal: <> ldap-master[22983]: <<< dnPrettyNormal: <>, <> ldap-master[22983]: conn=1000 op=0 BIND dn="" method=128 ldap-master[22983]: do_bind: version=3 dn="" method=128 ldap-master[22983]: send_ldap_result: conn=1000 op=0 p=3 ldap-master[22983]: send_ldap_result: err=0 matched="" text="" ldap-master[22983]: send_ldap_response: msgid=1 tag=97 err=0 ldap-master[22983]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-master[22983]: do_bind: v3 anonymous bind ---------------- Therefore the proxy is binding anonymously in the master, instead of using the dn of the certificate. Is there any problem with the SASL EXTERNAL method? If we use SIMPLE authentication through the proxy, there is no problem: root # ldapsearch -LLL -x -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://proxy-server1.example.com:1636 -D 'uid=user_w_pass,ou=people,dc=example,dc=com' -W userPassword Enter LDAP Password: dn: uid=user_w_pass,ou=people,dc=example,dc=com userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0= Thanks in advance. --------------------------------------------------------------------------------------------- ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en

3 4

Problem starting ldap 2.4
by Nick Milas 27 Dec '10

27 Dec '10

Hi, I am trying to migrate from CentOS 5.5 Openldap 2.3.43-12.el5_5.3 to 2.4.22-1.el5.x86_64 using Buckan RPMs (available at http://staff.telkomsa.net/packages/rhel5/openldap/x86_64/). I think I have done all necessary configuration, but when I try to start, I get a strange error: # service ldap2.4 start ' for reading (No such file or directory)f FNR=196) fatal: cannot open file `/etc/openldap2.4/schema/core.schema chown: cannot access `/var/lib/ldap2.4\r': No such file or directory Starting slapd (ldap + ldaps): [FAILED] Note, however that /etc/openldap2.4/schema/core.schema exists: # ls -la /etc/openldap2.4/schema/core.schema -rw-r--r-- 1 ldap ldap 19762 Nov 29 10:49 /etc/openldap2.4/schema/core.schema The core.schema is the first one included in slapd.conf, so there is probably a problem with all included schema files. The config file is supposed to be OK: # slaptest2.4 -f /etc/openldap2.4/slapd.conf config file testing succeeded The db data has been successfully input using slapadd, from an ldif backp. The db is in /var/lib/ldap2.4: # slapadd2.4 -l /root/ldapbk/ldif.ldap.bk -#################### 100.00% eta none elapsed 45s spd 23.7 k/s Closing DB... [root@vweb ldap2.4]# [root@vweb ldap2.4]# [root@vweb ldap2.4]# nano slapd.conf # # pwd /var/lib/ldap2.4 # slapindex2.4 # # # chown ldap:ldap * # # cd /var/lib # ls -la total 184 ... drwx------ 2 ldap ldap 4096 Dec 26 17:34 ldap drwxr-x--- 3 ldap ldap 4096 Dec 27 13:03 ldap2.4 ... I have googled around but can't find something about this error. Can someone please help? Thanks in advance, Nick Milas

1 2

No ProxyAuthz with SASL-GSSAPI?
by Jaap Winius 26 Dec '10

26 Dec '10

Hi folks, Although I've been able to get proxy authorization to work on Debian lenny systems using OpenLDAP 2.4.11 and Kerberos authentication with SASL-GSSAPI, and I've been able to get it to work on Debian squeeze using 2.4.23 (with Pierangelo's 2010-04-29 patch) and clear-text passwords, but for some reason I'm not having any same luck with the same patched 2.4.23 version when using Kerberos authentication with SASL-GSSAPI. If I compare the two squeeze systems -- clear-text vs. SASL-GSSAPI -- while the loglevels are both set to -1, and try submitting a similar change on both consumer servers, lines with "parseProxyAuthz" and "PROXYAUTHZ" show up in the syslog of the clear-text system's provider server, but nothing of the sort shows up in the syslog on the SASL-GSSAPI system's provider server. Instead, when attempting to add two objects -- cn=ccolumbus and uid=ccolumbus -- using the ldapadd utility as uid=admin on the consumer server, I see this kind of stuff in the logs: ======== begin log fragment consumer server ======================== Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: read active on 17 Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17) Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17): got connid=1003 Dec 23 18:54:16 ldapks2 slapd[29862]: connection_read(17): checking for input on id=1003 Dec 23 18:54:16 ldapks2 slapd[29862]: op tag 0x60, time 1293126856 Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 do_bind Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnPrettyNormal: <> Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnPrettyNormal: <>, <> Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 BIND dn="" method=163 Dec 23 18:54:16 ldapks2 slapd[29862]: do_bind: dn () SASL mech GSSAPI Dec 23 18:54:16 ldapks2 slapd[29862]: ==> sasl_bind: dn="" mech=<continuing> datalen=32 Dec 23 18:54:16 ldapks2 slapd[29862]: SASL Canonicalize [conn=1003]: authcid="admin" Dec 23 18:54:16 ldapks2 slapd[29862]: slap_sasl_getdn: conn 1003 id=admin [len=5] Dec 23 18:54:16 ldapks2 slapd[29862]: slap_sasl_getdn: u:id converted to uid=admin,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnNormalize: <uid=admin,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth> Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnNormalize: <uid=admin,cn=example.com,cn=gssapi,cn=auth> Dec 23 18:54:16 ldapks2 slapd[29862]: ==>slap_sasl2dn: converting SASL name uid=admin,cn=example.com,cn=gssapi,cn=auth to a DN Dec 23 18:54:16 ldapks2 slapd[29862]: [rw] authid: "uid=admin,cn=example.com,cn=gssapi,cn=auth" -> "uid=admin,ou=people,dc=example,dc=com" Dec 23 18:54:16 ldapks2 slapd[29862]: slap_parseURI: parsing uid=admin,ou=people,dc=example,dc=com Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnNormalize: <uid=admin,ou=people,dc=example,dc=com> Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnNormalize: <uid=admin,ou=people,dc=example,dc=com> Dec 23 18:54:16 ldapks2 slapd[29862]: <==slap_sasl2dn: Converted SASL name to uid=admin,ou=people,dc=example,dc=com Dec 23 18:54:16 ldapks2 slapd[29862]: slap_sasl_getdn: dn:id converted to uid=admin,ou=people,dc=example,dc=com Dec 23 18:54:16 ldapks2 slapd[29862]: SASL Canonicalize [conn=1003]: slapAuthcDN="uid=admin,ou=people,dc=example,dc=com" Dec 23 18:54:16 ldapks2 slapd[29862]: SASL proxy authorize [conn=1003]: authcid="admin(a)EXAMPLE.COM" authzid="admin(a)EXAMPLE.COM" Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 BIND authcid="admin(a)EXAMPLE.COM" authzid="admin(a)EXAMPLE.COM" Dec 23 18:54:16 ldapks2 slapd[29862]: SASL Authorize [conn=1003]: proxy authorization allowed authzDN="" Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_sasl: err=0 len=-1 Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 BIND dn="uid=admin,ou=people,dc=example,dc=com" mech=GSSAPI sasl_ssf=56 ssf=56 Dec 23 18:54:16 ldapks2 slapd[29862]: do_bind: SASL/GSSAPI bind: dn="uid=admin,ou=people,dc=example,dc=com" sasl_ssf=56 Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_response: msgid=3 tag=97 err=0 Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 RESULT tag=97 err=0 text= Dec 23 18:54:16 ldapks2 slapd[29862]: <== slap_sasl_bind: rc=0 Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on: Dec 23 18:54:16 ldapks2 slapd[29862]: Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on: Dec 23 18:54:16 ldapks2 slapd[29862]: 17r Dec 23 18:54:16 ldapks2 slapd[29862]: Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: read active on 17 Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17) Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17): got connid=1003 Dec 23 18:54:16 ldapks2 slapd[29862]: connection_read(17): checking for input on id=1003 Dec 23 18:54:16 ldapks2 slapd[29862]: op tag 0x68, time 1293126856 Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=3 do_add Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=3 do_add: dn (cn=ccolumbus,ou=groups,dc=example,dc=com) Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnPrettyNormal: <cn=ccolumbus,ou=groups,dc=example,dc=com> Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnPrettyNormal: <cn=ccolumbus,ou=groups,dc=example,dc=com>, <cn=ccolumbus,ou=groups,dc=example,dc=com> Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=3 ADD dn="cn=ccolumbus,ou=groups,dc=example,dc=com" Dec 23 18:54:16 ldapks2 slapd[29862]: bdb_dn2entry("cn=ccolumbus,ou=groups,dc=example,dc=com") Dec 23 18:54:16 ldapks2 slapd[29862]: => hdb_dn2id("cn=ccolumbus,ou=groups,dc=example,dc=com") Dec 23 18:54:16 ldapks2 slapd[29862]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Dec 23 18:54:16 ldapks2 slapd[29862]: hdb_referrals: tag=104 target="cn=ccolumbus,ou=groups,dc=example,dc=com" matched="ou=groups,dc=example,dc=com" Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on: Dec 23 18:54:16 ldapks2 slapd[29862]: Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: conn=1003 op=3 p=3 Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: err=10 matched="" text="" Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: referral="ldap://ldapks.example.com:389/cn=ccolumbus,ou=groups,dc=example,dc=com" Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnPrettyNormal: <cn=ccolumbus,ou=groups,dc=example,dc=com> Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnPrettyNormal: <cn=ccolumbus,ou=groups,dc=example,dc=com>, <cn=ccolumbus,ou=groups,dc=example,dc=com> Dec 23 18:54:16 ldapks2 slapd[29862]: ldap_back_db_open: URI=ldap://ldapks.example.com:389 Dec 23 18:54:16 ldapks2 slapd[29862]: ==> ldap_back_add("cn=ccolumbus,ou=groups,dc=example,dc=com") Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: conn=1003 op=3 p=3 Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: err=8 matched="" text="modifications require authentication" Dec 23 18:54:16 ldapks2 slapd[29862]: <== ldap_back_add("cn=ccolumbus,ou=groups,dc=example,dc=com"): 8 Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: conn=1003 op=3 p=3 Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: err=8 matched="" text="" Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_response: msgid=4 tag=105 err=8 Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on: Dec 23 18:54:16 ldapks2 slapd[29862]: 17r ======== end log fragment consumer server ========================== The only thing I think looks strange in the above is this line: SASL Authorize [conn=1003]: proxy authorization allowed authzDN="" Why is the authzDN empty? ======== begin log fragment provider server ======================== Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on: Dec 23 18:54:16 ldapks1 slapd[1265]: Dec 23 18:54:16 ldapks1 slapd[1265]: slap_listener_activate(8): Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8 busy Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: >>> slap_listener(ldap:///) Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: listen=8, new connection on 18 Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: added 18r (active) listener=(nil) Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 fd=18 ACCEPT from IP=192.168.2.56:43112 (IP=0.0.0.0:389) Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 2 descriptors Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on: Dec 23 18:54:16 ldapks1 slapd[1265]: 18r Dec 23 18:54:16 ldapks1 slapd[1265]: Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: read active on 18 Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18) Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18): got connid=1004 Dec 23 18:54:16 ldapks1 slapd[1265]: connection_read(18): checking for input on id=1004 Dec 23 18:54:16 ldapks1 slapd[1265]: op tag 0x60, time 1293126856 Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=0 do_bind Dec 23 18:54:16 ldapks1 slapd[1265]: >>> dnPrettyNormal: <> Dec 23 18:54:16 ldapks1 slapd[1265]: <<< dnPrettyNormal: <>, <> Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=0 BIND dn="" method=128 Dec 23 18:54:16 ldapks1 slapd[1265]: do_bind: version=3 dn="" method=128 Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: conn=1004 op=0 p=3 Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: err=0 matched="" text="" Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_response: msgid=1 tag=97 err=0 Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=0 RESULT tag=97 err=0 text= Dec 23 18:54:16 ldapks1 slapd[1265]: do_bind: v3 anonymous bind Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on: Dec 23 18:54:16 ldapks1 slapd[1265]: Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on: Dec 23 18:54:16 ldapks1 slapd[1265]: 18r Dec 23 18:54:16 ldapks1 slapd[1265]: Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: read active on 18 Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18) Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18): got connid=1004 Dec 23 18:54:16 ldapks1 slapd[1265]: connection_read(18): checking for input on id=1004 Dec 23 18:54:16 ldapks1 slapd[1265]: op tag 0x68, time 1293126856 Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 do_add Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 do_add: dn (cn=ccolumbus,ou=groups,dc=example,dc=com) Dec 23 18:54:16 ldapks1 slapd[1265]: >>> dnPrettyNormal: <cn=ccolumbus,ou=groups,dc=example,dc=com> Dec 23 18:54:16 ldapks1 slapd[1265]: <<< dnPrettyNormal: <cn=ccolumbus,ou=groups,dc=example,dc=com>, <cn=ccolumbus,ou=groups,dc=example,dc=com> Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 ADD dn="cn=ccolumbus,ou=groups,dc=example,dc=com" Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: conn=1004 op=1 p=3 Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: err=8 matched="" text="modifications require authentication" Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_response: msgid=2 tag=105 err=8 Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 RESULT tag=105 err=8 text=modifications require authentication Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on: ======== end log fragment provider server ========================== The ldapadd command on the consumer server gives: adding new entry "cn=ccolumbus,ou=groups,dc=example,dc=com" ldap_add: Strong(er) authentication required (8) Some more background info. In the DIT, the consumer server is represented by and authorized to function as a proxy via this object: dn: cn=ldapks2,ou=consumers,dc=example,dc=com cn: ldapks2 objectClass: simpleSecurityObject objectClass: organizationalRole description: LDAP server2 replicator authzTo: dn.regex:^uid=[^,]+,ou=people,dc=example,dc=com$ userPassword:: e0NSWVBUfSo= structuralObjectClass: organizationalRole entryUUID: d939b140-a341-102f-8cd1-6f46e6760f2b creatorsName: uid=admin,ou=people,dc=example,dc=com createTimestamp: 20101224003819Z entryCSN: 20101224003819.303636Z#000000#000#000000 modifiersName: uid=admin,ou=people,dc=example,dc=com modifyTimestamp: 20101224003819Z When the consumer, ldapks2, synchronizes with the provider, ldapks1, the consumer also shows up in the syslog on the provider server as cn=ldapks2,ou=consumers,dc=example,dc=com. That's a good sign, although after adding the relevant olcAuthzRegexp on the provider, it began to work that way after I had restarted slapd. On the provider, the cn=config DIT looks like this: ======== begin cn=config DIT fragment provider server ============== dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcAuthzPolicy: to olcAuthzRegexp: {0}uid=ldap/([^/\.]+).example.com,cn=example.com,cn=gssapi,cn= auth cn=$1,ou=consumers,dc=example,dc=com olcAuthzRegexp: {1}uid=([^,]+),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=peop le,dc=example,dc=com olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcSaslRealm: EXAMPLE.COM olcToolThreads: 1 dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcAccess: {0}to attrs=userPassword,shadowLastChange by dn.one="ou=consumers,d c=example,dc=com" read by * none olcAccess: {1}to attrs=loginShell by dn.one="ou=consumers,dc=example,dc=com" r ead by self write by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by users read by * none olcLastMod: TRUE olcRootDN: uid=admin,ou=people,dc=example,dc=com olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: cn eq olcDbIndex: ou eq olcDbIndex: dc eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq ======== end cn=config DIT fragment provider server ================ Chaining is enabled on the consumer server: ======== begin cn=config DIT fragment consumer server ============== dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}back_ldap dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://ldapks.example.com:389/" olcDbIDAssertBind: bindmethod=sasl saslmech=gssapi mode=self olcDbRebindAsUser: TRUE dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcAccess: {0}to attrs=userPassword,shadowLastChange by * none olcAccess: {1}to attrs=loginShell by self read by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by users read by * none olcLastMod: TRUE olcRootDN: cn=manager olcSyncrepl: {0}rid=123 provider="ldap://ldapks.example.com:389/" type=refresh AndPersist retry="60 30 300 +" searchbase="dc=example,dc=com" bindmethod=sasl saslmech=gssapi olcUpdateRef: "ldap://ldapks.example.com:389/" olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: uid eq olcDbIndex: cn eq olcDbIndex: ou eq olcDbIndex: dc eq ======== end cn=config DIT fragment consumer server ================ BTW, "ldapks.example.com" is an alias for "ldapks1.example.com." That's pretty much it, I think. Is this problem due to another bug, or have I made a mistake somewhere? Thanks, Jaap

1 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2010