Is attribute options supported?
by Angel L. Mateo
Hello,
Is attribute options supported in openldap (version 2.4.21)?
In RFC 2251 (LDAPv3) the attributes in search could be specified as
attribute_name;options, so you could indicate options in the return of
the attributes.
Specifically, what I want to do is: I have attributes wich value is a
URN, so I want to get just a special part of the URN, that is:
Traditional search:
Ldap filter: (mail=user(a)mydomain.com)
Atributos: mail, schacPersonalUniqueID
Result:
mail: user(a)mydomain.com
schacPersonalUniqueID:
urn:mace:terena.org:schac:personalUniqueID:es:12345678Q
Search with options:
Ldap filter: (mail=user(a)mydomain.com)
Atributos: mail, schacPersonalUniqueID;x-urn-7
Result:
mail: user(a)mydomain.com
schacPersonalUniqueID: 12345678Q
I have tried this with a standard configuration, but it isn't working:
amateo@joshua:~$ /usr/bin/ldapsearch ... mail=user(a)mydomain.com
schacPersonalUniqueID;x-urn-7
# extended LDIF
#
# LDAPv3
# base <dc=Telematica> with scope subtree
# filter: uid=amateo
# requesting: irisClassifCode
#
# amateo, Usuarios, telematica
dn: uid=user,ou=People,dc=mydomain,dc=com
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
x-urn-1: orden no encontrada
Is it supported? Do I have to configure anything in the slapd server?
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información _o)
y las Comunicaciones Aplicadas (ATICA) / \\
http://www.um.es/atica _(___V
Tfo: 868887590
Fax: 868888337
10 years, 3 months
ldapsearch from server does not work but works from client
by Seau Yeen Su
Hi all,
I have managed to install OpenLdap 2.4 on a RHEL 5.2 workstation. The basic
openldap without TLS/SSL works fine. On the server itself and from the
client I was able to do ldapsearch. However, after I created a server.pem by
going through this : [url=
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch31_:_Ce...
: Ch31 : Centralized Logins Using LDAP and RADIUS - Linux Home
Networking[/url]
ldapsearch on the ldap server itself does not work anymore. The summary of
the configuration is as below:
server.pem is created in /usr/local/etc/openldalp/cacerts and client.pem is
in /etc/openldap/cacerts. client.pem is also moved to clients and ldapsearch
works fine from client workstation. However, in the ldap server itself it
does not. THe output of /etc/ldap.conf looks like below:
uri ldaps://syna-ldap-02.synamatix.com/
tls_cacertdir /etc/openldap/cacerts
pam_password md5
My /usr/local/etc/openldap/slapd.conf TLS portion looks like below:
TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3:RSA
TLSCACertificateFile /usr/local/etc/openldap/cacerts/server.pem
TLSCertificateFile /usr/local/etc/openldap/cacerts/server.pem
TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/server.pem
TLSVerifyClient allow
The error from ldapsearch x -H ldaps://syna-ldap-02.synamatix.com -d127 in
the server itself is as below:
TLS ceritficate verification: depth: 0, err: 18, subject:
/C=MY/ST=KL/L=MV/O=MGRC/OU=IT/CN=
syna-ldap-02.synamatix.com/emailAddress=seauyeen@mgrc.com.my, issuer:
/C=MY/ST=KL/L=MV/O=MGRC/OU=IT/CN=
syna-ldap-02.synamatix.com/emailAddress=seauyeen@mgrc.com.my
TLS certificate verification: Error, self signed certificate
tls_write: want=7, write=7
0000: 15 03 01 00 02 02 30
TLS trace: SSL3 alert write:fata:unknown CA
TLS trace: SSL connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed
certificate).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
On the server end, as I started with debug mode, I get errors below:
TLS trace: SSL3 alert read: fatal: unknown CA
TLS trace: SSL_accept:failed in SSLv3 read client certificate A
TLS: can't accept: erro: 14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca.
connection_read(13): TLS accept failure error=-1 id=1010,closing
.....
Why is that ldapsearch from client workstation works fine but not in the
ldap server itself? It is osoo baffling. It is fine without TLS activated. I
have been working on this for 1 week! The information online does not seem
to cater to this weird incident of mine.
Hope to receive some assistance really soon. If you need files and
attachments, please inform me. Thanks and Happy new year guys!!!!
--
------------------------------
MGRC - Accelerating Your Journey of Discovery
*Su Seau Yeen
Assistant Manager IT Operations
* * *
*Malaysian Genomics Resource Centre Berhad (MGRC)*
T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 |
www.mgrc.com.my
------------------------------
This e-mail is intended only for the use of the individual or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient, is strictly prohibited. If you
receive this e-mail in error, please contact us immediately by return e-mail
and delete the original message(s).
10 years, 3 months
one system won't authenticate
by Christ Schlacta
I've got two systems authenticating against an openldap directory, and
one that refuses.
I'm attempting to debug why this system won't authenticate, but there's
nothing useful in auth.log, and I can't decipher the voluminous output
that -d 255 provides.
Iv'e checkeced all my configs and my passwords repeatedly. can anyone
suggest a next step from here?
PS: the system that won't auth is also the system hosting the ldap
directory. TIA!!
10 years, 3 months
ldap server failover on Kerberos servers?
by Kevin Longfellow
Hi,
Using LDAP as the back end for Kerberos principals and openldap 2.3.43 as the
client on the Kerberos servers, I see it's possible to add some failover with
ldap_servers in /etc/krb5.conf and URI in /etc/openldap/ldap.conf.
For example:
/etc/krb5.conf: ldap_servers = ldaps://hostname1:636 ldaps://hostname2:636
/etc/openldap/ldap.conf: URI ldaps://hostname1:636 ldaps://hostname2:636
In our situation, the ldap servers are behind a BigIP so only a single hostname
can be entered. I'm curious if it makes any sense to add the BigIP hostname
twice? Once the initial connection is made by the Kerberos server to the first
ldap server are there any failure scenarios that the below would make any sense?
/etc/krb5.conf: ldap_servers = ldaps://<bigip hostname>:636 ldaps://<bigip
hostname>:636
/etc/openldap/ldap.conf: URI ldaps://<bigip hostname>:636 ldaps://<bigip
hostname>:636
Hopefully it makes sense what I'm asking and thanks for your time.
Regards,
Kevin
10 years, 3 months
Problem with ACL in 2.4.22
by Nick Milas
Hi,
I have upgraded from 2.3.43 to 2.4.22 on CentOS 5.5.
Everything works fine, except my ACLs don't work on the new version.
Strange results occur.
Has anything changed significantly in v2.4 ACLs in comparison to v2.3 ACLs?
For example, the following piece of code works as expected in v2.3 but
not in v2.4. If some user logs in and is a member of a GroupXAdmins
(where X = 1-6), he can't see the branch at all.
# Allow access to entries of the subtree
#
access to dn.sub="dc=12.11.10.in-addr.arpa,ou=dns1,dc=example,dc=com"
attrs="children,entry"
by group.exact="cn=Group1Admins,ou=Groups,dc=example,dc=com" write
by group.exact="cn=Group2Admins,ou=Groups,dc=example,dc=com" read
by group.exact="cn=Group3Admins,ou=Groups,dc=example,dc=com" read
by group.exact="cn=Group4Admins,ou=Groups,dc=example,dc=com" write
by group.exact="cn=Group5Admins,ou=Groups,dc=example,dc=com" read
by group.exact="cn=Group6Admins,ou=Groups,dc=example,dc=com" read
by dn.exact="uid=dnsauthusr,ou=System,dc=example,dc=gr" read
by * break
# Allow access to all attributes of the subtree
#
access to dn.sub="dc=12.11.10.in-addr.arpa,ou=dns1,dc=example,dc=com"
by group.exact="cn=Group1Admins,ou=Groups,dc=example,dc=com" write
by group.exact="cn=Group2Admins,ou=Groups,dc=example,dc=com" read
by group.exact="cn=Group3Admins,ou=Groups,dc=example,dc=com" read
by group.exact="cn=Group4Admins,ou=Groups,dc=example,dc=com" write
by group.exact="cn=Group5Admins,ou=Groups,dc=example,dc=com" read
by group.exact="cn=Group6Admins,ou=Groups,dc=example,dc=com" read
by dn.exact="uid=dnsauthusr,ou=System,dc=example,dc=com" read
where Groups are of the form:
dn: cn=Group1Admins,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
cn: Group1Admins
member: uid=userx,ou=people,dc=example,dc=com
Please, help.
Nick
10 years, 3 months
Re: Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra
Hi,
El 28/12/10 12:00, openldap-technical-request(a)OpenLDAP.org escribió:
> Hi,
> Am Mon, 27 Dec 2010 15:15:21 +0000
> schrieb Ubay Dorta Guerra <udorta(a)iac.es>:
>
>
>> The simple bind under TLS worked but when i try to use cert-based
>> SASL EXTERNAL authentication i get no success.
>>
>> In the proxy server configuration i add the following directive
>>
>> idassert-bind bindmethod=sasl
>> saslmech=EXTERNAL
>> binddn="CN=proxy-server1.example.com,O=Internet
>>
> the binddn should be empty or just don't configure a binddn.
>
>
Thank you very much.
I have deleted the binddn in proxy configuration:
idassert-bind bindmethod=sasl
saslmech=EXTERNAL
tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
tls_key=/etc/ssl/private/proxy-server1.example.com.key
tls_cacertdir=/etc/ssl/cacerts/
tls_reqcert=demand
mode=self
Now when i make a password change:
ldapmodify -x -H ldaps://proxy-server1.example.com -f pass2_user.ldif -D
'uid=user_w_pass,ou=people,dc=example,dc=com' -W
Enter LDAP Password:
modifying entry "uid=user_w_pass,ou=people,dc=example,dc=com"
I get the following messages in syslog:
ldap-proxy[16709]: conn=1054 fd=8 TLS established tls_ssf=256 ssf=256
ldap-proxy[16709]: conn=1054 op=0 BIND
dn="uid=user_w_pass,ou=people,dc=example,dc=com" method=128
ldap-master[16879]: conn=1022 fd=20 TLS established tls_ssf=256 ssf=256
ldap-master[16879]: conn=1022 op=0 BIND
dn="uid=user_w_pass,ou=people,dc=example,dc=com" method=128
ldap-master[16879]: conn=1022 op=0 BIND
dn="uid=user_w_pass,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0
ldap-master[16879]: conn=1022 op=0 RESULT tag=97 err=0 text=
ldap-proxy[16709]: conn=1054 op=0 BIND
dn="uid=user_w_pass,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0
ldap-proxy[16709]: conn=1054 op=0 RESULT tag=97 err=0 text=
ldap-proxy[16709]: conn=1054 op=1 MOD
dn="uid=user_w_pass,ou=people,dc=example,dc=com"
ldap-proxy[16709]: conn=1054 op=1 MOD attr=userPassword
ldap-master[16879]: conn=1002 op=7 PROXYAUTHZ
dn="uid=user_w_pass,ou=people,dc=example,dc=com"
ldap-master[16879]: conn=1002 op=7 MOD
dn="uid=user_w_pass,ou=people,dc=example,dc=com"
ldap-master[16879]: conn=1002 op=7 MOD attr=userPassword
ldap-master[16879]: conn=1002 op=7 RESULT tag=103 err=0 text=
ldap-proxy[16709]: conn=1054 op=1 RESULT tag=103 err=0 text=
ldap-proxy[16709]: conn=1054 op=2 UNBIND
ldap-proxy[16709]: conn=1054 fd=8 closed
Regards.
---------------------------------------------------------------------------------------------
ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php
WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en
10 years, 3 months
Index Usage
by Paul
Hi all,
When I started at this job I acquired OpenLDAP based authentication
infrastructure, which I've pretty much been able to leave to its own
devices without looking under the hood at what's going on. Recently
I've been noticing that a few minor performance problems I'm having seem
to be linked to LDAP so I've started looking at how it's set up and it's
got some quirks, e.g.
# Indices to maintain
index entryUUID eq
index cn,sn,uid,displayName pres,sub,eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index sambaGroupType eq
index sambaSIDList eq
index sudoUser eq
index uniqueMember,member eq
index objectClass pres,eq
index mail,mailAlternateAddress eq,sub
index accountStatus eq
index mailHost,deliveryMode eq
index Status,HostGroup eq
index default sub
There are only around 600 users in the ldap tree, hardly anything. It
seems a bit excessive to have that many indexes set up for the tree. Is
there any way to identify which indexes are being used and how
frequently? I'm pretty certain some of those entries probably get
checked once in a blue moon.
I'm also seeing odd entries in the ldap logs:
Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates:
(objectClass) index_param failed (18)
Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates:
(objectClass) index_param failed (18)
Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates:
(gidNumber) index_param failed (18)
Which seems bizarre given those entries are in the list of indexes.
I've tried running slapindex and restarting to no avail. Those items
still seem to throw up those alerts, as does the sudoUser entry.
On a separate note I've found the slapcat doesn't produce an LDIF file
that slapadd will use, even keeping to the same version of software
(2.3.37), or importing into newer (2.3.43).
It always errors after the first entry because it seems to be trying to
add a user to an ou that doesn't exist yet, which disturbs me slightly
because the backup infrastructure has been relying on that mechanism for
recovery. To create another ldap slave I ended up having to use Apache
Directory Studio to create the LDIF for import, which slapadd was
perfectly happy to work with. I'm not sure if that may be a known bug
that I'm running up against. I see a few entries in archives relating
to it but not much by way of response other than suggests it should work.
Paul
10 years, 3 months
Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra
Hi,
We have some problems with certificate authentication when the master
server is behind a back-ldap proxy.
We have openldap 2.4.21 on Suse Linux Enterprise Server 10 SP3 and
these are the details of our scenario:
The master server: server1.example.com has the following slapd.conf file:
access to dn.base=""
by * read
access to dn.base="cn=Subschema"
by * read
access to attrs=userPassword,userPKCS12
by self write
by dn.exact="CN=admin_w_cert,O=Internet Widgits Pty
Ltd,ST=Some-State,C=AU" read
by *
auth
access to attrs=shadowLastChange
by self write
by * read
access to *
by * read
#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCertificateFile /etc/ssl/certs/server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key
TLSCACertificatePath /etc/ssl/cacerts/
TLSVerifyClient demand
#
#Log level
#
loglevel 256
# Require authentication
require authc
#######################################################################
# HDB database definitions
#######################################################################
database hdb
suffix "dc=example,dc=com"
checkpoint 1024 5
cachesize 10000
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
# Indices to maintain
index objectClass eq
# Overlay ppolicy
overlay ppolicy
----------------------
Authentication is required, and we give access to the user passwords
for the dn of a certificate.
When we search for passwords using the certificate we get the following:
root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://server1.example.com userPassword
SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
dn: uid=user_w_pass,ou=people,dc=example,dc=com
userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=
-----------------------
The root user (ldap client) has a ~/.ldaprc file with:
TLS_CACERTDIR /etc/ssl/cacerts/
TLS_CERT /etc/ssl/certs/admin_w_cert.pem
TLS_KEY /etc/ssl/private/admin_w_cert.key
TLS_REQCERT demand
SASL_MECH EXTERNAL
In /var/log/messages we get:
ldap-master[22358]: conn=1000 fd=11 ACCEPT from
IP=server1.example.com:40899 (IP=server1.example.com:636)
ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256
ldap-master[22358]: conn=1000 op=0 BIND dn="" method=163
ldap-master[22358]: conn=1000 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-master[22358]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-master[22358]: conn=1000 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword
ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=
ldap-master[22358]: conn=1000 op=2 UNBIND
ldap-master[22358]: conn=1000 fd=11 closed
This is the correct behavior for us. The problem appears when we
introduce a back-ldap proxy between the client and the master.
The proxy server (proxy-server1.example.com) is listening in port
1636 and its slapd.conf file is:
#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCACertificatePath /etc/ssl/cacerts/
TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key
TLSVerifyClient demand
# Log level
loglevel 256
#######################################################################
# Database definitions
#######################################################################
database ldap
rebind-as-user true
suffix "dc=example,dc=com"
uri "ldaps://server1.example.com"
tls ldaps
tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
tls_key=/etc/ssl/private/proxy-server1.example.com.key
tls_cacertdir=/etc/ssl/cacerts/
----------------------
If we search for passwords through the proxy we get:
root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://proxy-server1.example.com:1636 userPassword
SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
Server is unwilling to perform (53)
Additional information: authentication required
In the /var/log/messages the following messages appear:
ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from
IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636)
ldap-proxy[22802]: conn=1001 fd=8 TLS established tls_ssf=256 ssf=256
ldap-proxy[22802]: conn=1001 op=0 BIND dn="" method=163
ldap-proxy[22802]: conn=1001 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[22802]: conn=1001 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-proxy[22802]: conn=1001 op=0 RESULT tag=97 err=0 text=
ldap-proxy[22802]: conn=1001 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-proxy[22802]: conn=1001 op=1 SRCH attr=userPassword
ldap-master[22358]: conn=1008 op=2 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-master[22358]: conn=1008 op=2 SRCH attr=userPassword
ldap-master[22358]: conn=1008 op=2 SEARCH RESULT tag=101 err=53
nentries=0 text=authentication required
ldap-proxy[22802]: conn=1001 op=1 SEARCH RESULT tag=101 err=53
nentries=0 text=authentication required
ldap-proxy[22802]: conn=1001 op=2 UNBIND
ldap-proxy[22802]: conn=1001 fd=8 closed
The /root/.ldaprc file is the same than the previous one.
When we increase the logging level we discover this:
....
ldap-proxy[23008]: conn=1000 op=0 do_bind
ldap-proxy[23008]: >>> dnPrettyNormal: <>
ldap-proxy[23008]: <<< dnPrettyNormal: <>, <>
ldap-proxy[23008]: conn=1000 op=0 BIND dn="" method=163
ldap-proxy[23008]: do_bind: dn () SASL mech EXTERNAL
ldap-proxy[23008]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0
ldap-proxy[23008]: SASL Canonicalize [conn=1000]:
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: slap_sasl_getdn: conn 1000
id=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au [len=61]
ldap-proxy[23008]: ==>slap_sasl2dn: converting SASL name
cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au to a DN
ldap-proxy[23008]: <==slap_sasl2dn: Converted SASL name to <nothing>
ldap-proxy[23008]: SASL Canonicalize [conn=1000]:
slapAuthcDN="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: SASL proxy authorize [conn=1000]:
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: conn=1000 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: SASL Authorize [conn=1000]: proxy authorization
allowed authzDN=""
ldap-proxy[23008]: send_ldap_sasl: err=0 len=-1
ldap-proxy[23008]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-proxy[23008]: do_bind: SASL/EXTERNAL bind:
dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
sasl_ssf=0
ldap-proxy[23008]: send_ldap_response: msgid=1 tag=97 err=0
ldap-proxy[23008]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-proxy[23008]: <== slap_sasl_bind: rc=0
....
ldap-proxy[23008]: conn=1000 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-proxy[23008]: conn=1000 op=1 SRCH attr=userPassword
ldap-proxy[23008]: ==> limits_get: conn=1000 op=1
self="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
this="uid=user_w_pass,ou=people,dc=example,dc=com"
ldap-master[22983]: daemon: activity on 1 descriptor
ldap-master[22983]: daemon: activity on:
ldap-master[22983]:
ldap-master[22983]: slap_listener_activate(7):
ldap-master[22983]: daemon: epoll: listen=7 busy
ldap-master[22983]: >>> slap_listener(ldaps://server1.example.com)
.....
ldap-master[22983]: conn=1000 op=0 do_bind
ldap-master[22983]: >>> dnPrettyNormal: <>
ldap-master[22983]: <<< dnPrettyNormal: <>, <>
ldap-master[22983]: conn=1000 op=0 BIND dn="" method=128
ldap-master[22983]: do_bind: version=3 dn="" method=128
ldap-master[22983]: send_ldap_result: conn=1000 op=0 p=3
ldap-master[22983]: send_ldap_result: err=0 matched="" text=""
ldap-master[22983]: send_ldap_response: msgid=1 tag=97 err=0
ldap-master[22983]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-master[22983]: do_bind: v3 anonymous bind
----------------
Therefore the proxy is binding anonymously in the master, instead of
using the dn of the certificate.
Is there any problem with the SASL EXTERNAL method?
If we use SIMPLE authentication through the proxy, there is no problem:
root # ldapsearch -LLL -x -b
'uid=user_w_pass,ou=people,dc=example,dc=com' -H
ldaps://proxy-server1.example.com:1636 -D
'uid=user_w_pass,ou=people,dc=example,dc=com' -W userPassword
Enter LDAP Password:
dn: uid=user_w_pass,ou=people,dc=example,dc=com
userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=
Thanks in advance.
---------------------------------------------------------------------------------------------
ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php
WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en
10 years, 3 months
Problem starting ldap 2.4
by Nick Milas
Hi,
I am trying to migrate from CentOS 5.5 Openldap 2.3.43-12.el5_5.3 to
2.4.22-1.el5.x86_64 using Buckan RPMs (available at
http://staff.telkomsa.net/packages/rhel5/openldap/x86_64/).
I think I have done all necessary configuration, but when I try to
start, I get a strange error:
# service ldap2.4 start
' for reading (No such file or directory)f FNR=196) fatal: cannot
open file `/etc/openldap2.4/schema/core.schema
chown: cannot access `/var/lib/ldap2.4\r': No such file or directory
Starting slapd (ldap + ldaps): [FAILED]
Note, however that /etc/openldap2.4/schema/core.schema exists:
# ls -la /etc/openldap2.4/schema/core.schema
-rw-r--r-- 1 ldap ldap 19762 Nov 29 10:49
/etc/openldap2.4/schema/core.schema
The core.schema is the first one included in slapd.conf, so there is
probably a problem with all included schema files.
The config file is supposed to be OK:
# slaptest2.4 -f /etc/openldap2.4/slapd.conf
config file testing succeeded
The db data has been successfully input using slapadd, from an ldif
backp. The db is in /var/lib/ldap2.4:
# slapadd2.4 -l /root/ldapbk/ldif.ldap.bk
-#################### 100.00% eta none elapsed 45s
spd 23.7 k/s
Closing DB...
[root@vweb ldap2.4]#
[root@vweb ldap2.4]#
[root@vweb ldap2.4]# nano slapd.conf
#
# pwd
/var/lib/ldap2.4
# slapindex2.4
#
#
# chown ldap:ldap *
#
# cd /var/lib
# ls -la
total 184
...
drwx------ 2 ldap ldap 4096 Dec 26 17:34 ldap
drwxr-x--- 3 ldap ldap 4096 Dec 27 13:03 ldap2.4
...
I have googled around but can't find something about this error.
Can someone please help?
Thanks in advance,
Nick Milas
10 years, 3 months
No ProxyAuthz with SASL-GSSAPI?
by Jaap Winius
Hi folks,
Although I've been able to get proxy authorization to work on Debian
lenny systems using OpenLDAP 2.4.11 and Kerberos authentication with
SASL-GSSAPI, and I've been able to get it to work on Debian squeeze
using 2.4.23 (with Pierangelo's 2010-04-29 patch) and clear-text
passwords, but for some reason I'm not having any same luck with the
same patched 2.4.23 version when using Kerberos authentication with
SASL-GSSAPI.
If I compare the two squeeze systems -- clear-text vs. SASL-GSSAPI --
while the loglevels are both set to -1, and try submitting a similar
change on both consumer servers, lines with "parseProxyAuthz" and
"PROXYAUTHZ" show up in the syslog of the clear-text system's provider
server, but nothing of the sort shows up in the syslog on the
SASL-GSSAPI system's provider server.
Instead, when attempting to add two objects -- cn=ccolumbus and
uid=ccolumbus -- using the ldapadd utility as uid=admin on the
consumer server, I see this kind of stuff in the logs:
======== begin log fragment consumer server ========================
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: read active on 17
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17)
Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17): got connid=1003
Dec 23 18:54:16 ldapks2 slapd[29862]: connection_read(17): checking
for input on id=1003
Dec 23 18:54:16 ldapks2 slapd[29862]: op tag 0x60, time 1293126856
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 do_bind
Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnPrettyNormal: <>
Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnPrettyNormal: <>, <>
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 BIND dn="" method=163
Dec 23 18:54:16 ldapks2 slapd[29862]: do_bind: dn () SASL mech GSSAPI
Dec 23 18:54:16 ldapks2 slapd[29862]: ==> sasl_bind: dn=""
mech=<continuing> datalen=32
Dec 23 18:54:16 ldapks2 slapd[29862]: SASL Canonicalize [conn=1003]:
authcid="admin"
Dec 23 18:54:16 ldapks2 slapd[29862]: slap_sasl_getdn: conn 1003
id=admin [len=5]
Dec 23 18:54:16 ldapks2 slapd[29862]: slap_sasl_getdn: u:id converted
to uid=admin,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnNormalize:
<uid=admin,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>
Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnNormalize:
<uid=admin,cn=example.com,cn=gssapi,cn=auth>
Dec 23 18:54:16 ldapks2 slapd[29862]: ==>slap_sasl2dn: converting SASL
name uid=admin,cn=example.com,cn=gssapi,cn=auth to a DN
Dec 23 18:54:16 ldapks2 slapd[29862]: [rw] authid:
"uid=admin,cn=example.com,cn=gssapi,cn=auth" ->
"uid=admin,ou=people,dc=example,dc=com"
Dec 23 18:54:16 ldapks2 slapd[29862]: slap_parseURI: parsing
uid=admin,ou=people,dc=example,dc=com
Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnNormalize:
<uid=admin,ou=people,dc=example,dc=com>
Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnNormalize:
<uid=admin,ou=people,dc=example,dc=com>
Dec 23 18:54:16 ldapks2 slapd[29862]: <==slap_sasl2dn: Converted SASL
name to uid=admin,ou=people,dc=example,dc=com
Dec 23 18:54:16 ldapks2 slapd[29862]: slap_sasl_getdn: dn:id converted
to uid=admin,ou=people,dc=example,dc=com
Dec 23 18:54:16 ldapks2 slapd[29862]: SASL Canonicalize [conn=1003]:
slapAuthcDN="uid=admin,ou=people,dc=example,dc=com"
Dec 23 18:54:16 ldapks2 slapd[29862]: SASL proxy authorize
[conn=1003]: authcid="admin(a)EXAMPLE.COM" authzid="admin(a)EXAMPLE.COM"
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 BIND
authcid="admin(a)EXAMPLE.COM" authzid="admin(a)EXAMPLE.COM"
Dec 23 18:54:16 ldapks2 slapd[29862]: SASL Authorize [conn=1003]:
proxy authorization allowed authzDN=""
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_sasl: err=0 len=-1
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 BIND
dn="uid=admin,ou=people,dc=example,dc=com" mech=GSSAPI sasl_ssf=56
ssf=56
Dec 23 18:54:16 ldapks2 slapd[29862]: do_bind: SASL/GSSAPI bind:
dn="uid=admin,ou=people,dc=example,dc=com" sasl_ssf=56
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_response: msgid=3 tag=97 err=0
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=2 RESULT tag=97 err=0 text=
Dec 23 18:54:16 ldapks2 slapd[29862]: <== slap_sasl_bind: rc=0
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on:
Dec 23 18:54:16 ldapks2 slapd[29862]:
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on:
Dec 23 18:54:16 ldapks2 slapd[29862]: 17r
Dec 23 18:54:16 ldapks2 slapd[29862]:
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: read active on 17
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17)
Dec 23 18:54:16 ldapks2 slapd[29862]: connection_get(17): got connid=1003
Dec 23 18:54:16 ldapks2 slapd[29862]: connection_read(17): checking
for input on id=1003
Dec 23 18:54:16 ldapks2 slapd[29862]: op tag 0x68, time 1293126856
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=3 do_add
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=3 do_add: dn
(cn=ccolumbus,ou=groups,dc=example,dc=com)
Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnPrettyNormal:
<cn=ccolumbus,ou=groups,dc=example,dc=com>
Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnPrettyNormal:
<cn=ccolumbus,ou=groups,dc=example,dc=com>,
<cn=ccolumbus,ou=groups,dc=example,dc=com>
Dec 23 18:54:16 ldapks2 slapd[29862]: conn=1003 op=3 ADD
dn="cn=ccolumbus,ou=groups,dc=example,dc=com"
Dec 23 18:54:16 ldapks2 slapd[29862]:
bdb_dn2entry("cn=ccolumbus,ou=groups,dc=example,dc=com")
Dec 23 18:54:16 ldapks2 slapd[29862]: =>
hdb_dn2id("cn=ccolumbus,ou=groups,dc=example,dc=com")
Dec 23 18:54:16 ldapks2 slapd[29862]: <= hdb_dn2id: get failed:
DB_NOTFOUND: No matching key/data pair found (-30988)
Dec 23 18:54:16 ldapks2 slapd[29862]: hdb_referrals: tag=104
target="cn=ccolumbus,ou=groups,dc=example,dc=com"
matched="ou=groups,dc=example,dc=com"
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on:
Dec 23 18:54:16 ldapks2 slapd[29862]:
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: conn=1003 op=3 p=3
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: err=10
matched="" text=""
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result:
referral="ldap://ldapks.example.com:389/cn=ccolumbus,ou=groups,dc=example,dc=com"
Dec 23 18:54:16 ldapks2 slapd[29862]: >>> dnPrettyNormal:
<cn=ccolumbus,ou=groups,dc=example,dc=com>
Dec 23 18:54:16 ldapks2 slapd[29862]: <<< dnPrettyNormal:
<cn=ccolumbus,ou=groups,dc=example,dc=com>,
<cn=ccolumbus,ou=groups,dc=example,dc=com>
Dec 23 18:54:16 ldapks2 slapd[29862]: ldap_back_db_open:
URI=ldap://ldapks.example.com:389
Dec 23 18:54:16 ldapks2 slapd[29862]: ==>
ldap_back_add("cn=ccolumbus,ou=groups,dc=example,dc=com")
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: conn=1003 op=3 p=3
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: err=8
matched="" text="modifications require authentication"
Dec 23 18:54:16 ldapks2 slapd[29862]: <==
ldap_back_add("cn=ccolumbus,ou=groups,dc=example,dc=com"): 8
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: conn=1003 op=3 p=3
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_result: err=8
matched="" text=""
Dec 23 18:54:16 ldapks2 slapd[29862]: send_ldap_response: msgid=4
tag=105 err=8
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks2 slapd[29862]: daemon: activity on:
Dec 23 18:54:16 ldapks2 slapd[29862]: 17r
======== end log fragment consumer server ==========================
The only thing I think looks strange in the above is this line:
SASL Authorize [conn=1003]: proxy authorization allowed authzDN=""
Why is the authzDN empty?
======== begin log fragment provider server ========================
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on:
Dec 23 18:54:16 ldapks1 slapd[1265]:
Dec 23 18:54:16 ldapks1 slapd[1265]: slap_listener_activate(8):
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8 busy
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: >>> slap_listener(ldap:///)
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: listen=8, new connection on 18
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: added 18r (active) listener=(nil)
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 fd=18 ACCEPT from
IP=192.168.2.56:43112 (IP=0.0.0.0:389)
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 2 descriptors
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on:
Dec 23 18:54:16 ldapks1 slapd[1265]: 18r
Dec 23 18:54:16 ldapks1 slapd[1265]:
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: read active on 18
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18)
Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18): got connid=1004
Dec 23 18:54:16 ldapks1 slapd[1265]: connection_read(18): checking for
input on id=1004
Dec 23 18:54:16 ldapks1 slapd[1265]: op tag 0x60, time 1293126856
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=0 do_bind
Dec 23 18:54:16 ldapks1 slapd[1265]: >>> dnPrettyNormal: <>
Dec 23 18:54:16 ldapks1 slapd[1265]: <<< dnPrettyNormal: <>, <>
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=0 BIND dn="" method=128
Dec 23 18:54:16 ldapks1 slapd[1265]: do_bind: version=3 dn="" method=128
Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: conn=1004 op=0 p=3
Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: err=0
matched="" text=""
Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_response: msgid=1 tag=97 err=0
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=0 RESULT tag=97 err=0 text=
Dec 23 18:54:16 ldapks1 slapd[1265]: do_bind: v3 anonymous bind
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on:
Dec 23 18:54:16 ldapks1 slapd[1265]:
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on:
Dec 23 18:54:16 ldapks1 slapd[1265]: 18r
Dec 23 18:54:16 ldapks1 slapd[1265]:
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: read active on 18
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18)
Dec 23 18:54:16 ldapks1 slapd[1265]: connection_get(18): got connid=1004
Dec 23 18:54:16 ldapks1 slapd[1265]: connection_read(18): checking for
input on id=1004
Dec 23 18:54:16 ldapks1 slapd[1265]: op tag 0x68, time 1293126856
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 do_add
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 do_add: dn
(cn=ccolumbus,ou=groups,dc=example,dc=com)
Dec 23 18:54:16 ldapks1 slapd[1265]: >>> dnPrettyNormal:
<cn=ccolumbus,ou=groups,dc=example,dc=com>
Dec 23 18:54:16 ldapks1 slapd[1265]: <<< dnPrettyNormal:
<cn=ccolumbus,ou=groups,dc=example,dc=com>,
<cn=ccolumbus,ou=groups,dc=example,dc=com>
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 ADD
dn="cn=ccolumbus,ou=groups,dc=example,dc=com"
Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: conn=1004 op=1 p=3
Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_result: err=8
matched="" text="modifications require authentication"
Dec 23 18:54:16 ldapks1 slapd[1265]: send_ldap_response: msgid=2 tag=105 err=8
Dec 23 18:54:16 ldapks1 slapd[1265]: conn=1004 op=1 RESULT tag=105
err=8 text=modifications require authentication
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on 1 descriptor
Dec 23 18:54:16 ldapks1 slapd[1265]: daemon: activity on:
======== end log fragment provider server ==========================
The ldapadd command on the consumer server gives:
adding new entry "cn=ccolumbus,ou=groups,dc=example,dc=com"
ldap_add: Strong(er) authentication required (8)
Some more background info. In the DIT, the consumer server is
represented by and authorized to function as a proxy via this object:
dn: cn=ldapks2,ou=consumers,dc=example,dc=com
cn: ldapks2
objectClass: simpleSecurityObject
objectClass: organizationalRole
description: LDAP server2 replicator
authzTo: dn.regex:^uid=[^,]+,ou=people,dc=example,dc=com$
userPassword:: e0NSWVBUfSo=
structuralObjectClass: organizationalRole
entryUUID: d939b140-a341-102f-8cd1-6f46e6760f2b
creatorsName: uid=admin,ou=people,dc=example,dc=com
createTimestamp: 20101224003819Z
entryCSN: 20101224003819.303636Z#000000#000#000000
modifiersName: uid=admin,ou=people,dc=example,dc=com
modifyTimestamp: 20101224003819Z
When the consumer, ldapks2, synchronizes with the provider, ldapks1,
the consumer also shows up in the syslog on the provider server as
cn=ldapks2,ou=consumers,dc=example,dc=com. That's a good sign,
although after adding the relevant olcAuthzRegexp on the provider, it
began to work that way after I had restarted slapd.
On the provider, the cn=config DIT looks like this:
======== begin cn=config DIT fragment provider server ==============
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAuthzPolicy: to
olcAuthzRegexp: {0}uid=ldap/([^/\.]+).example.com,cn=example.com,cn=gssapi,cn=
auth cn=$1,ou=consumers,dc=example,dc=com
olcAuthzRegexp: {1}uid=([^,]+),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=peop
le,dc=example,dc=com
olcLogLevel: stats
olcPidFile: /var/run/slapd/slapd.pid
olcSaslRealm: EXAMPLE.COM
olcToolThreads: 1
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=example,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn.one="ou=consumers,d
c=example,dc=com" read by * none
olcAccess: {1}to attrs=loginShell by dn.one="ou=consumers,dc=example,dc=com" r
ead by self write by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by users read by * none
olcLastMod: TRUE
olcRootDN: uid=admin,ou=people,dc=example,dc=com
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: cn eq
olcDbIndex: ou eq
olcDbIndex: dc eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
======== end cn=config DIT fragment provider server ================
Chaining is enabled on the consumer server:
======== begin cn=config DIT fragment consumer server ==============
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}back_ldap
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
olcChainReturnError: TRUE
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: "ldap://ldapks.example.com:389/"
olcDbIDAssertBind: bindmethod=sasl saslmech=gssapi mode=self
olcDbRebindAsUser: TRUE
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=example,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange by * none
olcAccess: {1}to attrs=loginShell by self read by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by users read by * none
olcLastMod: TRUE
olcRootDN: cn=manager
olcSyncrepl: {0}rid=123 provider="ldap://ldapks.example.com:389/" type=refresh
AndPersist retry="60 30 300 +" searchbase="dc=example,dc=com" bindmethod=sasl
saslmech=gssapi
olcUpdateRef: "ldap://ldapks.example.com:389/"
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: uid eq
olcDbIndex: cn eq
olcDbIndex: ou eq
olcDbIndex: dc eq
======== end cn=config DIT fragment consumer server ================
BTW, "ldapks.example.com" is an alias for "ldapks1.example.com."
That's pretty much it, I think. Is this problem due to another bug, or
have I made a mistake somewhere?
Thanks,
Jaap
10 years, 3 months
