November 2010 - openldap-technical

Newly configured replication (master / slave) on 2.3 not quite working..
by Michael March 16 Nov '10

16 Nov '10

Entries are taking a LONG time to propagate (if they do at all).. I'm getting a TON of entries in the log like this on the slave side (continuously): Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2629 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "uid=mwatson,ou=People,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(uid=mwatson,ou=People,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "uid=mwatson,ou=People,dc=acme,dc=com" "entryUUID" requested Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2630 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "cn=mwatson,ou=Group,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(cn=mwatson,ou=Group,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "cn=mwatson,ou=Group,dc=acme,dc=com" "entryUUID" requested Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2631 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com" "entryUUID" request ed Here's the slave config: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/ldapab.schema include /etc/openldap/schema/ppolicy.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap moduleload ppolicy.la TLSCertificateFile /etc/openldap/ldap.cert TLSCertificateKeyFile /etc/openldap/ldap.key database bdb suffix "dc=acme,dc=com" rootdn "uid=helpdesk,ou=People,dc=acme,dc=com" rootpw {SHA}FOOOOOO+pZB93s06zAM1vQo= directory /var/lib/ldap overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=acme,dc=com" ppolicy_use_lockout sizelimit 2500 loglevel -1 directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub syncrepl rid=123 provider=ldap://ldap-stage.acme.com:389 #type=refreshAndPersist type=refreshOnly interval=00:00:02:00 searchbase="dc=acme,dc=com" # filter="(objectClass=organizationalPerson)" filter="(objectClass=*)" updatedn "uid=helpdesk,ou=People,dc=acme,dc=com" scope=sub schemachecking=off bindmethod=simple binddn="uid=helpdesk,ou=People,dc=acme,dc=com" credentials=FOOOBAR updateref ldap://ldap-stage.acme.com -- <cowmix>

1 0

Problems with ppolicy_forward_updates and starttls with certificate-based auth
by Kartik Subbarao 16 Nov '10

16 Nov '10

I'm trying to get a consumer server to forward ppolicy-related updates to its provider server, and to use certificate-based authentication (SASL EXTERNAL) over STARTTLS when authenticating to the provider. This is with 2.4.23 on a Debian 5.0.5 system (I've seen similar issues reported elsewhere so I doubt this is platform specific). I'm running into multiple problems here. The core problem seems to be that enabling ppolicy_forward_updates breaks the chaining overlay such that it binds anonymously instead of with SASL EXTERNAL. Another problem is that bind operations to the consumer server start to return two result messages -- one with the error code of the chained operation, and one with the error code of the bind operation. This latter problem seems to the cause of the (still unresolved?) errors from this message thread earlier this year: http://www.mail-archive.com/openldap-technical@openldap.org/msg01215.html To simplify reproducing the problem, I've worked with test022-ppolicy in the openldap test framework. I've submitted ITS 6711 based on this. Here, I ran into another issue. I can't seem to be able to configure sasl external/starttls chaining properly with the cn=config style configuration that test022-ppolicy applies. The self-signed cert that I'm using works fine with replication, but it doesn't seem to work with chaining. This may or may not be another issue that needs to be resolved. In any case, with the attached files in the ITS, I hope that what I'm trying to do and the results that I'm getting should be as clear and unambiguous as possible. I'd appreciate any feedback on whether there is something else I need to configure or if there are bugs here that need to be fixed. Thanks, -Kartik

1 0

password problems
by Stef Coene 16 Nov '10

16 Nov '10

Hi, I can not figure out why my AIX box does not want to authenticate with my ldap server. I think I have a problem with the ldap setup so I can only bind to ldap with anonymous bind or with olcRoot. Checking password for cn=admin,dc=axi,dc=intra (my LDAP manager account): root@ldap1:/etc # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=admin,dc=axi,dc=intra SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=admin,dc=axi,dc=intra> with scope subtree # filter: (objectclass=*) # requesting: ALL # # admin, axi.intra dn: cn=admin,dc=axi,dc=intra cn: admin objectClass: simpleSecurityObject objectClass: organizationalRole description: LDAP administrator userPassword:: e1NTSEF9UkJXSitCZy92V2ZLNlJ5Rzdwa1pvOStpQUh5aSt4NG0= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Changing password: root@ldap1:/etc # ldappasswd -Y EXTERNAL -H ldapi:/// -s secret cn=admin,dc=axi,dc=intra SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Checking that the password is changed: root@ldap1:/etc # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=admin,dc=axi,dc=intra SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=admin,dc=axi,dc=intra> with scope subtree # filter: (objectclass=*) # requesting: ALL # # admin, axi.intra dn: cn=admin,dc=axi,dc=intra cn: admin objectClass: simpleSecurityObject objectClass: organizationalRole description: LDAP administrator userPassword:: e1NTSEF9TnBIK0hBN2JpWEczb0FSU1YwQm5HWmZSVll3S0NaTms= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Using the password: root@ldap1:/etc # ldapsearch -D "cn=admin,dc=axi,dc=intra" -w secret ldap_bind: Invalid credentials (49) So I change the password but I can not use it ? Stef ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

2 3

Pass-Through authentication
by Paulo Jorge N. Correia (paucorre) 16 Nov '10

16 Nov '10

Hi all, I'm just starting with openLDAP and saslauth, and I'm trying to replicate what I can achieve with ADAM/AD LDS in Windows platform. I'm trying to use openldap to aggregate user information from several AD servers under different forests. So single point of contact from an LDAP perspective for an organization, and then openldap should pass-through the authentication request that receives to the AD DC of the respective user. This works well with saslauthd for a single domain, but if I need to do this with multiple domains, I don't know how to configure saslauthd. Can someone help ? Thank you, Paulo

3 7

I'm completely confused by ACLs ... @-)
by Götz Reinicke - IT-Koordinator 16 Nov '10

16 Nov '10

Hi, it should be so simple ... I thought. At first some things worked, but than I messed something up and now I'm completely confused. What I want (sooner or later): - users should authenticate using posix and samba accounts. - they may change there password. - they may look up other mail, phone, ... addresses in the ldap using Thunderbird or apple Addressbook - they may change there phone number and (may be) there postal address - admin users should be able to write and read everything. - anonymous users may later read the mail and cn/sn attribute. May be someone has such ACLs already set up and like to share them or can help me? Would be great, cause reading the docs and experiment is helpful, but I did not ended in a working secure, flexible, understandable setup. Thanks a lot and best regards. /Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke(a)filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt

2 1

Problems Enabling Authentication using Cyrus SASL
by Fernando Torrez 16 Nov '10

16 Nov '10

Hi all I tried to enable SASL authentication using Cyrus SASL to both connect to openldap server and to authenticate users as this document explains: http://www.arschkrebs.de/slides/surviving_cyrus_sasl-handout.pdf I studied openldap and Cyrus SASL documentations with no success when I try to test my configuration with ldapwhoami I get this error: (with a second terminal running this cyrus sasl command: saslauthd -d -V -a ldap -r -O /etc/saslauthd.conf) firewall:~ # ldapwhoami -U proxyuser -X u:test -Y digest-md5 SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database I enabled full login (please see OPENLDAP LOGS below) and I realized that the 'proxyuser' is handled perfectly according to my configuration, but when trying to authenticate then 'test' user gets the error show above (OPENLDAP LOGS lines 138 to 141). I also realized that there is an strange error on line 123 (OPENLDAP LOGS): Nov 11 17:19:10 firewall slapd[11011]: slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined I will appreciate any hints to fix this problem thanks in advance Below are all software used, configuration files, data stored on ldap server and the openldap logs SOFTWARE USED Opensuse 11.3 openldap2-client-2.4.21-9.1.i586 openldap2-2.4.21-9.1.i586 cyrus-sasl-gssapi-2.1.23-11.1.i586 cyrus-sasl-ldap-auxprop-2.1.23-11.2.i586 cyrus-sasl-saslauthd-2.1.23-11.2.i586 cyrus-sasl-2.1.23-11.1.i586 cyrus-sasl-plain-2.1.23-11.1.i586 cyrus-sasl-digestmd5-2.1.23-11.1.i586 cyrus-sasl-crammd5-2.1.23-11.1.i586 CONFIGURATION FILES /etc/saslauthd.conf ldap_servers: ldap://127.0.0.1/ ldap://192.168.1.2/ ldap_search_base: ou=people,dc=plainjoe,dc=org ldap_filter: (userPrincipalName=%u) ldap_bind_dn: uid=proxyuser,ou=people,dc=plainjoe,dc=org ldap_password: secret /etc/openldap/slapd.conf include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema loglevel -1 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args access to attrs=userPassword,userPKCS12 by self write by anonymous auth by dn.base="uid=proxyuser,ou=people,dc=plainjoe,dc=org" manage by users read by * none access to * by * read database bdb suffix "dc=plainjoe,dc=org" checkpoint 1024 5 cachesize 10000 rootdn "cn=Manager,dc=plainjoe,dc=org" # the password is: secret rootpw {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ== directory /var/lib/ldap index objectClass eq index cn,sn,mail eq,sub index departmentNumber eq password-hash {CLEARTEXT} authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=people,dc=plainjoe,dc=org authz-policy to sasl-authz-policy to sasl-regexp uid=(.*),cn=DIGEST-MD5,cn=auth uid=$1,ou=people,dc=plainjoe,dc=org sasl-auxprops slapd sasl-host localhost /etc/sasl2/slapd.conf log_level: 7 mech_list: DIGEST-MD5 pwcheck_method: saslauthd saslauthd_path: /var/run/sasl2/mux #pwcheck_method: auxprop #auxprop_plugin: slapd # auxprop_plugin: ldapdb ldapdb_uri: ldap://localhost ldapdb_id: proxyuser ldapdb_pw: secret ldapdb_mech: DIGEST-MD5 DATA STORED ON LDAP SERVER firewall:~/openldap # slapcat bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=plainjoe,dc=org dc: plainjoe objectClass: dcObject objectClass: organizationalUnit ou: PlainJoe Dot Org structuralObjectClass: organizationalUnit entryUUID: 0335be26-7c73-102f-8bd2-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104152159Z entryCSN: 20101104152159.733766Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101104152159Z dn: ou=people,dc=plainjoe,dc=org ou: people objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 033e9352-7c73-102f-8bd3-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104152159Z entryCSN: 20101105231448.878588Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101105231448Z dn: cn=Gerald W. Carter,ou=people,dc=plainjoe,dc=org cn: Gerald W. Carter sn: Carter mail: jerry(a)plainjoe.org labeledURI: http://www.plainjoe.org/ roomNumber: 1234 Dudley Hall departmentNumber: Engineering telephoneNumber: 222-555-2345 pager: 222-555-6789 mobile: 222-555-1011 objectClass: inetOrgPerson structuralObjectClass: inetOrgPerson entryUUID: 6d8be49c-7c7a-102f-8bd4-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104161504Z entryCSN: 20101104162307.381290Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101104162307Z dn: cn=Gerry Carter,ou=people,dc=plainjoe,dc=org sn: Carter mail: carter(a)nowhere.net objectClass: inetOrgPerson structuralObjectClass: inetOrgPerson entryUUID: 6da59928-7c7a-102f-8bd5-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104161504Z labeledURI: http://www.plainjoe.org/~jerry/ telephoneNumber: 234-555-6789 begin_of_the_skype_highlighting 234-555-6789 end_of_the_skype_highlighting cn: Gerry Carter userPassword:: Z2Vycnk= entryCSN: 20101104212850.439996Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101104212850Z dn: uid=fernandito,ou=people,dc=plainjoe,dc=org uid: fernandito cn: Fernandito Torrez gidNumber: 10000 uidNumber: 10000 homeDirectory: /dev/null objectClass: account objectClass: posixAccount userPassword:: e21kNX1kZDAyYzdjMjIzMjc1OTg3NGUxYzIwNTU4NzAxN2JlZA== structuralObjectClass: account entryUUID: 44afffcc-7f90-102f-8d26-bf24473f4596 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101108142858Z entryCSN: 20101108142858.480384Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101108142858Z dn: uid=test,ou=people,dc=plainjoe,dc=org uid: test cn: testeo principal gidNumber: 10001 uidNumber: 10001 homeDirectory: /dev/null objectClass: account objectClass: posixAccount structuralObjectClass: account entryUUID: b3b5d6f4-8133-102f-9b9b-294e4b3fed35 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101110163123Z userPassword:: e01ENX1DWTlyelVZaDAzUEszazZESmllMDlnPT0= entryCSN: 20101110190152.065873Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101110190152Z dn: uid=proxyuser,ou=people,dc=plainjoe,dc=org uid: proxyuser cn: proxyuser gidNumber: 10002 uidNumber: 10002 homeDirectory: /dev/null objectClass: account objectClass: posixAccount userPassword:: e01ENX1YcjRpbE96UTRQQ09xM2FRMHFidWFRPT0= authzTo: dn.regex:uniqueIdentifier=(.*),ou=people,dc=plainjoe,dc=org structuralObjectClass: account entryUUID: 85999ef4-8214-102f-9c1d-411cc739a95b creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101111192043Z entryCSN: 20101111192043.279474Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101111192043Z OPENLDAP LOGS 1 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 2 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 3 Nov 11 17:19:07 firewall slapd[11011]: 4 Nov 11 17:19:07 firewall slapd[11011]: slap_listener_activate(8): 5 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 6 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 busy 7 Nov 11 17:19:07 firewall slapd[11011]: >>> slap_listener(ldap://) 8 Nov 11 17:19:07 firewall slapd[11011]: daemon: listen=8, new connection on 12 9 Nov 11 17:19:07 firewall slapd[11011]: daemon: added 12r (active) listener=(nil) 10 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 fd=12 ACCEPT from IP=[::1]:47665 (IP=[::]:389) 11 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 12 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 13 Nov 11 17:19:07 firewall slapd[11011]: 14 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 15 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 16 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 17 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 18 Nov 11 17:19:07 firewall slapd[11011]: 12r 19 Nov 11 17:19:07 firewall slapd[11011]: 20 Nov 11 17:19:07 firewall slapd[11011]: daemon: read active on 12 21 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 22 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 23 Nov 11 17:19:07 firewall slapd[11011]: connection_get(12) 24 Nov 11 17:19:07 firewall slapd[11011]: connection_get(12): got connid=1001 25 Nov 11 17:19:07 firewall slapd[11011]: connection_read(12): checking for input on id=1001 26 Nov 11 17:19:07 firewall slapd[11011]: op tag 0x60, time 1289510347 27 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 op=0 do_bind 28 Nov 11 17:19:07 firewall slapd[11011]: >>> dnPrettyNormal: <> 29 Nov 11 17:19:07 firewall slapd[11011]: <<< dnPrettyNormal: <>, <> 30 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 op=0 BIND dn="" method=163 31 Nov 11 17:19:07 firewall slapd[11011]: do_bind: dn () SASL mech DIGEST-MD5 32 Nov 11 17:19:07 firewall slapd[11011]: ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0 33 Nov 11 17:19:07 firewall slapd[11011]: SASL [conn=1001] Debug: DIGEST-MD5 server step 1 34 Nov 11 17:19:07 firewall slapd[11011]: send_ldap_sasl: err=14 len=182 35 Nov 11 17:19:07 firewall slapd[11011]: send_ldap_response: msgid=1 tag=97 err=14 36 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: 37 Nov 11 17:19:07 firewall slapd[11011]: <== slap_sasl_bind: rc=14 38 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 39 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 40 Nov 11 17:19:07 firewall slapd[11011]: 41 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 42 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 43 Nov 11 17:19:07 firewall ldapwhoami: DIGEST-MD5 client step 2 44 Nov 11 17:19:10 firewall ldapwhoami: DIGEST-MD5 client step 2 45 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 46 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 47 Nov 11 17:19:10 firewall slapd[11011]: 12r 48 Nov 11 17:19:10 firewall slapd[11011]: 49 Nov 11 17:19:10 firewall slapd[11011]: daemon: read active on 12 50 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 51 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 52 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12) 53 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12): got connid=1001 54 Nov 11 17:19:10 firewall slapd[11011]: connection_read(12): checking for input on id=1001 55 Nov 11 17:19:10 firewall slapd[11011]: op tag 0x60, time 1289510350 56 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 op=1 do_bind 57 Nov 11 17:19:10 firewall slapd[11011]: >>> dnPrettyNormal: <> 58 Nov 11 17:19:10 firewall slapd[11011]: <<< dnPrettyNormal: <>, <> 59 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 op=1 BIND dn="" method=163 60 Nov 11 17:19:10 firewall slapd[11011]: do_bind: dn () SASL mech DIGEST-MD5 61 Nov 11 17:19:10 firewall slapd[11011]: ==> sasl_bind: dn="" mech=<continuing> datalen=296 62 Nov 11 17:19:10 firewall slapd[11011]: SASL [conn=1001] Debug: DIGEST-MD5 server step 2 63 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: authcid="proxyuser" 64 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: conn 1001 id=proxyuser [len=9] 65 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: u:id converted to uid=proxyuser,cn=DIGEST-MD5,cn=auth 66 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=proxyuser,cn=DIGEST-MD5,cn=auth> 67 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=proxyuser,cn=digest-md5,cn=auth> 68 Nov 11 17:19:10 firewall slapd[11011]: ==>slap_sasl2dn: converting SASL name uid=proxyuser,cn=digest-md5,cn=auth to a DN 69 Nov 11 17:19:10 firewall slapd[11011]: [rw] authid: "uid=proxyuser,cn=digest-md5,cn=auth" -> "uid=proxyuser,ou=people,dc=plainjoe,dc=org" 70 Nov 11 17:19:10 firewall slapd[11011]: slap_parseURI: parsing uid=proxyuser,ou=people,dc=plainjoe,dc=org 71 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> 72 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> 73 Nov 11 17:19:10 firewall slapd[11011]: <==slap_sasl2dn: Converted SASL name to uid=proxyuser,ou=people,dc=plainjoe,dc=org 74 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: dn:id converted to uid=proxyuser,ou=people,dc=plainjoe,dc=org 75 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: slapAuthcDN="uid=proxyuser,ou=people,dc=plainjoe,dc=org" 76 Nov 11 17:19:10 firewall slapd[11011]: => bdb_search 77 Nov 11 17:19:10 firewall slapd[11011]: bdb_dn2entry("uid=proxyuser,ou=people,dc=plainjoe,dc=org") 78 Nov 11 17:19:10 firewall slapd[11011]: => bdb_dn2id("dc=plainjoe,dc=org") 79 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 80 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 81 Nov 11 17:19:10 firewall slapd[11011]: 82 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 83 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 84 Nov 11 17:19:10 firewall slapd[11011]: <= bdb_dn2id: got id=0x1 85 Nov 11 17:19:10 firewall slapd[11011]: => bdb_dn2id("ou=people,dc=plainjoe,dc=org") 86 Nov 11 17:19:10 firewall slapd[11011]: <= bdb_dn2id: got id=0x2 87 Nov 11 17:19:10 firewall slapd[11011]: => bdb_dn2id("uid=proxyuser,ou=people,dc=plainjoe,dc=org") 88 Nov 11 17:19:10 firewall slapd[11011]: <= bdb_dn2id: got id=0x10 89 Nov 11 17:19:10 firewall slapd[11011]: entry_decode: "uid=proxyuser,ou=people,dc=plainjoe,dc=org" 90 Nov 11 17:19:10 firewall slapd[11011]: <= entry_decode(uid=proxyuser,ou=people,dc=plainjoe,dc=org) 91 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "entry" requested 92 Nov 11 17:19:10 firewall slapd[11011]: => acl_get: [2] attr entry 93 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "entry" requested 94 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: to all values by "", (=0) 95 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: * 96 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] applying read(=rscxd) (stop) 97 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] mask: read(=rscxd) 98 Nov 11 17:19:10 firewall slapd[11011]: => slap_access_allowed: auth access granted by read(=rscxd) 99 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access granted by read(=rscxd) 100 Nov 11 17:19:10 firewall slapd[11011]: base_candidates: base: "uid=proxyuser,ou=people,dc=plainjoe,dc=org" (0x00000010) 101 Nov 11 17:19:10 firewall slapd[11011]: => test_filter 102 Nov 11 17:19:10 firewall slapd[11011]: PRESENT 103 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "objectClass" requested 104 Nov 11 17:19:10 firewall slapd[11011]: => acl_get: [2] attr objectClass 105 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "objectClass" requested 106 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: to all values by "", (=0) 107 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: * 108 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] applying read(=rscxd) (stop) 109 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] mask: read(=rscxd) 110 Nov 11 17:19:10 firewall slapd[11011]: => slap_access_allowed: auth access granted by read(=rscxd) 111 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access granted by read(=rscxd) 112 Nov 11 17:19:10 firewall slapd[11011]: <= test_filter 6 113 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "userPassword" requested 114 Nov 11 17:19:10 firewall slapd[11011]: => acl_get: [1] attr userPassword 115 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "userPassword" requested 116 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: to all values by "", (=0) 117 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: self 118 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: anonymous 119 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [2] applying auth(=xd) (stop) 120 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [2] mask: auth(=xd) 121 Nov 11 17:19:10 firewall slapd[11011]: => slap_access_allowed: auth access granted by auth(=xd) 122 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access granted by auth(=xd) 123 Nov 11 17:19:10 firewall slapd[11011]: slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined 124 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: conn=1001 op=1 p=3 125 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: err=0 matched="" text="" 126 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: authzid="u:test" 127 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: conn 1001 id=u:test [len=6] 128 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: u:id converted to uid=test,cn=DIGEST-MD5,cn=auth 129 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=test,cn=DIGEST-MD5,cn=auth> 130 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=test,cn=digest-md5,cn=auth> 131 Nov 11 17:19:10 firewall slapd[11011]: ==>slap_sasl2dn: converting SASL name uid=test,cn=digest-md5,cn=auth to a DN 132 Nov 11 17:19:10 firewall slapd[11011]: [rw] authid: "uid=test,cn=digest-md5,cn=auth" -> "uid=test,ou=people,dc=plainjoe,dc=org" 133 Nov 11 17:19:10 firewall slapd[11011]: slap_parseURI: parsing uid=test,ou=people,dc=plainjoe,dc=org 134 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=test,ou=people,dc=plainjoe,dc=org> 135 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=test,ou=people,dc=plainjoe,dc=org> 136 Nov 11 17:19:10 firewall slapd[11011]: <==slap_sasl2dn: Converted SASL name to uid=test,ou=people,dc=plainjoe,dc=org 137 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: dn:id converted to uid=test,ou=people,dc=plainjoe,dc=org 138 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: slapAuthzDN="uid=test,ou=people,dc=plainjoe,dc=org" 139 Nov 11 17:19:10 firewall slapd[11011]: SASL [conn=1001] Failure: no secret in database 140 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: conn=1001 op=1 p=3 141 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database" 142 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_response: msgid=2 tag=97 err=49 143 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 144 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 145 Nov 11 17:19:10 firewall slapd[11011]: 12r 146 Nov 11 17:19:10 firewall slapd[11011]: 147 Nov 11 17:19:10 firewall slapd[11011]: daemon: read active on 12 148 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 149 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 150 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12) 151 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12): got connid=1001 152 Nov 11 17:19:10 firewall slapd[11011]: connection_read(12): checking for input on id=1001 153 Nov 11 17:19:10 firewall slapd[11011]: ber_get_next on fd 12 failed errno=0 (Success) 154 Nov 11 17:19:10 firewall slapd[11011]: connection_read(12): input error=-2 id=1001, closing. 155 Nov 11 17:19:10 firewall slapd[11011]: connection_closing: readying conn=1001 sd=12 for close 156 Nov 11 17:19:10 firewall slapd[11011]: connection_close: deferring conn=1001 sd=12 157 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 158 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 159 Nov 11 17:19:10 firewall slapd[11011]: 160 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 161 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 162 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 op=1 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database 163 Nov 11 17:19:10 firewall slapd[11011]: <== slap_sasl_bind: rc=49 164 Nov 11 17:19:10 firewall slapd[11011]: connection_resched: attempting closing conn=1001 sd=12 165 Nov 11 17:19:10 firewall slapd[11011]: connection_close: conn=1001 sd=12 166 Nov 11 17:19:10 firewall slapd[11011]: daemon: removing 12 167 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 fd=12 closed (connection lost)

2 1

No object has been found error message
by Darouichi, Aziz 15 Nov '10

15 Nov '10

Hi all, Friday last week before I left for the week end LDAP was working fine with no problems. This morning When I tried to do an ldapsearch, I get error no such object (32) error. I checked ldap services and they are running fine. Plus I have a script that sends emails and restarts ldap services if there is a problem on the week end or a night. No emails were generated and no changes have been made. FY this is openldap-2.3.43-12.el5_5.2 Thanks, Aziz

2 1

AIX as openldap client
by Stef Coene 15 Nov '10

15 Nov '10

Hi, Some time ago, I configured an ubuntu intrepid as openldap server and I was able to use it as authentication server for AIX 6.1. I tried the same with an ubuntu maverick server, but I can not get it working anymore. I can see all the user information on the AIX server. I can do 'su - <user>' to become the user. But I can not login so I think there is a problem with the password. When I change the password of a user on the AIX server, I get these errors in the logfile on the openldap server: Oct 26 20:44:12 ldap1 slapd[28664]: Entry (uid=xxx,ou=people,dc=xxx,dc=xxx), attribute 'shadowLastChange' not allowed Oct 26 20:44:12 ldap1 slapd[28664]: entry failed schema check: attribute 'shadowLastChange' not allowed Is this important? The intrepid has version 2.4.11-0ubuntu6.2, the maverick has version 2.4.21-0ubuntu5.3. I didn't noted down what I did on the intrepid server, but I can remember that it asked a bunch of questions when I installed slapd. These initial steps are removed from the maverick version. I also remember using the ldapinit command. How can I debug the difference between these 2 versions? Using slapcat, I can see some differeces, but nothing that is important in my opinion. How can I debug the openldap server to see what's going on? I can use the openldap server on a linux ldap client without problems. Stef PS I also tried to post this message to openldap-software(a)openldap.org, but I got a 'Delivery status notification' saying that the user does not exist.

6 17

Performance issues lately.
by Jorgen Lundman 14 Nov '10

14 Nov '10

Hello list, Solaris 10u8 db-4.8.30.NC openldap-2.4.23 So in the last week, simple queries have been really slow. For example: # time /usr/local/bin/ldapsearch -h 0 -D cn=admin,dc=company,dc=com -x -w pass -b ou=mail,dc=company,dc=com mail=testlookup(a)domain.com 1m21s Of course "mail" in indexed. The server is dedicated to LDAP (test server) so there are no other connections. Not even syncrepl connection. I have checked the usual things, memory usage, BDB cache, and disk IO. All seem to be within reasonable limits. Then I went deeper. I started trussing it, and it seems to send the query reply nearly right away, then sit around 200 seconds before we send a few more bytes and exit. I tried out db_stat on various db, and found it is also really slow on stat on "id2entry.bdb". For example: # time /usr/local/BerkeleyDB.4.8/bin/db_stat -d id2entry.bdb 2m32s So, trussing that call (including all calls in libdb-4.2): 19700/1@1: 0.0001 -> libdb-4.8:__db_stat_print_pp(0x419920, 0x0, 0x412c30, 0x4146a0, 0xfffffd7fffdff880, 0xfffffd7fffdff824) 19700/1: 0.0009 time() = 128972 5450 19700/1: 0.0001 brk(0x0041EC20) = 0 19700/1: 0.0001 brk(0x00422C20) = 0 19700/1: 0.0001 open("/usr/share/lib/zoneinfo/Japan", O_RDONLY) = 4 19700/1: 0.0000 fstat(4, 0xFFFFFD7FFFDFF880) = 0 19700/1: 0.0001 read(4, 0xFFFFFD7FFEEA0880, 125) = 125 19700/1: T Z i f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\003\0\0\003\0\0\0 \0 19700/1: \0\0\0\t\0\0\003\0\0\0\fC3CE85 pD7 >1E90D7EC1680D8F91690D9CBF8 80 19700/1: DB071D10DBABDA80DCE6FF10DD8BBC80020102010201020102\0\0 ~90\0\0 \0 19700/1: \08CA00104\0\0 ~90\0\b C J T\0 J D T\0 J S T\0\0\0\0\0\0\0 19700/1: 0.0000 close(4) = 0 19700/1: 0.0002 ioctl(1, TCGETA, 0xFFFFFD7FFFDFE8B0) = 0 19700/1: 0.0000 fstat(1, 0xFFFFFD7FFFDFE840) = 0 19700/1: 0.0001 write(1, 0xFFFFFD7FFF006764, 36) = 36 19700/1: S u n N o v 1 4 1 8 : 0 4 : 1 0 2 0 1 0\t L o c a l t 19700/1: i m e\n 19700/1: 589.8794 write(1, 0xFFFFFD7FFF006764, 25) = 25 19700/1: 5 3 1 6 2\t B t r e e m a g i c n u m b e r\n 19700/1: 0.0046 write(1, 0xFFFFFD7FFF006764, 23) = 23 Not entirely sure why a write (everything leading up) to stdout takes 589 seconds. I have tried rebuilding the whole database with slapadd but made no difference. I put all DB files in /tmp on x4540 (has 32G RAM) and yet, still 2mins to do db_stat. General db_stat -m output: 4GB Total cache size 8 Number of caches 8 Maximum number of caches 512MB Pool individual cache size 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 407M Requested pages found in the cache (99%) 38 Requested pages not found in the cache 425405 Pages created in the cache 38 Pages read into the cache 425427 Pages written from the cache to the backing file 0 Clean pages forced from the cache 0 Dirty pages forced from the cache 0 Dirty pages written by trickle-sync thread 425427 Current total page count 425427 Current clean page count 0 Current dirty page count 524296 Number of hash buckets used for page location 4096 Assumed page size used 407M Total number of times hash chains searched for a page (407904893) 32 The longest hash chain searched for a page 466M Total number of hash chain entries checked for page (466861223) 0 The number of hash bucket locks that required waiting (0%) 0 The maximum number of times any hash bucket lock was waited for (0%) 0 The number of region locks that required waiting (0%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 425538 The number of page allocations 0 The number of hash buckets examined during allocations 0 The maximum number of hash buckets examined for an allocation 0 The number of pages examined during allocations 0 The max number of pages examined for an allocation 0 Threads waited on page I/O 0 The number of times a sync is interrupted Pool File: id2entry.bdb 16384 Page size 0 Requested pages mapped into the process' address space 13M Requested pages found in the cache (99%) 2 Requested pages not found in the cache 163449 Pages created in the cache 2 Pages read into the cache 163451 Pages written from the cache to the backing file Pool File: mail.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2797594 Requested pages found in the cache (99%) 2 Requested pages not found in the cache 3335 Pages created in the cache 2 Pages read into the cache 3337 Pages written from the cache to the backing file -rw-r--r-- 1 root root 168 Nov 14 12:54 DB_CONFIG -rw------- 1 root root 3.8M Nov 14 14:03 DNSData.bdb -rw------- 1 root root 5.4M Nov 14 14:03 DNSHostName.bdb -rw------- 1 root root 3.3M Nov 14 14:03 DNSIPAddr.bdb -rw------- 1 root root 2.7M Nov 14 14:03 DNSType.bdb -rw------- 1 root root 24K Nov 14 12:54 __db.001 -rw------- 1 root root 180M Nov 14 18:28 __db.002 -rw------- 1 root root 512M Nov 14 13:45 __db.003 -rw------- 1 root root 512M Nov 14 14:35 __db.004 -rw------- 1 root root 512M Nov 14 14:40 __db.005 -rw------- 1 root root 512M Nov 14 13:45 __db.006 -rw------- 1 root root 512M Nov 14 13:45 __db.007 -rw------- 1 root root 512M Nov 14 13:45 __db.008 -rw------- 1 root root 512M Nov 14 14:35 __db.009 -rw------- 1 root root 512M Nov 14 14:27 __db.010 -rw------- 1 root root 160K Nov 14 12:54 __db.011 -rw------- 1 root root 1.2M Nov 14 18:25 __db.012 -rw------- 1 root root 32K Nov 14 12:54 __db.013 -rw------- 1 root root 2.1M Nov 14 14:03 accountStatus.bdb -rw-r--r-- 1 root root 2.0K Nov 14 16:12 alock -rw------- 1 root root 536K Nov 14 14:03 deliveryMode.bdb -rw------- 1 root root 621M Nov 14 14:07 dn2id.bdb -rw------- 1 root root 172M Nov 14 14:03 entryCSN.bdb -rw------- 1 root root 125M Nov 14 14:03 entryUUID.bdb -rw------- 1 root root 17M Nov 14 14:03 gecos.bdb -rw------- 1 root root 1.8M Nov 14 14:03 gidNumber.bdb -rw------- 1 root root 2.5G Nov 14 14:40 id2entry.bdb -rw------- 1 root root 50M Nov 14 16:12 log.0000000266 -rw------- 1 root root 13M Nov 14 14:03 mail.bdb -rw------- 1 root root 3.2M Nov 14 14:03 mailAlternateAddress.bdb -rw------- 1 root root 8.7M Nov 14 14:03 o.bdb -rw------- 1 root root 4.9M Nov 14 14:03 objectClass.bdb -rw------- 1 root root 1.3M Nov 14 14:03 radiusGroupName.bdb -rw------- 1 root root 20M Nov 14 14:03 uid.bdb -rw------- 1 root root 17M Nov 14 14:03 uidNumber.bdb checkpoint 128 15 cachesize 5000 idlcachesize 15000 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 1000 # DB_CONFIG FILE. Warning, these entries are only written if the DB_CONFIG # file DOES NOT EXIST. So if you change any of these values, you will need # to remove the file, then restart slapd. dbconfig set_lk_detect DB_LOCK_DEFAULT dbconfig set_lg_max 52428800 dbconfig set_cachesize 4 0 8 dbconfig set_flags db_log_autoremove dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 # DB_CONFIG FILE. Any suggestions? Must have hit some limit somewhere I guess. Lund

4 9

Chaining not working
by Jaap Winius 14 Nov '10

14 Nov '10

Hi folks, While testing the current Debian squeeze version of OpenLDAP, v2.4.23-6, in a provider/consumer syncprov/syncrepl (refreshAndPersist) configuration, using a patch(1) written by Pierangelo, I have not been able to get chaining to work. The consumer, ldaps2, was configured with a referral(2) to the provider, ldaps1, as well as a chaining configuration(3). A couple of authzTo rules(4) were added to its entry in the DIT, which immediately replicated to the consumer, and the provider was configured with an olcAuthzPolicy directive for "to"(5). So far, so good. However, when using ldapmodify on the consumer to test that an entry in the DIT could actually be modified (the description attr of the consumer's entry) from there as a result, I got this response: ------------------------------------------------------------ modifying entry "cn=ldaps2,dc=example,dc=com" ldap_modify: Referral (10) referrals: ldap://ldaps.example.com/cn=ldaps2,dc=example,dc=com ------------------------------------------------------------ I know ldapmodify doesn't understand referrals; this is where chaining should have worked instead. So, I removed the referral from the consumer's configuration to see what would then happen with the same command: ------------------------------------------------------------ modifying entry "cn=ldaps2,dc=example,dc=com" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral ------------------------------------------------------------ (shadow context?). In both cases, this shows up in the syslog as a result: ------------------------------------------------------------ Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 ACCEPT from IP=127.0.1.1:43982 (IP=0.0.0.0:389) Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn="cn=admin,dc=example,dc=com" method=128 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 RESULT tag=97 err=0 text= Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD dn="cn=ldaps2,dc=example,dc=com" Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD attr=description Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 RESULT tag=103 err=53 text=shadow context; no update referral Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=2 UNBIND Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 closed ------------------------------------------------------------ Have I made a mistake somewhere, or could this be another bug? Thanks, Jaap 1) ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch 2) LDIF applied to ldaps2 (the consumer) to create the referral to ldaps1 (the provider) via an alias (ldaps): --------------------------------- dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcUpdateref olcUpdateref: ldap://ldaps.example.com --------------------------------- 3) LDIF applied to ldaps2 to create the chaining configuration: --------------------------------- dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}back_ldap dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldaps.example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=ldaps2,dc=example,dc=com" credentials=bilineatus mode=self --------------------------------- 4) LDIF to create a couple of authzTo rules for the consumer: --------------------------------- dn: cn=ldaps2,dc=example,dc=com changetype: modify add: authzTo authzTo: {0}dn.regex:^uid=[^,]+,ou=people,dc=example,dc=com$ authzTo: {1}dn.exact:cn=admin,dc=example,dc=com --------------------------------- 5) LDIF to add an olcAuthzPolicy directive to the provider, ldaps1: --------------------------------- dn: cn=config changetype: modify add: olcAuthzPolicy olcAuthzPolicy: to ---------------------------------

2 2

Re: Trying to understand an error message
by Khaled Blah 13 Nov '10

13 Nov '10

Thanks for your reply, Hallvard. Do I understand it correctly that I can re-use LDAP structures on which a bind has already been done? Do you know of any other stateful data I would have to look at? Regards, Khaled 2010/11/12 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no>: > Khaled Blah writes: >> My application creates LDAP structures (using ldap_init) and re-uses >> these structures whenever possible so that the least number of LDAP >> binds have to done. Is there anything I need to do after an LDAP >> operation has finished or maybe do I have to unbind at some point to >> make sure the LDAP structure remains in a valid state? I would be >> happy to receive any insight into this. > > With LDAP *ld, call ldap_unbind(ld) when you are finished with ld, and > not before. ldap_unbind() is actually the destructor for an LDAP*, in > addition to sending an Unbind message. > > -- > Hallvard >

2 2

Out of memory Errors when starting up Slurpd: Openldap-server-2.3.43
by Traiano Welcome 13 Nov '10

13 Nov '10

Hi List We're using openldap-server 2.3.43 on FreeBSD 6.2-RELEASE-p9 #0. When trying to start up slurpd (/usr/local/etc/rc.d/slurpd start), slurpd runs for a while then dies at various points during it's replication with error "Out of memory". The following are various attempts to start slurpd, with the last messages it dies with before "Out of Memory". My question is: Is this a known bug? What could be the cause of these out of memory errors in Slurpd? Test one: --- Initializing session to ldap://server.ops.aanet.co.za:389 Error: ldap_initialize(0, ldap://server.ops.aanet.co.za:389) failed: Out of memory --- Test two: --- malloc of 3 bytes failed Error: ldap_modify_s failed modifying DN "uid=sherbert.buth,ou=mycast.co.za,ou=AuthSystem,dc=za,dc=oo,dc=com": Out of memory --- Test three: ---- Error: ldap operation failed, data written to "/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej" ---- Test four: --- Error: ldap_modify_s failed modifying DN "uid=bruce,ou=fatnet.co.za,ou=AuthSystem,dc=za,dc=uu,dc=net": Out of memory --- Test 5: --- Error: ldap operation failed, data written to "/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej" --- Test 6: --- ldif_parse_line: type malloc failed Error: malformed replog line "replace: sn" Warning: freeing re (dn: uid=dericks,ou=anb.co.za,ou=AuthSystem,dc=za,dc=uu,dc=net) with nonzero refcnt error: malformed replog entry (begins with "replica: server.ops.aanet.co.za:389") Error: ldap_modify_s failed modifying DN "uid=tyrone,ou=business.net,ou=AuthSystem,dc=za,dc=,dc=net": Out of memory Error: ldap operation failed, data written to "/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej" ldif_parse_line: value malloc failed Error: malformed replog line "olcPasswordHash: 92XXXXXXXXXXXXXXXXXXXX" Warning: freeing re (dn: uid=adi,ou=anb.co.za,ou=AuthSystem,dc=za,dc=oo,dc=net) with nonzero refcnt error: malformed replog entry (begins with "replica: server.ops.aanet.co.za:389") malloc of 12 bytes failed malloc of 8 bytes failed --- Thanks in Advance, Traiano Welcome

2 1

Assigning a Member to Multiple Groups
by Anton Chu 12 Nov '10

12 Nov '10

Unfortunately there's can only be one GID number per user entry into the DIT, how can I assign multiple groups to one user? So when that user logs into a server, he or she will have multiple group IDs.

2 1

How to convert Solaris m5 passwords to LDAP?
by Christian Schmidt 12 Nov '10

12 Nov '10

Hi all, we want to switch a server machine from Solaris (credentials stored in "traditional" passwd and shadow file) to Debian with OpenLDAP for authentication. Creating LDIF files from /etc/passwd and /etc/shadow using PADL's migrationtools is working fine. The only problem is, that many user passwords on the Solaris machine have been encrypted using Sun's md5 scheme which results in hashes beginning with the characters "$md5$". These hashes can be "imported" into our LDAP directory, but they cannot be used for authentication: Each attempt results in "access denied" on the client side and LDAP bind errors on the server side. Even when adding the user information to /etc/passwd and /etc/shadow on the Linux machine, there's no success. With CRYPT password hashes, everything works fine. Do you know any means to "convert" these Solaris-md5-hashed password strings into something we can use with OpenLDAP? I appreciate your helpful answers. Thanks in advance! Gruss/Regards, Christian Schmidt -- You have an ability to sense and know higher truth.

4 7

Syncrepl from OSX slapd to Centos5 slapd
by Markku Tavasti 12 Nov '10

12 Nov '10

Hi! We have OSX as primary ldap server (slapd 2.3.27). Schema is OSX tuned schema, with Apple provided extensions. I'm trying to set up backup-ldap to Centos5 server (slapd 2.3.43). I have copied schemas from OSX /etc/openldap/schema, and edited & commented out attributetype 'authAuthority' definition from apple.schema. OSX is running with configuration from cn=config, so how I can check if schema it uses is 100% same as in schema files? Here is my syncrepl config on client side: syncrepl rid=23 provider=ldap://xxxx.domain.com type=refreshOnly interval=00:00:10:00 retry="60 10 300 +" searchbase="dc=xxxx,dc=domain,dc=com" scope=sub schemachecking=off bindmethod=simple binddn="uid=replicator,cn=users,dc=xxxx,dc=domain,dc=com" credentials=secret Client-slapd starts ok, and replication gets only one entry: # xxxx, computers, xxxx.domain.com dn: cn=xxxx,cn=computers,dc=xxxx,dc=domain,dc=com To log on client side I get only these: Nov 11 05:31:46 xxxx slapd[13962]: do_syncrep2: rid 023 LDAP_RES_SEARCH_RESULT Nov 11 05:41:46 xxxx slapd[13962]: daemon: epoll: listen=7 active_threads=0 tvp =zero Nov 11 05:41:46 xxxx slapd[13962]: daemon: epoll: listen=8 active_threads=0 tvp =zero Any ideas what is problem? -- M. Tavasti / tavasti(a)tavasti.fi / +358-40-5078254

1 1

Trying to understand an error message
by Khaled Blah 12 Nov '10

12 Nov '10

Hello all, I have written an application which uses OpenLDAP and I keep receiving this error message: "sasl.c:75: ldap_sasl_bind: Assertion `( (ld)->ld_options.ldo_valid == 0x2 )' failed." The code at this position says the following: "assert( LDAP_VALID( ld ) );" My application creates LDAP structures (using ldap_init) and re-uses these structures whenever possible so that the least number of LDAP binds have to done. Is there anything I need to do after an LDAP operation has finished or maybe do I have to unbind at some point to make sure the LDAP structure remains in a valid state? I would be happy to receive any insight into this. Regards, Khaled

1 0

German Umlauts are converted and also not accepted
by Götz Reinicke - IT-Koordinator 11 Nov '10

11 Nov '10

Hallo, I'v searched for an answer but did not found one yet. I do have a openldap-2.3.43 server (centos 5.5.) in test and tried to add a ldif-file with my data using the apache directory studio (on mac os x). As my name contains a german umlaut I do get an error adding 'Götz Reinicke' for the gecko. Also for 'displayName', 'cn' and 'givenName' the 'ö' is automatically replaced by 'oe'. If I change the entry in the ldap by hand in the apache DS, the 'ö' is accepted accept for the geckos. An 'ü' in 'o' is manually accepted to. Any hints, explanations, suggestions? Thanks and best regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke(a)filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt

3 3

olcDbURI error
by Jaap Winius 11 Nov '10

11 Nov '10

Hi folks, After applying some changes to a consumer server used for testing purposes, my attempts to run slapcat result in the following error: #################################### slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config: slapcat: bad configuration file! #################################### (Debian squeeze, slapd v2.4.23-6) After having configure syncrepl on the same host, I used slapcat to compare its newly replicated database to the one on the provider. At that point it still worked and the databases proved to be identical. I then proceeded to configure chaining and a referral. The above slapcat error appeared after I made the following changes (which applied successfully): ########################################################################### # 1. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcUpdateref olcUpdateref: ldap://ldaps.example.com # 2. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}back_ldap # 3. dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE # 4. dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldaps.example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=ldaps2,dc=example,dc=com" credentials=bilineatus mode=self ########################################################################### Afterwards, slapd could no longer be restarted either, with the same error showing up in the syslog. I am aware that this is a known bug: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6540;selectid=6540 According to the report, a patch was made available on April the 29th, but I'm not sure if it actually fixed anything. At any rate, my Debian slapd version is dated from the 23rd of September and still has this problem. However, Followup 17 (31 July) in the bug report refers to a "simple fix". Unfortunately, I haven't yet been able to find what that's supposed to be. This seems to me to be a serious bug, but for the time being I'd be happy with simple workaround. Can anyone help? Thanks, Jaap

2 3

Asynchronicity
by William Ahern 11 Nov '10

11 Nov '10

Excepting DNS, is the latest release of OpenLDAP fully asynchronous-capable, even with TLS? Perusing the source code I can't find any obvious places other than DNS where things might block, but it's harder to prove the negative. I remember many years ago this wasn't the case, and I had to thread the connect phase, but the ChangeLog suggests that things have changed considerably.

3 5

number of contextcsn entries per database
by PJunod＠mediageneral.com 11 Nov '10

11 Nov '10

I have setup two ldap servers for authentication and access control in a multi-master configuration. I am concerned about the number of contextcsn entries that are supposed to be present in each database. Right now there are two servers participating in the multi-master configuration. From my understanding, there should be one contextCSN entry per database per host. My cn=config database has two contextCSN entries as I would expect. One for each syncrepl rid configured. My bdb database only has one contextCSN entry though, with an rid of just "000". (my rid's are 001, 002, 101, and 102) Replication seems to work fine on both databases. I can write to either one and the changes are replicated over immediately. I am just curious about this discrepancy in the number of contextCSN entries. Could someone confirm the number of contextCSN entries per database and if it should match the number of hosts participating in the multi-master replication? Here are some relevant settings for the replication: dn: cn=config olcServerID: 1 ldap://<server1> olcServerID: 2 ldap://<server2> ####################### # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap2.4 olcModuleLoad: {0}syncprov.la ####################### # {0}config, config dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes olcMirrorMode: TRUE ####################### # {0}syncprov, {0}config, config dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ####################### # {1}bdb, config dn: olcDatabase={1}bdb,cn=config olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" timeout=1 starttls=yes olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" timeout=1 starttls=yes olcMirrorMode: TRUE ############################## Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net: ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b "cn=config" contextCSN contextCSN: 20101110214932.998233Z#000000#000#000000 contextCSN: 20101028121213.444193Z#000000#001#000000 ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b "dc=mgcorp,dc=net" contextCSN contextCSN: 20101110213409.736943Z#000000#000#000000

2 1

Attributes for filtering OS logins
by Anton Chu 11 Nov '10

11 Nov '10

I have a scenario where I want to setup two LDAP groups where one group can access a file on the server while the other one cannot after they login. Can some PAM tweaks make this happen if not on the ldap side?

3 3

Re: ldapsearch performance degradation
by Tim Dyce 11 Nov '10

11 Nov '10

Hi Dieter, Thanks for the tips on tuning, sadly the problem is still haunting us :( Andrey Kiryanov at CERN has been doing a lot of work on this performance degradation problem as well. He has tried BDB 4.8.30 and OpenLDAP 2.4.23 but the problem is still apparent. The basic test we are running (sent earlier) creates 100 ou entries in the root, each with 250 child ou entries, then deletes 20-35% of these and re-adds them. For each deletion cycle the ldapsearch performance degrades, taking longer to complete the search each time. The performance is consistent, across restarts of slapd, and tied to the current state of the database. I have tried rsyncing out the database, and returning it later, and the performance is consistent with the number of deletion cycles the database has undergone. The only clue I have is that when dumping the databases which db_dump it's clear that the ordering of the database becomes increasingly less aligned with the order of the output data when doing a full tree search as we are. Which suggests that the database is writing frequently accessed entires too often instead of holding them in cache? I have run cachegrind against the server at 2, 20 and 1000 deletion iterations and the results are very different - http://www.ph.unimelb.edu.au/~tjdyce/callgrind.tar.gz The number of fetches grows massively over time. Anything you guys can suggest would be much appreciated, it's started to affect quite a number of our grid sites. Cheers, Tim > On 04/11/10 02:56, Dieter Kluenter wrote: >>> Hi Dieter, >>> >>> I've done some more testing with openldap 2.3 and 2.4, on Redhat and >>> Ubuntu. >>> I even went as far as placing the BDB database directory in a ramdisk. >>> But the performance still seems to degrade over time as data is added >>> then deleted repeatedly from the ldap server. >>> >>> It looks like the BDB database starts to fragment or lose structure >>> over time? >>> I've tried a few DB options that seem to have some impact. >>> >>> Any ideas on what I can do from here? >> Quite frankly, I have no clue, all i can do is guessing. First let's >> define the problem: you have measured the presentation of search >> Results the client side, and you observered an increase of time >> required to present the results. >> Mostlikely it is either a caching problem, a disk problem or a network >> problem. >> As far as openldap related, there are four caches to watch: >> 1. the bdb/hdb database (DB_CONFIG, cachesize) >> 2. the DN cache (dncachesize) >> 2. the cache of searched and indexed attribute types (idlcachesize) >> 3. the frontside cache of search results (cachesize) >> >> please check slapd.conf whether appropriate sizes are configured, see >> man slapd-bdb(5) and slapd.conf(5) for more information. >> >> But I must admit, a misconfiguration of any of this caches would not >> lead to such a degrading in presenting search results. >> >> An other approach would be to check the caching behaviour of clients, >> to check the network cache and the disk cache. >> >> -Dieter >> > -- ---------- Tim Dyce Research Computing EPP Group The School of Physics The University of Melbourne +61 3 8344 5462 +61 431 485 166

2 7

LDAPCon 2011?
by xsun 10 Nov '10

10 Nov '10

Hi there, There is something planned to 2011 about an LDAP Conference? I couldn't attend at 2009 and I think is too late for the conference on this year. Thanks, Matheus Morais

2 2

pamL-dap configuration guide
by Tim Dunphy 10 Nov '10

10 Nov '10

Hey List, I was just wondering if anyone happened to know of a good guide to use for configuring centos clients to authenticate pam modules (such as su, sudoers, ssh, system authentication and the like) against openLDAP? I am running a FreeBSD openLDAP server, but I believe that shouldn't affect the clients ability to log in via pam/ldap. At the moment I am googling this to not much avail! Thanks! -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

3 3

tls
by Christian Bösch 10 Nov '10

10 Nov '10

Hi Can someone tell me if it's possible to require strong encryption like TLS except from one IP address? /chris

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2010