openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

Re: invalid syntax on pwdPolicy object add
by Julien Vehent 13 Sep '10

13 Sep '10

On Mon, 13 Sep 2010 19:29:12 +0530, Kiran Ayyagari <kayyagari(a)apache.org> wrote: > On Mon, Sep 13, 2010 at 5:07 PM, Julien Vehent <julien(a)linuxwall.info> wrote: >> >> >> >> # slapd -V >> @(#) $OpenLDAP: slapd 2.4.23 (Aug 26 2010 18:33:04) $ >> root@monster:/tmp/buildd/openldap-2.4.23/debian/build/servers/slapd >> >> >> It's not a space/tab problem, and I've tried to put the request in an ldif file and insert it, with the same result. >> It's definitely a constraint that's not satisfied... but which one ?? > > think it is reproducible cause I have got the same error when I > followed the above steps > 'error code 21 - pwdAttribute: value #0 invalid per syntax' > > I have built OpenLDAP version 2.4.23 on Ubuntu 9.04 with berkeley db > version 4.7.25 > > Kiran Ayyagari > Alright, so it's either my steps that are wrong, or a problem with slapd. I'll be humble and suppose that my configuration is wrong first. Any hint on what I could have missed ? described here: http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:openldap:openlda… Julien

2 1

Logging practices of OpenLDAP
by Mark John Rank 13 Sep '10

13 Sep '10

List: UW-Milwaukee is in the process of reviewing IAM infrastructure and looking to harmonize logging, audit and data retention configuration for many of our IAM related services. Our OpenLDAP service is in scope for this review. To help frame the review, I am looking for guidance or best practices for configuring logging for OpenLDAP, especially for the HigherEd community. Of particular interest is the decision process around balancing log level, performance overhead and data retention. A search of the archives didn't result in much so I though I would just ask the question of the list. If individuals are interested in sharing, they can reply to the list or they can contact me directly at the address below. Regards, Mark ------------------------------------------ Mark Rank, Middleware Architect University Information Technology Services UW-Milwaukee Email: rankm(a)uwm.edu Phn: 414-229-3706 ------------------------------------------

1 0

Confused about password authentication formats
by 1.41421＠gmail.com 12 Sep '10

12 Sep '10

I have an OpenLDAP 2.4.23 server up and running in a Linux box L against which I can carry out password authentication on behalf of users logging into an embedded system E. To accomplish this, in LI have an LDIF file with entries along the following lines: dn: uid=xxx,ou=yyy,dc=zzz,dc=com uid: xxx cn: xxx objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: ThisIsthePassword shadowLastChange: 14014 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1003 gidNumber: 1003 homeDirectory: /home/xxx gecos: ,,, I would like to change this so that, when sending password information from my LDAP client in E to the LDAP server in L, the password itself is never sent in the clear. So I thought to change the value of the userPassword attribute to read {SHA}3DRF4FXpG8r+Ki8i8azuZh7KwO8= instead, where the string above was obtained by means of slappasswd -v -s ThisIsthePassword -h "{SHA}" in L. After restarting the LDAP server in L, when user xxx logs into E with password "ThisIsthePassword" I can verify in the traces of the LDAP server (I am running it as slapd -d 255) that the client in E is sending the "3DRF4FXpG8r+Ki8i8azuZh7KwO8=" string, exactly as specified in the value of the userPassword attribute. However, the authentication is failing. What is it exactly that the LDAP client in L is supposed to be sending to the LDAP server in this case? I noticed that if the client sends the actual "ThisIsthePassword" string instead the authentication also fails. I am obviously missing something here but, what is it?

2 2

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical