tls_checkpeer directive
by Michael Starling
I'm running openldap-2.3.43-12.el5 on a RHEL 5.5 system:
I believe I have TLS encryption working but I'd like to be able to verify my client connections.
On my LDAP server I have the following in slapd.conf
TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3
TLSCertificateFile /etc/openldap/cacerts/slapdcert.pem
TLSCertificateKeyFile /etc/openldap/cacerts/slapdkey.pem
TLSCACertificateFile /etc/openldap/cacerts/slapdcert.pem
On the client I have the following in /etc/ldap.conf
uri ldaps://10.70.5.67/
ssl on
tls_cacertfile /etc/openldap/cacerts/slapdcert.pem
tls_checkpeer no
On the client /etc/openldap/ldap.conf
URI ldaps://10.70.5.67/
TLS_CACERT /etc/openldap/cacerts/slapdcert.pem
TLS_REQCERT demand
These commands work both from the client and server.
openssl s_client -connect servername:636 -showcerts
ldapsearch -x -H ldaps://servername -b dc=domain,dc=domain -D cn=root,dc=domain,dc=domain -W
So my first question would be does this guarantee encrypted sessions?
Second, if I change tls_checkpeer to yes then I can't contact the LDAP server. How can I verify my clients?
-Mike
12 years, 7 months
Handling slapd.d in OpenLDAP and Kerberos
by sarathkrishna89＠gmail.com
Hi,
We are currently trying to use OpenLDAP as the database for Kerberos in our
lab.
We installed OpenLDAP in Ubuntu 10.04 and is working without any problem
(i,e. queries are showing the correct results)
But we are not able to get Kerberos authenticate via OpenLDAP.
For authenticating via OpenLDAP, the principles needs to be rewritten (using
authz-policy and authz-regexp). We know how to do
that in older version of OpenLDAP which had (slapd.conf) but don't know how
to do the same in new OpenLDAP which has slapd.d directory instead.
The manuals also doesn't say anything on this issue.
We did the following for testing authentication via Kerberos:
kinit username; ldapsearch -H ldaps://server.example.com
And we got this result:
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
We just want to perform this:
authz-policy from
authz-regexp
uid=(.*),cn=example.com,cn=GSSAPI,cn=auth
uid=$1,ou=people,dc=example,dc=com
We think adding this in slapd.conf should serve the purpose. Any
suggestions/help is highly appreciated.
--
Sarath
12 years, 7 months
Multimaster replication of cn=config working too well?!
by Mark Cairney
Hi,
Has anyone experienced problems with the cn=config directory syncing the same change across all nodes and breaking the configuration?
In the past I've had problems where the syncrepl parameters are synced across all nodes, including that node itself, which results in the servers then trying to sync with themselves.
The most recent problem however was that the olcSaslHost value was synced to be one particular server on all 3 nodes. As I was using GSSAPI to do the replication this broke it completely and it meant that I could only bind via GSSAPI to one of the 3 servers.
In the meantime I've set the servers not to syncrepl cn=config but this isn't ideal.
Anyone else on the list had similar problems?
Kind regards,
Mark
/*********************************
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cairney(a)ed.ac.uk
*********************************/
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
12 years, 7 months
slapd.d syntax help for ldap proxy server
by Anton Chu
I'm trying to setup a ldap proxy server for push based replication. I'm in
need of help with providing the correct syntax on installing a ldap proxy
using slapd.d instead of slapd.conf. The items in bold are the
questionable syntax that can crossover to slapd.d. Here's my slapd.d
configuration:
Standalone LDAP Proxy:
>
> # load the schemas
> ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
>
> ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif
>
> ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
>
> ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif
>
> ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif
>
> ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif
>
>
> # Load dynamic backend modules
>
> dn: cn=module,cn=config
>
> objectClass: olcModuleList
>
> cn: module
>
> olcModulepath: /usr/lib/ldap
>
> olcModuleload: back_hdb
>
> olcModuleload: syncprov
>
>
> # Database settings
>
> dn: olcDatabase=hdb,cn=config
>
> objectClass: olcDatabaseConfig
>
> objectClass: olcHdbConfig
>
> olcDatabase: {1}hdb
>
> *olcHidden: TRUE*
>
> olcSuffix: dc=suretecsystems,dc=com
>
> olcDbDirectory: /var/lib/ldap
>
> olcRootDN: cn=admin,dc=suretecsystems,dc=com
>
> olcRootPW: secret
>
> *olcUri: ldap://localhost:9012/*
>
>
>
> # We don't need any access to this DSA
>
> *olcRestrict: ALL
>
> olcAcl-bind: bindmethod=simple
> binddn="cn=replicator,dc=suretecsystems,dc=com"
> credentials=testing*
>
> olcSyncrepl: rid=001
> provider=ldap://localhost:9011/
> binddn="cn=replicator,dc=suretecsystems,dc=com"
> bindmethod=simple
> credentials=testing
> searchbase="dc=suretecsystems,dc=com"
> type=refreshAndPersist
> retry="5 5 300 5"
>
>
Here's the slapd.conf provided at the site that I'm trying to convert:
http://www.openldap.org/doc/admin24/replication.html
The following configuration is an example of a standalone LDAP Proxy:
>
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/nis.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
>
> include /usr/local/etc/openldap/slapd.acl
>
> modulepath /usr/local/libexec/openldap
> moduleload syncprov.la
> moduleload back_ldap.la
>
> ##############################################################################
> # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap
> ##############################################################################
>
> database ldap
> # ignore conflicts with other databases, as we need to push out to same suffix
> hidden on
> suffix "dc=suretecsystems,dc=com"
> rootdn "cn=slapd-ldap"
> uri ldap://localhost:9012/
>
> lastmod on
>
> # We don't need any access to this DSA
> restrict all
>
> acl-bind bindmethod=simple
> binddn="cn=replicator,dc=suretecsystems,dc=com"
> credentials=testing
>
> syncrepl rid=001
> provider=ldap://localhost:9011/
> binddn="cn=replicator,dc=suretecsystems,dc=com"
> bindmethod=simple
> credentials=testing
> searchbase="dc=suretecsystems,dc=com"
> type=refreshAndPersist
> retry="5 5 300 5"
>
> overlay syncprov
>
>
12 years, 7 months
Re: slapo-lastbind
by Marco Pizzoli
On 7 Feb 2011 22:31, "Marco Pizzoli" <marco.pizzoli(a)gmail.com> wrote:
> Hi Jonathan,
> I understand the "locality" of the attribute, but my question is motivated
> by the ppolicy_forward_updates directive that addresses this identical
> problem.
> Do you think it would be possible to have a similar feature with this
> overlay?
>
> Thanks
> Marco
> On 7 Feb 2011 20:49, "Jonathan CLARKE" <jonathan.clarke(a)normation.com>
> wrote:
12 years, 7 months
slapo-lastbind
by Marco Pizzoli
Hi all,
I used effectively the new slapo-lastbind overlay.
I noticed that my authTimestamp attribute become populated for each user who
successfully does a bind, but on my multi-master deploy I cannot have that
attribute shared/replicated on all servers
Any suggestions?
Thanks
Marco
--
_________________________________________
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
12 years, 7 months
Compile contrib modules?
by Marco Pizzoli
Hi list,
Today I downloaded the HEAD repository and tried to compile also the contrib
module "lastbind".
With the configure script I'm not able to have that module built in.
I have to do something particular?
Thanks
Marco
--
_________________________________________
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
12 years, 7 months
Search with filter doesn't return any results?
by Markku Tavasti
Hi!
I have strange problem:
I have newly built ldap database. System is running on Centos 5.5
(same as RHEL 5)
# slapd -V
@(#) $OpenLDAP: slapd 2.3.43 (Nov 29 2010 03:44:41) $
mockbuild@builder10.centos.org:/builddir/build/BUILD/openldap-2.3.43/openldap-2.3.43/build-servers/servers/slapd
I have configured syncrepl from ldap1 to ldap2. Both systems
have same slapd.conf execpt on ldap1 syncprov overlay, ldap2
syncrepl consumer.
To both servers ldapsearch without additional filters works fine, and
returns content of database. However, to ldap1 (synrepl master)
applying any search filter gives no results. Only filters I have
noticed working are objectClass-filters.
For example like this:
--------- shell commands & output start ---------
[root@srv]# ldapsearch -x -h ldap1 -b "dc=hq,dc=mydomain,dc=com"
... actual search results removed .....
# search result
search: 2
result: 0 Success
# numResponses: 33
# numEntries: 32
[root@srv]# ldapsearch -x -h ldap1 -b "dc=hq,dc=mydomain,dc=com" | grep
tavasti
memberUid: tavasti
memberUid: tavasti
memberUid: tavasti
# tavasti, Users, hq.mydomain.com
dn: uid=tavasti,ou=Users,dc=hq,dc=mydomain,dc=com
uid: tavasti
homeDirectory: /home/ldap/tavasti
[root@srv]# ldapsearch -x -h ldap1 -b "dc=hq,dc=mydomain,dc=com" uid=tavasti
# extended LDIF
#
# LDAPv3
# base <dc=hq,dc=mydomain,dc=com> with scope subtree
# filter: uid=tavasti
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
--------- shell commands & output end ---------
On log I get with the last one:
Feb 4 18:29:54 ldap1 slapd[8611]: conn=30 fd=15 ACCEPT from IP=10.x.x.x:347
25 (IP=0.0.0.0:389)
Feb 4 18:29:54 ldap1 slapd[8611]: conn=30 op=0 BIND dn="" method=128
Feb 4 18:29:54 ldap1 slapd[8611]: conn=30 op=0 RESULT tag=97 err=0 text=
Feb 4 18:29:54 ldap1 slapd[8611]: begin get_filter
Feb 4 18:29:54 ldap1 slapd[8611]: EQUALITY
Feb 4 18:29:54 ldap1 slapd[8611]: end get_filter 0
Feb 4 18:29:54 ldap1 slapd[8611]: conn=30 op=1 SRCH
base="dc=hq,dc=mydomain,dc=com" scope=2 deref=0 filter="(uid=tavasti)"
Feb 4 18:29:54 ldap1 slapd[8611]: => bdb_filter_candidates
Feb 4 18:29:54 ldap1 slapd[8611]: AND
Feb 4 18:29:54 ldap1 slapd[8611]: => bdb_list_candidates 0xa0
Feb 4 18:29:54 ldap1 slapd[8611]: => bdb_filter_candidates
Feb 4 18:29:54 ldap1 slapd[8611]: OR
Feb 4 18:29:54 ldap1 slapd[8611]: => bdb_list_candidates 0xa1
Feb 4 18:29:54 ldap1 slapd[8611]: => bdb_filter_candidates
Feb 4 18:29:54 ldap1 slapd[8611]: EQUALITY
Feb 4 18:29:54 ldap1 slapd[8611]: <= bdb_filter_candidates: id=0
first=0 last=0
Feb 4 18:29:54 ldap1 slapd[8611]: => bdb_filter_candidates
Feb 4 18:29:54 ldap1 slapd[8611]: EQUALITY
Feb 4 18:29:54 ldap1 slapd[8611]: <= bdb_filter_candidates: id=0
first=0 last=0
Feb 4 18:29:54 ldap1 slapd[8611]: <= bdb_list_candidates: id=0 first=0
last=0
Feb 4 18:29:54 ldap1 slapd[8611]: <= bdb_filter_candidates: id=0
first=0 last=0
Feb 4 18:29:54 ldap1 slapd[8611]: <= bdb_list_candidates: id=0 first=1
last=0
Feb 4 18:29:54 ldap1 slapd[8611]: <= bdb_filter_candidates: id=0
first=1 last=0
Feb 4 18:29:54 ldap1 slapd[8611]: conn=30 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Feb 4 18:29:54 ldap1 slapd[8611]: conn=30 op=2 UNBIND
Feb 4 18:29:54 ldap1 slapd[8611]: conn=30 fd=15 closed
----------------------------------------------------------------------
On config I have 'loglevel filter config stats'
Any ideas what on earth is going on?
--
M. Tavasti / tavasti(a)tavasti.fi / +358-40-5078254
12 years, 7 months
Ghost/invisible subtree
by David Mohr
Hi,
I'm having a strange issue. I'm running openldap 2.4.23 (on debian), and
after playing around with some software using my ldap server I now have
a ghost subtree.
'Ghost' meaning that I cannot see this subtree, but if I try to add an
entry that used to exist, I get an 'Already exists (68)' error. With
slapcat I can see all the invisible entries.
I tried to run slapindex, but that did not help. Then I created a dump
using slapcat, deleted the database, and used slapadd to fill it with
data again. Yet my subtree is still invisible.
Does anyone have suggestions on how to solve this issue? I can't seem to
find any information beyond slapcat & slapadd. I don't see any obvious
issues in the ldif dump either.
Any help?
Thanks,
~David
12 years, 7 months
AccessLog behaviour
by Marco Pizzoli
Hi all,
I would like to know the internal behaviour of slapo-accesslog.
I would like to have accesslog with a data retention of 10 days. In my ldap
usage scenario this retention produce an accesslog db of quite 10GB of data.
Things are working quite fine, but when the log db contains data older than
the retention I defined after restart slapd has a thread allocated at 100%
of cpu of one processor.
I logged at loglevel 992 = 512 + 256 + 128 + 64 + 32, blocked with iptables
every external ldap access and saw these lines in the log:
[cut]
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to
"reqStart=20110202042854.000008Z,cn=log03,dc=mycorp.it" "reqStart" requested
Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access
granted by manage(=mwrscxd)
Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6
Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter
Feb 3 09:37:08 ldap03 slapd[16289]: LE
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to
"reqStart=20110202042854.000010Z,cn=log03,dc=mycorp.it" "reqStart" requested
Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access
granted by manage(=mwrscxd)
Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6
Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter
Feb 3 09:37:08 ldap03 slapd[16289]: LE
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to
"reqStart=20110202042854.000012Z,cn=log03,dc=mycorp.it" "reqStart" requested
Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access
granted by manage(=mwrscxd)
Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6
Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter
Feb 3 09:37:08 ldap03 slapd[16289]: LE
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to
"reqStart=20110202042854.000014Z,cn=log03,dc=mycorp.it" "reqStart" requested
Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access
granted by manage(=mwrscxd)
Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6
Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter
Feb 3 09:37:08 ldap03 slapd[16289]: LE
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to
"reqStart=20110202042855.000000Z,cn=log03,dc=mycorp.it" "reqStart" requested
Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted
Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access
granted by manage(=mwrscxd)
Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6
Feb 3 09:37:09 ldap03 slapd[16289]: => test_filter
Feb 3 09:37:09 ldap03 slapd[16289]: LE
Feb 3 09:37:09 ldap03 slapd[16289]: => access_allowed: search access to
"reqStart=20110202042855.000002Z,cn=log03,dc=mycorp.it" "reqStart" requested
Feb 3 09:37:09 ldap03 slapd[16289]: <= root access granted
Feb 3 09:37:09 ldap03 slapd[16289]: => access_allowed: search access
granted by manage(=mwrscxd)
Feb 3 09:37:09 ldap03 slapd[16289]: <= test_filter 6
Feb 3 09:37:09 ldap03 slapd[16289]: => test_filter
Feb 3 09:37:09 ldap03 slapd[16289]: LE
Feb 3 09:37:09 ldap03 slapd[16289]: => access_allowed: search access to
"reqStart=20110202042855.000004Z,cn=log03,dc=mycorp.it" "reqStart" requested
[cut]
I could assume that slapo-accesslog is querying all entries older than the
retention and passes to delete them.
What if this step to end the job will take more time than the interval time
of re-starting?
Augmenting the frequency of this job could help in this meaning?
Every best practice to follow to use accesllog effectively will be very
appreciated! :-)
Thanks
Marco Pizzoli
--
_________________________________________
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
12 years, 7 months
