OpenLDAP 2.3.4 TLS negotiation failure
by Tian Zhiying
Hi
On the LDAP Server , I run following command is ok:
#ldapsearch -x -H ldap://ldap.server.com -ZZ
#ldapsearch -x -H ldap://ldap.server.com
But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com", is ok;
Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the following error:
[root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ
ldap_start_tls: Connect error (-11)
On LDAP Server log file, I get the following error messages:
Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from IP=192.168.9.9:45648 (IP=0.0.0.0:389)
Oct 23 16:41:25 auth slapd[4213]: conn=206 op=0 STARTTLS
Oct 23 16:41:25 auth slapd[4213]: conn=206 op=0 RESULT oid= err=0 text=
Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure)
My client ldap configuration:
/etc/openldap/ldap.conf file:
URI ldap://ldap.server.com/
BASE dc=server,dc=com
TLS_CACERT /etc/openldap/cacerts/ca.crt
SSL ON
TLS_REQCERT demand
/etc/ldap.conf file:
BASE dc=server,dc=com
URI ldap://ldap.server.com
SSL ON
TLS_CACERT /etc/openldap/cacert/ca.crt
TLS_REQCERT demand
Any suggestion what cause TLS negotiation failure?
Thanks!
Tian Zhiying
9 years, 5 months
Pass-through authentication to Active Directory when using saslbind
by Jesus Jr M Salvo
Hi All,
First off, I am a beginner with OpenLDAP, so please bear with me as I try
to explain what I am trying to achieve.
1) There are 2 Active Directory servers that I need to connect to. Both of
these are NOT under my control. We shall call them AD1 and AD2 here.
2) I can connect to AD1 via testsaslauthd using both simple bind and
saslbind using DIGEST-MD5.
2a) For simple bind, I know of an adminstrative read-only account that I
use to perform the initial LDAP bind request in order to allow an LDAP
searchRequest to authenticate any user with AD1. Below is a sample
/etc/saslauthd.conf ( ldap_bind_dn and ldap_bind_pw altered slightly to
protect the identity )
###################################################################
#/etc/saslauthd.conf
ldap_servers: ldap://172.21.128.49:3268
ldap_default_domain: ad1.priv
ldap_search_base: DC=ad1,DC=priv
ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv
ldap_bind_pw: readonly
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%u
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768
#########################################################################
$ testsaslauthd -u salvojo -p mypassword
0: OK "Success."
... and what was captured by tshark ( I included port 53 for DNS queries as
it was essential for finding out why digest-uri was only IP addresses
instead of the hostname later on ):
$ sudo tshark -i any port 3268 or port 53 or port 389
<...time elapsed .. snipped..>
81336.300597 172.21.17.193 -> 172.21.128.49 TCP 76 44477 > msft-gc [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50014473 TSecr=0 WS=128
81336.301498 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44477 [SYN,
ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1
81336.301626 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK]
Seq=1 Ack=1 Win=14720 Len=0 TSval=50014474 TSecr=0
81336.301840 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1)
"CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple
81336.304464 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success
81336.304559 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK]
Seq=74 Ack=23 Win=14720 Len=0 TSval=50014474 TSecr=5446546
81336.304930 172.21.17.193 -> 172.21.128.49 LDAP 139 searchRequest(2)
"DC=ad1,DC=priv" wholeSubtree
81336.305702 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2)
"CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" |
searchResDone(2) success
81336.305972 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(3)
"CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" simple
81336.308982 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(3) success
81336.349661 172.21.17.193 -> 172.21.128.49 TCP 68 44477 > msft-gc [ACK]
Seq=231 Ack=152 Win=14720 Len=0 TSval=50014486 TSecr=5446547
2b) For saslbind using DIGEST-MD5, I have no need for the administrative
read-only account, as shown below by my /etc/saslauthd.conf: ( saslauthd
was restarted in each case when saslauthd.conf was changed )
###################################################################
#/etc/saslauthd.conf
ldap_servers: ldap://172.21.128.49:3268
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5
ldap_start_tls: no
ldap_version: 3
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768
#########################################################################
$ testsaslauthd -u salvojo -p mypassword
0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389
<...time elapsed .. snipped..>
7.488292 172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128
7.489163 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK]
Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1
7.489258 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK]
Seq=1 Ack=1 Win=14720 Len=0 TSval=50082985 TSecr=0
7.489757 172.21.17.193 -> 172.21.10.24 DNS 88 Standard query PTR
49.128.21.172.in-addr.arpa
7.490577 172.21.10.24 -> 172.21.17.193 DNS 120 Standard query response
PTR aassydc01.ad1.priv
7.492610 172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>"
sasl
7.493828 172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1)
saslBindInProgress
7.493928 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK]
Seq=27 Ack=259 Win=15744 Len=0 TSval=50082986 TSecr=5449287
7.494828 172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>"
sasl
7.498503 172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success
7.536572 172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK]
Seq=401 Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
All good so far with simple bind and saslauthd to AD1.
3) I can only connect to AD2, the second active directory server, via
testsaslauthd using only sasl bind.
That is because I do not know of an adminstrative read-only account in AD2
that I can use to perform the initial LDAP bindRequest in order to allow an
LDAP searchRequest. Here is the /etc/saslauthd.conf for saslbind to AD2:
###################################################################
#/etc/saslauthd.conf
# Your AD server adress
# NOTE: This will only work IFF there is also a reverse DNS entry for this
A record
# Otherwise, the digest-uri in the LDAP SASL bind request will only contain
the IP address instead of the hostname
# which will result in "The digest-uri does not match any LDAP SPN's
registered for this server"
ldap_servers: ldap://ad2idcdc11.au.ad2.corp:3268
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_start_tls: no
ldap_version: 3
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768
#EOF
#########################################################################
$ testsaslauthd -u anotheruser -p otherpassword
0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389
<...time elapsed .. snipped..>
321.883648 172.21.17.193 -> 10.3.90.55 TCP 76 49226 > msft-gc [SYN] Seq=0
Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50161583 TSecr=0 WS=128
321.884343 10.3.90.55 -> 172.21.17.193 TCP 80 msft-gc > 49226 [SYN, ACK]
Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1
321.884541 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK] Seq=1
Ack=1 Win=14720 Len=0 TSval=50161583 TSecr=0
321.886323 172.21.17.193 -> 10.3.90.55 LDAP 94 bindRequest(1) "<ROOT>"
sasl
321.887247 10.3.90.55 -> 172.21.17.193 LDAP 329 bindResponse(1)
saslBindInProgress
321.887336 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK]
Seq=27 Ack=262 Win=15744 Len=0 TSval=50161584 TSecr=65953794
321.888296 172.21.17.193 -> 10.3.90.55 LDAP 447 bindRequest(2) "<ROOT>"
sasl
321.892567 10.3.90.55 -> 172.21.17.193 LDAP 132 bindResponse(2) success
321.933533 172.21.17.193 -> 10.3.90.55 TCP 68 49226 > msft-gc [ACK]
Seq=406 Ack=326 Win=15744 Len=0 TSval=50161596 TSecr=65953794
4) I am using SASL because I currently have Subversion 1.8 configured to
use SASL to authenticate users to AD1, but currently using simple bind. I
will be changing this later on so that saslauthd will use sasl bind to AD1.
$ cat /etc/sasl2/svn.conf
pwcheck_method: saslauthd
mech_list: PLAIN
-----------------------------------------------------
Now here is what I am trying to achieve with OpenLDAP:
I am using slapd.conf.
I am also using the meta backend, as my instance of OpenLDAP will not
really have its own LDAP database as I intended to use OpenLDAP for
pass-through authentication.
5) I am able to use OpenLDAP as a proxy to AD1 for pass-through
authentication via the meta backend, but only if OpenLDAP is configured to
use simplebind to AD1. That is: testsaslauthd ( simple bind ) -> OpenLDAP (
simple bind ) -> AD1.
Here is my /etc/ldap/slapd.conf:
#########################################################################
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel stats
modulepath /usr/lib/ldap
moduleload back_meta.so
moduleload back_ldap.so
sizelimit 500
tool-threads 1
backend meta
database meta
access to *
by * read
suffix "dc=ad1,dc=priv"
uri ldap://172.21.128.49:3268/dc=ad1,dc=priv
chase-referrals no
lastmod off
protocol-version 3
#########################################################################
.. and here is my /etc/saslauthd.conf for this specific test:
( The only difference between this and [2a] is the ldap_servers entry,
which now points to OpenLDAP, and the ldap_filter, which now has an OR
condition )
###################################################################
#/etc/saslauthd.conf
#
# Your AD server adress
ldap_servers: ldap://127.0.0.1:389
ldap_default_domain: ad1.priv
ldap_search_base: DC=ad1,DC=priv
ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv
ldap_bind_pw: readonly
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: (|(uid=%U)(sAMAccountName=%U))
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768
#EOF
#########################################################################
$ testsaslauthd -u salvojo -p mypassword
0: OK "Success."
$ sudo tshark -i any port 3268 or port 53 or port 389
<...time elapsed .. snipped..>
1310.330189 127.0.0.1 -> 127.0.0.1 TCP 76 50279 > ldap [SYN] Seq=0
Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128
1310.330234 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50279 [SYN, ACK]
Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=50408695
TSecr=50408695 WS=128
1310.330262 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=1
Ack=1 Win=32896 Len=0 TSval=50408695 TSecr=50408695
1310.330612 127.0.0.1 -> 127.0.0.1 LDAP 141 bindRequest(1)
"CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv" simple
1310.330640 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50279 [ACK] Seq=1
Ack=74 Win=32768 Len=0 TSval=50408695 TSecr=50408695
1310.331106 172.21.17.193 -> 172.21.128.49 TCP 76 44485 > msft-gc [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408695 TSecr=0 WS=128
1310.332041 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44485 [SYN,
ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1
1310.332129 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK]
Seq=1 Ack=1 Win=14720 Len=0 TSval=50408695 TSecr=0
1310.332239 172.21.17.193 -> 172.21.128.49 LDAP 141 bindRequest(1)
"cn=administrativero,ou=Service_Accounts,dc=ad1,dc=priv" simple
1310.335445 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success
1310.335575 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK]
Seq=74 Ack=23 Win=14720 Len=0 TSval=50408696 TSecr=5462316
1310.336554 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(1) success
1310.336634 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=74
Ack=15 Win=32896 Len=0 TSval=50408697 TSecr=50408697
1310.336863 127.0.0.1 -> 127.0.0.1 LDAP 157 searchRequest(2)
"DC=ad1,DC=priv" wholeSubtree
1310.337809 172.21.17.193 -> 172.21.128.49 LDAP 157 searchRequest(2)
"dc=ad1,dc=priv" wholeSubtree
1310.339277 172.21.128.49 -> 172.21.17.193 LDAP 175 searchResEntry(2)
"CN=John Salvo,OU=Users,OU=_Windows7 Pilot Group,DC=ad1,DC=priv" |
searchResDone(2) success
1310.339581 127.0.0.1 -> 127.0.0.1 LDAP 141 searchResEntry(2)
"cn=John Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv"
1310.339871 127.0.0.1 -> 127.0.0.1 LDAP 82 searchResDone(2) success
1310.339966 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=163
Ack=102 Win=32896 Len=0 TSval=50408697 TSecr=50408697
1310.340053 127.0.0.1 -> 127.0.0.1 LDAP 154 bindRequest(3) "cn=John
Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple
1310.340698 172.21.17.193 -> 172.21.128.49 TCP 76 44486 > msft-gc [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50408698 TSecr=0 WS=128
1310.341883 172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44486 [SYN,
ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1
1310.341977 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK]
Seq=1 Ack=1 Win=14720 Len=0 TSval=50408698 TSecr=0
1310.342157 172.21.17.193 -> 172.21.128.49 LDAP 154 bindRequest(1) "cn=John
Salvo,ou=Users,ou=_Windows7 Pilot Group,dc=ad1,dc=priv" simple
1310.345643 172.21.128.49 -> 172.21.17.193 LDAP 90 bindResponse(1) success
1310.345733 172.21.17.193 -> 172.21.128.49 TCP 68 44486 > msft-gc [ACK]
Seq=87 Ack=23 Win=14720 Len=0 TSval=50408699 TSecr=5462316
1310.346198 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(3) success
1310.377558 172.21.17.193 -> 172.21.128.49 TCP 68 44485 > msft-gc [ACK]
Seq=163 Ack=130 Win=14720 Len=0 TSval=50408707 TSecr=5462316
1310.384549 127.0.0.1 -> 127.0.0.1 TCP 68 50279 > ldap [ACK] Seq=249
Ack=116 Win=32896 Len=0 TSval=50408709 TSecr=50408699
You can see from the above that:
* The initial administrative simple bind to OpenLDAP was delegated by
OpenLDAP to AD1.
* The searchRequest to OpenLDAp was delegated by OpenLDAP to AD1.
* The second bindRequest ( that is authenticating the user that I specified
with testsaslauthd ) to OpenLDAP was delegated by OpenLDAP to AD1.
That is, on all 3 cases above, OpenLDAP only returned success back to
testsaslauthd only if AD1 only returned success.
So far so good.
6) I am unable to use ... or rather confused on how to use .. OpenLDAP as a
proxy to AD1 so that OpenLDAP will use sasl bind to AD1.
This is where I am stuck.
Here is my /etc/saslauthd.conf for this test: The only difference between
this and saslauthd.conf in [2b] is the ldap_servers entry, which is now
pointing to OpenLDAP.
###################################################################
#/etc/saslauthd.conf
#
# Your AD server adress
ldap_servers: ldap://127.0.0.1:389
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5
ldap_start_tls: no
ldap_version: 3
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768
#EOF
#########################################################################
Here is my /etc/ldap/slapd.conf for this test: ( The only difference
between this file and the slapd.conf file in [5] is the addition of the
idassert-bind line )
#########################################################################
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel stats
modulepath /usr/lib/ldap
moduleload back_meta.so
moduleload back_ldap.so
sizelimit 500
tool-threads 1
backend meta
database meta
access to *
by * read
suffix "dc=ad1,dc=priv"
uri ldap://172.21.128.49:3268/dc=ad1,dc=priv
chase-referrals no
lastmod off
protocol-version 3
idassert-bind bindmethod=sasl saslmech=DIGEST-MD5 mode=none
#########################################################################
$ testsaslauthd -u salvojo -p mypassword
0: NO "authentication failed"
$ sudo tshark -i any port 3268 or port 53 or port 389
<...time elapsed .. snipped..>
401.111261 127.0.0.1 -> 127.0.0.1 TCP 76 50299 > ldap [SYN] Seq=0
Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330 TSecr=0 WS=128
401.111304 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50299 [SYN, ACK]
Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=51388330
TSecr=51388330 WS=128
401.111332 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=1
Ack=1 Win=32896 Len=0 TSval=51388330 TSecr=51388330
401.113332 127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl
401.113419 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50299 [ACK] Seq=1
Ack=27 Win=32768 Len=0 TSval=51388330 TSecr=51388330
401.113806 127.0.0.1 -> 127.0.0.1 LDAP 304 bindResponse(1)
saslBindInProgress (SASL(0): successful result: )
401.114023 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=27
Ack=237 Win=32768 Len=0 TSval=51388331 TSecr=51388330
401.114362 127.0.0.1 -> 127.0.0.1 LDAP 393 bindRequest(2) "<ROOT>"
sasl
401.114671 127.0.0.1 -> 127.0.0.1 LDAP 130 bindResponse(2)
invalidCredentials (SASL(-13): user not found: no secret in database)
401.153939 127.0.0.1 -> 127.0.0.1 TCP 68 50299 > ldap [ACK] Seq=352
Ack=299 Win=32768 Len=0 TSval=51388341 TSecr=51388331
As you can see from the above tshark, OpenLDAP did not even try to
communicate at all to AD1 !
What should I have in slapd.conf ?
Maybe the problem is that, I am using testsaslauthd, which uses saslauthd
to connect to OpenLDAP, but also need OpenLDAP to use saslauthd to AD1 (
e.g. It is using the same saslauthd daemon ) ?
I also read about at ( Section 14.5 ):
http://www.openldap.org/doc/admin24/security.html
... about setting the userPassword attribute to something of the form:
userPassword: {SASL}user@realm
... but:
*) I am using a meta backend, and thus I have no internal users, so I
cannot set the userPassword attribute .... or is this saying that I need a
"copy" of the DN name of the users from AD1 to my local OpenLDAP ?
It also says:
"Since OpenLDAP 2.0 slapd has had the ability to delegate password
verification to a separate **PROCESS** ( emphasis mine ). This uses the
sasl_checkpass(3) function so it can use any back-end server that Cyrus
SASL supports for checking passwords."
.. but:
*) How was OpenLDAP able to delegate password verification in the
simple-bind proxy as I have demonstrated above WITHOUT going through a
separate proccess but going straight through a TCP/IP connection ?
*) Is the statement saying that OpenLDAP will use saslauthd to connect to a
remote LDAP/AD ? If so, since I am using testsaslauthd and I am already
using saslauthd to connect to OpenLDAP, and saslauthd.conf is configured to
point to the local OpenLDAP, does this mean I need another instance of
saslauthd with its own unix socket and its own saslauthd.conf ? If so,
what's the point of having the uri in slapd.conf when the separate instance
of saslauthd.conf will have its own entry of the remote ldap / AD1 anyway ?
Anyway, as you can see .. I am confused on how to do item [6] above.
All I really need to happen is ( from a tcp capture / wireshark perspective
), something like ( similar to the simple bind PTA ):
127.0.0.1 -> 127.0.0.1 TCP 76 44478 > msft-gc [SYN] Seq=0 Win=14600 Len=0
MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128
127.0.0.1 -> 127.0.0.1 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0 Ack=1
Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1
127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1 Win=14720
Len=0 TSval=50082985 TSecr=0
127.0.0.1 -> 127.0.0.1 LDAP 94 bindRequest(1) "<ROOT>" sasl
172.21.17.193 -> 172.21.128.49 TCP 76 44478 > msft-gc [SYN] Seq=0
Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=50082984 TSecr=0 WS=128
172.21.128.49 -> 172.21.17.193 TCP 80 msft-gc > 44478 [SYN, ACK] Seq=0
Ack=1 Win=64512 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1
172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=1 Ack=1
Win=14720 Len=0 TSval=50082985 TSecr=0
172.21.17.193 -> 172.21.128.49 LDAP 94 bindRequest(1) "<ROOT>" sasl
172.21.128.49 -> 172.21.17.193 LDAP 326 bindResponse(1) saslBindInProgress
172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259
Win=15744 Len=0 TSval=50082986 TSecr=5449287
127.0.0.1 -> 127.0.0.1 LDAP 326 bindResponse(1) saslBindInProgress
127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=27 Ack=259
Win=15744 Len=0 TSval=50082986 TSecr=5449287
127.0.0.1 -> 127.0.0.1 LDAP 442 bindRequest(2) "<ROOT>" sasl
172.21.17.193 -> 172.21.128.49 LDAP 442 bindRequest(2) "<ROOT>" sasl
172.21.128.49 -> 172.21.17.193 LDAP 132 bindResponse(2) success
172.21.17.193 -> 172.21.128.49 TCP 68 44478 > msft-gc [ACK] Seq=401
Ack=323 Win=15744 Len=0 TSval=50082997 TSecr=5449287
127.0.0.1 -> 127.0.0.1 LDAP 132 bindResponse(2) success
127.0.0.1 -> 127.0.0.1 TCP 68 44478 > msft-gc [ACK] Seq=401 Ack=323
Win=15744 Len=0 TSval=50082997 TSecr=5449287
7) If I can find out how to do item [6] above with help from this list,
then I will try to do the same for AD2.
8) The end goal therefore is to use OpenLDAP as a dumb proxy that will
authenticate users to either AD1 or AD2.
Any help / hints appreciated,
Jesus Salvo
9 years, 5 months
Subject Alternative Name in TLS - does this work?
by lejeczek
dear all
I'm trying to set a seeminglysimple setup
having a box with openldap I want it to use TLS on both
internal and external hostnames/IPs
openldap was set up earlier and was/is working
I generate TLS certificate with SAN
everything seems working fine
but
when I ldapsearch on external fqdn/IP (which in the
certificate is the subjectAltName) search fails
whereas it succeeds on internal fqdn(which is the hostname/
CN in the certificate)
error is: additional info: TLS error -8157:Certificate
extension not found.
is such a scenario even possible? having very same DN being
served on more than one name via TLS?
best wishes
9 years, 5 months
prevent mail loops using constraint overlay
by Ole
Hi,
some user always try to build mail loops, creating a
mailForwadingAddress attribute with the value of one of their mail
attribute.
according to the manpage SLAPO-CONSTRAINT(5):
[...]
constraint_attribute cn,sn,givenName set
"(this/givenName + [ ] + this/sn) & this/cn"
[...]
it requires the values of the
attribute cn to be constructed by pairing values of the
attributes sn and givenName, separated by a space,
[...]
I understand the syntax of the constraint overlay in that way, that the
expression after the "set" command has to be true.
But if I try to use
constraint_attribute mail,mailForwardingAddress set
"this/mail | this/mailForwardingAddress"
it takes no effect. It should require that there can be a attribute mail
with value X OR a value mailForwardingAddress with value X.
Is it not valid to use the | operator?
Regards
Ole
9 years, 5 months
Updated scheme
by Artur Nike
Hi all ,
I have a question.
How as the most updated schema file (dynamic) and all objects in the ldif
file in. in OpenLDAP 2.4.31.
Let's say I have a scheme with its own defined attributes and classes
and after a while you need to add an attribute and for example, change the
class.
How to upload an updated scheme under the same name and do not change the
names of the updated attributes and classes.
Now Loading a revised scheme under a new name and change the object
definitions in the ldif.
Can anyone have any suggestions or experience with this problem.
For all thank you in advance.
Mariusz
9 years, 5 months
ACL with val.regex expression
by Mark Dieterich
Hi all,
I'm banging my head against a wall trying to get one particular ACL
setup. We want our users, with the exception of those that have a
restricted shell, to be able to change their own shell values. A
typical user looks like:
dn: uid=user,ou=people,dc=cs,dc=brown,dc=edu
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: krb5Principal
objectClass: sambaSamAccount
objectClass: ownCloudUser
objectClass: mailUser
...
loginShell: /bin/bash
We'd ideally like to have an ACL in place that looks like:
access to dn.subtree="ou=people,dc=cs,dc=brown,dc=edu" attrs=loginShell
val.regex="/bin/[^f][^s][^h]"
by ssf=128 self write
by * read
The idea being that a user with a loginShell value of /bin/fsh would NOT
be allowed to change their shell value. However, with this rule in
place, no user is able to change their shell value. Even if I change
the rule to be:
access to dn.subtree="ou=people,dc=cs,dc=brown,dc=edu" attrs=loginShell
val.exact="/bin/bash"
by ssf=128 self write
by * read
users with loginShell of /bin/bash still can't change their own values.
If I drop the val.<type>="<whatever>" restriction, users can change
their shell values just fine. This the first time I've ever used and
ACL with a val.<type>= restriction, but I've scoured the internet and I
can't for the life of me figure out what I'm doing wrong. I'm happy to
have someone here give me a dope slap... I'm just tired of the headaches ;)
Thanks!
Mark
9 years, 5 months
Need to Create Default Printer Entries
by Michael C. Ibarra
Greetings;
I’ve recently built a new LDAP infrastructure, migrated from NIS. Under NIS, I had a map, “printers”, which I used to query with “ypcat printers.byname|grep username”.
I need to setup default printers for several applications, and making them centrally available, and configurable, is a must for me.
The issue I am facing is that my users, now listed under people, have no place to add a default printer; although there is an “allowed attribute” for “host”, which right now for me goes unused.
What I would like to do is to create a new database in my DIT, call it say defaultPrinters, which contains left side username, right side printer; i.e.:
smitha hp001
joner hp002
carsont hp001
Additionally, I would like to be able to add an allowable attribute under People, named defaultPrinters, which points to the database that I am trying to create.
Thanks in advance.
-mi
9 years, 5 months
Does MDB backend shrinks on disk files after delete operation?
by Igor Zinovik
Hello.
I would like to understand one thing about mdb backend:
Current size of /var/lib/ldap is 15 megabytes (~ 10000 entries).
After i added to my database 1839 entries on disk directory size
becomes 93 megabytes. But when i delete all 1839 entires mdb does
not free disk space, my /var/lib/ldap is still 93 megabytes in size.
It does not remove data and just marks it as 'free' meaning that it is
reusable for new write operations?
I use mdb from openldap 2.4.33
9 years, 5 months
Berkeley DB backend - exact version check
by Jan Synacek
Hello,
slapd checks the exact version of BDB at runtime and fails if it doesn't equal
to the version that it's been linked against. Is there a reason for such precise
check? Shouldn't the major and minor version numbers be enough?
The code seems to have been there for a while, so I'm sorry if such question has
been asked before. I couldn't find any answers.
Thank you,
--
Jan Synacek
Software Engineer, Red Hat
9 years, 5 months
bind-dyndb-ldap
by Brendan Kearney
i am trying to setup BIND to use LDAP as the zone data repository, using
bind-dyndb-ldap and continue to run into issues. i am not sure what
this error message means, but it seems to be part of the problem.
i see that the bind attempt succeeds and that a search is attempted.
but, when the search is attempted, a critical piece of the puzzle is
missing and an extension is not recognized. indexing will be done once
i get the rest of this working...
2013-10-15T19:10:16.980653-04:00 test slapd[12675]: conn=1057 fd=11
ACCEPT from IP=127.0.0.1:57849 (IP=0.0.0.0:389)
2013-10-15T19:10:16.980675-04:00 test slapd[12675]: conn=1057 op=0 BIND
dn="cn=Manager,dc=my-domain,dc=com" method=128
2013-10-15T19:10:16.980680-04:00 test slapd[12675]: conn=1057 op=0 BIND
dn="cn=Manager,dc=my-domain,dc=com" mech=SIMPLE ssf=0
2013-10-15T19:10:16.980683-04:00 test slapd[12675]: conn=1057 op=0
RESULT tag=97 err=0 text=
2013-10-15T19:10:16.982325-04:00 test slapd[12675]: conn=1058 fd=17
ACCEPT from IP=127.0.0.1:57850 (IP=0.0.0.0:389)
2013-10-15T19:10:16.983442-04:00 test slapd[12675]: conn=1058 op=0 BIND
dn="cn=Manager,dc=my-domain,dc=com" method=128
2013-10-15T19:10:16.983456-04:00 test slapd[12675]: conn=1058 op=0 BIND
dn="cn=Manager,dc=my-domain,dc=com" mech=SIMPLE ssf=0
2013-10-15T19:10:16.983459-04:00 test slapd[12675]: conn=1058 op=0
RESULT tag=97 err=0 text=
2013-10-15T19:10:16.990216-04:00 test slapd[12675]: conn=1057 op=1
SEARCH RESULT tag=101 err=12 nentries=0 text=critical extension is not
recognized
2013-10-15T19:10:16.990883-04:00 test slapd[12675]: conn=1057 op=1
do_search: get_ctrls failed
2013-10-15T19:10:16.991177-04:00 test slapd[12675]: conn=1058 op=1 SRCH
base="cn=dns,dc=my-domain,dc=com" scope=2 deref=0
filter="(&(idnsZoneActive=TRUE)(|(objectClass=idnsZone)(objectClass=idnsForwardZone)))"
2013-10-15T19:10:16.991468-04:00 test slapd[12675]: conn=1058 op=1 SRCH
attr=idnsName idnsUpdatePolicy idnsAllowQuery idnsAllowTransfer
idnsForwardPolicy idnsForwarders idnsAllowDynUpdate idnsAllowSyncPTR
objectClass
2013-10-15T19:10:16.991740-04:00 test slapd[12675]: <=
bdb_equality_candidates: (idnsZoneActive) not indexed
2013-10-15T19:10:16.992025-04:00 test slapd[12675]: conn=1058 op=1
SEARCH RESULT tag=101 err=0 nentries=1 text=
i know that the schema for dyn-dns is loaded and all the objectClasses
and attributeTypes are available. the problem i run into is an A Record
that should be in the zone data cannot be queried out of the BIND
instance that is talking to LDAP.
[root@test conf.d]# nslookup foo.my-domain.com. localhost
;; Got SERVFAIL reply from 127.0.0.1, trying next server
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server: localhost
Address: 127.0.0.1#53
** server can't find foo.my-domain.com: SERVFAIL
i am using:
bind - 9.9.3
bind-dyndb-ldap - 3.5
openldap 2.4.36
on Fedora 19 (yes, it is the distro packaged version). Can anyone give
me some pointers on how to get this working?
9 years, 5 months
