openldap-technical

openldap-technical@openldap.org

5 participants
9973 discussions

How to setup bindmethod=sasl
by Gaurav Gugnani 10 Jan '12

10 Jan '12

Hello All, I need to setup the encrypted password for replicator user in the slapd.conf Currently we have setup the replication process, however it is using: bindmethod=simple credentials=[password] But the requirement is like: that we want to specify encrypted password at credentials column. I know this can be achieved with bindmethod=sasl etc. I tried lot but got stuck with some or the other thing and ends up getting error at last. Can we have some document explaining step-by-step how to achieve it? Or some document putting more light on this issue? Thanks for your support. Regards, Gaurav Gugnani Version of OpenLdap - 2.4.26

1 0

ldif_back_add: err: 68 text:
by Maxim Vetrov 08 Jan '12

08 Jan '12

Hi! Trying to start test server (openldap 2.4.25) on my home box (FreeBSD 8.2 i386) I get this error: ... ldif_back_add: "olcDatabase={0}config,cn=config" oc_check_required entry (olcDatabase={0}config,cn=config), objectClass "olcDatabaseConfig" oc_check_allowed type "objectClass" oc_check_allowed type "olcDatabase" oc_check_allowed type "olcAddContentAcl" oc_check_allowed type "olcLastMod" oc_check_allowed type "olcMaxDerefDepth" oc_check_allowed type "olcReadOnly" oc_check_allowed type "olcRootDN" oc_check_allowed type "olcSyncUseSubentry" oc_check_allowed type "olcMonitoring" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=68 matched="" text="" slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. Config I use: # global configuration entry dn: cn=config objectClass: olcGlobal cn: config olcAttributeOptions: x-hidden lang- olcLogLevel: conns config acl # internal schema dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/etc/openldap/schema/core.ldif include: file:///usr/local/etc/openldap/schema/cosine.ldif include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif #include: file:///usr/local/etc/openldap/schema/collective.ldif include: file:///usr/local/etc/openldap/schema/nis.ldif # Load modules for database type dn: cn=module,cn=config objectclass: olcModuleList cn: module olcModulePath: /usr/local/libexec/openldap olcModuleLoad: back_bdb.so # global database parameters dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcAccess: to attrs=name;x-hidden by * =cs olcAccess: to attrs=userPassword by * auth olcAccess: to * by * read dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootPW: {SSHA}PHExDMWET41b/KoOHyTY1finE7Em3Xdo olcAccess: to * by * none # BDB definition for muxas.net dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=muxas,dc=net olcDbDirectory: /home/ldap/databases/muxas.net olcRootDN: cn=Administrator,ou=Users,dc=muxas,dc=net olcDbIndex: cn,sn,uid pres,eq,approx,sub olcDbIndex: objectClass eq olcAccess: to attrs=userPassword by self write by anonymous auth by * none olcAccess: to * by self write by * read I'm new to openldap software, so I have no guess what's the reason behind the error. I googled that error 68 means that there is duplicate entry in the DIT but there is no text part in the message so I don't know what entry is causing the error. Any help would be greatly appreciated! Maxim

2 3

OpenLDAP 2.4.28 RPMs for CentOS 5 and CentOS 6
by Clément OUDOT 06 Jan '12

06 Jan '12

Hi, I just published new versions of OpenLDAP 2.4.28 RPMs, for CentOS 5 and CentOS 6, see http://ltb-project.org/wiki/download#openldap They include a new version of init script in which I added two commands: # service slapd backupconfig # service slapd restoreconfig This allows to dump your cn=config, edit it and reload it very quick. Hope it helps, Clément.

1 0

misconfigured read-only replica causes master slapd to crash
by Kevan Carstensen 05 Jan '12

05 Jan '12

Hi, We use a single master and two read-only replicas; we use back-bdb on all systems. Each read-only replica replicates from the master with syncrepl, configured to refreshAndPersist. During a particularly heavy update load recently, replication on one of the read-only replicas started to fail due to a misconfigured DB_CONFIG. The replica wrote the following messages to its log repeatedly: Dec 14 04:01:08 pip-dev slapd[12645]: bdb(dc=csupomona,dc=edu): Lock table is out of available lock entries Dec 14 04:01:08 pip-dev slapd[12645]: => bdb_idl_delete_key: c_get failed: Cannot allocate memory (12) Dec 14 04:01:08 pip-dev slapd[12645]: conn=-1 op=0: attribute "memberUid" index delete failure Dec 14 04:01:08 pip-dev slapd[12645]: null_callback : error code 0x50 Dec 14 04:01:08 pip-dev slapd[12645]: syncrepl_entry: rid=001 be_modify failed (80) Dec 14 04:01:08 pip-dev slapd[12645]: do_syncrepl: rid=001 rc 80 retrying as it tried and failed to start replication again. Shortly after, the master slapd crashed, writing nothing to its log indicating why (or even referencing the crash at all). We initially noticed this behavior with a 2.4.26 master and a 2.4.28 read-only replica (we came upon this problem while performing some maintenance, which is why there's a version mismatch). I reproduced the problem on a 2.4.28 master while researching ITS #7113 [1] (which describes this problem more precisely and in more detail). Has anyone else run into this issue? Is there a good way to insulate the master slapd from misconfigured replicas? Our replicas shouldn't break like this (we've tuned our DB_CONFIG to ensure that they don't in the future), and hopefully slapd can be modified so that the master doesn't crash even if replicas do break, but we'd rather not have to worry about our master crashing if our DB_CONFIG proves inadequate in the meantime. [1] http://www.openldap.org/its/index.cgi/Incoming?id=7113 Thanks for any help, -- Kevan Carstensen <kacarstensen(a)csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

3 2

Re: Issue with index in OpenLDAP?
by External Mathieu DEDECKER (CAMPUS) 05 Jan '12

05 Jan '12

Hi Quanah and thank you again for your quick reply, I did not deleted the *.bdb files, but I moved them in a backup folder. My /db folder was empty, but the slapindex command failed because both "dn2id.bdb" and "id2entry.bdb" files was not present. I needed to add them in the /db folder in order to run the slapindex command. Then, all index have been re-generated. After the reindexation, the "cardnumber.bdb" file had the same size than before. Could you confirm me that it's the best process to reindex an OpenLDAP? Thank you, Mathieu 2012/1/5 Quanah Gibson-Mount <quanah(a)zimbra.com> > Hi Mathieu, > > It sounds like you didn't delete the cardnumber.bdb file before > reindexing? That is what I'd have done. > > Also, you previously had some questions about OpenLDAP tuning. You may > wish to read over <http://wiki.zimbra.com/wiki/** > OpenLDAP_Performance_Tuning<http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning>>. > Some of the bits in there have Zimbra specific names, but they all apply > directly to OpenLDAP and BDB in general. > > --Quanah > > > --On Wednesday, January 04, 2012 2:46 PM +0100 "External Mathieu DEDECKER > (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: > > I will read the man page in order to have more informations about the >> command. >> >> I tried to reindex all the index of the database with the slapindex >> command, but I allways the same behaviour: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> Other .bdb files size have been updated, but my "cardnumber.bdb" has >> still the same size. >> >> Regards, >> >> Mathieu >> >> >> 2012/1/4 Quanah Gibson-Mount <quanah(a)zimbra.com> >> >> Hi Mathieu, >> >> If you read the slapindex man page, it is possibly to just recreate a >> specific index file (for situations like this), rather than generating >> all of them. >> >> --Quanah >> >> >> --On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu >> DEDECKER (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: >> >> >> >> Hello Quanah, >> >> First I would like to thank you for your answer. >> >> Indeed, I also think that the "cardnumber" index is somehow corrupted. >> His size is to small in comparison to other indexes >> >> We suppressed all existing index and Used slapindex to re-create them all. >> >> It's undergoing. >> >> I will keep you informed about the solution. >> >> Best Regards, >> >> Mathieu >> >> >> 2012/1/3 Quanah Gibson-Mount <quanah(a)zimbra.com> >> >> >> >> >> >> --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER >> (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: >> >> >> Hi @All, >> >> We meet a performance problem with our OpenLDAP. >> >> We think that we face a problem with the index of the database, and we >> think that the problem can be resolve by tunning the config (but not >> sure). >> >> We would like to be sure that our configuration is correct, in order to >> confirm if we are on a wrong track or not. >> >> [Description] >> >> We have an attribute (cardNumber) which is indexed. >> >> When we request the indexed attribute (cardNumber) with an LDAP Client >> (Ldapbrowser), we have either fast or very long response time. >> >> For the long response time, the CPU of the server hits 100%. >> >> For example: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> By checking the hit ratio of the attribute, we can see that cache is >> correctly used (97%). >> >> >> It sounds like you added an index to cardnumber after there was already >> data for cardnumber in your database, and didn't run slapindex for that >> attribute. Alternatively, your cardnumber.bdb file is corrupted. >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> >> >> >> >> >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

problem with authentication to AD server with translucent overlay
by juhlig 04 Jan '12

04 Jan '12

I am using openldap 2.4.23-20 on Centos 6.2 server and trying to configure the translucent overlay to do simple user/password authentication (or anything that works) to our Microsoft AD servers. I can do authenticated commandline ldap searches with a Windows test account and password with no problems. I have tried to build a config based on the examples in the openldap admin and faq-o-matic web pages without success. All I get from the AD servers through my server are anonymous bind results. If anyone has this working, I would appreciate any information or config file samples as I need to deploy the server ASAP. thanks, John. p.s. I am not including my config files (ldap.conf,slapd.conf,etc.) as they are essentially copies of the ones from the openldap website. However, if you wish to see them, I can reply with the latest of 100 iterations :(

1 0

Re: Issue with index in OpenLDAP?
by External Mathieu DEDECKER (CAMPUS) 04 Jan '12

04 Jan '12

I will read the man page in order to have more informations about the command. I tried to reindex all the index of the database with the slapindex command, but I allways the same behaviour: Request1: cardnumber=2098001010034 (less than 1sec) Request2: cardnumber=2090389917486 (nearly 20 sec). Other .bdb files size have been updated, but my "cardnumber.bdb" has still the same size. Regards, Mathieu 2012/1/4 Quanah Gibson-Mount <quanah(a)zimbra.com> > Hi Mathieu, > > If you read the slapindex man page, it is possibly to just recreate a > specific index file (for situations like this), rather than generating all > of them. > > --Quanah > > > --On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu DEDECKER > (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: > > Hello Quanah, >> >> First I would like to thank you for your answer. >> >> Indeed, I also think that the "cardnumber" index is somehow corrupted. >> His size is to small in comparison to other indexes >> >> We suppressed all existing index and Used slapindex to re-create them all. >> >> It's undergoing. >> >> I will keep you informed about the solution. >> >> Best Regards, >> >> Mathieu >> >> >> 2012/1/3 Quanah Gibson-Mount <quanah(a)zimbra.com> >> >> >> --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER >> (CAMPUS)" <external.z02mdebe(a)oxylane.com**> wrote: >> >> >> Hi @All, >> >> We meet a performance problem with our OpenLDAP. >> >> We think that we face a problem with the index of the database, and we >> think that the problem can be resolve by tunning the config (but not >> sure). >> >> We would like to be sure that our configuration is correct, in order to >> confirm if we are on a wrong track or not. >> >> [Description] >> >> We have an attribute (cardNumber) which is indexed. >> >> When we request the indexed attribute (cardNumber) with an LDAP Client >> (Ldapbrowser), we have either fast or very long response time. >> >> For the long response time, the CPU of the server hits 100%. >> >> For example: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> By checking the hit ratio of the attribute, we can see that cache is >> correctly used (97%). >> >> >> It sounds like you added an index to cardnumber after there was already >> data for cardnumber in your database, and didn't run slapindex for that >> attribute. Alternatively, your cardnumber.bdb file is corrupted. >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

TLS issue (again)
by Olivier 04 Jan '12

04 Jan '12

I had to renew my openssl certificates and now my ldap tls negociation doesn't work anymore : $ ldapsearch -ZZ -D uid=guillard,ou=staff,ou=people,dc=example,dc=fr -W uid=guillard -h ldap2.th3.example.fr ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Unknown code ___f 20 Here are the server configuration relevant directives : olcTLSCACertificateFile /etc/openldap/cacerts/CA.crt olcTLSCertificateFile /etc/openldap/cacerts/server.crt olcTLSCertificateKeyFile /etc/openldap/cacerts/server.key olcTLSCipherSuite HIGH ( see at the very end of this mail : these certificates are correct since I have successfully proceed to openssl connexion tests). and here are logs collected on the server side when receiving ldapsearch request : daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(7): daemon: epoll: listen=7 busy >>> slap_listener(ldap://ldap2.th3.example.fr:389) daemon: listen=7, new connection on 15 daemon: added 15r (active) listener=(nil) conn=1003 fd=15 ACCEPT from IP=10.10.86.93:41013 (IP=10.1.92.25:389) daemon: activity on 2 descriptors daemon: activity on: 15r daemon: read active on 15 daemon: epoll: listen=7 active_threads=0 tvp=zero connection_get(15) connection_get(15): got connid=1003 connection_read(15): checking for input on id=1003 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_dump: buf=0x7f272017aa70 ptr=0x7f272017aa70 end=0x7f272017aa8d len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 op tag 0x77, time 1325683329 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1003 op=0 do_extended ber_scanf fmt ({m) ber: ber_dump: buf=0x7f272017aa70 ptr=0x7f272017aa73 end=0x7f272017aa8d len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 conn=1003 op=0 EXT oid=1.3.6.1.4.1.1466.20037 do_extended: oid=1.3.6.1.4.1.1466.20037 conn=1003 op=0 STARTTLS send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 15 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ conn=1003 op=0 RESULT oid= err=0 text= daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 15r daemon: read active on 15 daemon: epoll: listen=7 active_threads=0 tvp=zero connection_get(15) connection_get(15): got connid=1003 connection_read(15): checking for input on id=1003 tls_read: want=3, got=3 0000: 80 3a 01 .:. tls_read: want=57, got=57 0000: 03 01 00 21 00 00 00 10 00 00 35 00 00 04 00 00 ...!......5..... 0010: 05 00 00 2f 00 00 0a 00 00 09 00 00 64 00 00 62 .../........d..b 0020: 00 00 03 00 00 06 00 00 ff 70 1e 75 15 46 04 b3 .........p.u.F.. 0030: 16 ed d1 87 1c 77 58 06 48 .....wX.H tls_write: want=2157, written=2157 0000: 16 03 01 08 68 02 00 00 4d 03 01 4f 04 52 81 3c ....h...M..O.R.< 0010: c6 b8 b6 8a d8 4a 75 83 a7 fc 09 13 2c c8 d4 d4 .....Ju.....,... 0020: ce e7 12 73 80 bc 42 f6 f2 05 de 20 6c db 35 d1 ...s..B.... l.5. 0030: e0 2b bb 93 a4 c2 8c 82 df 51 58 0a 93 e6 c9 ff .+.......QX..... 0040: 10 0d 92 08 6c 96 3e f8 92 aa d8 83 00 35 00 00 ....l.>......5.. 0050: 05 ff 01 00 01 00 0b 00 06 d3 00 06 d0 00 02 e3 ................ 0060: 30 82 02 df 30 82 01 c7 02 09 00 a6 1d 1f 28 63 0...0.........(c 0070: 5e 6a 57 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 ^jW0...*.H...... 0080: 05 00 30 81 87 31 0b 30 09 06 03 55 04 06 13 02 ..0..1.0...U.... 0090: 66 72 31 0f 30 0d 06 03 55 04 08 0c 06 66 72 61 fr1.0...U....fra 00a0: 6e 63 65 31 11 30 0f 06 03 55 04 07 0c 08 6d 6f nce1.0...U....mo 00b0: 6e 74 69 67 6e 79 31 0e 30 0c 06 03 55 04 0a 0c ntigny1.0...U... 00c0: 05 61 66 6e 69 63 31 0d 30 0b 06 03 55 04 0b 0c .example1.0...U... 00d0: 04 6c 64 61 70 31 0d 30 0b 06 03 55 04 03 0c 04 .ldap1.0...U.... 00e0: 6c 64 61 70 31 26 30 24 06 09 2a 86 48 86 f7 0d ldap1&0$..*.H... 00f0: 01 09 01 16 17 6f 6c 69 76 69 65 72 2e 67 75 69 .....olivier.gui 0100: 6c 6c 61 72 64 40 6e 69 63 2e 66 72 30 1e 17 0d llard(a)example.fr0... 0110: 31 31 31 32 32 39 31 35 33 39 35 38 5a 17 0d 32 111229153958Z..2 0120: 31 30 37 32 39 31 35 33 39 35 38 5a 30 81 a2 31 10729153958Z0..1 0130: 0b 30 09 06 03 55 04 06 13 02 66 72 31 0f 30 0d .0...U....fr1.0. 0140: 06 03 55 04 08 0c 06 66 72 61 6e 63 65 31 11 30 ..U....france1.0 0150: 0f 06 03 55 04 07 0c 08 6d 6f 6e 74 69 67 6e 79 ...U....myplace 0160: 31 0e 30 0c 06 03 55 04 0a 0c 05 61 66 6e 69 63 1.0...U....example 0170: 31 0d 30 0b 06 03 55 04 0b 0c 04 6c 64 61 70 31 1.0...U....ldap1 0180: 28 30 26 06 03 55 04 03 0c 1f 6c 64 61 70 32 2e (0&..U....ldap2. 0190: 64 61 74 61 62 61 73 65 2e 70 72 69 76 65 2e 74 t 01a0: 68 33 2e 6e 69 63 2e 66 72 31 26 30 24 06 09 2a h3.example.fr1&0$..* 01b0: 86 48 86 f7 0d 01 09 01 16 17 4f 6c 69 76 69 65 .H........Olivie 01c0: 72 2e 47 75 69 6c 6c 61 72 64 40 6e 69 63 2e 66 r.Guillard(a)example.f 01d0: 72 30 5c 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 r0\0...*.H...... 01e0: 05 00 03 4b 00 30 48 02 41 00 bf 72 68 cc 54 9d ...K.0H.A..rh.T. 01f0: 10 d3 8b c0 4a 1b 5c 90 d6 03 7a 41 5e 05 6f 8d ....J.\...zA^.o. 0200: cc 2d 61 31 7b 94 0f c2 f7 c1 51 8a 4f d5 59 89 .-a1{.....Q.O.Y. 0210: 51 79 87 3f fa c3 5f af 30 8c 87 f8 ca be bb 0b Qy.?.._.0....... 0220: 28 8c d5 4a 3a 73 b5 a9 e3 d9 02 03 01 00 01 30 (..J:s.........0 0230: 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 03 82 ...*.H.......... 0240: 01 01 00 c0 3c 2a 0a d4 af 13 24 b5 2a 2b e3 cd ....<*....$.*+.. 0250: 0f 57 f6 86 99 e1 ae ba d7 b2 87 4e 02 a6 d6 a3 .W.........N.... 0260: 7d 9f 7b 89 03 61 ac b6 40 9e 93 ca 8d 3a d4 95 }.{..a..@....:.. 0270: 7a 48 e2 9a 01 2f ed 3d 2b c3 96 41 c0 58 39 cf zH.../.=+..A.X9. 0280: 52 a2 db 08 78 85 c4 85 17 08 d8 11 62 60 8e d0 R...x.......b`.. 0290: b5 61 71 fe 83 d5 94 9d f2 42 1d b5 56 bd fa 67 .aq......B..V..g 02a0: db 8e bf 09 af ef e3 b0 c8 0a f1 38 8b bf 59 75 ...........8..Yu 02b0: 6a 21 01 c0 0b 8c cf 87 20 d2 2f d9 89 a0 37 11 j!...... ./...7. 02c0: a0 62 6a a1 32 4b ff e4 cf 30 4c 8f 8e ef d2 51 .bj.2K...0L....Q 02d0: ec cc d1 fc 21 43 58 5e 09 40 8b bf ca bb fc 4f ....!CX^.@.....O 02e0: d1 d4 e9 cf 80 8f b1 af 72 d0 ff c1 d7 52 f3 4b ........r....R.K 02f0: e3 85 69 ef e9 36 6e 4d 54 13 d2 bd 3b 93 ad ed ..i..6nMT...;... 0300: 6e 36 cc 4f e6 b9 c5 01 1e 86 c8 88 aa de a6 7b n6.O...........{ 0310: c1 99 9a 3f c5 69 9e af e0 94 6e ba 51 5b ec 2a ...?.i....n.Q[.* 0320: 2c aa 09 ff 4a 27 15 96 ad 9f b0 5c f0 c4 9c 34 ,...J'.....\...4 0330: 53 32 03 1c d4 e2 dd b8 96 88 d2 5d b2 c6 e1 5e S2.........]...^ 0340: 32 ba 81 00 03 e7 30 82 03 e3 30 82 02 cb a0 03 2.....0...0..... 0350: 02 01 02 02 09 00 a1 67 1e 44 66 c6 f6 59 30 0d .......g.Df..Y0. 0360: 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 81 87 ..*.H........0.. 0370: 31 0b 30 09 06 03 55 04 06 13 02 66 72 31 0f 30 1.0...U....fr1.0 0380: 0d 06 03 55 04 08 0c 06 66 72 61 6e 63 65 31 11 ...U....france1. 0390: 30 0f 06 03 55 04 07 0c 08 6d 6f 6e 74 69 67 6e 0...U....montign 03a0: 79 31 0e 30 0c 06 03 55 04 0a 0c 05 61 66 6e 69 y1.0...U....afni 03b0: 63 31 0d 30 0b 06 03 55 04 0b 0c 04 6c 64 61 70 c1.0...U....ldap 03c0: 31 0d 30 0b 06 03 55 04 03 0c 04 6c 64 61 70 31 1.0...U....ldap1 03d0: 26 30 24 06 09 2a 86 48 86 f7 0d 01 09 01 16 17 &0$..*.H........ 03e0: 6f 6c 69 76 69 65 72 2e 67 75 69 6c 6c 61 72 64 olivier.guillard 03f0: 40 6e 69 63 2e 66 72 30 1e 17 0d 31 31 31 32 32 @example.fr0...11122 0400: 39 31 34 31 33 35 35 5a 17 0d 33 31 31 32 32 34 9141355Z..311224 0410: 31 34 31 33 35 35 5a 30 81 87 31 0b 30 09 06 03 141355Z0..1.0... 0420: 55 04 06 13 02 66 72 31 0f 30 0d 06 03 55 04 08 U....fr1.0...U.. 0430: 0c 06 66 72 61 6e 63 65 31 11 30 0f 06 03 55 04 ..france1.0...U. 0440: 07 0c 08 6d 6f 6e 74 69 67 6e 79 31 0e 30 0c 06 ...myplace1.0.. 0450: 03 55 04 0a 0c 05 61 66 6e 69 63 31 0d 30 0b 06 .U....example1.0.. 0460: 03 55 04 0b 0c 04 6c 64 61 70 31 0d 30 0b 06 03 .U....ldap1.0... 0470: 55 04 03 0c 04 6c 64 61 70 31 26 30 24 06 09 2a U....ldap1&0$..* 0480: 86 48 86 f7 0d 01 09 01 16 17 6f 6c 69 76 69 65 .H........olivie 0490: 72 2e 67 75 69 6c 6c 61 72 64 40 6e 69 63 2e 66 r.guillard(a)example.f 04a0: 72 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 r0.."0...*.H.... 04b0: 01 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 .........0...... 04c0: 01 00 c8 90 e1 61 d2 28 38 aa 35 a9 21 5b f7 2b .....a.(8.5.![.+ 04d0: f2 ed 04 5c 73 03 c5 f8 f9 97 5a 53 3b 39 bf aa ...\s.....ZS;9.. 04e0: 20 b8 45 c1 92 2e 27 ea bf b1 78 57 f9 41 a3 b3 .E...'...xW.A.. 04f0: 23 11 fc 8d 79 ea 21 a9 01 c0 ce 01 27 e6 0f a6 #...y.!.....'... 0500: 13 8d 12 5c 72 bf ba 60 41 71 76 94 99 da 43 f7 ...\r..`Aqv...C. 0510: e0 f9 b4 2f e7 25 7c 36 4f e9 4f dc 18 26 a9 7c .../.%|6O.O..&.| 0520: ad 98 2a 9c 91 16 76 41 31 1e 5d dd 81 2a b9 38 ..*...vA1.]..*.8 0530: ec 91 5c 91 11 03 fb 14 7d 59 d5 49 6d 32 42 c7 ..\.....}Y.Im2B. 0540: 66 73 58 b0 fb 02 b4 a0 4d 3e e3 3c ab ff 8c 42 fsX.....M>.<...B 0550: 83 51 b5 51 b7 19 71 61 f8 39 5c b7 8d 1a 70 97 .Q.Q..qa.9\...p. 0560: 69 5d e6 47 9e 7e ae ec 5c 7c be 73 7b d0 df df i].G.~..\|.s{... 0570: a7 53 6d a8 d3 d3 f6 7e e6 2f 13 3e c5 80 e6 f2 .Sm....~./.>.... 0580: fe 2a cc d4 1e 4d 3d 6a bc b0 a9 fa a5 51 12 31 .*...M=j.....Q.1 0590: 0e 41 2d 7a 8a 52 de 66 bd 3b 0c ef fa 9b fe 82 .A-z.R.f.;...... 05a0: df ad 1c 7f d9 53 4b c0 db fe f3 e6 b9 3d ea 5d .....SK......=.] 05b0: 66 7f fb 14 41 b5 0a e7 70 11 4e 5d 80 69 04 bd f...A...p.N].i.. 05c0: 9e 97 02 03 01 00 01 a3 50 30 4e 30 1d 06 03 55 ........P0N0...U 05d0: 1d 0e 04 16 04 14 24 05 af 2a 63 a4 0b 0f ae a4 ......$..*c..... 05e0: e2 2c e9 13 40 5a 8b d7 a4 41 30 1f 06 03 55 1d .,..@Z...A0...U. 05f0: 23 04 18 30 16 80 14 24 05 af 2a 63 a4 0b 0f ae #..0...$..*c.... 0600: a4 e2 2c e9 13 40 5a 8b d7 a4 41 30 0c 06 03 55 ..,..@Z...A0...U 0610: 1d 13 04 05 30 03 01 01 ff 30 0d 06 09 2a 86 48 ....0....0...*.H 0620: 86 f7 0d 01 01 05 05 00 03 82 01 01 00 57 2d 0a .............W-. 0630: d5 88 d0 98 2b 9e f9 d7 bc e6 82 08 65 25 d9 65 ....+.......e%.e 0640: 84 98 e3 da a3 36 a1 6f 40 3b d0 d8 16 3d 48 06 .....6.o@;...=H. 0650: 6c ee 99 fd b6 4c f3 3b 10 50 bb 71 97 6e 4d e0 l....L.;.P.q.nM. 0660: 77 48 57 5b db d1 e6 ca c8 80 79 d0 f5 17 94 5d wHW[......y....] 0670: 11 93 07 74 8b 5c 4b b1 ad 45 1f 5a 2c d9 6e e8 ...t.\K..E.Z,.n. 0680: d4 7a e4 99 e7 ba 86 36 93 1d 4c 0e 9b 13 4d ef .z.....6..L...M. 0690: 25 72 7b ae b0 f1 95 c0 17 dc 4a c0 ed 04 b5 54 %r{.......J....T 06a0: 98 90 47 2f dc f0 1c 5a ca b0 2e 0d ee 58 14 e8 ..G/...Z.....X.. 06b0: 2c d0 cd a8 d9 2c ae 2f 65 81 89 70 af f9 d8 01 ,....,./e..p.... 06c0: 1b 14 ae 63 1d 90 af 3d 29 71 7d 74 4a e8 7a e5 ...c...=)q}tJ.z. 06d0: ed a0 fb 9b ce 1d 5a e2 82 7e c4 bc 97 88 e7 06 ......Z..~...... 06e0: 66 86 77 23 85 29 2c b1 28 72 8c af a5 51 96 b1 f.w#.),.(r...Q.. 06f0: d5 dc 51 62 bd 2d e6 8f 4c 22 24 4e e1 c6 a3 64 ..Qb.-..L"$N...d 0700: 40 fc e9 d8 6d b1 48 d8 80 10 3a 6a bc 35 06 d9 @...m.H...:j.5.. 0710: 4c e8 4c e6 66 82 9d fd a9 a2 9f 3e 13 37 c0 52 L.L.f......>.7.R 0720: 3f c3 15 e1 3e 9c 05 67 b2 11 0d 38 a4 0d 00 01 ?...>..g...8.... 0730: 38 02 01 02 01 33 00 8a 30 81 87 31 0b 30 09 06 8....3..0..1.0.. 0740: 03 55 04 06 13 02 66 72 31 0f 30 0d 06 03 55 04 .U....fr1.0...U. 0750: 08 0c 06 66 72 61 6e 63 65 31 11 30 0f 06 03 55 ...france1.0...U 0760: 04 07 0c 08 6d 6f 6e 74 69 67 6e 79 31 0e 30 0c ....myplace1.0. 0770: 06 03 55 04 0a 0c 05 61 66 6e 69 63 31 0d 30 0b ..U....example1.0. 0780: 06 03 55 04 0b 0c 04 6c 64 61 70 31 0d 30 0b 06 ..U....ldap1.0.. 0790: 03 55 04 03 0c 04 6c 64 61 70 31 26 30 24 06 09 .U....ldap1&0$.. 07a0: 2a 86 48 86 f7 0d 01 09 01 16 17 6f 6c 69 76 69 *.H........olivi 07b0: 65 72 2e 67 75 69 6c 6c 61 72 64 40 6e 69 63 2e er.guillard@example. 07c0: 66 72 00 a5 30 81 a2 31 0b 30 09 06 03 55 04 06 fr..0..1.0...U.. 07d0: 13 02 66 72 31 0f 30 0d 06 03 55 04 08 0c 06 66 ..fr1.0...U....f 07e0: 72 61 6e 63 65 31 11 30 0f 06 03 55 04 07 0c 08 rance1.0...U.... 07f0: 6d 6f 6e 74 69 67 6e 79 31 0e 30 0c 06 03 55 04 myplace1.0...U. 0800: 0a 0c 05 61 66 6e 69 63 31 0d 30 0b 06 03 55 04 ...example1.0...U. 0810: 0b 0c 04 6c 64 61 70 31 28 30 26 06 03 55 04 03 ...ldap1(0&..U.. 0820: 0c 1f 6c 64 61 70 32 2e 64 61 74 61 62 61 73 65 ..ldap2. 0830: 2e 70 72 69 76 65 2e 74 68 33 2e 6e 69 63 2e 66 .th3.example.fr 0840: 72 31 26 30 24 06 09 2a 86 48 86 f7 0d 01 09 01 1&0$..*.H....... 0850: 16 17 4f 6c 69 76 69 65 72 2e 47 75 69 6c 6c 61 .Olivier.Guilla 0860: 72 64 40 6e 69 63 2e 66 72 0e 00 00 00 rd(a)example.fr.... tls_read: want=5 error=Resource temporarily unavailable daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 15r daemon: read active on 15 daemon: epoll: listen=7 active_threads=0 tvp=zero connection_get(15) connection_get(15): got connid=1003 connection_read(15): checking for input on id=1003 tls_read: want=5, got=5 0000: 15 03 01 00 02 ..... tls_read: want=2, got=2 0000: 02 30 .0 TLS: error: accept - force handshake failure: errno 11 - moznss error -12195 TLS: can't accept: TLS error -12195:Unknown code ___P 93. connection_read(15): TLS accept failure error=-1 id=1003, closing connection_closing: readying conn=1003 sd=15 for close connection_close: conn=1003 sd=15 daemon: removing 15 conn=1003 fd=15 closed (TLS negotiation failure) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero ^Cdaemon: shutdown requested and initiated. daemon: closing 7 connection_closing: readying conn=1000 sd=13 for close connection_close: conn=1000 sd=13 daemon: removing 13 conn=1000 fd=13 closed (slapd shutdown) As far as I can see it doesn't looks like [root@ldap2 cacerts]# openssl s_server -accept 5555 -key /etc/openldap/cacerts/server.key -cert /etc/openldap/cacerts/server.crt -state Using default temp DH parameters ACCEPT SSL_accept:before/accept initialization SSL_accept:SSLv3 read client hello A SSL_accept:SSLv3 write server hello A SSL_accept:SSLv3 write certificate A SSL_accept:SSLv3 write key exchange A SSL_accept:SSLv3 write server done A SSL_accept:SSLv3 flush data SSL_accept:SSLv3 read client key exchange A SSL_accept:SSLv3 read finished A SSL_accept:SSLv3 write session ticket A SSL_accept:SSLv3 write change cipher spec A SSL_accept:SSLv3 write finished A SSL_accept:SSLv3 flush data -----BEGIN SSL SESSION PARAMETERS----- MFoCAQECAgMBBAIAOQQABDB88nXC0TcyHgrQcZ+51a/16Nw874VzV1cEEkOMwfSy VCIJ8jOiylXmk2gHkAK7y6OhBgIETwRP56IEAgIBLKQGBAQBAAAAqwMEAQE= -----END SSL SESSION PARAMETERS----- Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AES256-SHA:CAMELLIA256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5 CIPHER is DHE-RSA-AES256-SHA Secure Renegotiation IS supported ERROR shutting down SSL CONNECTION CLOSED ACCEPT [guillard@fouine ~]$ openssl s_client -CAfile /etc/openldap/cacerts/CA.crt -connect ldap2.th3.example.fr:5555 CONNECTED(00000003) depth=1 C = fr, ST = france, L = myplace, O = example, OU = ldap, CN = ldap, emailAddress = olivier.guillard(a)example.fr verify return:1 depth=0 C = fr, ST = france, L = myplace, O = example, OU = ldap, CN = ldap2.th3.example.fr, emailAddress = Olivier.Guillard(a)example.fr verify return:1 --- Certificate chain 0 s:/C=fr/ST=france/L=myplace/O=example/OU=ldap/CN=ldap2.th3.example.fr/emailAddress=Olivier.Guillard@example.fr i:/C=fr/ST=france/L=myplace/O=example/OU=ldap/CN=ldap/emailAddress=olivier.guillard@example.fr --- Server certificate -----BEGIN CERTIFICATE----- MIIC3zCCAccCCQCmHR8oY15qVzANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMC ZnIxDzANBgNVBAgMBmZyYW5jZTERMA8GA1UEBwwIbW9udGlnbnkxDjAMBgNVBAoM BWFmbmljMQ0wCwYDVQQLDARsZGFwMQ0wCwYDVQQDDARsZGFwMSYwJAYJKoZIhvcN AQkBFhdvbG24KJJD7GJVBIYTIVHTFJCGFDHGFXGRFCYTDFYTDjkxNTM5NThaFw0y MTA3MjkxNTM5NThaMIGiMQswCQYDVQQGEwJmcjEPMA0GA1UECAwGZnJhbmNlMREw DwYDVQQHDAhtb250aWdueTEOMAwGA1UECgwFYWZuaWMxDTALBgNVBAsMBGxkYXAx KDAmBgNVBAMMH2xkYXAyLmRhdGFiYXNlLnByaXZlLnRoMy5uaWMuZnIxJjAkBgkq hkiG9w0BCQEWFNBIHGJ4UTFHGXCYTDCYXDYCYTFCUGCUTTFUYFUJKoZIhvcNAQEB BQADSwAwSAJBAL9yaMxUnRDTi8BKG1yQ1gN6QV4Fb43MLWExe5QPwvfBUYpP1VmJ UXmHP/rDX68wjIf4yr67CyiM1Uo6c7Wp49kCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEAwDwqCtSvEyS1KivjzQ9X9oaZ4a6617KHTgKm1qN9n3uJA2GstkCek8qNOtSV ekjimgEv7T0rw5ZBwFg5z1Ki2wh4hcSFFwjYEWJgjtC1YXH+g9WUnfJCHbVWvfpn 246NBVJHJHVJVJJKVJHVJHVJKHVJHVJHVJHVJHVJHVJHVJHVJHVJHVJHVJHV79JR 7MzR/CFDWF4JQIu/yrv8T9HU6c+Aj7GvctD/wddS80vjhWnv6TZuTVQT0r07k63t bjbMT+a5xQEehsiIqt6me8GZmj/FaZ6v4JRuulFb7Cosqgn/SicVlq2fsFzwxJw0 UzIDHNTi3biWiNJdssbhXjK6gQ== -----END CERTIFICATE----- subject=/C=fr/ST=france/L=myplace/O=example/OU=ldap/CN=ldap2.th3.example.fr/emailAddress=Olivier.Guillard(a)example.fr issuer=/C=fr/ST=france/L=myplace/O=example/OU=ldap/CN=ldap/emailAddress=olivier.guillard(a)example.fr --- No client certificate CA names sent --- SSL handshake has read 1265 bytes and written 247 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 512 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: DBCDE5CD6EB4D7FF8C38DD1557CA90EDBEDDCB27600CFA4D1FD9D58388A11EBE Session-ID-ctx: Master-Key: 7CF275C2D137321E0AD0719FB9D5AFF5E8DC3CEF857357570412438CC1F4B2542209F233A2CA55E69368079002BBCBA3 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket: 0000 - c2 bb 20 23 85 0a cf b0-bc b2 6d cd 4b d2 32 0e .. #......m.K.2. 0010 - 6f 51 29 7f 3a 44 c3 95-76 c2 c6 23 e5 8d 98 3c oQ).:D..v..#...< 0020 - 7a b9 eb 6b 8e d1 c5 c4-57 74 26 34 4c db ec fe z..k....Wt&4L... 0030 - a9 3b 77 12 fb 74 67 fb-57 f1 8f 2a 71 d3 a6 ae .;w..tg.W..*q... 0040 - 17 48 9e bf 7d 94 1f c3-d4 02 6e 7f 27 07 f4 d6 .H..}.....n.'... 0050 - 98 6f 24 6c f9 63 b7 4c-cd ce d8 85 e5 be 3e fd .o$l.c.L......>. 0060 - 65 a2 1b 36 cc 26 76 3b-d3 f6 cf e1 f9 a7 c3 c2 e..6.&v;........ 0070 - 2f fe 8f 3c 7c d1 0f 58-43 be d7 a5 64 69 04 91 /..<|..XC...di.. 0080 - cb 68 08 82 fe 8d 9d 4e-1b 0f 96 27 59 5e d8 76 .h.....N...'Y^.v 0090 - be 44 01 6d 53 2e 9e 67-22 07 35 d1 6f a4 80 e1 .D.mS..g".5.o... Compression: 1 (zlib compression) Start Time: 1325682663 Timeout : 300 (sec) Verify return code: 0 (ok) --- ^C

3 2

Re: slapd-ldap as proxy to active directory
by Juan Miscaro 04 Jan '12

04 Jan '12

On 14 December 2011 17:44, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, December 14, 2011 3:40 PM -0500 Juan Miscaro > <jmiscaro(a)gmail.com> wrote: >> I would like to use the slapd-ldap backend as a proxy to Active >> Directory (Windows Server 2008 R2). >> >> Firstly, AD can be queried directly: > Does your local OpenLDAP have a schema file that defines the AD attributes > you are using? No. I read that since OpenLDAP 2.3 this was not necessary (I'm running 2.4.25 on Ubuntu 11.10). I got my project from a tutorial [1] where this all worked. [1]: http://is.gd/dqM1Ts (see section "Using OpenLDAP 2.3 to Pass Unknown Schema" on page 2) -- /jm

5 7

Re: Issue with index in OpenLDAP?
by Quanah Gibson-Mount 04 Jan '12

04 Jan '12

Hi Mathieu, If you read the slapindex man page, it is possibly to just recreate a specific index file (for situations like this), rather than generating all of them. --Quanah --On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu DEDECKER (CAMPUS)" <external.z02mdebe(a)oxylane.com> wrote: > Hello Quanah, > > First I would like to thank you for your answer. > > Indeed, I also think that the "cardnumber" index is somehow corrupted. > His size is to small in comparison to other indexes > > We suppressed all existing index and Used slapindex to re-create them all. > > It's undergoing. > > I will keep you informed about the solution. > > Best Regards, > > Mathieu > > > 2012/1/3 Quanah Gibson-Mount <quanah(a)zimbra.com> > > > --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER > (CAMPUS)" <external.z02mdebe(a)oxylane.com> wrote: > > > Hi @All, > > We meet a performance problem with our OpenLDAP. > > We think that we face a problem with the index of the database, and we > think that the problem can be resolve by tunning the config (but not > sure). > > We would like to be sure that our configuration is correct, in order to > confirm if we are on a wrong track or not. > > [Description] > > We have an attribute (cardNumber) which is indexed. > > When we request the indexed attribute (cardNumber) with an LDAP Client > (Ldapbrowser), we have either fast or very long response time. > > For the long response time, the CPU of the server hits 100%. > > For example: > > Request1: cardnumber=2098001010034 (less than 1sec) > Request2: cardnumber=2090389917486 (nearly 20 sec). > > By checking the hit ratio of the attribute, we can see that cache is > correctly used (97%). > > > It sounds like you added an index to cardnumber after there was already > data for cardnumber in your database, and didn't run slapindex for that > attribute. Alternatively, your cardnumber.bdb file is corrupted. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical