openldap-software

openldap-software@openldap.org

2719 discussions

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

Fwd: how to configure tls and ldap
by Alfonsas Stonis 11 Dec '08

11 Dec '08

Hi, Thanks for replay. I copied them to this directory. There should be no problems with permissions. The thing is that when I first got error message I changed permission to by giving all rights to everyone. It did not changed a thing. Alfas 2008/12/11 Markus Wernig <listener(a)wernig.net> Hi > > You have either > - set permissions on the certificates/keys that do not allow slapd to read > them (check also directory permissions). > or > - /etc/ldap/ssl/demoCA/newreq.pem is not a RSA private key. This depends on > how you created your certificate. If you followed the instructions in > http://www.openldap.org/faq/data/cache/185.html, you should have your > certificates and keys in a separate folder. The demoCA component in your > path names shows that you seem to have created the CA under > /etc/ldap/ssl/demoCA, which was probably not what you wanted (hint: don't > run CA.sh from /etc/ldap/ssl). > > Please follow the instructions more closely and locate the following three > files and verify that slapd has read access to them: > > 1) CA certificate > 2) slapd's private key > 3) slapd's certificate > > kind regards > /markus > > > Alfonsas Stonis wrote: > > Dec 11 16:47:41 axew0204 slapd[434]: main: TLS init def ctx failed: -34 >> >

1 0

Unable do slapadd a LDIF dump from slapd 2.2.6 to slapd 2.4.9
by Markus Wernig 11 Dec '08

11 Dec '08

Hello all! In the process of upgrading slapd from 2.2.6 to 2.4.9 (ubuntu 6.06 to 8.04), I get the following error when trying to import the LDIF dump from the old server: # slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif slapadd: dn="o=Company Name,c=CH" (line=1): (65) no structural object class provided (same result if I skip the -b "o=Company Name,c=CH") slapd.conf has not been altered during the upgrade and contains: [...] include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema [...] database bdb suffix "O=Company Name, C=CH" checkpoint 512 30 directory "/var/lib/ldap" rootdn "cn=root, O=Company Name, C=CH" rootpw XXX index objectClass eq [...] The first entry in the LDIF dump is: dn: o=Company Name,c=CH objectClass: top entryUUID: ... creatorsName: cn=root,o=Company Name,c=CH modifiersName: cn=root,o=Company Name,c=CH createTimestamp: 20071214103903Z modifyTimestamp: 20071214103903Z entryCSN: 20071214103903Z#000001#00#000000 (This directory contains only x.509 CRLs and certificates.) From the error I assumed that for some reason the "top" objectclass was not correctly defined. In core.schema I found the following new entry from RFC2256, which was commented out: #objectclass ( 2.5.6.0 NAME 'top' # DESC 'RFC2256: top of the superclass chain' # ABSTRACT # MUST objectClass ) After uncommenting, though, the error is: slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif /etc/ldap/schema/core.schema: line 366 objectclass: Duplicate objectClass: "2.5.6.0" slapadd: bad configuration file! Yet, no other schema file contains any definition for 2.5.6.0, so I assume that it's compiled into slapd. This leaves me stuck, scratching my head, and extremely grateful for any hint on where to look further. Thank you all krgds /markus

5 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software