openldap-technical January 2011

openldap-technical@openldap.org

91 participants
107 discussions

Emergency recovery strategy needed by novice
by Richard Troy 08 Jan '11

08 Jan '11

Hello All, I've got a bit of a problem.... Management chose a software product that depends on OpenLDAP's SLAPD service and had us put it into production without our quite understanding the software well enough to be clueful. The deployment is across virtual and real servers, the virtual servers handling the web stack and other user-oriented functionality while "real" servers handle data management. Regarding the data management, one system was chosen as a replication master, and another as slave, but being understaffed, we never quite got the replication of the OpenLDAP data configured when, today, some serious networking problems cropped up. The symptom is that we can establish an OpenLDAP (slapd) connection from the virtual side to the master, and a postgres connection - our RDBMS, but we can't get the rest of our primary application to connect properly so it's down. And it is absolutely not clear what's wrong with the master anyway. I can't get to the physical hardware because it's off in some data center somewhere that the founder located near him - and he's off traveling. So, we're "dead in the water." I was thinking that we might salvage the situation by dumping the data from the Postgres and OpenLDAP databases and restoring them to the slave system - promoting it to master - and while I've succeeded in moving over the Postgres data, I haven't a CLUE how to get started unloading and reloading the OpenLDAP data. ...I'm very competent with most things related to computing but I am _completely_ inexperienced with OpenLDAP. I've never issued any commands to or with OpenLDAP / slapd and have no idea what's normal for dealing with it. Are there dump and reload utilities? Any and all pointers / help GREATLY appreciated. Richard

4 5

Strange behavior with TLS with self-signed certs
by Michael Starling 08 Jan '11

08 Jan '11

I'm running openldap-2.3.43-12.el5 on a RHEL 5.5 system: I find that TLS will not work if I use uri ldap://10.3.5.207/ in /etc/ldap.conf on my clients. TLS magically starts working if I use the deprecated host directive instead: So if I use host 10.3.5.207 instead everything starts working: Any insight as to what might be going on?..Possibly a bug? Here are my TLS directives on my clients: #TLS settings ssl start_tls ssl on tls_cacertdir /etc/openldap/cacerts tls_cacertfile /etc/openldap/cacerts/slapdcert.pem tls_checkpeer no -Mike

4 8

Re: Index for objectclass does not work...
by Steeg Carson 08 Jan '11

08 Jan '11

2011/1/4 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, January 04, 2011 1:43 AM +0100 Steeg Carson > <steeg.carson(a)googlemail.com> wrote: > >> I simulate this on my database just right now: > > I suggest you read: > > <http://www.openldap.org/lists/openldap-technical/201011/msg00146.html> > > to understand how indices and their slots work. > As I now understand, the entire index for one attribute (e.g. objectClass) is "split" in several indexes. They holds for each path/node (resp. DN, but not leaf) an separate index for this attribute with all "hits" for his subtree (and for onelevel too). If I do an ldapsearch with -b "cn=ownPath,ou=root" the slapd takes the index which is bound on this node/DN? In my DIT are 470812 entires. The objectClass=subEngine exists 104384 times in the entire directory (ou=root). The objectClass=subEngine exists only 1 time under "cn=ownPath,ou=root", The following test I made with BDB, because each node holds an index for subtree and one for onelevel (hdb only for onelevel) When I search (loglevel 33): ldapsearch -x -h localhost -wpassword -D"uid=admin,ou=root" -b"cn=ownPath,ou=root" "(ObjectClass=subEngine)" I get in the logfile: ================================================ => key_read <= bdb_index_read 470601 candidates <= bdb_equality_candidates: id=-1, first=228, last=470828 <= bdb_filter_candidates: id=-1 first=228 last=470828 <= bdb_list_candidates: id=-1 first=228 last=470828 <= bdb_filter_candidates: id=-1 first=228 last=470828 <= bdb_list_candidates: id=-1 first=40595 last=470825 <= bdb_filter_candidates: id=-1 first=40595 last=470825 bdb_search_candidates: id=-1 first=40595 last=470825 => test_filter EQUALITY <= test_filter 5 bdb_search: 40595 does not match filter . . . ================================================. . Should the index at this level not hold only one entry: ldapsearch -x -h localhost -wpassword -D"uid=admin,ou=root" -b"cn=ownPath,ou=root" "(ObjectClass=subEngine)" dn | grep "^dn:" | wc -l 1 thanks Steeg!

3 7

Re: slow ldap authentication
by bluethundr 07 Jan '11

07 Jan '11

Hi list, It's been a few days and I just wanted to check back to see if anyone had any troubleshooting tips that might help to solve this situation that I'm dealing with as I'm still a relatively new LDAP admin. I really appreciated your advice in the past and have overcome some very significant technical hurdles with your assistance on a number of occasions. Thanks in advance!and I would like to wish you a belated happy new year! Tim On Sun, Jan 2, 2011 at 12:58 AM, bluethundr <bluethundr(a)gmail.com> wrote: > Hello list!! > > I would greatly appreciate your help with an issue I am having here. > It seems that when you log into hosts on the network via ldap > authentication, said authentication is extremely sloooowww... on the > order of up to 30 seconds to log in! I could use some assistance in > correlating the information in the logs with the way that slapd.conf > is configured. > > What I did to capture the event in the logs was to (after backing > them up) empty them with cat /dev/null > /var/log/openldap.log and > then log into a host on the network via an ldap account. Right after > login was finished I copied the log file to another location on the > nas and enclosed it here. Therefore it reflects only what happened > during the login. I've also enclosed my slapd.conf and ldap schema as > attachments for your perusal. > > I've attempted adding some indexes to the configuration to alleviate > the situation but unfortunately this had no effect. The ones I added > were uid and uidNumber which I've read can help address this sort of > situation. > > > [root@LBSD2:~]#grep -i index /usr/local/etc/openldap/slapd.conf > index objectClass,uid,uidNumber eq > index sudoUser eq > > thanks in advice with any assistance you can provide. > > best regards > > -- > GPG me!! > > gpg --keyserver pgp.mit.edu --recv-keys F186197B > -- GPG me!! gpg --keyserver pgp.mit.edu --recv-keys F186197B

2 1

Re: Index for objectclass does not work...
by Steeg Carson 07 Jan '11

07 Jan '11

> > I have written up documentation on performance tuning OpenLDAP 2.4 that > covers most other areas, for my work @ Zimbra, you can find it at: > > <http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_6.0> > > It's based on you using Zimbra's tools to automatically update the > configuration database, but you can easily tweak what it's talking about > directly. Hello Quanah, I know this page. Its really very helpful! As talked, I tested openldap with shared memory and found, that this can accelerate the load of the LDAP-Database with slapadd a lot :-) Thanks for your help. Kindly regards, Steeg

1 0

Automated testing routines?
by Jaap Winius 07 Jan '11

07 Jan '11

Hi folks, Compiling the Debian sources for the OpenLDAP packages can take over an hour on my relatively fast workstation. Much of that time seems to be spent running a slapd server with all kinds of test routines. Is that what's actually going on? Whatever, perhaps someone could explain. Thanks, Jaap

5 6

users, groups, etc. for posix authentication?
by Christ Schlacta 06 Jan '11

06 Jan '11

is there any reason that a posix usernames, groups, passwords, etc. must be stored in distinct locations in a directory ? I realize this mostly applies to the padl pam/nis and the libnsspam-ldapd module specific. can they be stored in other structures effectively and usefully? can they be stored on a department by department basis, or in any other organizational scheme? (ou=arbitrary1,dc=... having groups and users, while ou=arb2,ou=arb3,dc=... also has users and groups?) if a scheme like the above is used, will all users and groups be available on a system? must they be free of naming conflicts, or will group=users,ou=arbitrary1,... be different from group=users,ou=arb2,ou=arb3,... ? if they're different, how would this be indicated by the systems?

2 2

ACLs to allow users to traverse DIT down to their own entry, lock down everything else
by Andreas Ntaflos 06 Jan '11

06 Jan '11

Hi list, I've been fighting with ACLs for quite a bit now and most things seems to work but I not quite everything I need. I am using OpenLDAP 2.4.21 (2.4.21-0ubuntu5.3) on Ubuntu 10.04. A DN for a typical user looks like this (horribly long): uid=foo(a)example.net,ou=users,domainName=example.net, ou=virtualDomains,dc=example,dc=com What works is users authenticating against the director and changing their own password (using ldappasswd, i.e. the LDAP extended password modify operation). I also have an authentication user that may read most of the directory. == What I want to achieve == a) Users such as just described should be able to: a.1) traverse the directory from the top (the base being "dc=example,dc=com") and a.2) see only their own entry along with the parent/ancestor entries leading to it. b) The directory should be as locked down as possible. Anonymous binds are not allowed, nor should users see any attributes other than their own. Essentially I want users to be able to use tools like phpLDAPadmin and traverse the tree down to their own entry. == What I have so far == Please comment if you find anything objectionable. {0}to attrs=userPassword by dn="uid=authenticator,ou=services,dc=example,dc=com" read by self write by users auth by anonymous auth by * none {1}to dn.subtree="ou=virtualDomains,dc=example,dc=com" by dn="uid=authenticator,ou=services,dc=example,dc=com" read by users =d break {2}to dn.regex="uid=[^,]+,ou=users,domainName=[^,]+, \ ou=virtualDomains,dc=example,dc=com" by self read This mostly works. == What doesn't work == Users can authenticate and change passwords and don't see anything except their own entry, *IF* they specify their own DN as search base in i.e. ldapsearch. Tools like phpLDAPadmin are not happy with this and say that the top entry (dc=example,dc=com) doesn't exist ("No such object"). Which is of course consistent with the ACLs as specified. So what do I need to do so users can specify "dc=example,dc=com" as search base and traverse the directory tree down to their own DN entry? I must admit that ACLs in LDAP are far more complex than I would ever have guessed. It also doesn't help that many examples on ACLs have a world-readable directory (by * read) that just gets locked down a bit. I on the other hand want the directory completely locked down and open up only specific parts to users (and later groups). Sorry for this long post. Any and all help is appreciated. Thanks, Andreas

2 1

viewing cn=config
by E.S. Rosenberg 06 Jan '11

06 Jan '11

Hi, I have a standard Debian install of slapd that was apparently automatically upgraded/updated from using slapd.conf to using olc. Now I would like to view settings before editing them so I tried some simple ldapsearch queries but all the things I try return empty results. How do I get to see the contents of cn=config? Things I have tried: ldapsearch -b cn=config -D cn=admin,dc=mydomain -W ldapsearch -x cn=config ldapsearch -D cn=admin,dc=mydomain -W cn=config Some help/pointers in the right direction would be greatly appreciated. Thanks, Eli

7 8

Granting write to ou
by Thomas D. Dahlmann 06 Jan '11

06 Jan '11

Hi I'm trying to add ordinary users write access to a specific ou. I've googled a lot and haven't really found any useful regarding to openldap 2.4 (slapd.d format). What would be the correct syntax for a ldapmodify command to accomplish this to the dn: ou=addressbook,dc=example,dc=net ? Thanks. /Thomas

4 7

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2011