openldap-technical

openldap-technical@openldap.org

18 participants
9897 discussions

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

invalid credentials (49) for normal user
by rui 25 Dec '10

25 Dec '10

Hi, I have imported my passwd and groups file in ldap using migrate_all_online.sh script. I am able to simple bind to ldap using binddn= uid=root,ou=People,o=M1,c=GB but i can't seem to bind with any other user like rui etc with their linux password. Its says invalid credentials. I need to bind for authentication and then get all the primary and secondary groups of a user(how can i do that). Why am i having this problem - do i have to do something extra? When bound as root, if i do "memberUid=root" i get all the secondary groups but i want to do it for any user. I am using c ldap api at the moment. Here is my slapd.conf file: ################################################## # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema ####################################################################### # ldbm database definitions ####################################################################### database ldbm suffix "o=M1,c=GB" rootdn "uid=root,ou=People,o=M1,c=GB" rootpw abc123 directory /var/lib/ldap # Indices to maintain index objectClass,uid,uidNumber,gidNumber eq index cn,mail,surname,givenname eq,subinitial # # ACLs # #access to dn="ou=People,o=M1,c=GB" #attr=userPassword #by self write #by dn="uid=root,ou=People,o=M1,c=GB" write #by * auth access to dn=".*,o=M1,c=GB" by self write #by dn="uid=root,ou=People,o=M1,c=GB" write #by * read access to dn=".*,o= M1,c=GB" #by * read defaultaccess read access to attr=userpassword by self write by dn="uid=root,ou=People,o=M1,c=GB" write by * read access to * by self write by dn=".+" read by * read ############################################### Regards, rui

2 1

Openldap Authentication
by Sachin Bhugra 23 Dec '10

23 Dec '10

Hi All, I have configured a ldap server and trying to login to same ldap server using a ldap user. However, I am not able to login and getting the following in /var/log/secure: Dec 22 20:06:29 redhat5 sshd[7241]: Invalid user ldapu1 from 192.168.85.1 Dec 22 20:06:31 redhat5 sshd[7242]: input_userauth_request: invalid user ldapu1 Dec 22 20:06:37 redhat5 sshd[7241]: pam_unix(sshd:auth): check pass; user unknown Dec 22 20:06:37 redhat5 sshd[7241]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.85.1 Dec 22 20:06:37 redhat5 sshd[7241]: pam_succeed_if(sshd:auth): error retrieving information about user ldapu1 Dec 22 20:06:39 redhat5 sshd[7241]: Failed password for invalid user ldapu1 from 192.168.85.1 port 4461 ssh2 Following appears in ldap.log: Dec 22 20:07:52 redhat5 slapd[2966]: conn=1 op=30 SRCH base="ou=Users,dc=homeldap,dc=com" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=ldapu1))" Dec 22 20:07:52 redhat5 slapd[2966]: conn=1 op=30 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Dec 22 20:07:52 redhat5 slapd[2966]: conn=1 op=30 SEARCH RESULT tag=101 err=0 nentries=0 text= Dec 22 20:07:52 redhat5 slapd[2966]: conn=1 op=31 SRCH base="ou=Computers,dc=homeldap,dc=com" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=ldapu1))" Dec 22 20:07:52 redhat5 slapd[2966]: conn=1 op=31 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Dec 22 20:07:52 redhat5 slapd[2966]: conn=1 op=31 SEARCH RESULT tag=101 err=0 nentries=0 text= I can see that if I use the ldapsearch with same filter, I am not able to locate the user "ldapu1". However, if I change the filter to (|(objectClass=posixAccount)(uid=ldapu1))", it shows me the ldap user: ============= [root@redhat5 ~]# ldapsearch -x -b "ou=Users,dc=homeldap,dc=com" -D "cn=Manager,dc=homeldap,dc=com" -W -H "ldap://127.0.0.1/" "(|(objectClass=posixAccount)(uid=ldapu1))" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=Users,dc=homeldap,dc=com> with scope subtree # filter: (|(objectClass=posixAccount)(uid=ldapu1)) # requesting: ALL # # ldapu1, Users, homeldap.com dn: cn=ldapu1,ou=Users,dc=homeldap,dc=com objectClass: inetOrgPerson cn: ldapu1 sn: ldapu1 uid: ldapu1 userPassword:: bGRhcHV1MQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ============= Can someone please tell me where I have made a mistake? -- Is it necessary to create an account on Linux box and then migrate it to ldap? -- I was just wondering if I can somehow change the default filter from AND to OR at the time of login. I used "pam_filter |objectClass=inetOrgPerson" in ldap.conf however, it didn't change the filter. Regards,

2 1

Is large size of __db file a problem?
by Amol Kulkarni 22 Dec '10

22 Dec '10

Hi List, On one of my servers, the size of a __db file is about 1.9 gb. What does this mean ? Will it cause prbs? The bdb cachesize is also set to about 1.9 gb on this server bcos the that is the size of .bdb files. The server has 4gb ram and 8gb swap. Kindly share your learnings and experiences about this. Thanks and Regards, Amol.

1 0

doubt about cache tuning
by Amol Kulkarni 22 Dec '10

22 Dec '10

Hi List, I read the performance tuning document in the openldap admin guide. It says ideal case is to allocate cachesize for all entries in ldap. In case I do set cachesize for all entries, is it necessary to allocate cache for bdb in the DB_CONFIG ? Currently I'm facing a problem on a server where I've foll. config : slapd.conf : cachesize 419363 idlcachesize 419363 the cachesize here is the number of entries in ldap. Also in DB_CONFIG, I have set set_cachesize 0 2026582016 1 This cache size in DB_CONFIG is abt 1.9 gb. It was calculated by adding file sizes of all .bdb files in the ldap data folder. The problem is that the slapd process is using more than 100% cpu ( on a multicpu server ) . The usage does fluctuate from 20% to 200%. Higher cpu usage is triggered when there are ldap write operations. I doubt that I have overtuned the cache. Kindly share your learnings and experiences. Thanks and Regards, Amol

1 0

Enable SASL and GSSAPI authentication
by Jörg Herzinger 22 Dec '10

22 Dec '10

Hi, I've been running openLDAP with GSSAPI authentication for quite a while now and everything has been running quite fine. The last days I tried enabling SASL password auth as described in [1] Now password authentication works fine, but it seems that GSS somehow has been disabled: root@ldap1 ~ # ldapsearch -x -H ldap:// -b '' -s base -LLL supportedSASLMechanisms dn: While without SASL enabled I get: root@ldap1 ~ # ldapsearch -x -H ldap:// -b '' -s base -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI Is it possible to enable both, GSS and SASL pass through auth? I checked the dokumentation and couldn't find a clue if it is or not. openLDAP version is 2.4.11 on Debian Lenny, Kerberos is MIT version 1.6 also on Lenny. Slapd config can be found here [2] tia, Jörg Herzinger [1] http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication [2] https://github.com/joerg/global2000-puppet/blob/master/modules/ldapserver/t…

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical