openldap-technical September 2010

openldap-technical@openldap.org

111 participants
113 discussions

Re: objectClass index from slapd.conf is not working
by tim stone 10 Sep '10

10 Sep '10

> The very first time you start slapd, I always expect searches to be slow, as > it has to load up the dncache, entrycache, and idlcache. If you are only > seeing this slowness the first time the search executes after slapd is > started, then this is normal behavior. No, as I said, it takes always a long(er) time. It seems to me, that the index for objectClass returns too much entires?! If I search for an other indexed attribute in the same container (exist in this container also only one time), then the index returned the matched entity in only 0,05 sec (used command time for measuring). See my first posting. Only for the index objectClass I see this strange behavior. The index should return only one Candidate, if there is only one entry that match in this searchBase? kindly regards, Tim

1 0

Re: objectClass index from slapd.conf is not working
by tim stone 10 Sep '10

10 Sep '10

>> >> I tried to increase the cachesize and idlcachesize to 100000 and >> restarted the slapd, but it did not help. > > If you are using back-hdb, and using a subtree as the base (which it looked > like you were doing), the first time through the search will be very slow > while the cache is filled. That's a long-standing issue with back-hdb. > Subsequent searches are substantially faster. > Thanks, but I use bdb as backend (see config). Due more investigation today I find out, that if I use cachsize and idlcachsize about 500000 the second response (after first search) is quite faster, because now the entries are cached. But by configuring an index for objectClass it should avoid for searching all the entries? This Configuration is not applicable at the moment, because my Linux is 32bit (PAE) and the cachesize for the bdb-index is 1GByte. Slapd is using about 2Gby of RAM at the moment. But if I could increase the RAM, the problem of the index still exist. In one of my DN (Container) are 88000 entires. I placed my search there (searchBase) Only the Container itself has the searched objectClass, but all entires in this container will be examined too. Should the index for objectClass not only give back this _one_ (and not 355545) Candidate, or do I misunderstood this? ================================================== Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates ================================================== Thanks Tim

2 1

GSSAPI Bind across trusted realms
by Indexer 09 Sep '10

09 Sep '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have REALM.A and REALM.B in my KDC setup. There is a two way trust between REALM.A and REALM.B. I have a client computer on REALM.A, and can correctly kinit to get tickets from both realms via this trust pathway. I also have an OpenLDAP server on the server with REALM.B, and it is identified by ldap/ldap.realm.b(a)REALM.B When i obtain a ticket on REALM.A via this , and try to execute a SASL bind to the ldap server, i get an error of SASL/GSSAPI authentication started ldap_err2string ldap_sasl_interactive_bind_s: Local error (-2) It says that Minor code may provide more information (Server ldap/ldap.realm.b(a)REALM.B not found in Kerberos database). A user from REALM.B can access the LDAP server correctly with GSSAPI klist shows that i am getting a TGT for both REALM.A and REALM.B on my user(a)REALM.A. Is this an issue with kerberos being unable to find the ticket across the realm trust for ldap to be verified? What steps can i follow to help fix this issue? Are there principal flags that i am forgetting to add to my LDAP principal for this to work? Your help is appreciated. William Brown pgp.mit.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iQIcBAEBAgAGBQJMiF0cAAoJEHF16AnLoz6J6mIP/0Jnfw8vG13LyOlv2gm3zwrF psHWASKmzaPngS0c7nbNSDDWi6jZJXogP9kF8uI/JQibUlYJb9TtfiG1K7l6yMol /jD8l3TGVy/VBrG6Yk0sqiQeHn52IaPTXv/xk0a8o6rk/wAUFzEnXH3+K/oRg+4A +Z5WHWHsdz73QBkMRVE+IY+IHwUB+GoglyocZmnQBjigU+2+So2hhlxp8XqmZPSZ jke2yk375LXHgv8/cppIIx3YV5VtvMe/O/lQoptBl39D8Y7CFwJsuQqGtyTRQVJh PpnMDARhqR+UKqJeZRksQLUeFZhQYzLWpTStm/8NhYAVBhTF32NPwgkcv5LohUdH yK3TCjvPodXCs27kGFX2s20tpFjLfpnx+gzyCTRQbbygPR4/Nn+11kmqDlrC05fW GpUOA8aknL7J6tN5twlO/wHtIaIvTPP4MmDD9DlS6OtNbBtaumDrS6ehWQ0j4FlA IfK+eHwIRgvjxCGa7N9S7jv5ZqxkAyeVArWWJczcCL6qKij7Zgh0w8nvzMTJq1Jj TwYK9O8RHL0d66NSFs2sTaEUZECnYA29oh6XppmvaOUdI5JOzQ4keG6xhTieRPBx Tdkq/1B51nl6EfJTu4fLOKfRz2UnOY2Uvms+2qdH0cZZIhOu98I3BsSdKhUgPtAB kZoLSAwYj33BL/KU/8Yj =RZcN -----END PGP SIGNATURE-----

2 1

Re: Authenticate to ldap using Kerberos
by Bill MacAllister 09 Sep '10

09 Sep '10

--On Thursday, September 09, 2010 08:02:54 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, September 09, 2010 5:13 PM +0800 Wouter van Marle <wouter(a)squirrel-systems.com> wrote: > >> Kerberos is the authentication system, it's specialised in that. At >> least that's what I learned about it. I have set it up in order to have >> a single sign-on, a single password for all services running on my >> network, makes it much easier for me to administer. >> >> LDAP is a specialised database system storing typically personal >> information, I also use it for aliases database, userID, groupID, and >> other system info. This part works great as well. >> >> Now all I want is for openldap to use kerberos as its authentication >> broker. Nothing more, nothing less. LDAP is now authenticating its users >> by itself which seems to be the default behaviour, and that's what I >> want to get rid of. As you say yourself LDAP is not an authentication >> broker, but why can it not easily be configured to use an external >> authentication broker, such as pam, which is designed to be just that? > > You are directing your unhappiness at the wrong place, as Howard > already noted. As someone who set up a large OpenLDAP directory > service that only allows SASL/GSSAPI connections, the issue is not > OpenLDAP. The problem is client software that, even though SASL has > been a standard for many, many years, still fail to properly support > it. This includes things like Evolution and Postfix. I used to > maintain a patch for Postfix specifically that allowed it to do > SASL/GSSAPI binds. > > In sum, SASL is the RFC supported mechanism to use for doing these > types of binds to LDAP. It has been the RFC supported method for a > very, very long time. Unfortunately, people who write LDAP client > software often skip implementing SASL support. This is not the > fault of the OpenLDAP or any other directory project. If you have > client software that doesn't support SASL that implements LDAP v3 > support, then you need to contact the authors of that software or > fix it yourself. > > --Quanah Following up on Quanah's assertion that this is a client problem, you might want to help some clients pick the correct SASL mechanism when connecting to your LDAP server by restricting the mechanism list that is presented to the clients. In the default installation OpenLDAP's slapd will present all of the mechanisms that it knows about which probably includes mechanisms that you don't support. In the case of allowing only Kerberos authenticated binds you will want to restrict the mechanism list to GSSAPI. I went back to look at where setting the mechanism list was documented and what I found was a set of internal email exchanges describing the problem. Re-reading email stream it looks like the mechanism list on Debian systems will be read from either /usr/lib/sasl2/slapd.conf or /etc/ldap/sasl2/slapd.conf. We are using a /etc/ldap/sasl2/slapd.conf that consists of: mech_list: GSSAPI Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

slapcat generate extra "space" characters in LDIF output
by Frank Bonnet 09 Sep '10

09 Sep '10

Hello I'm in trouble with slapcat when generating a LDIF file it puts some extra "space" characters into some dn longer than 80 characters. is there a way to change the output format of slapcat command to generate lines longer than 80 characters in the LDIF file ? I need this because I need to duplicate our directory server to another TLD and I need to substitute dc=fr by dc=biz but sometime I get this ------------------------------------------------dc=fr sometime I get this ------------------------------------------------dc= fr sometime I get this ------------------------------------------------dc =fr sometime I get this ------------------------------------------------dc= fr Thank you

6 7

Re: slapcat generate extra "space" characters in LDIF output
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

> I'd note that while the current maximum width of lines is enforced to 76 > chars, they happen to be 78 char long (because of an extra LDIF_KLUDGE set > to 1 and, I guess, of the leading blank). > > In any case, in the spirit of being liberal when needed, I have nothing > against allowing OpenLDAP tools to visualize LDIF with arbitrary width, as > soon as the default behavior remains the original one, in order to avoid > breaking existing software. See <http://www.openldap.org/its?findid=6645>. p.

1 0

cn=config and ACL formatting
by Victor Mataré 09 Sep '10

09 Sep '10

Hi everyone, I just switched our servers from slapd.conf to cn=config in slapd.d, and I'm a bit annoyed with my ACLs now. The problem is that olcAccess attributes tend to be somewhat lengthy and I'd really appreciate some newlines in them, but slapd seems to eat those. Is there any way to tell the server to preserve the newlines in attribute values, or maybe use some other character that causes a line break? Of course I might edit the files in /etc/slapd.d, but then the whole cn=config thingy becomes pointless, doesn't it? greetings, Victor

5 5

rwm rewrite
by Mark Coetser 09 Sep '10

09 Sep '10

Hi I have googled and read over slapo-rwm man page, some great examples there BUT I cant seem too grasp the rewrite rule. Basically I have merged a couple of individual openldap directories under a meta database which works fine. Some of the individual directories have clashing posix uidnumber attributes ie uid=joe,dc=subdomain1,dc=test uidnumber: 1023 uid=soap,dc=subdomain2,dc=test uidnumber: 1023 uid=user2,dc=sudomain2,dc=test uidnumber: 1024 what I am trying too do is create a rwm overlay that would rewrite the uidnumber attribute for subdomain2 so add a 10 in front of each uidnumber for each user in the subdomain database. ie uid=soap,dc=subdomain2,dc=test uidnumber: 101023 uid=user2,dc=sudomain2,dc=test uidnumber: 101024 -- Thank you, Mark Adrian Coetser mark(a)tux-edo.co.za http://www.tux-edo.co.za http://www.tux-voip.co.za cel: +27 76 527 8789 fax: +27 86 677 4117

2 2

Authenticate to ldap using Kerberos
by Wouter van Marle 08 Sep '10

08 Sep '10

Hi group, I have been fighting the whole day already for something that I think is quite simple but I just can't get it to work: have slapd authenticate users against kerberos. Following many tutorials, trying many things, I give up on that and ask for your help. System: Debian Lenny. Situation: - workstation logins over the network authenticate against kerberos - credentials from LDAP - postfix has its alias database etc in LDAP, as are the groups and userIDs and everything - helps keeping uids the same on the workstations. Essential for NFS. - anything using pam will be authenticated against kerberos, including imap, postfix, etc. Except LDAP. Then slapd authenticates by itself against the password stored there. And that's not what I want. There should be no passwords in LDAP any more, everything against kerberos. Then at least when a user changes their kerberos password, the same password is used everywhere. I just can't get this to work for some reason. I have followed many tutorials, so many that I forgot what I did, and it still doesn't work. Slapd should use pam to authenticate, or directly talk to the kerberos server, whatever. saslauthd has the gssapi module installed. I have created an ldap/acorn.squirrel@SQUIRREL key, and added this keytab in /etc/defaults/slapd. acorn.squirrel is the fqdn of the server, SQUIRREL is its kerberos realm. My clients all run Ubuntu 10.04 LTS (a nice desktop but shitty to get kerberos/ldap authentication work on amongst other griefs). Current situation after all the hacking: $ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h acorn.squirrel Enter LDAP Password: ldap_bind: Invalid credentials (49) when entering my Kerberos password; it accepts my credentials when I enter the LDAP stored password (a different password). Then I just did: ======================= wouter@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) wouter@acorn:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w Default principal: wouter@SQUIRREL Valid starting Expires Service principal 09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/SQUIRREL@SQUIRREL renew until 09/09/10 22:42:07 09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squirrel@SQUIRREL renew until 09/09/10 22:42:07 Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached ======================= OK it seems ldap gets it's ticket. Issued the moment I ran the above command. Still I get the bind error. But for some reason I do not have a ticket myself, interesting. Running kinit doesn't solve this strangely enough, on the workstations it does give me a ticket. And running kinit kills the ldap ticket. Appears strange to me. Any ideas? I probably miss something very simple... it shouldn't be that hard to have slapd get its credentials from kerberos! Thanks! Wouter.

3 5

back-sql disconnects
by Frederik Bosch 08 Sep '10

08 Sep '10

While I have my slapd-server completely up and running, I do have one obstacle. The sql connection disconnects after some time of idling (MySQL server has gone away). Probably because the maximum seconds of idling has been reached. This means I have to restart slapd to fix the connection. I could open a cronjob to do that, but that's more a last-resort-solution. Is there a config option for reconnection or is there another possible solution? I could imagine that slapd would try to reconnect in case it loses sql connection because this could happen for all sort of reaons. Server information: I am on Debian Squeeze using openldap 2.4.17, recompiled with back-sql and openssl. The sql server is MySQL 5/InnoDB. I do not have full control over the sql server. So I cannot add a user without idling limit.

2 5

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2010