> 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
>> 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: => bdb_equality_candidates (objectClass)
Sep 1 14:02:52 LDAP01 slapd: => key_read
Sep 1 14:02:52 LDAP01 slapd: <= bdb_index_read 355545 candidates
-----BEGIN PGP SIGNED MESSAGE-----
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_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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
-----END PGP SIGNATURE-----
--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.
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:
Infrastructure Delivery Group, Stanford University
I'm in trouble with slapcat when generating a LDIF file
it puts some extra "space" characters into some dn longer than 80
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
sometime I get this
sometime I get this
sometime I get this
> 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.
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?
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
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
Mark Adrian Coetser
cel: +27 76 527 8789
fax: +27 86 677 4117
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.
- 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
Slapd should use pam to authenticate, or directly talk to the kerberos
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
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)
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
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.
I probably miss something very simple... it shouldn't be that hard to
have slapd get its credentials from kerberos!
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
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.