openldap-software

openldap-software@openldap.org

2719 discussions

Bug(?) With OpenLDAP 2.3.32
by daniel＠ncsu.edu 24 Jan '07

24 Jan '07

Hi folk! We upgraded to OpenLDAP 2.3.32 recently and I ran into something that, unless I have completely lost my mind, should not be occuring: /local/ldap/data # /local/ldap/bin/ldapmodify -x -h localhost -D "cn=ldapadmin,dc=ncsu,dc=edu" -w LDAPADMINPASSWORD dn: uid=STUDENTUSERNAME,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: B A - Physics ou: B S - Philosophy - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL modifying entry "uid=STUDENTUSERNAME,ou=students,ou=people,dc=ncsu,dc=edu" ldap_modify: Type or value exists (20) additional info: modify/replace: ou: value #1 already exists Obviously I replaced the user's username and my ldap admin password. ;D A replace should literally be replacing the ou and ignoring what it's currently set to, correct? And since those two ou's are not the same, it should be fine? What's even more bizarre is that I didn't run into this while populating the database in the first place. Is this, perchance, fixed in 2.3.33? Thanks! Daniel

3 2

getting DN from client with GSSAPI bind?
by Kenneth Rogers 24 Jan '07

24 Jan '07

Hi, After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server? KR -- "Linux doesn't exist." -- Kieren O'Shaghnessy (Director of SCO Australia)

6 9

backend-meta usage
by Stephen Agar 24 Jan '07

24 Jan '07

I have an LDAP server with a base "o=company, c=us". There is another server which controls "ou=people,o=company,c=us", so in slapd.conf i have the following: database bdb suffix "o=company,c=US" rootdn "cn=Manager,o=company,c=US" rootpw ******* directory /usr/var/openldap-data # Indices to maintain index objectClass eq index ou,cn,uid eq,pres,sub #meta test database meta suffix "ou=people,o=company,c=US" uri "ldap://directory.company.com/ou=People,o=company,c=US" When I try to start slapd, I get: /etc/openldap/slapd.conf: line 84: <suffix> namingContext "o=company,c=US" already served by a preceding bdb database serving namingContext "o=company,c=US". Am I misusing meta? Can I not proxy binds/lookups to specific OUs to a secondary LDAP? I understand what the message is saying, but don't think I understand the proper use of meta. For example, I have an ou=groups that contains "groupofnames" and the members of those groups are like "uid=123456,ou=people,o=company,c=us". So I want ou = groups owned on my server, then the when specific members try to bind, they are proxied to this external LDAP server that serves ou=people,o=company,c=us and contains their uids and passwords. Am I going about this the wrong way? Is there a way to accomplish what im trying to do? Thanks in advance... --stephen

3 10

meta backend config problem
by Julien Oix 24 Jan '07

24 Jan '07

hi everyone, I made a previous post, but noone answered, so I try again :) I'm trying to deploy a meta directory using the OpenLdap meta backend. I'm using the slapd Etch Debian package, version 2.3.27-1 when my target server includes the next ACL, eveything is fine, I can retrieve any data by the meta directory using ldapsearch, it works fine ## access to attrs=userPassword by dn="cn=admin,dc=toto,dc=fr" write by anonymous auth by self write by * none and access to * by dn="cn=admin,dc=toto,dc=fr" write by * read ## but I want only authentified connections (no anonymous bind, if i'm right) to have read access, so I change the ACL like that ## access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=toto,dc=fr" write by anonymous auth by self write by * none and access to * by dn="cn=admin,dc=toto,dc=fr" write by self read by anonymous auth by * none ## So, for this target, i'm adding the acl-authcDN and acl-passwd directives to the meta directory, with the target's rootdn and rootpw values, in order to enable ACL checking and matching (in that case, the write privilege for dn="cn=admin,dc=toto,dc=fr") giving this in the meta backend conf ## database meta suffix "dc=meta-ufr-info-p7,dc=jussieu,dc=fr" uri "ldap://localhost:389/dc=meta-ufr-info-p7,dc=jussieu,dc=fr" suffixmassage "dc=meta-ufr-info-p7,dc=jussieu,dc=fr" "dc=toto,dc=fr" acl-authcDN "cn=admin,dc=toto,dc=fr" acl-passwd "xxxxx" ## But at this moment, I can't retrieve any data anymore, as I perform an ldapsearch by the meta directory .... Is there anything wrong in my conf ? the slapd-meta man page says about acl-authcDN directives : "it is supposed to have read access on the target server to attributes used on the proxy for acl checking." what does that mean exactly ? :) Thanks. -- Julien Oix UFR d'Informatique - Université Paris Diderot Bureau 5C01 (5ème étage) 175 rue du Chevaleret 75013 PARIS Tel : +33 (0) 144 278 504 Mobile : +33 (0) 664 392 207 --------------------------------------------- http://www.gnu.org/philosophy/no-word-attachments.html

2 2

change tracelevel programatically
by Lukacs David 24 Jan '07

24 Jan '07

Hello! I'm using slapd (version 2.2.6) with a custom backend. I've tried to implement a feature to change the trace level triggered by some events. I used the following piece of code to do this (found it originally in log.c): slap_debug = newTraceLevel; lutil_set_debug_level( "slapd", slap_debug ); ber_set_option(NULL, LBER_OPT_DEBUG_LEVEL, &slap_debug); ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, &slap_debug); ldif_debug = slap_debug; Although it works at the first glance, i get strange segfaults later on mostly from `backend.c'. For example in: int backend_check_referrals( Operation *op, SlapReply *rs ) when checking on `op->o_bd->be_chk_referrals' or int backend_connection_destroy( Connection *conn ) when checking on `backends[i].be_connection_destroy' The code to change trace level is called from the backend when an operation is started. Does anybody know the appropriate way of change tracing programatically? Thanks for the help in advance. Regards, David ___________________________________________________________ "Diszlexiás-e a gyerekem?" - 25 kérdéses gyorsteszt (hálás lesz utána, akármi is az eredmény!) http://ad.adverticum.net/b/cl,1,6022,133103,204265/click.prm

3 4

Error using TLS
by Iñaki 23 Jan '07

23 Jan '07

Hi, this is my first post to the list. I get an error when trying to run slapd with TLS options. I've looked a lot and sincerely don't know what I'm doing wrong. I use Debian Sarge. These are the steps I follow to create and configure the TLS certificate: 1) Create a directory ssl: #> mkdir /etc/ldap/ssl #> cd /etc/ldap/ssl 2) Generate a private/public key: #> /usr/lib/ssl/misc/CA.pl -newreq Generating a 1024 bit RSA private key .++++++ ...................................++++++ writing new private key to 'newreq.pem' Enter PEM pass phrase: ***** Verifying - Enter PEM pass phrase: ***** Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:Vizcaya Locality Name (eg, city) []:Barakaldo Organization Name (eg, company) [Internet Widgits Pty Ltd]:domain.net Organizational Unit Name (eg, section) []:debian Common Name (eg, YOUR name) []:debian.domain.net Email Address []:ibc@domain.net Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Request (and private key) is in newreq.pem 3) Remove the password from the unique "newreq.pem" created: #> openssl rsa -in newreq.pem -out key.pem Enter pass phrase for newreq.pem: ***** writing RSA key 4) Edit the certificate to remove the key and rename: #> vi newreq.pem [...] #> mv newreq.pem cert.pem 5) Change permissions for the key: #> chmod 600 key.pem 6) Now I have the cetificate and the key: #> ls -l -rw-r--r-- 1 root root 708 2007-01-23 21:35 cert.pem -rw------- 1 root root 887 2007-01-23 21:35 key.pem 7) Configure slapd.conf: ---------------- TLSCipherSuite HIGH TLSCertificateFile /etc/ldap/ssl/cert.pem TLSCertificateKeyFile /etc/ldap/ssl/key.pem ---------------- 8) Save and restart slapd: #> /etc/init.d/slapd restart Stopping OpenLDAP: slurpd slapd. Starting OpenLDAP: running BDB recovery, slapd - failed. The operation failed but no output was produced. For hints on what went wrong please refer to the system's logfiles (e.g. /var/log/syslog) or try running the daemon in Debug mode like via "slapd -d 16383" (warning: this will create copious output). 9) The syslog says: Jan 23 21:38:20 debian slapd[2339]: @(#) $OpenLDAP: slapd 2.2.23 (May 30 2005 08:52:42) $ ^I@pulsar:/home/torsten/packages/openldap/openldap2.2-2.2.23/debian/build/servers/slapd Jan 23 21:38:20 debian slapd[2339]: bdb_db_init: Initializing BDB database Jan 23 21:38:20 debian slapd[2339]: main: TLS init def ctx failed: -1 Jan 23 21:38:20 debian slapd[2339]: slapd stopped. Jan 23 21:38:20 debian slapd[2339]: connections_destroy: nothing to destroy. Could you tell me why this error occurs? I've read in many sites about those exact steps to configure TLS in OpenLDAP but it doesnt' work for me. Thanks in advance for any help. Regards. -- Iñaki Baz Castillo

3 5

olcTLSCipherSuite?
by Eric Irrgang 23 Jan '07

23 Jan '07

Does the TLSCipherSuite directive translate to anything in cn=config? I'm not seeing anything when I convert my slapd.conf file and the server doesn't seem to be interpreting the directive "TLSCipherSuite HIGH:MEDIUM" the way I would expect. That is, to only allow high and medium strength connections while trying to negotiate high-strength first. -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

2 1

cn=include
by Eric Irrgang 23 Jan '07

23 Jan '07

Are olcInclude attributes in cn=config honored as per the Admin Guide section 5.2.2 or is that documentation misleading? -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

2 1

Re: OpenLDAP issues when connecting over SSL
by Kurt D. Zeilenga 23 Jan '07

23 Jan '07

At 03:44 PM 1/21/2007, Jean-Yves Avenard wrote: >On 1/22/07, Kurt D. Zeilenga <Kurt(a)openldap.org> wrote: >>Given other clients seem to work well using ldaps://, >>it seems more likely that this particular client is >>not properly configured or is otherwise flawed. > >Unfortunately, I have no play on how to configure this client as this >is one major one ! You might ask on a list supporting the particular client you are using how to configure this client to secure LDAP with TLS (SSL). >Actually, two quite common do not work with OpenLDAP over SSL :( >But they will work fine over a non encrypted link > >>I guess that the client is configured to use ldap://server:636 >>not ldaps://server:636. >That was my guess also. >I there anything I can do on the server side to get over the flaw of >broken clients ? If the client doesn't support securing LDAP with TLS (SSL), either by using ldaps:// or by using ldap:// with Start TLS, there is nothing the server can do to change that. You can configure the server to support ldap:// on port 636 instead of ldaps:// if you want, but I don't recommend doing so. Kurt

5 7

deferring operation: too many executing
by Sepp 23 Jan '07

23 Jan '07

Hello, sorry when this is a FAQ. What is the exact meaning of: connection_input: conn=4412677 deferring operation: too many executing and what could be done against it ? Thanks Sepp

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software