OpenLDAP and DNS SRV records
by Matt Kowske
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?
14 years, 9 months
Sync replication and "*Password" attributes
by Alexey Lobanov
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
14 years, 9 months
Re: Re: SASL/GSSAPI: ldap_sasl_interactive_bind_s: Local error (-2)
by thecwin＠gmail.com
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
14 years, 9 months
SASL/GSSAPI: ldap_sasl_interactive_bind_s: Local error (-2)
by Cameron Harris
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
14 years, 9 months
Re: Updating a private schema (cn=config)?
by hyc＠symas.com
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.
14 years, 9 months
Re: Updating a private schema (cn=config)?
by Andrzej Jan Taramina
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
14 years, 9 months
How to hide namingContext in rootDSE ?
by Thomas Chemineau
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
14 years, 9 months
Disable GSSAPI confidentiality
by Jeremiah Martell
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
14 years, 9 months
Re: Updating a private schema (cn=config)?
by Andrzej Jan Taramina
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
14 years, 9 months
