openldap-technical December 2009

openldap-technical@openldap.org

59 participants
67 discussions

stuck transactions?
by Peter Mogensen 15 Dec '09

15 Dec '09

Hi, I notice that when I run db4.8tat -t the Active Transaction list does not change very often. I would have expected it to not be the same twice. So I guess I have a lot of stuck transactions? I use back_hdb and slapd is under some load. Could this be related to the messages in the log: Dec 15 15:09:19 server1 slapd[32060]: => bdb_idl_delete_key: c_del id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Dec 15 15:09:19 server1 slapd[32060]: conn=40803 op=18: attribute "entryCSN" index delete failure /Peter Active transactions: 80000003: running; pid/thread 32060/47089260848688; begin LSN: file/offset 0/0 80000004: running; pid/thread 32060/47089260848688; begin LSN: file/offset 0/0 80000006: running; pid/thread 32060/1127287120; begin LSN: file/offset 0/0 80000007: running; pid/thread 32060/1110501712; begin LSN: file/offset 0/0 80000008: running; pid/thread 32060/1118894416; begin LSN: file/offset 0/0 8000006b: running; pid/thread 32060/1135679824; begin LSN: file/offset 0/0 8000006d: running; pid/thread 32060/1088940368; begin LSN: file/offset 0/0 80000076: running; pid/thread 32060/1144072528; begin LSN: file/offset 0/0 80000077: running; pid/thread 32060/1152465232; begin LSN: file/offset 0/0 8000007c: running; pid/thread 32060/1160857936; begin LSN: file/offset 0/0 80000081: running; pid/thread 32060/1169250640; begin LSN: file/offset 0/0 80000082: running; pid/thread 32060/1177643344; begin LSN: file/offset 0/0 800000b7: running; pid/thread 32060/1186036048; begin LSN: file/offset 0/0 ....

2 2

Useless ldapwhoami behavior?
by Jaap Winius 15 Dec '09

15 Dec '09

Hi all, The utility of the "ldapwhoami" tool is a mystery to me. As opposed to the usual Unix "whoami" command, which prints the effective userid, "ldapwhoami" doesn't seem to print the matching LDAP DN... at least not for me. My test setup includes an OpenLDAP server and a separate client. The server's slapd.conf includes these ACLs: access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=umrk,dc=nl" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=umrk,dc=nl" write by * read My LDAP DIT includes an account for a normal user with a password. Without any problem I can use this to login to the client host, but when I want to test, or verify, the account's LDAP DN, all I get is this: ~$ ldapwhoami -x anonymous ~$ _ Even stranger, if I supply the account's DN and password (although this would seem a useless thing to do, since it's the very same info I'm asking for), I get this error: ~$ ldapwhoami -x -D "cn=testuser,dc=umrk,dc=nl" -w testpass ldap_bind: Invalid credentials (49) ~$ _ On the other hand, this does work if I supply the admin DN and password: ~$ ldapwhoami -x -D "cn=admin,dc=umrk,dc=nl" -w adminpass dn:cn=admin,dc=umrk,dc=nl ~$ _ The "ldapsearch" command is the same: I can get a response when binding anonymously ("-x"), as well as when binding as the admin user, but not when I use a normal user account, which results in the same error 49 as above. This behavior seems rather useless to me. Surely I've made a mistake somewhere. Can anyone say what it might be? Thanks, Jaap

6 6

Valid configure options for 2.4.20
by J. Landamore 14 Dec '09

14 Dec '09

I'm trying to build 2.4.20 so that it stores the userPassword attribute crypt'ed rather than in clear text - yes I know it violates the RFC. I tried ./configure --enable-crypt --disable-cleartext This compiled fine but failed test002-populate for bdb Is this a valid configuration and will it achieve what I want? Is it possible to store the userPassword attribute crypt'ed? Thanks John -- John Landamore Department of Computer Science University of Leicester University Road, LEICESTER, LE1 7RH J.Landamore(a)mcs.le.ac.uk Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604

3 2

ApacheDS + openLDAP
by bren norris 14 Dec '09

14 Dec '09

Anyone using Eclipse based ApacheDS for works with openLDAP? I get a socket closed everytime I try and add a custom objectclass to the DIT... but it works fine with Softerra LDAP administrator. Server is a aptitude installed Ubuntu Karmic release and I thought I'd tap your heads just incase I'm missing the "bleedingly obvious". Happy DAPin'

2 1

Many TCP connections
by Peter Mogensen 14 Dec '09

14 Dec '09

Hi, I tried to increase the number of simultaneous TCP connection to my slapd (to around 800) and was a little surprised to see the result. While slapd still answers very fast in ldapi:/// , TCP connections now takes a while to connect() and after that even longer to answer the query. I can see ldapsearch hanging waiting for response. Eventually it answers - after more than a minute. So it doesn't seem to be a load problem for the backend, but what could make TCP-connections that slow compared to ldapi:/// ? I have no FD limits. /Peter

1 0

proxied attributedescription inserted
by Alexander 'Leo' Bergolth 13 Dec '09

13 Dec '09

Hi! When running slaptest, slapcat or other related utilities, I keep getting 'PROXIED attributeDescription "OU" inserted.' warnings. Initially I thought that some schema definitions could be missing but as far as I can see, the core-schema should be OK. Maybe the problem is that the modifiersName (uid=leoadm,ou=LDAPusers,dc=wu-wien,dc=ac,dc=at) of cn=config is outside of cn=config? Here is the snippet of slaptest output (debuglevel -1) where the errors occur: -------------------- 8< -------------------- backend_startup_one: starting "cn=config" ldif_read_file: read entry file: "/etc/openldap2.4/slapd.d/cn=config.ldif" => str2entry: "dn: cn=config [...] modifiersName: uid=leoadm,ou=LDAPusers,dc=wu-wien,dc=ac,dc=at modifyTimestamp: 20091208164511Z " >>> dnPrettyNormal: <cn=config> <<< dnPrettyNormal: <cn=config>, <cn=config> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnPretty: <uid=leoadm,ou=LDAPusers,dc=wu-wien,dc=ac,dc=at> PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. <<< dnPretty: <uid=leoadm,OU=LDAPusers,DC=wu-wien,DC=ac,DC=at> >>> dnNormalize: <uid=leoadm,OU=LDAPusers,DC=wu-wien,DC=ac,DC=at> <<< dnNormalize: <uid=leoadm,OU=LDAPusers,DC=wu-wien,DC=ac,DC=at> <= str2entry(cn=config) -> 0x93a7ee4 -------------------- 8< -------------------- Any hints? Thanks, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria

2 1

TLS + SSL and openldap
by Bruno Steven 12 Dec '09

12 Dec '09

Hi, I am trying configure openldap work with tls , but I have two question about this, first when I use tls openldap use port 389 and ssl port 639 , is this correct ? Second How I can test connection between client and server, cryptography is working ? Thnaks. -- 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.

7 10

Re: restrict host login based on group
by Adam Hough 11 Dec '09

11 Dec '09

There are other ways to populate the pam_groupdn that you have associated with each machine but those all correspond to some attribute in the user's profile. I have pam_groupdn setup like this /etc/ldap.conf: pam_groupdn cn=<GROUP_NAME>,ou=Systems,dc=domain,dc=com pam_member_attribute member cn=<GROUP_NAME>,ou=Systems,dc=domain,dc=com cn: <GROUP_NAME> objectClass: top objectClass: groupOfNames objectClass: labeledURIObject member: uid=nobody,ou=People, dc=domain,dc=com labeledURI: ldap:///ou=People,dc=domain,dc=com??one?(host=<type of system>) labeledURI: ldap:///ou=People,dc=domain,dc=com??one?(gidNumber=XXXX) So as you can see you can have as many labeledURI attributes as you want or need. I tend to use the host name function of what the host does. This is how my account profile would look: uid=<MYUSERID>,ou=People,dc=domain,dc=com host: "cluster" host: sysadmin So "cluster" is a compute cluster that we have and thus for all those machines the pam_groupdn cn="cluster",ou=Systems,dc=domain,dc=com, and for machines where only the sysadmins login to then pam_groupdn cn=sysadmin,ou=Systems,dc=domain,dc=com. As long as you can for a labeledURI: ldap:///ou=People,dc=domain,dc=com??one?<attribute>=<value>) type search you can use it to auto populate the group. Summary: * Do to not think of the host attribute as host = hostname but as host = type of machine and that you can have more then one labeledURI per group to help populate the group. * Use good gidNumbers for groups to help auto populate groupOfName style groups. - Adam On Wed, Dec 9, 2009 at 4:01 AM, Shamika Joshi <shamika.joshi(a)gmail.com>wrote: > Hi Adam, > I'm able to get host auth working by using host attribute.But the drawback > of that is everytime there a new machine, I have to add that host to all the > users I want to grant access to. If I decide to do it based on group > membership, I can use pam_groupdn but then it does not allow multiple group > entries there, plus it has to be managed on client side,which is even more > undesirable by any administrator. > > I went through this article but I'm not sure if it will work if I have some > members already associated with some groups. Like ldap1 & ldap2 members of > qagroup & ldap3 & ldap4 members of sysadmin, would this method allow me to > limit access based on their group membership?? if yes...could you briefly > explain with an example? > > Thank for your time in advance > Shamika > > > > On Wed, Dec 9, 2009 at 9:04 AM, Adam Hough <adam(a)gradientzero.com> wrote: > >> Here is is the write up that I read to figure out how to do setup to >> auto-restrict users to certain hosts. >> >> >> http://www.hurricanelabs.com/september2009_login_security_using_openldap_an… >> >> >> >> On Tue, Dec 8, 2009 at 4:40 PM, Howard Chu <hyc(a)symas.com> wrote: >> >>> Shamika Joshi wrote: >>> >>>> Thanks Howard, >>>> Could you point me to some good documentation or HowTos on that? >>>> >>> >>> Search the archives. I posted an example in here a few months ago. >>> http://www.openldap.org/lists/openldap-technical/200905/msg00108.html >>> >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>> >> >> >

2 2

MUA that could address LDAP Groups ?
by Frank Bonnet 11 Dec '09

11 Dec '09

Hello I'm searching for a Mail User Agent that could send emails to all users living in a LDAP group. Anyone knows such program ? Thanks

1 0

syncrepl broke, connection loss
by Peter Mogensen 10 Dec '09

10 Dec '09

Hi, I've loaded my mirror mode setup with data and let it run for a few day, Both cn=config and the application database is mirrored. Only server1 is receiving writes from the application. OpenLDAP 2.4.20, BDB 4.8 After about 6 hours the mirror partly broke and I experience 3 symptoms: 1) The syncrepl connection from server1->server2 for the application database is missing and data only flows from server1 to server2 - not the other way. The cn=config connections exists. $ netstat -tna # shows tcp 0 0 192.168.0.102:636 0.0.0.0:* LISTEN tcp 8125 0 192.168.0.102:45535 192.168.0.101:636 ESTABLISHED tcp 0 0 192.168.0.102:636 192.168.0.101:34954 ESTABLISHED tcp 0 0 192.168.0.102:45537 192.168.0.101:636 ESTABLISHED Where it should show, something like: tcp 0 0 192.168.0.101:636 0.0.0.0:* LISTEN tcp 0 0 192.168.0.101:34954 192.168.0.102:636 ESTABLISHED tcp 261 0 192.168.0.101:33409 192.168.0.102:636 ESTABLISHED tcp 0 0 192.168.0.101:636 192.168.0.102:45537 ESTABLISHED tcp 0 0 192.168.0.101:636 192.168.0.102:33226 ESTABLISHED 2) Meanwhile the log on server1 says: Dec 8 02:04:03 server1 slapd[6863]: do_syncrepl: rid=004 rc -1 retrying Dec 8 02:05:03 server1 slapd[6863]: do_syncrepl: rid=004 rc -2 retrying Dec 8 02:06:03 server1 slapd[6863]: do_syncrepl: rid=004 rc -2 retrying etc... The first such entry appear around 6 hours after start of the mirror. 3) If I try to change cn=config with ldapmodify on either server, server1 will hang, not answering queries until I restart it. For instance, if I do: ---------- dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: None sync ----------- ... it'l hang. I was able to connect and search the database on both server, to both servers like (on server1), using client certs: ldapsearch -H ldaps://server2/ -YEXTERNAL -b cn=data,dc=example,dc=com -s sub -D cn=config '(cn=*)' + \* So it's not that the TCP connection can't be established. Which make me suspect that this is related to this thread: http://www.mail-archive.com/openldap-software@openldap.org/msg16028.html Now after 27 hours the connection finally came back by it self, and replication works both ways. The "rc -2 retrying" in the log on server1 stopped and was replaced by: Dec 8 15:39:34 server1 slapd[11177]: do_syncrepl: rid=004 rc -2 retrying Dec 8 15:40:34 server1 slapd[11177]: do_syncrepl: rid=004 rc -2 retrying Dec 8 15:42:15 server1 slapd[11177]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Dec 8 15:47:05 server1 slapd[11177]: => bdb_idl_delete_key: c_del id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Dec 8 15:47:05 server1 slapd[11177]: conn=15694 op=16: attribute "entryCSN" index delete failure Dec 8 15:47:06 server1 slapd[11177]: => bdb_idl_delete_key: c_del id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Dec 8 15:47:06 server1 slapd[11177]: conn=15569 op=36: attribute "entryCSN" index delete failure ... and a bit more of the same. Trying to modify cn=config with ldapmodify still makes server1 (and ldapmodify) hang though. /Peter

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2009