openldap-software December 2008

openldap-software@openldap.org

45 participants
42 discussions

OpenLDAP and DNS SRV records
by Matt Kowske 16 Dec '08

16 Dec '08

Hello, I have been searching google trying to find an answer to this, but have only things dated 2001 and prior. Question: Does openldap (client) support the use of SRV records to determine the availability of an ldap server? In this particular case, the openldap libraries are compiled into another unix executable and 1 of 8 AD servers is contacted via round robin DNS aliasing. Is it possible for openldap to reference the SRV record in DNS rather than the A record?

1 0

Sync replication and "*Password" attributes
by Alexey Lobanov 16 Dec '08

16 Dec '08

Hello all. I see a dumb problem trying to implement LDAP Sync Replication in a group of Debian servers. Everything works fine except userPassword, sambaLMPassword and sambaNTPassowrd attributes; the replicas (two of two) just don't have those attributes in any downloaded entries. Yes, I have checked the access rights: syncrepl binddn has "read" rights for passwords, and "ldapsearch -H ldap://master..." with RDN and credentials used in replicas shows everything including all three password hashes. Slave logs show nothing useful. "loglevel Args" at slave mentions all attributes except those "*Password" upon master entry modification. OpenLDAP version is 2.3.30-5+etch2, the current in Debian Etch. A proposal to upgrade to 2.4 will not be accepted unless I'll know about *exact* change in 2.4 fixing this [mis]behavior; just because the master is a production server. Alexey

4 7

Re: Re: SASL/GSSAPI: ldap_sasl_interactive_bind_s: Local error (-2)
by thecwin＠gmail.com 15 Dec '08

15 Dec '08

On Dec 15, 2008 3:49pm, Dan White <dwhite(a)olp.net> wrote: > Cameron Harris wrote: > > > On Sun, Dec 14, 2008 at 3:34 PM, Michael Ströder michael(a)stroeder.com michael(a)stroeder.com>> wrote: > > > > Cameron Harris wrote: > > > On Sun, Dec 14, 2008 at 11:31 AM, Michael Ströder > > michael(a)stroeder.com michael(a)stroeder.com> > > > michael(a)stroeder.com michael(a)stroeder.com>>> wrote: > > > > > > > Did you obtain a TGT before? What's the output of command klist? > > > > > > I did obtain a TGT with kinit: > > > > Hmm, I vaguely remember having to use "kinit -A" to avoid the > > local error. > > > > Ciao, Michael. > > > > > > Didn't work, unfortunately. > > Same error. :( > > > > Cameron Harris > > > > > Cameron, > > > > Here are some sanity checks to try: > > > > Query your LDAP server to make sure that it is offering GSSAPI: > > > > ldapsearch -H ldap://ldap.example.net -x -b "" -s base -LLL supportedSASLMechanisms > > > > dn: > > supportedSASLMechanisms: DIGEST-MD5 > > supportedSASLMechanisms: NTLM > > supportedSASLMechanisms: GSSAPI > > supportedSASLMechanisms: OTP > > supportedSASLMechanisms: CRAM-MD5 > > > > If GSSAPI is not listed, verify configuration on the server. Check that the GSSAPI SASL mechanism is installed: > > > > ~# pluginviewer | grep -i gssapi > > pluginviewer: SASL Other: OTP: auxprop backend can't store properties > > LOGIN DIGEST-MD5 NTLM GSSAPI OTP PLAIN ANONYMOUS CRAM-MD5 EXTERNAL > > Plugin "gssapiv2" [loaded], API version: 4 > > SASL mechanism: GSSAPI, best SSF: 56, supports setpass: no > > LOGIN DIGEST-MD5 NTLM GSSAPI OTP PLAIN ANONYMOUS CRAM-MD5 EXTERNAL > > Plugin "gssapiv2" [loaded], API version: 4 > > SASL mechanism: GSSAPI, best SSF: 56 > > > > Verify configuration of your slapd.conf SASL config: > > > > ~# cat /usr/lib/sasl2/slapd.conf > > keytab: /etc/krb5.keytab-ldap > > pwcheck_method: auxprop saslauthd > > auxprop_plugin: slapd > > > > (The location of your SASL slapd.conf config is dependant on how your SASL libraries are compiled). Your config doesn't have to match mine. You might want to explicitly set the location of your keytab, and verify that you do not have a restricive 'mech_list'. *If* you have a mech_list defined, make sure it includes GSSAPI. > > > > If your server config looks Ok, verify that you have the GSSAPI mechanism installed correctly on your client system with the (Cyrus SASL) pluginviewer command. > > > > Verify that you are retrieving the ldap/ldap.local@LOCAL service ticket from the KDC on your client (with klist). If not, you may not not be specifying a fully qualified domain name in your URI statement within your ldap.conf config. Make sure your URI statement is a FQDN (and not an IP address or ldapi:///) or that you're specifying one within the ldapsearch statement. > > > > Most likely the error you're receiving can be traced down to a Cyrus SASL or Kerberos misconfiguration. Check your syslog and auth.log on the server and client for possible additional errors. > > > > - Dan > This is the output from my system: cameron@gimli:~$ ldapsearch -H ldaps://ldap.local/ -x -b "" -s base -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: PLAIN supportedSASLMechanisms: NTLM supportedSASLMechanisms: LOGIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 cameron@gimli:~$ saslpluginviewer | grep -i gssapi GSSAPI PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 ANONYMOUS EXTERNAL Plugin "gssapiv2" [loaded], API version: 4 SASL mechanism: GSSAPI, best SSF: 56, supports setpass: no GSSAPI PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 ANONYMOUS EXTERNAL Plugin "gssapiv2" [loaded], API version: 4 SASL mechanism: GSSAPI, best SSF: 56 I didn't have a sasl2/slapd.conf (strace showed that it was looking for one, but getting -1 ENOENT because obviously it didn't exist). I created one defining the keytab location explicitly, but I get the same error. FYI: cameron@gimli:~$ cat /etc/ldap/ldap.conf | grep -Ev "^(#|$)" BASE dc=local URI ldaps://ldap.local TLS_REQCERT allow cameron@gimli:~$ dig +short ldap.local gimli.local. 192.168.0.11 The slapd server and krb5-kdc are on the same system After running ldap commands, still the only thing that remains in my klist is my TGT -- no tickets from LDAP. The /var/log files contain nothing useful about SASL. Perhaps I should build it myself at some point, and eliminate the ubuntu-server build as a possible problem (and then I might also be able to do some gdbugging :)). Thanks, Cameron Harris

1 0

BDB 4.7.25 second patch released
by Quanah Gibson-Mount 15 Dec '08

15 Dec '08

Oracle has released the second official patch to BDB 4.7.25 that addresses ITS#5707. This patch is required for OpenLDAP 2.4.12 and later releases if you are using BDB 4.7.25. <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

SASL/GSSAPI: ldap_sasl_interactive_bind_s: Local error (-2)
by Cameron Harris 15 Dec '08

15 Dec '08

Hi all, I'm new to this so forgive me for any stupid questions/assumptions or if I miss anything out. :) I'm trying to set up a Krb5 authenticated OpenLDAP server, mainly for educational purposes, so I've been trying to merge together various guides on the internet to a working setup. Unfortunately, I'm now getting the following error: cameron@gimli:~$ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) No additional information or anything. ldapsearch -x works as expected. My setup is currently all on one system: Ubuntu Server 8.10, slapd/ldap-utils 2.4.11, MIT krb5-kdc 1.6. This is my config file (slapd.d format): root@gimli:~# cat /etc/ldap/slapd.d/cn\=config.ldif dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 olcTLSCACertificateFile: /etc/ldap/ssl/server.pem olcTLSCertificateFile: /etc/ldap/ssl/server.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/server.pem olcTLSVerifyClient: allow olcSaslRealm: LOCAL olcSaslHost: ldap.local structuralObjectClass: olcGlobal entryUUID: ccd3335c-5da4-102d-9155-ed2c61020a96 creatorsName: cn=config createTimestamp: 20081213210021Z entryCSN: 20081213210021.939004Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081213210021Z I'm using ldaps://ldap.local as the service URL, and that all seems to be working okay as indicated by the simple authentication. ldap.local has an entry in the DNS server. Any ideas on where I can go from here? Thanks, Cameron Harris

3 5

Re: Updating a private schema (cn=config)?
by hyc＠symas.com 13 Dec '08

13 Dec '08

On Thu, Dec 11, 2008 at 10:37:26AM -0500, Andrzej Jan Taramina wrote: > Howard replied: > >> This was just discussed on -technical as well. You can delete >> individual schema elements using ldapmodify. You cannot delete entire >> cn=config entries (using ldapdelete). There are no plans to change this >> behavior for schema in the future. > > Using ldapmodify for individual entries is painful in the extreme, since > each entry only has a single attribute...basically a monster string with > all the schema constraints in it. What are you talking about? A schema entry under cn=config has individual attribute values per schema element. Editing individual schema elements is far more useful than deleting the entire schema and reloading it.

7 14

Re: Updating a private schema (cn=config)?
by Andrzej Jan Taramina 13 Dec '08

13 Dec '08

Howard said: > Exactly. "database" != "RDBMS", no matter how much the RDBMS folks > like to claim otherwise. According to Wikipedia: "A database is a structured collection of records or data that is stored in a computer system. The structure is achieved by organizing the data according to a database model. The model in most common use today is the relational model. Other models such as the hierarchical model and the network model use a more explicit representation of relationships." So I suppose technically a ldif-formatted flat file does fit the definition of a "database". But I think you guys are splitting hairs, the red flag indicator being someone mentioning "sparking a semantic war". As for RDBMS's, they do have their place. I tend to prefer XML databases these days for many applications. It would be interesting to see an LDAP interface put on top of an XML database, though I doubt that is worth doing or will happen. > What you've described is similar to the original design, 3 years ago, but it > proved unworkable. You can read through the openldap-devel archives from that > time period for more background on the decisions. As I recall, we ran into > trouble with schema extensions and a few other elements that didn't lend > themselves well to being treated as distinct attributes. Pity. Then again, times change and new solutions to old problems sometimes surface, so decisions made that long ago are worth revisiting sometimes. 3 years is a long time in technological terms. As for reading the archives, in my copious spare time, right? ;-) > You should learn a bit more about why and how things work, before suggesting > they be changed. I did not suggest that they be changed, Howard. Try re-reading my post. I only suggested that had the outlined, more granular attribute structure, been implemented, I would have agreed with you about the "ease of use" issue. You seem to have a big chip on your shoulder, Howard, though that might just be the typical email impedence mismatch issue and a mis-interpretation on my part. Regardless, not exactly conducive to attracting new involvement in the OpenLDAP project from other people who might have something to contribute, IMO. 'nuff said from me on this topic. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com

2 1

How to hide namingContext in rootDSE ?
by Thomas Chemineau 12 Dec '08

12 Dec '08

Hi, My question is relative to "how to hide a namingContext in rootDSE?". But for information, I will explain why I need to configure this. Ref : http://www.openldap.org/lists/openldap-software/200501/msg00494.html I have two distinct OpenLDAP servers : - V1 : "o=example" ; - V2 : "dc=example,dc=com" I would like to delete the first one, and to allow most of V1's actions on V2 : - respond to V1 suffix ; - take care of DN in search result ; - take care of DN in uniqueMember ; For the moment, I have : - 1 back-ldap on "o=example" ; rwm-suffixmassage "o=example" "o=example transitional" rwm-map attribute uniqueMember tmpUniqueMember - 1 back-ldap on "o=example transitional" rwm-suffixmassage "o=example transitional" "dc=example,dc=com" rwm-map attribute tmpUniqueMember uniqueMember - 1 back-hdb on "dc=example,dc=com" datas... nothing special - define tmpUniqueMember inherits from member, and used by an auxiliary objectclass in my groups All work fine. DN are rewritten on my uniqueMember's values. But, I think it is really ugly... Well now, I have few questions : 1/ Is there a better way to do this, without rewrite V2 values ? 2/ How can I hide my transitional LDAP suffix in the rootDSE ? 3/ Could it be possible to close all on this transitional LDAP backend and allow read access only for a particular user which will be use by the first LDAP backend (through acl-bind for example) ? Cheers, Thomas -- Thomas Chemineau Groupe LINAGORA - http://www.linagora.com Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29

2 1

Disable GSSAPI confidentiality
by Jeremiah Martell 12 Dec '08

12 Dec '08

Is there a way, when calling "ldap_sasl_interactive_bind_s", to tell it that when it does LDAP+GSSAPI authentication, only use GSSAPI for authentication, and not confidentiality? In other words, just use GSSAPI to encrypt the authentication part, but not all subsequent searches, etc. Thanks, -- - Jeremiah Martell http://inlovewithGod.com

4 5

Re: Updating a private schema (cn=config)?
by Andrzej Jan Taramina 12 Dec '08

12 Dec '08

Howard replied: > This was just discussed on -technical as well. You can delete > individual > schema elements using ldapmodify. You cannot delete entire cn=config > entries > (using ldapdelete). There are no plans to change this behavior for > schema in > the future. Using ldapmodify for individual entries is painful in the extreme, since each entry only has a single attribute...basically a monster string with all the schema constraints in it. > > > What about any entries that depend on the schema? Will they be > affected... > > The answer is "it depends"... Depends on what? I would really like to know what OpenLDAP does internally by way of linking entries back to their schema definitions, and when such linkages are used. > In general, once you start using a schema, you're stuck with it. > (Which is one > reason why ldapdelete for schema entries will never be implemented.) That makes no sense. Checking to see if there are entries that depend on the schema before attempting the delete and declining the delete if there are such entries makes sense. A blanket refusal to do such a delete is inappropriate, IMO. > You can > fine tune individual elements of it (alter definitions, add/remove > definitions), but there are issues that are still being worked on. > See ITS#5540 for one of the problems still in progress. Not receiving any practical tips on how to update a whole private schema in one fell swoop, here's what I did and what seemed to work fine: 1) Delete all entries that depend on the schema you need to updated (used ldapmodify) 2) Shut down slapd 3) sudo rm /etc/ldap/slapd.d/cn=config/cn=schema/cn={4}myschema.ldif. Change the last part to refer to your custom schema. I'm using latest Ubuntu Intrepid OpenLDAP, so the location of the cn=config dir may be different for you. 4) Restart slapd 5) Use ldapadd to add your modified schema 6) Use ldapadd to re-add your schema entries. This worked well for me, since I have entry deletion/creation ldif declarations that are automatically generated by our application....no problems detected so far. Anyone see any issues with this approach? Seems to me that the whole alternate configuration approach using cn=config in the database is still very much a work in progress. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software December 2008