openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

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 15 Jun '10

15 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

How to use BLOB while using Back-NDB
by Priyesh Potdar 14 Jun '10

14 Jun '10

Hi All, I am using back-ndb as a backend for my openldap. I want to know, what is configuration change in slapd.conf I need to make to instruct openldap to always use BLOB and not the VARCHAR. Thanks, Best Regards, Priyesh Potdar

2 1

Re: Tool to covert from LDIF cn=config to slapd.conf?
by Quanah Gibson-Mount 13 Jun '10

13 Jun '10

--On Wednesday, June 09, 2010 12:26 PM -0700 j(a)gropefruit.com wrote: > Actually I don't think this idea solely implies "going backwards in > development", in fact I think this tool is an excellent idea and > shouldn't be immediately balked at by the OpenLDAP team. slapd.conf is deprecated and will likely be removed in OpenLDAP 2.5. > Let's look at this from the Disaster Recovery standpoint. Consider this: > > * One uses slapd.conf as a boot-strap to general the cn=config database > * cn=config works fine at first, and you are able to add new entries to > your runtime configuration, instead of adding them to slapd.conf (the > original boot-strapper). > * One day, your Junior admin tries to add an "olc" attribute to your > cn=config backend, only to crash slapd (happens occasionally). > * You start up slapd only to find the cn=config database has been > corrupted. > * You use your original slapd.conf boot-strap to generate a NEW > cn=config backend. > * You find your original bootstrap config LACKS some of the recent > changes your team made to the cn=config DB. So, in essence, you're > screwed. I would suggest you instead take backups of your cn=config database via slapcat. This is what I do, on a nightly basis. If some junior admin makes a mistake, then I can restore it very trivially via slapadd. The rest of your email is invalid due to the above. bootstrapping via slapd.conf should only be a one-time affair, and not used for disaster recovery. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

3 2

sizelimit doesn't work - keep on getting "Size limit exceeded"
by nano mir 13 Jun '10

13 Jun '10

Hi all, I have an address book of 540 entries, and I cannot get openLDAP to return them all... Please take a look: $ uname -r && cat /etc/issue 2.6.28-19-generic Ubuntu 9.04 \n \l $ grep -i --context=2 "limit\|size" /etc/ldap/slapd.conf ... # The maximum number of entries that is returned for a search operation #sizelimit 1000 limits anonymous size.soft=50 size.hard=100 size.unchecked=32767 time.soft=15 time.hard=60 sizelimit -1 limits dn.exact="cn=theadmin,dc=my,dc=server,dc=com" size=unlimited time=unlimited limits group/groupOfUniqueNames/uniqueMember="cn=theadmin,ou=testingab,dc=my,dc=server,dc=com" size=unlimited time=unlimited # The tool-threads parameter sets the actual amount of cpu's that is used -- # For the Debian package we use 2MB as default but be sure to update this # value if you have plenty of RAM dbconfig set_cachesize 0 2097152 0 # Sven Hartge reported that he had to set this value incredibly high ... $ sudo /etc/init.d/slapd restart Stopping OpenLDAP: slapd. Starting OpenLDAP: slapd. $ sudo /etc/init.d/apache2 reload * Reloading web server config apache2 apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName [ OK ] . And even after I do all this (add limits to '/etc/ldap/slapd.conf' and restart servers), I *still* get "Size limit exceeded": --------- $ ldapsearch -W -D cn=theadmin,dc=my,dc=server,dc=com -b ou=testingab,dc=my,dc=server,dc=com $cn=*$ ... ... # search result search: 2 result: 4 Size limit exceeded # numResponses: 501 # numEntries: 500 --------- Frustrating ! :( :( :( Can anyone tell me what am I doing wrong?! Thanks in advance, Cheers!

2 1

back-sql with thunderbird-frontend fails
by rpeschke＠peschke-it.de 12 Jun '10

12 Jun '10

Hi, I have an OpenLDAP running with the back-sql. On ldapsearch it runs quite good, but thunderbird refuses to use the LDAP addressbook. In the logged query, excerpts see below, it requests it's "secondary" attributes like custom1 etc.. These attributes are not part of any schema. What's the solution: 1. to modify all thunderbirds configuration, where the secondary attributes are configured. There are some th...!? 2. defining my own schema to extend the mozillaAbPersonAlpha-schema? 3. Looking for a schema in the net? Any suggestions what to do? Thank you Ralf PS: Here are some lines from the slapd-log: Jun 11 23:30:49 osicsd slapd[2652]: conn=1000 op=2 SRCH base="dc=address" scope=2 deref=0 filter="(|(mail=*.*)(cn=*.*)(givenName=*.*)(sn=*.*))" Jun 11 23:30:49 osicsd slapd[2652]: conn=1000 op=2 SRCH attr=o company mail mozillaCustom3 custom3 street streetaddress postOfficeBox mozillaUseHtmlMail xmozillausehtmlmail mozillaCustom2 custom2 mozillaHomeCountryName ou department departmentnumber orgunit mobile cellphone carphone telephoneNumber title mozillaCustom1 custom1 mozillaNickname xmozillanickname mozillaWorkUrl workurl fax facsimiletelephonenumber mozillaSecondEmail xmozillasecondemail mozillaCustom4 custom4 nsAIMid nscpaimscreenname givenName l locality homePhone mozillaHomeUrl homeurl mozillaHomeStreet st region mozillaHomePostalCode mozillaHomeLocalityName birthyear mozillaWorkStreet2 mozillaHomeStreet2 postalCode zip c countryname pager pagerphone sn surname mozillaHomeState description notes modifytimestamp cn commonname Jun 11 23:30:49 osicsd slapd[2652]: is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute Jun 11 23:30:49 osicsd slapd[2652]: is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute Jun 11 23:30:49 osicsd slapd[2652]: conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Jun 11 23:34:31 osicsd slapd[2652]: conn=1000 op=3 UNBIND Jun 11 23:34:31 osicsd slapd[2652]: conn=1000 fd=13 closed

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