openldap-technical June 2010

openldap-technical@openldap.org

104 participants
113 discussions

syncrepl vs is_entry_objectclass "2.5.17.0" no objectClass attribute
by Guy.Baconniere＠swisscom.com 16 Jun '10

16 Jun '10

Hello, A syncrepl with a searchbase of "dc=foo,dc=bar" is working fine but not with a empty/null "" searchbase. On the provider side I have the following error "is_entry_objectclass("", "2.5.17.0") no objectClass attribute" and on the consumer I have "do_syncrep2: rid=002 (32) No such object". ldapsearch -LLL -h foo.bar -p 389 -x -D 'cn=syncrepl,dc=foo,dc=bar' -w '*****' -b '' -s sub '(objectclass=*)' '*' '+' Do not have any issue to retrieve the full DIT(s) and is able to find the sub of root object. Is it possible to replicate an null/empty searchbase with syncrepl ? If not how can I replicate part of a null/empty searchbase setup on a provider ? Best Regards, Guy Baconniere I am running OpenLDAP slapd 2.4.11 on Debian Lenny. # syncrepl directives syncrepl rid=002 provider=ldap://foo.bar:389/ searchbase="" filter="(objectClass=*)" scope=sub attrs="*,+" type=refreshAndPersist schemachecking=off retry="60 30 300 +" bindmethod=simple binddn="cn=syncrepl,dc=foo,dc=bar" credentials="*****" SYNCREPL OF SEARCHBASE="" NOT WORKING conn=1443 fd=33 ACCEPT from IP=172.16.8.204:44128 (IP=0.0.0.0:389) conn=1443 op=0 BIND dn="cn=syncrepl,dc=foo,dc=bar" method=128 conn=1443 op=0 BIND dn="cn=syncrepl,dc=foo,dc=bar" mech=SIMPLE ssf=0 conn=1443 op=0 RESULT tag=97 err=0 text= conn=1442 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1442 op=1 SRCH attr=* + is_entry_objectclass("", "2.5.17.0") no objectClass attribute conn=1442 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= conn=1443 op=1 SRCH base="dc=foo,dc=bar" scope=2 deref=0 filter="(objectClass=*)" conn=1443 op=1 SRCH attr=* + conn=1442 op=2 UNBIND conn=1442 fd=24 closed do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=002 (32) No such object do_syncrepl: rid=002 retrying (29 retries left) LDAPSEARCH IS ABLE TO RETRIEVE SEARCHBASE "" ldapsearch -LLL -h foo.bar -p 389 -x -D 'cn=syncrepl,dc=foo,dc=bar' -w '*****' -b '' -s sub '(objectclass=*)' '*' '+' conn=1441 fd=24 ACCEPT from IP=127.0.0.1:47269 (IP=0.0.0.0:389) conn=1441 op=0 BIND dn="cn=syncrepl,dc=foo,dc=bar" method=128 conn=1441 op=0 BIND dn="cn=syncrepl,dc=foo,dc=bar" mech=SIMPLE ssf=0 conn=1441 op=0 RESULT tag=97 err=0 text= conn=1441 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1441 op=1 SRCH attr=* +

3 3

LDAP clients
by Foo Bar 16 Jun '10

16 Jun '10

hi i search for a stable openldap client. Can you recommend a client who works with openldap very good? thx -- Mit freundlichen Grüßen / Best Regards fooCCfoo

3 2

overlay unique in cn=config
by Nick Urbanik 16 Jun '10

16 Jun '10

Dear Folks, 1. Can I use the unique overlay with the dynamic cn=config configuration? 2. If so, what is the LDIF syntax for the configuration? 3. Would this work with OpenLDAP 2.3.43? -- Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 I disclaim, therefore I am.

3 4

Re: LDAP clients
by Chris Jacobs 16 Jun '10

16 Jun '10

I totally agree. One gotcha though: to see the system attributes (like pwdpolicy settings on an acct) you have to right click the acct and select show system attributes. That confused me for a while. - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ________________________________ From: openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org To: Foo Bar Cc: openldap-technical(a)openldap.org Sent: Wed Jun 16 02:42:47 2010 Subject: Re: LDAP clients http://directory.apache.org/studio/ On Wed, Jun 16, 2010 at 11:29, Foo Bar <fooccfoo(a)googlemail.com<mailto:fooccfoo@googlemail.com>> wrote: hi i search for a stable openldap client. Can you recommend a client who works with openldap very good? thx -- Mit freundlichen Grüßen / Best Regards fooCCfoo -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

1 0

Windows doesn't find user of openldap database
by Bruno Steven 15 Jun '10

15 Jun '10

Hi I need help for resolve this situation, I have trying set permission for folder, the windows 2003 integrated doesn't find all users of my ldap database only user "root". How resolve this problem ? Thanks. -- Bruno Steven - Administrador de sistemas. LPIC-1 - LPI ID: lpi000119659 / Code: p2e4wz47e4 https://www.lpi.org/caf/Xamman/certification MCP-Windows 2003 - TranscriptID: 793804 / Access Code: 080089100 https://mcp.microsoft.com/authenticate/validatemcp.aspx P Antes de imprimir pense em sua responsabilidade e comprometimento com o Meio Ambiente. Before printing this message, think about your ecologic responsability and environment commitment.

1 1

Best way to merge two local DITs vs empty search base suffix
by Guy.Baconniere＠swisscom.com 15 Jun '10

15 Jun '10

Hello, We want to update our old OpenLDAP server from 2.1.x to 2.4.x but the current configuration do not use a regular suffix (o=foo,c=bar nor dc=foo,dc=bar) but use an empty suffix (""). We want to move away from empty suffix as we cannot use cn=monitor or any additional suffixes as they can not bind when a suffix ""is in use in a hdb database : <suffix> namingContext "o=..." already served by a preceding hdb database serving namingContext "" We still have some old applications which are using empty search base and query implicitly the union of o=A and o=B stored within the same ldbm database. To maintain the backward compatibility we did a meta backend to merge the two local DITs under suffit "". The side effect of meta backend with ldap://localhost is the increase of the number opened tcp connection to slapd which are eating "thread" connections for "nothing". The number of "thread" in use is linked to the number of suffixmassage used in meta backend (2 in our case). We want to try to avoid increasing by two the number of theads in use to maintain the backward compatibility. Do you know an alternative way to merge two local DITs without using meta backend ? Can we use relay/ldap backend with rwm overlay instead of using meta backend ? database meta suffix "" uri "ldap://localhost/o=test1" suffixmassage "o=test1" "o=test1" uri "ldap://localhost/o=test2" suffixmassage "o=test2" "o=test2" Thank you for your help. Best Regards, Guy Baconniere. CURRENT CONFIG (slapd 2.1.x) suffix "" database ldbm rootdn "cn=manager" directory "/var/lib/ldap" # o=test1, o=test2, cn=manager are stored within the same ldbm database CURRENT LDAPSEARCH (slapd 2.1.x) ldapsearch -LLL -h localhost -p 389 -x -b '' -s one '(objectclass=*)' '1.1' dn: o=test1 dn: o=test2 dn: cn=manager TEST CONFIG WITH BACKWARD COMPATIBILITY (slapd 2.4.x) database hdb suffix "o=test1" rootdn "cn=admin,dc=test3,dc=com" directory "/var/lib/ldap/test1" database hdb suffix "o=test2" rootdn "cn=admin,dc=test3,dc=com" directory "/var/lib/ldap/test2" database hdb suffix "dc=test3,dc=com" rootdn "cn=admin,dc=test3,dc=com" directory "/var/lib/ldap/dc=test3,dc=com" database relay suffix "cn=manager" overlay rwm rwm-rewriteEngine on rwm-suffixmassage "cn=manager" "cn=manager,o=admin" rwm-normalize-mapped-attrs yes database meta suffix "" uri "ldap://localhost/o=test1" suffixmassage "o=test1" "o=test1" uri "ldap://localhost/o=test2" suffixmassage "o=test2" "o=test2" LDAPSEARCH WITHOUT META BACKEND (slapd 2.4.x) ldapsearch -LLL -h localhost -p 389 -x -b '' -s one '(objectclass=*)' '1.1' No such object (32) LDAPSEARCH WITH META BACKEND (slapd 2.4.x) ldapsearch -LLL -h localhost -p 389 -x -b '' -s one '(objectclass=*)' '1.1' dn: o=test1 dn: o=test2 OPENLDAP LOGS SHOWING THE LOCAL CONNECTIONS OF META BACKEND slapd[29622]: conn=11 fd=37 ACCEPT from IP=127.0.0.1:33680 (IP=0.0.0.0:389) slapd[29622]: conn=11 op=0 BIND dn="" method=128 slapd[29622]: conn=11 op=0 RESULT tag=97 err=0 text= slapd[29622]: conn=11 op=1 SRCH base="" scope=1 deref=0 filter="(objectClass=*)" slapd[29622]: conn=11 op=1 SRCH attr=1.1 slapd[29622]: conn=8 op=3 SRCH base="o=test1" scope=0 deref=0 filter="(objectClass=*)" slapd[29622]: conn=8 op=3 SRCH attr=1.1 slapd[29622]: conn=8 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[29622]: conn=9 op=3 SRCH base="o=test2" scope=0 deref=0 filter="(objectClass=*)" slapd[29622]: conn=9 op=3 SRCH attr=1.1 slapd[29622]: conn=9 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[29622]: conn=11 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text= slapd[29622]: conn=11 op=2 UNBIND slapd[29622]: conn=11 fd=37 closed

3 4

Re: Tool to covert from LDIF cn=config to slapd.conf?
by Chris Jacobs 14 Jun '10

14 Jun '10

Woah - no need to take anything personal. We're not all devs. SysAdmin != Code Dev. His memory /could/ be off - that's why he didn't state it as a fact. And there's certainly more civil ways to suggest one checkout code from a deprecated branch. If feedback isn't desired, simply state so on the mailing list site. Francis even seems like an informed /user/ of the openldap software. Francis: I suggest you simply do a slapcat and then a sed replacement on the output to get what you need. It won't help with cn=config; that'd really have to be done by hand, but I don't think it'd be too difficult. My 2 cents, - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ----- Original Message ----- From: openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org <openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org> To: Francis Swasey <Frank.Swasey(a)uvm.edu> Cc: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> Sent: Sun Jun 13 12:31:48 2010 Subject: Re: Tool to covert from LDIF cn=config to slapd.conf? Francis Swasey wrote: > On 6/9/10 3:32 PM, Quanah Gibson-Mount wrote: >> slapd.conf is deprecated and will likely be removed in OpenLDAP 2.5. > > Do all of the overlays support cn=config yet? Last I remember, there > were still overlays that didn't work with cn=config. If your memory is correct, you're welcome to submit patches. > I would rather that cn=config was working with everything for one entire > release before slapd.conf is removed to give those of us that depend on > those overlays a chance to migrate -- rather than a repeat of the forced > conversion to syncrepl before it was completely baked (which I for one > do not think has completely happened even now in 2.4.22). All of the core overlays support cn=config. You can always pull slurpd from CVS if you enjoy that sort of thing, no one put a gun to your head to force you in any direction. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

3 2

Re: Posix group with /etc/ldap.conf read priv
by Aaron Richton 14 Jun '10

14 Jun '10

Please keep replies on the list. On Mon, 14 Jun 2010, Ariel wrote: > On Jun 14, 2010, at 1:33 PM, Aaron Richton wrote: > >> On Mon, 14 Jun 2010, Ariel wrote: >> >>> I don't like having the /etc/ldap.conf world readable [...] >>> Advice? >> >> And you didn't chmod /etc/passwd and /etc/group too? What if people get >> valuable information out of those? You can't do this and be POSIX >> multi-user; getgr*/getpw* are unprivileged operations. Your users >> should be able to get some output with getent(1), and your users should >> be able to get the same output with "cat /etc/ldap.conf" and a bit of >> thought, and any attempts to make that harder will be a waste of time >> on your part. Change back the permissions, or change your OS. >> >> Now, with all this said, if your users can get *more* information with >> "cat /etc/ldap.conf" and thought than getent(1) provides, that may well >> be a configuration error on your part, which would be appropriate to >> discuss on this list... > > I have not heard of getent before, but it seems it would only be able to > read ldap users if there was a copy of the ldap database locally? Or am > I wrong about this? Don't think about this in terms of LDAP or any other network name service. Imagine you've got a fresh-from-factory laptop. You start adding users, they go into /etc/passwd. /etc/passwd is world-readable. Everybody on the laptop can see the list of users as you update it. Same for a server with LDAP. The actual name service is irrelevant, it's a requirement of the API that has to be provided... > I am not worried about local users being seen, there are few per server > and they have low privileges. I was worried about someone being able to > read all our ldap users which can access every system on our network and > many of which have very high privileges. This is the reason why we > restrict reading from our ldap server to a validated read-only user in > the first place. OK, again forget LDAP. You've got two servers now, each with their own /etc/passwd. Say there are 6 users on one and 8 on the other. In the simple, non-network case, cat /etc/passwd should show 6 or 8 (depending on where you type it) and getent passwd should match with 6 or 8 users shown. > Even if they cannot read the password hash, getting a full list of users > seemed like something I would want to avoid. But if any attempts at > doing so in the way I was describing is meaningless then I can move on > to other things that need doing. ...well, to continue my example, if you configure things such that "getent passwd" shows 14 users, that would probably be a mistake. You're right that outputting a full list of users, across disparate authentication configurations, is probably something to be avoided. But that's what ACLs are for. See slapd.access(5). And you do this server-side (possibly combined with a binddn on the client) by editing the world-readable ldap.conf, not by chmod'ing the file...

3 2

Re: Restricting client access using pam_groupdn with dynamic groups : Was[Re: restrict host login based on group]
by Adam Hough 14 Jun '10

14 Jun '10

On Mon, Jun 14, 2010 at 12:32 AM, Shamika Joshi <shamika.joshi(a)gmail.com>wrote: > Ya here it is ...output of slapcat attached. Please let me knw if u could > see anything missing from this. > > Thanks & regards > Shamika > > > > > Howard, I will remember that. I always use the ldap commands normally since I have a 3 way multi-master mirror setup. Shamika, Just in case i get to busy this week to look at your config here is the slapcat of my configuration with any sensitive information removed. http://www.gradientzero.com/openldap/Example_config/config.ldif.gz (I am sure that my is not 100% optimal but it is currently working for me.)

1 0

Re: Best way to merge two local DITs vs empty search base suffix
by Chris Jacobs 14 Jun '10

14 Jun '10

Where is it documented how the conf file slapd.conf file is processed? I've read the documentation, more than once, and still don't know. I suspect this whole 'order thing' is pretty darn important (outside of access config). Seriously, please me at it. Thanks, - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ----- Original Message ----- From: openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org <openldap-technical-bounces+chris.jacobs=apollogrp.edu(a)OpenLDAP.org> To: Guy.Baconniere(a)swisscom.com <Guy.Baconniere(a)swisscom.com>; openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> Sent: Sun Jun 13 20:20:07 2010 Subject: Re: Best way to merge two local DITs vs empty search base suffix --On Sunday, June 13, 2010 12:17 PM +0200 Guy.Baconniere(a)swisscom.com wrote: > Hello, > > We want to update our old OpenLDAP server from 2.1.x to 2.4.x but the > current configuration do not use a regular suffix (o=foo,c=bar nor > dc=foo,dc=bar) but use an empty suffix (""). > > We want to move away from empty suffix as we cannot use cn=monitor or any > additional suffixes as they can not bind when a suffix ""is in use in a > hdb database : You can do this just fine. I do it in all my installs. You simply need to declare them in the right order. I.e., you must declare monitor, etc before the empty suffix. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

3 2

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2010