openldap-technical

openldap-technical@openldap.org

13 participants
9906 discussions

s_client working against 636 but not 389
by Nate Marks 04 Sep '11

04 Sep '11

[root@ldap01 cacerts]# netstat -panv | grep slap ... tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 3220/slapd tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 3220/slapd [root@ldap01 cacerts]# grep TL /etc/openldap/slapd.conf # The next three lines allow use of TLS for encrypting connections using a # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCACertificateFile /etc/pki/CA/cacert.pem TLSCACertificateFile /etc/pki/tls/certs/cacert.pem # TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateFile /etc/openldap/cacerts/ldap01.infra.ops.hcs.cert.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/openldap/cacerts/ldap01.infra.ops.hcs.key.pem ***COMMENT: This command seems a little slow, but it succeeds *** [root@ldap01 cacerts]# openssl s_client -CAfile /etc/pki/tls/certs/cacert.pem -connect 10.60.1.57:636 CONNECTED(00000003) depth=1 /C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs verify return:1 depth=0 /C=US/ST=MA/L=Waltham/O=NWN Corporation/OU=hcs/CN=ldap01.infra.ops.hcs/emailAddress=support(a)nwnit.com verify return:1 --- Certificate chain 0 s:/C=US/ST=MA/L=Waltham/O=NWN Corporation/OU=hcs/CN=ldap01.infra.ops.hcs/emailAddress=support(a)nwnit.com i:/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs 1 s:/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs i:/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs --- Server certificate -----BEGIN CERTIFICATE----- MIIDATCCAmqgAwIBAgIJANZXaZL0G6eAMA0GCSqGSIb3DQEBBQUAMHIxCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJNQTEYMBYGA1UEChMPTldOIENvcnBvcmF0aW9uMQww CgYDVQQLEwNoY3MxEzARBgNVBAMTCmNhLm9wcy5oY3MxGTAXBgkqhkiG9w0BCQEW CmNhQG9wcy5oY3MwHhcNMTEwODMxMDkwOTEyWhcNMTIwODMwMDkwOTEyWjCBlTEL MAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1BMRAwDgYDVQQHEwdXYWx0aGFtMRgwFgYD VQQKEw9OV04gQ29ycG9yYXRpb24xDDAKBgNVBAsTA2hjczEdMBsGA1UEAxMUbGRh cDAxLmluZnJhLm9wcy5oY3MxIDAeBgkqhkiG9w0BCQEWEXN1cHBvcnRAbnduaXQu Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDV/XlgAuwbisnokbCXUvXz M5SXTeG6D697Sgh7ggcvdwVprKlfFWCLu3RcSkBbJ69bTDgRQS6qlplUm9kB44XB Ej+8w+YVvTGxZWYIxyr3u2SKYFrIVj4DpeCZyYrgFds9JK9YGh6cDj57PGXbw9aK ApE1SKPNx2SCkMy9WSzLOwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUdO79 lD14LPMt0cviy00Bi/zoVz8wHwYDVR0jBBgwFoAURUA5pElJg/XvOcDIdWZ6W+EN 54IwDQYJKoZIhvcNAQEFBQADgYEANOSnNbRW+US5xf4fQrz0M765wuOKjvuWK4yG K5GcWPv8zAM9bEf0Ju9A9RiMzxwDfQndRQ84fTELXKQeHFYa0ELse8G4ZdxRyEtN GzigGoPQYqtofW3N2mIRb85RntHoIBwfrhnogsY2UXssIWc/8CGgwp4OjtYhiXMU JtHLAms= -----END CERTIFICATE----- subject=/C=US/ST=MA/L=Waltham/O=NWN Corporation/OU=hcs/CN=ldap01.infra.ops.hcs/emailAddress=support(a)nwnit.com issuer=/C=US/ST=MA/O=NWN Corporation/OU=hcs/CN=ca.ops.hcs/emailAddress=ca(a)ops.hcs --- No client certificate CA names sent --- SSL handshake has read 1775 bytes and written 319 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 1F3B030DD062E3EFC3E143DF978A622DD8B0E2167331EAC45C307C8997F59BC3 Session-ID-ctx: Master-Key: 834A1CF62289DB6C4367109B9EF2172796A4AF403F4FE040C4EDDC48ED722437E96717A860038A70323DFFD1EDE3562D Key-Arg : None Krb5 Principal: None Start Time: 1315065479 Timeout : 300 (sec) Verify return code: 0 (ok) --- *** COMMENT: This obviosly doesn't *** [root@ldap01 cacerts]# openssl s_client -CAfile /etc/pki/tls/certs/cacert.pem -connect 10.60.1.57:389 CONNECTED(00000003) 4392:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: [root@ldap01 cacerts]# The only thing I could think of is a timeout difference between ssl and tls, iun which case I'll be fine wheh I figure out why it's slow, but I'd like to validate that before moving on to the slowness problem. ANyone have ideas?

2 1

same users / groups in different openldap instances
by Bernhard Dübi 04 Sep '11

04 Sep '11

Hello everybody, I'm new to openldap and I don't know if this is the right place to ask. If not, please direct me to the correct tool. Thanks I have a openldap instance for unix / Linux users with Kerberos integration. Now I need an LDAP server for Oracle Names (or what ever the correct term is for that service). In a book I read that it is not a good idea to have multiple databases in the same openldap instance. So I decided to create a new instance of openldap. The unix directory has the base dn="dc=unix,dc=mycorp,dc=org". The oracle directory has the base dn="dc=oracle,dc=mycorp,dc=org". Now my problem is, I want to allow a group of people from my unix directory to update the oracle directory. Is that possible? If yes, how? if no, what is best practice to implement such a problem? Sincerely Bernhard

1 0

syncrepl giving error "CSN too old, ignoring " for detla replication
by Rupesh Thakkar 03 Sep '11

03 Sep '11

Hi, I am using openldap 2.4.23-12.el6.i686 for provider and openldap version 2.2.28-4AV1.1 for slave. My configuration is Provider with proxy consumer on one machin and slave on another machine. I am getting error “CSN too old, ignoring” in logs(provide-proxycosumer config) slap_queue_csn: queing 0x8d7fe85e 20110901223155.770109Z#000000#000#000000 slap_graduate_commit_csn: removing 0x8d805020 20110901223155.770109Z#000000#000#000000 slap_queue_csn: queing 0x8b9fb300 20110901223155.770109Z#000000#000#000000 syncprov_sendresp: cookie=rid=128,csn=20110901223155.770109Z#000000#000#000000 do_syncrep2: rid=128 cookie=rid=128,csn=20110901223155.770109Z#000000#000#000000 do_syncrep2: rid=128 CSN too old, ignoring 20110901223155.770109Z#000000#000#000000 slap_graduate_commit_csn: removing 0x8d80b9a8 20110901223155.770109Z#000000#000#000000 Do my both provider and slave machines needs times synched using NTP or lag of few seconds is allowed (1-2 seconds)? Thanks Rupesh

3 3

RH EL Openldap dies after update at night ....
by Götz Reinicke 03 Sep '11

03 Sep '11

Hi, recently I updated our ldapd on our RH EL 6.1 to the most recent RH EL version openldap-2.4.23-15.el6_1.1.x86_64 (from 2.4.19-15) Since than the deamon died in the middle of the night nearly every night, leaving no traces to me why. The 2.4.19-15-version never died ... Any hints or suggestions on how to debug that problem? What information may I provide? 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 Vorsitzender des Aufsichtsrats: Jürgen Walter MdL Staatssekretär im Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg Geschäftsführer: Prof. Thomas Schadt

3 2

Question on best way to partially disable users
by Ski Kacoroski 02 Sep '11

02 Sep '11

Hi, I have an openldap server that several applications use for authenication. What we need to do is when a person is disabled, we need to disable access for that user for all applications but one (employeeonline). My first thought was simply to move the disabled person to a different OU (e.g. ou=eoonly,dc=... instead of ou=people,dc=...). The problem I am running into is that employeeonline is windows/vbscript that uses SASL to bind which means that I cannot just move the user to a different OU as they are always coming in as sasl-realm OL.NSD.ORG. Does any one have a good trick for how to do this? So far all I have come up with is: 1. Bind as a admin user and then check the user's password instead of binding as the user. 2. Figure out someway for vbscript to bind as a different SASL realms. Thanks in advance for your advice. cheers, ski -- "When we try to pick out anything by itself, we find it connected to the entire universe" John Muir Chris "Ski" Kacoroski, Unix Admin, NSD 206-501-9803, ski98033 on IRC and most IM services

2 2

change syncrepl creds with no restart?
by Christopher Wood 02 Sep '11

02 Sep '11

(I'm having trouble finding the answer with Google, so inquiring here. If you have RTFM urls I will be quite happy indeed.) It looks like I'm unable to change syncrepl (client) credentials without restarting slapd. When I tried this I couldn't modify an entry after the change, with an error message apparently indicating that this was a replicated consumer. Things went back to multimaster-normal after restarting both slapd's involved. My questions (more details are below): 1) Is this intended? 2) Is there something that I can prod slapd with in order to have it change syncrepl credentials without restarting slapd? (Details caveats: s/${companyname}/base/; munged hostnames too; I have checked that all passwords are the same on the real hosts just like here; I have checked that the syncrepl provider= are correct on the real hosts): The "before" state is me using the olcRootDN for multimaster syncrepl, on the grounds that I wanted to set it up quickly in the lab. Now I want to use a less privileged user. All changes to cn=config were replicated between supplier hosts. First I added a new user: dn: uid=sync,o=base userPassword:: YmFzZQ== objectClass: account objectClass: shadowAccount uid: sync Then I gave that user read access to everything: dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess olcAccess: to dn.subtree="uid=basero,o=base" by anonymous auth by dn=uid=basero,o=base by dn=uid=sync,o=base read olcAccess: to attrs="userPassword" by anonymous auth by self read by dn=uid=basero,o=base by dn=uid=sync,o=base read olcAccess: to dn.subtree="ou=groups,o=base" by * read olcAccess: to dn.subtree="ou=people,o=base" by * read olcAccess: to * by dn=uid=sync,o=base read The acls for the o=base tree were then: olcAccess: {0}to dn.subtree="uid=basero,o=base" by anonymous auth by dn=uid=basero,o=base read olcAccess: {1}to attrs="userPassword" by anonymous auth by self read by dn=uid=basero,o=base read olcAccess: {2}to dn.subtree="ou=groups,o=base" by * read olcAccess: {3}to dn.subtree="ou=people,o=base" by * read olcAccess: {4}to * by dn=uid=sync,o=base read So I updated the olcSyncrepl rules: dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcSyncRepl olcSyncrepl: rid=003 provider=ldap://ldap-supplier-lab-01 binddn="uid=sync,o=base" bindmethod=simple credentials=base searchbase="o=base" type=refreshOnly interval=00:00:00:10 retry="5 5 30 +" timeout=1 olcSyncrepl: rid=004 provider=ldap://ldap-supplier-lab-02 binddn="uid=sync,o=base" bindmethod=simple credentials=base searchbase="o=base" type=refreshOnly interval=00:00:00:10 retry="5 5 30 +" timeout=1 However, when I attempted to change my password on one of the hosts (using o=base not cn=config)... dn: uid=cwood,ou=people,o=base changetype: modify add: userPassword userPassword: fakefakefake I got this: modifying entry "uid=cwood,ou=people,o=base" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral And this is what turned up in the logs: Sep 1 11:34:03 ldap-supplier-lab-01 slapd[8549]: conn=42902 op=1 MOD dn="uid=cwood,ou=people,o=base" Sep 1 11:34:03 ldap-supplier-lab-01 slapd[8549]: conn=42902 op=1 MOD attr=userPassword Sep 1 11:34:03 ldap-supplier-lab-01 slapd[8549]: conn=42902 op=1 RESULT tag=103 err=53 text=shadow context; no update referral Sep 1 11:34:03 ldap-supplier-lab-01 slapd[8549]: conn=42902 op=2 UNBIND

2 2

LDAP authentication of unregistered user at client side.
by vijay s sheelavantar 02 Sep '11

02 Sep '11

Hi Friends, I have a openldap server running on one machine (fedora10) and pam_ldap.so and nss_ldap.so running on the other machine. I have added a new user to the LDAP server database, this user is not created on client machine. 1. Can i login to the client machine using this new user?2. Now if i try logging with this new user I am getting error messages, the error messages are as follows at client side Sep  2 10:34:36 localhost sshd[8484]: Invalid user kim from 10.254.194.148Sep  2 10:34:36 localhost sshd[8485]: input_userauth_request: invalid user kim Sep  2 10:35:16 localhost sshd[8484]: pam_ldap: error trying to bind as user "cn=min soo,ou=people,dc=samsung,dc=com" (Invalid credentials)Sep  2 10:35:16 localhost sshd[8484]: pam_succeed_if(sshd:auth): error retrieving information about user kimSep  2 10:35:16 localhost sshd[8484]: Failed password for invalid user kim from 10.254.194.148 port 52652 ssh2 Kindly let me know is it a limitation with LDAP ??? Thanks and Regards,VIJAY S.

2 1

OpenLDAP client test program connecting to LDAP server over SSL failed
by daisy.wu＠emc.com 01 Sep '11

01 Sep '11

I am trying to write a simple client test program using OpenLDAP client API to connect to Microsoft Active Directory Server over SSL. Below is code snippet. The program failed to connect. It failed because of this error: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I know there's no problem with LDAP certificate store /path/to/ldap_certdb because a simple LDAP client test program written in Mozilla LDAP C-SDK worked fine connecting to this same AD server, over SSL. I need to know if I am using the correct OpenLDAP client API calls. Any input would be much appreciated. Thanks. Source Code: ldap_initialize( &ld, uri ); if ( ld == NULL ) { tester_perror( "ldap_initialize", NULL ); exit( EXIT_FAILURE ); } rc = ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version ); printf("rc=ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, %d)=%d, error=%s\n", version, rc, ldap_err2string(rc)); rc = ldap_set_option( ld, LDAP_OPT_REFERRALS, chaserefs ? LDAP_OPT_ON : LDAP_OPT_OFF ); printf("rc=ldap_set_option(ld, LDAP_OPT_REFERRALS, %d)=%d, error=%s\n", chaserefs, rc, ldap_err2string(rc)); int debug_flag1 = -1; // LDAP_DEBUG_ANY ; rc = ldap_set_option( ld, LDAP_OPT_DEBUG_LEVEL, &debug_flag1); printf("rc=ldap_set_option(ld, LDAP_OPT_DEBUG_LEVEL, %d)=%d, error=%s\n", debug_flag1, rc, ldap_err2string(rc)); char *cert_path="/path/to/ldap_certdb"; rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CACERTDIR, &cert_path); printf("rc=ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR, %s)=%d, error=%s\n", cert_path, rc, ldap_err2string(rc)); int reqcert = LDAP_OPT_X_TLS_ALLOW; rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); printf("rc=ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, %d)=%d, error=%s\n", reqcert, rc, ldap_err2string(rc)); rc = ldap_sasl_bind_s( ld, manager, LDAP_SASL_SIMPLE, passwd, NULL, NULL, NULL ); if ( rc != LDAP_SUCCESS ) { tester_ldap_error( ld, "ldap_sasl_bind_s", NULL ); switch ( rc ) { case LDAP_BUSY: case LDAP_UNAVAILABLE: /* fallthru */ default: break; } exit( EXIT_FAILURE ); } Here's program output: rc=ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, 3)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_REFERRALS, 0)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_DEBUG_LEVEL, -1)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR, /path/to/ldap_certdb)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, 3)=0, error=Success PID=4781 - Search(2): base="OU=people,OU=documentum,DC=adldap112,DC=dctmlabs,DC=com", filter="cn=aduser2*" attr="cn". slapd-search PID=4781: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed From: Wu, Daisy Sent: Friday, August 26, 2011 4:53 PM To: openldap-technical(a)openldap.org; 'openldap-devel-request(a)openldap.org' Subject: Need sample OpenLDAP client test program connecting to LDAP server over SSL Hi, OpenLDAP developers, Do you have any sample test programs (or code snippets) that uses OpenLDAP client API to connect to LDAP server over SSL? Thanks in advance. Daisy

3 11

Status of persistent search in OpenLDAP
by Clément OUDOT 01 Sep '11

01 Sep '11

Hello, I tried to know if the persistent search control (OID 2.16.840.1.113730.3.4.3) was supported in OpenLDAP. The latests messages I read were saying "no", as we can see in this discussion: http://www.openldap.org/lists/openldap-technical/201008/msg00246.html But this blog entry is saying this control was introduced in OpenLDAP 2.2: http://www.connexitor.com/blog/pivot/entry.php?id=112 So can you confirm that OpenLDAP 2.4 does not support persistent search control? Is this feature planned? Thanks for your help, Clément.

4 7

task slapd blocked for more than 120 seconds.
by ml+openldap＠esmtp.org 01 Sep '11

01 Sep '11

I'm trying some scenarios to see how syncrepl behaves in certain error conditions. In one of these slapd blocks and is terminated(?) (2.4.23 and 2.4.26, running on RH 5.5): slapd D ffff810002536420 0 21032 1 21037 4521 (NOTLB) slapd D ffff810002536420 0 21032 1 21037 4521 (NOTLB) ffff810003f3fce8 0000000000000082 ffff81007eaae080 ffff81007faec100 000ec08328ac597e 0000000000000007 ffff81007eaae080 ffffffff80311b60 000ec0832bef5b8d 0000000000000990 ffff81007eaae268 0000000000000001 Call Trace: [<ffffffff8006315f>] wait_for_completion+0x79/0xa2 [<ffffffff8008e430>] default_wake_function+0x0/0xe [<ffffffff8004213e>] exit_mm+0x76/0xf5 [<ffffffff800158e6>] do_exit+0x305/0x965 [<ffffffff80049392>] cpuset_exit+0x0/0x88 [<ffffffff8002b42d>] get_signal_to_deliver+0x465/0x494 [<ffffffff8005af5e>] do_notify_resume+0x9c/0x7af [<ffffffff8008e430>] default_wake_function+0x0/0xe [<ffffffff80031545>] do_fork+0x148/0x1c1 [<ffffffff800a6061>] sys_futex+0x10a/0x12b [<ffffffff8005d19f>] sysret_signal+0x1c/0x27 [<ffffffff8005d427>] ptregscall_common+0x67/0xac INFO: task slapd:21037 blocked for more than 120 seconds. How to reproduce: Configuration: one master with a push replica (see also ITS 6999). On the replica: stop slapd, clean out the database directory, set up the essential files, start slapd. On the master: add a new entry to LDAP and run ldapsearch on that entry afterwards: the command hangs. ldap log entries for this: conn=1002 fd=20 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) conn=1002 op=0 BIND dn="cn=Manager" method=128 conn=1002 op=0 BIND dn="cn=Manager" mech=SIMPLE ssf=0 conn=1002 op=0 RESULT tag=97 err=0 text= conn=1002 op=1 ADD dn="uid=user2002,ou=People,dc=example,dc=com" slap_queue_csn: queing 0x43224150 20110831224446.739440Z#000000#001#000000 syncprov_sendresp: cookie=rid=001,sid=001,csn=20110831224446.739440Z#000000#001#000000 do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110831224446.739440Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) conn=1002 op=2 UNBIND conn=1002 op=1 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x2aaab0004160 20110831224446.739440Z#000000#001#000000 conn=1002 fd=20 closed syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 uid=user2002,ou=People,dc=example,dc=com slap_queue_csn: queing 0x5d4ea70 20110831224446.739440Z#000000#001#000000 syncrepl_entry: rid=001 be_add uid=user2002,ou=People,dc=example,dc=com (32) Is this an error in slapd or in RH?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical