Re: ldap_sasl_interactive_bind_s failed (-2) using openldap v2.3.43 when trying to replicate via syncrepl.
I should provide one more piece of information that might be important. I just
noticed in /var/log/messages:
slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more
information (Unknown code krb5 194)
Looking that error code up @
http://www.lineox.net/lineox/docs/HTML/info2html/krb5-admin/krb5-admin.info.Kerberos_V5_Library_Error_Codes.html
yeilds:
194. KRB5_FCC_PERM: Credentials cache file permissions incorrect
However, the credential cache file has the appropriate perms. LDAP runs as
user root. So, it should have no problems reading the /etc/krb5.keytab and the
credential cache file under /tmp
ls -la /tmp/krb5cc_0
-rw--- 1 root root 569 Mar 31 18:11 krb5cc_0
Thanks again!
Kris.
PGP Key: 4CC63A18
PGP Server: pool.sks-keyservers.net
On 2010-03-31, at 6:20 PM, Kristian Kostecky wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi guys,
I have a configuration that consists of 3 ldap servers. One is the provider
and there are 2 consumers. I am using syncrepl to do the synchronization.
simple and anonymous binds are totally disabled and Kerberos must be used via
SASL (GSSAPI) and TLS to connect to the LDAP server.
distro: centos 5.4
openldap 2.3.43
cyrus-sasl 2.1.22
Other things:
- - clocks are all in sync
- - hostnames all have forward and reverse mappings and all dns servers in
/etc/resolv.conf respond with proper entries on the consumer and both
providers.
Here's the catch, the two providers are configured the same (except for
hostnames/ips) and the first one works perfect. What is really frustrating
is the lack of logging that is available to tell me what the problem is.
I've tried loglevel -1 and it gave me even less info in regards to the SASL
authentication than leaving it off.
The affected consumer is giving me:
Mar 31 22:41:00 ZZZ slapd[2442]: slapd starting
Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrep1: rid 010
ldap_sasl_interactive_bind_s failed (-2)
Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrepl: rid 010 quitting
On the Provider:
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 ACCEPT from
IP=10.130.1.230:60288 (IP=0.0.0.0:389)
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 STARTTLS
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 RESULT oid= err=0 text=
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 TLS established tls_ssf=256
ssf=256
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=1 UNBIND
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 closed
This is what's REALLY weird - from the affected/broken box, ZZZ, after I
kinit, I can do an LDAP search or ldapwhoami, no problems! So, kerberos and
GSSAPI via SASL is working fine. ie:
ldapsearch -H ldaps://XXX/ -Y GSSAPI - will dump the entries.
or
ldapwhoami -H ldaps://XXX/ -Y GSSAPI - shows me that proper creds
If I destroy the credentials, it doesn't work as would be expected.
ON the working consumer, the behaviour is that I can ldapsearch and
ldapwhoami properly after I kinit and when I start ldap it will authenticate
properly with the provider via SASL GSSAPI and replicates the DB. If I
kdestroy the credentials and start it, I get the same error that I'm
struggling with on the box that doesn't work -ldap_sasl_interactive_bind_s
failed (-2) This behaviour leads me to believe that for some reason the ldap
server on the box that doesn't work is having problems transmitting the
kerberos credentials to the provider, whereas the ldapsearch and ldapwhoami
binaries are not having problems.
There are some suspicious differences between the consumer that works and the
broken one. The provider and consumer that works both have TLDs that match -
'.com' and the consumer whose synrepl process won't authenticate is part of
the .eu TLD. However, as you can see below in the krb5.conf files, the .com
and .eu TLDS are always mapped to the same authentication realm. PLUS,
again, ldapsearch and ldapwhoami WORK. It's just the syncrepl process that
isn't quite getting the auth right.
This is the provider's pertinent configs:
slapd.conf:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
This is the consumer's pertinent configs (WORKS ON one, not on the other)
slapd.conf:
syncrepl rid=10
provider=ldap://xxx.XXX.com
starttls=yes
type=refreshOnly
interval=00:00:01:00
searchbase=dc=XXX,dc=com
schemachecking=off
bindmethod=sasl
saslmech=GSSAPI
krb5.conf [same as provider and kerb server]:
[libdefaults]
default_realm = BOUNCE.AAA.COM
encrypt = true
allow_weak_crypto = false
clockskew = 600
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 8h
forwardable = no
proxiable = no
[realms]
BOUNCE.AAA.COM = {
kdc = XXX.com
kdc = YYY.com
kdc = ZZZ.eu
admin_server = XXX.com
}
[domain_realm]
.com = BOUNCE.AAA.COM
.eu = BOUNCE.AAA.COM
All help is greatly appreciated!
Re: ldap_sasl_interactive_bind_s failed (-2) using openldap v2.3.43 when trying to replicate via syncrepl.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My apologies. Problem solved.
I straced the slapd process and noticed that there were all sorts of SELINUX
policies preventing the process from reading /tmp. I've enabled /tmp access
and all works now. Thanks!
Kris.
PGP Key: 4CC63A18
PGP Server: pool.sks-keyservers.net
On 2010-03-31, at 6:20 PM, Kristian Kostecky wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi guys,
I have a configuration that consists of 3 ldap servers. One is the provider
and there are 2 consumers. I am using syncrepl to do the synchronization.
simple and anonymous binds are totally disabled and Kerberos must be used via
SASL (GSSAPI) and TLS to connect to the LDAP server.
distro: centos 5.4
openldap 2.3.43
cyrus-sasl 2.1.22
Other things:
- - clocks are all in sync
- - hostnames all have forward and reverse mappings and all dns servers in
/etc/resolv.conf respond with proper entries on the consumer and both
providers.
Here's the catch, the two providers are configured the same (except for
hostnames/ips) and the first one works perfect. What is really frustrating
is the lack of logging that is available to tell me what the problem is.
I've tried loglevel -1 and it gave me even less info in regards to the SASL
authentication than leaving it off.
The affected consumer is giving me:
Mar 31 22:41:00 ZZZ slapd[2442]: slapd starting
Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrep1: rid 010
ldap_sasl_interactive_bind_s failed (-2)
Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrepl: rid 010 quitting
On the Provider:
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 ACCEPT from
IP=10.130.1.230:60288 (IP=0.0.0.0:389)
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 STARTTLS
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 RESULT oid= err=0 text=
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 TLS established tls_ssf=256
ssf=256
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=1 UNBIND
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 closed
This is what's REALLY weird - from the affected/broken box, ZZZ, after I
kinit, I can do an LDAP search or ldapwhoami, no problems! So, kerberos and
GSSAPI via SASL is working fine. ie:
ldapsearch -H ldaps://XXX/ -Y GSSAPI - will dump the entries.
or
ldapwhoami -H ldaps://XXX/ -Y GSSAPI - shows me that proper creds
If I destroy the credentials, it doesn't work as would be expected.
ON the working consumer, the behaviour is that I can ldapsearch and
ldapwhoami properly after I kinit and when I start ldap it will authenticate
properly with the provider via SASL GSSAPI and replicates the DB. If I
kdestroy the credentials and start it, I get the same error that I'm
struggling with on the box that doesn't work -ldap_sasl_interactive_bind_s
failed (-2) This behaviour leads me to believe that for some reason the ldap
server on the box that doesn't work is having problems transmitting the
kerberos credentials to the provider, whereas the ldapsearch and ldapwhoami
binaries are not having problems.
There are some suspicious differences between the consumer that works and the
broken one. The provider and consumer that works both have TLDs that match -
'.com' and the consumer whose synrepl process won't authenticate is part of
the .eu TLD. However, as you can see below in the krb5.conf files, the .com
and .eu TLDS are always mapped to the same authentication realm. PLUS,
again, ldapsearch and ldapwhoami WORK. It's just the syncrepl process that
isn't quite getting the auth right.
This is the provider's pertinent configs:
slapd.conf:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
This is the consumer's pertinent configs (WORKS ON one, not on the other)
slapd.conf:
syncrepl rid=10
provider=ldap://xxx.XXX.com
starttls=yes
type=refreshOnly
interval=00:00:01:00
searchbase=dc=XXX,dc=com
schemachecking=off
bindmethod=sasl
saslmech=GSSAPI
krb5.conf [same as provider and kerb server]:
[libdefaults]
default_realm = BOUNCE.AAA.COM
encrypt = true
allow_weak_crypto = false
clockskew = 600
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 8h
forwardable = no
proxiable = no
[realms]
BOUNCE.AAA.COM = {
kdc = XXX.com
kdc = YYY.com
kdc = ZZZ.eu
admin_server = XXX.com
}
[domain_realm]
.com = BOUNCE.AAA.COM
.eu = BOUNCE.AAA.COM
All help is greatly appreciated! This has been going on for days and I've
already yanked out most of my hair. Thank you.
Kris.
PGP Key: 4CC63A18
PGP Server: pool.sks-keyservers.net
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAkuzyroACgkQ2C/J5/UUQWEuUACdH/BhiZgTXFWbNMXS7Q99k8Rg
VY8An3YWKcpnkxVYvZMlelkT0TIpYuAP
=O9KI
-END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Re: remote connections cannot write to LDAP
Ray Carrender mrsmile...@gmail.com writes: Not sure what's going on here, but when I try making a non TLS connection to the LDAP Repository and it's local (say using ldapmodify) I can write to it, but when trying to connect to remotely (on the internal network) it doesn't throw an error but it ignores the write command. Am I missing something here? Maybe it's because I'm using JNDI instead of the written ldapmodify. Also, remotely I can read information, just not write it. Did you configure a security strength factor? -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
handshake failure / SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr
Hi, this drives my crazy for about two days: I do have two virtual Red Hat El 5.4 servers in a test environment. One should be an openldap master, the second should be a openldap slave. openssl-0.9.8e-12.el5_4.1, openldap-2.3.43-3.el5 (RH EL original rpms) I followed some instructions to set up TLS: Set up a CA, generate/sign certificates and keys, install tham on the servers and configure openldap, restart. My problem is: tls works on the master (which also is my CA for the test), but not on the slave. I've openssl verifyed and openssl x509 -texted the certs - everything seams o.k. I've checked ip addresses, name resolving, locations, pathes, permissions, fileversions - anything I can think of. I've regenerated the key and cert for the slave following an other documentation (at least with the same steps), but alway do get the same error: from the ldap server debug: TLS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client hello B TLS trace: SSL_accept:error in SSLv3 read client hello B TLS: can't accept. TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:975 connection_read(13): TLS accept failure error=-1 id=0, closing from the ldap client debug: TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in SSLv2/v3 read server hello A TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure May be I missed a step or still skiped something ... A thousand kowtows for any helping hint...!! Best regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt
Re: Partial replication
On Wed, Mar 31, 2010 at 08:43:19AM +0200, Zdenek Styblik wrote: How about to refuse rights to the syncrepl user? Actually, you could apply this to the whole tree. Just allow read to DNs you want to replicate. So, let's say you use cn=mirrorA,dc=domain,dc=tld for replication, then allow this cn=mirrorA to read only o=support,dc=example,dc=com and o=location_A,dc=example,dc=com, but nowhere else. I have used that technique for a fairly complex design with a central office and many small satellites. It works OK *provided* you never change the list of entries that can be seen by the replicas. The syncrepl system has no way to evaluate the effect of an ACL change (and probably no way to know that one has happenned). In this case it may be better to set up multiple replication agreements to cover the multiple subtrees required at the slave server. That would also make it possible to chain or refer queries for the rest of the DIT back to the master. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Partial replication
On 04/01/10 21:43, Andrew Findlay wrote: On Wed, Mar 31, 2010 at 08:43:19AM +0200, Zdenek Styblik wrote: How about to refuse rights to the syncrepl user? Actually, you could apply this to the whole tree. Just allow read to DNs you want to replicate. So, let's say you use cn=mirrorA,dc=domain,dc=tld for replication, then allow this cn=mirrorA to read only o=support,dc=example,dc=com and o=location_A,dc=example,dc=com, but nowhere else. I have used that technique for a fairly complex design with a central office and many small satellites. It works OK *provided* you never change the list of entries that can be seen by the replicas. The syncrepl system has no way to evaluate the effect of an ACL change (and probably no way to know that one has happenned). Could you please elaborate more on this one? Because I'd say if you refuse access later to some DN then it must be like DN has been deleted. Same goes for adding. I mean, syncrepl won't see data. And it checks, well it should check, for changes in some regular intervals, right? I have no need for nor experience with this, yet it's somewhat interesting. ACLs of anykind in OpenLDAP are kinda ... PITA, no offense to anybody!!! :) It just needs a lot of work to maintain and stuff (please please, no bashing). Thanks, Zdenek In this case it may be better to set up multiple replication agreements to cover the multiple subtrees required at the slave server. That would also make it possible to chain or refer queries for the rest of the DIT back to the master. Andrew
Re: Partial replication
Andrew Findlay wrote: On Wed, Mar 31, 2010 at 08:43:19AM +0200, Zdenek Styblik wrote: How about to refuse rights to the syncrepl user? Actually, you could apply this to the whole tree. Just allow read to DNs you want to replicate. So, let's say you use cn=mirrorA,dc=domain,dc=tld for replication, then allow this cn=mirrorA to read only o=support,dc=example,dc=com and o=location_A,dc=example,dc=com, but nowhere else. I have used that technique for a fairly complex design with a central office and many small satellites. It works OK *provided* you never change the list of entries that can be seen by the replicas. The syncrepl system has no way to evaluate the effect of an ACL change (and probably no way to know that one has happenned). In this case it may be better to set up multiple replication agreements to cover the multiple subtrees required at the slave server. That would also make it possible to chain or refer queries for the rest of the DIT back to the master. Multiple agreements with the same provider won't work, since there will only be one contextCSN sent from the master. After the first consumer runs, the second one will assume it is up to date. The correct solution here is to use a extended filter with dnSubtreeMatch on each desired branch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
