openldap-technical August 2014

openldap-technical@openldap.org

62 participants
58 discussions

(no subject)
by Meunier, Antonin 25 Aug '14

25 Aug '14

Hello, In my openldap with mdb I imported a ldif that made add and modify (1000 objects). 95% of the file is processed in 2 minutes without problems. 5% of the rest of file is porcessed in more than 1 hour. The problem is on the groupOfName with lots of member (more than 1000 members). Each modify can take between 3 and 10 minutes. My Openldap is MMR with 2 servers. The problem appears only on one of the two ldap server. On the second one, each modification take 2 seconds. I've tried a reindex of the member attribute but nothing change. I've tried a delete and reimport (ldif file from the second server) the ldap and the problem persist. The configurations are the same on the 2 servers. What can explain this huge time to modify a group ? Exemple of a modification in my ldif file : dn: cn=522495,ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr changetype: modify add: member member: uid=2142279020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr dn: cn=522813, ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr changetype: modify add: member member: uid=1021253020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr Thanks a lot by advance Antonin Meunier

3 3

idassert-authzFrom ignored
by Charles Bueche 22 Aug '14

22 Aug '14

Hi, I have an OpenLDAP proxy using back_meta to talk to two back-ends Microsoft AD servers. My goal is to provide a single view of both AD trees. Basically, it works, as long as I use a bind account which exists in one of the back-end AD's. However, to first search where an AD account is, I would like to use a local account on the LDAP proxy. To my understanding, I need to use database meta suffix dc=proxy,dc=stuff,dc=ch rootdn "cn=root,dc=proxy,dc=stuff,dc=ch" rootpw "secret" subordinate ... idassert-bind bindmethod=simple binddn="CN=srvLDAP,..." credentials="..." mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=root,dc=proxy,dc=stuff,dc=ch" The DN "cn=root,dc=proxy,dc=stuff,dc=ch" does exist in the proxy and can do local searches. However, the account defined in the idassert is never used, and the connections to the back-ends AD's fail. Respectively, I think they are contacted using anonymous instead of the account I specify (not sure about the anonymous part, the debug log isn't very clear about it). Hints welcome. Below is a part of the relevant log if it helps. Charles .......... tls_read: want=64, got=64 0000: 65 87 ac 08 7e 49 8d 7f 95 3c d0 1f 09 57 b7 ce e...~I...<...W.. 0010: d4 13 2e ac 57 c9 27 6b 58 f7 76 70 a1 95 10 3e ....W.'kX.vp...> 0020: e2 96 0d cf a1 d3 13 ff e7 0b b1 2f c0 6f dc 19 .........../.o.. 0030: 93 38 07 b9 f7 e4 81 a8 e0 45 0e 97 ec 7f 21 a6 .8.......E....!. TLS trace: SSL_connect:SSLv3 read finished A ldap_int_poll: fd: -1 tm: 0 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=4 53679e3b conn=1000 op=1 <<< meta_back_search_start[0]=4 53679e3b conn=1000 op=1 meta_back_search: ncandidates=1 cnd="*" 53679e3b conn=1000 op=1 >>> meta_search_dobind_init[0] ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 12 tm: 0 ldap_is_sock_ready: 12 ldap_ndelay_off: 12 TLS trace: SSL_connect:before/connect initialization tls_write: want=225, written=225 0000: 16 03 01 00 dc 01 00 00 d8 03 02 53 67 9e 3b 55 ...........Sg.;U 0010: 4b 2f ee 53 01 81 ee ca 6a 3f a0 ea 85 3a c9 7e K/.S....j?...:.~ 0020: e3 01 d7 e6 d1 09 65 14 21 05 ef 00 00 66 c0 14 ......e.!....f.. 0030: c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f ...".!.9.8...... 0040: c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 ...5............ 0050: 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e ................ 0060: 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 .3.2.....E.D.... 0070: 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 ./...A.......... 0080: 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................ 0090: 00 03 00 ff 01 00 00 49 00 0b 00 04 03 00 01 02 .......I........ 00a0: 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c ...4.2.......... 00b0: 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 ................ 00c0: 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 ................ 00d0: 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 .........#...... 00e0: 01 . TLS trace: SSL_connect:SSLv3 write client hello A tls_read: want=5 error=Connection reset by peer TLS trace: SSL_connect:error in SSLv3 read server hello A TLS: can't connect: . ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=0 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ tls_write: want=69, written=69

1 1

Re : RE24 testing call (2.4.40)
by "POISSON Frédéric" 22 Aug '14

22 Aug '14

Hello, I have tested with success the rev 55eddb0 on an RHEL 5.3 x86_64. I also copy a small test file (starting from a copy of the 051) in order to check if the new code correct the ITS#7822 "Segmentation fault while modifying olcDbMaxSize". The test file (see attachment) succeed like this : # ./run -b mdb test065-config-update Cleaning up test run directory leftover from previous run. Running ./scripts/test065-config-update for mdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Check the olcDbMaxSize dn: olcDatabase={1}mdb,cn=config olcDbMaxSize: 10485760 Dynamically updating the olcDbMaxSize Re-check the olcDbMaxSize dn: olcDatabase={1}mdb,cn=config olcDbMaxSize: 123456789 >>>>> Test succeeded While if i run the same test on release 2.4.39 and older it fail with a seg fault. I'm not sure that this is a good test for future release of openldap but if you agree, the ITS#7822 could be closed if release 2.4.40 of openldap has the same behavior :-). Thanks a lot, Regards, Le 11/08/14 20:58, Quanah Gibson-Mount <quanah(a)zimbra.com> a écrit : > > If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.39 release, please do so. > > Generally, get the code for RE24: > > <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> > > Configure & build. > > Execute the test suite (via make test) after it is built. > > Thanks! > > --Quanah > > > -- > Quanah Gibson-Mount > Server Architect > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- Frederic Poisson

1 0

Accesslog: Excluding attributes from logging
by Oriol Rosa Ramoneda 22 Aug '14

22 Aug '14

4 5

memberof overlay surpresses accesslog olcAccessLogOps = all
by Jan Prinsloo 21 Aug '14

21 Aug '14

Hi All, I would appreciate it if someone could give me some insight into the following issue: I have a standalone openldap 2.4.26 setup. We would like to use the accesslog overlay for auditing. I have enabled the accesslog overlay with olcAccessLogOps = all. This writes all groups of operations (writes, reads, session) to cn=accesslog without issues. We would also like to make use of the memberof overlay. The issue we're seeing is that once you enable the memberof overlay, only search, unbind, add operations are logged to accesslog. We do not see delete, modify, modrdn values logged. If I then change the logops to "olcAccessLogOps = add delete modify modrdn" we see those operations logged, but no bind, search, unbind operations (ie. no reads or session). Is this a limitation of using these two overlay's together, or am I completely missing something? Here is the configuration output: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read structuralObjectClass: olcDatabaseConfig entryUUID: 174cbd2c-bbe1-1033-97e1-99c5bb2fcfe1 creatorsName: cn=config createTimestamp: 20140819113832Z entryCSN: 20140819113832.018426Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819113832Z dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=config structuralObjectClass: olcDatabaseConfig entryUUID: 174cc498-bbe1-1033-97e2-99c5bb2fcfe1 creatorsName: cn=config createTimestamp: 20140819113832Z olcAccess: {0}to * by * manage entryCSN: 20140819153732.253785Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819153732Z dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=novell,dc=com olcAccess: {0}to attrs=userPassword by self write by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to * by * read olcRootDN: cn=admin,dc=novell,dc=com olcRootPW:: e1NTSEF9eTUrcGVLRmtBSlY4aytQUVJZOVVDTzByN1FwV1RrbENSZz09 olcDbCacheSize: 10000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_cachesize 0 15000000 1 olcDbConfig: {1}set_lg_regionmax 262144 olcDbConfig: {2}set_lg_bsize 2097152 olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE olcDbConfig: {4}set_lk_max_locks 30000 olcDbConfig: {5}set_lk_max_objects 30000 olcDbIDLcacheSize: 30000 olcDbIndex: objectclass eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: member eq olcDbIndex: memberUid eq olcDbIndex: mail eq olcDbIndex: cn eq,sub olcDbIndex: displayName eq,sub olcDbIndex: uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: givenName eq,sub olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 174ccbbe-bbe1-1033-97e3-99c5bb2fcfe1 creatorsName: cn=config createTimestamp: 20140819113832Z entryCSN: 20140819114039.896372Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819114039Z dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcAccessLogDB: cn=accesslog olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 827deb2a-bbe1-1033-8b97-93a12773fffb creatorsName: cn=config createTimestamp: 20140819114131Z olcOverlay: {0}accesslog olcAccessLogOps: writes entryCSN: 20140819154607.969610Z#000000#000#000000 modifiersName: cn=admin,dc=novell,dc=com modifyTimestamp: 20140819154607Z dn: olcOverlay={1}refint,olcDatabase={1}bdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {1}refint olcRefintAttribute: memberof member manager owner structuralObjectClass: olcRefintConfig entryUUID: e5b204be-bbfb-1033-9b62-8fa7905953f2 creatorsName: cn=config createTimestamp: 20140819145025Z entryCSN: 20140819145025.207784Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819145025Z dn: olcDatabase={2}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=novell,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart structuralObjectClass: olcBdbConfig entryUUID: 827bc75a-bbe1-1033-8b95-93a12773fffb creatorsName: cn=config createTimestamp: 20140819114131Z entryCSN: 20140819114131.842907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819114131Z Regards, Jan Prinsloo

2 1

setting up mirroring with ldaps
by Sterling Sahaydak 20 Aug '14

20 Aug '14

Setting up mirroring between 2 servers - (ldap1 and ldap2) Have a self signed cert installed on ldap1(provider) and connecting to ldap2(consumer) which is using the same cert as ldap1. What I'm not sure about is can I put the same self signed cert on both ldap1 and ldap2? Or on ldap2 create a self signed cert and copy it to ldap1 and register it using (certutil) to fix the issue below? Thanks! [root@ldap1 log]# slapd -d Sync @(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) $ mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd /etc/openldap/slapd.conf: line 149: warning, destination attributeType 'sAMAccountName' is not defined in schema PROXIED attributeDescription "SAMACCOUNTNAME" inserted. /etc/openldap/slapd.conf: line 199: rootdn is always granted unlimited privileges. bdb_monitor_db_open: monitoring disabled; configure monitor database to enable slapd starting TLS: error: the certificate '/etc/openldap/certs/testldap1cert.pem' could not be found in the database - error -8174:security library: bad database.. TLS: certificate '/etc/openldap/certs/testldap1cert.pem' successfully loaded from PEM file. TLS: no unlocked certificate for certificate 'E=sterling.sahaydak(a)example.com,CN=ldap1.example.net,OU=IT,O=example,L=xxxx,ST=xx,C=xx'. TLS: hostname (ldap2.example.net) does not match common name in certificate (ldap1.example.net). TLS: can't connect: TLS error -8157:Certificate extension not found.. slap_client_connect: URI=ldaps://ldap2.example.net DN="cn=testsync,ou=roles,dc=example,dc=net" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=001 rc -1 retrying

1 0

question about ldap log file
by Wang, Holly 20 Aug '14

20 Aug '14

Hello, I am working on configure the OpenLDAP log file. Openldap has a document on the log level. However, I can't find where to configure the log file location and how to configure the log file in our current sladp.conf file. Where do we usually define the log file location? How to configure the log files? Holly Wang CSUN IT Department Identity and Directory Service 818-677-2031 holly.wang(a)csun.edu

2 1

TLS negotiation failed on ldaps:// - sslv3 alert bad record mac
by Oriol Rosa Ramoneda 19 Aug '14

19 Aug '14

2 1

Antw: Q: querying accesslog with reqStart>=partial time spec
by Ulrich Windl 18 Aug '14

18 Aug '14

>>> Ulrich Windl schrieb am 18.08.2014 um 11:53 in Nachricht <53F1CD10.741 : 161 : 60728>: > Hi! > > Can anybody explain when openLDAP with bdb succeeds on a filter like >(reqStart>=X) on accesslog? > When I use "(reqStart>=2014080100)" I get "no match", but when I use >"(reqStart>=20140801000)" I get the expected matches. > (And I don't get any match when just using "reqStart>=20140801)") > I see no log messages on the server's syslog... Sorry, I was telling nonsense (my program just dropped the longer stings) due to a bad regex match. It seems I must specify the full legth date specification (20140811073600.000000Z) > > Regards, > Ulrich > >

2 1

using {CRYPT} for rootpw, using SHA512?
by Brian Reichert 18 Aug '14

18 Aug '14

I've been messing with trying to get SHA512 password hash formats in openldap 2.4.39 under a 64-bit CentOS 6 distribution, using the LTB RPMs. I have read the FAQ at http://www.openldap.org/faq/data/cache/1467.html - The first entry describes a third-party module; I have been using that for years on a 32-bit CentOS 5 platform, using the vendor-provided openldap-2.3.43 RPMs. My efforts to build that module for 2.4.39 seemed to build clean, but effort to bind as a user with a {SHA512} hashed password cause slapd to segfault. I didn't try very hard to track that down, as there seem to be better supported techniques. - The third entry describes a slapo-pw-sha2 overlay, but no LTB RPM provides the overlay. I tried exactly once to build this overlay, but that failed due to a configure failure. I blame me; I'll revisit this when I have the time. However, I had some luck with the second entry, using {CRYPT}. Following these instructions, I was able to create users, successfully bind, and even use ldappasswd to change the passwords: http://www.openldap.org/lists/openldap-technical/201305/msg00002.html But, when I generated a hashed password using suggestions like this: http://serverfault.com/questions/330069/how-to-create-an-sha-512-hashed-pas… # python -c 'import crypt; print crypt.crypt("test", "$6$random_salt")' $6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10 and tried to embed this rootpw in my config file; rootpw {CRYPT}$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10 I would get bind errors. Have I misunderstood how to use {CRYPT} for storing root's password? -- Brian Reichert <reichert(a)numachi.com> BSD admin/developer at large

8 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2014