Hello everyone!
I have been trying to configure slapd for a week to use it as a proxy for
Google's LDAP service in order to connect some legacy applications. Since I
have multiple domains in Google, I need to centralize all users into a
common "dc."
Everything is working well, but the problem is that, apparently, when
connecting to Google, I am provided with a certificate that I download from
the admin console. However, with that certificate alone, slapd cannot
connect to the target. So, I generate some credentials from the Google LDAP
admin and add them to the slapd configuration. The issue is that, for some
reason, slapd converts the username to lowercase, and Google rejects it
because it is case-sensitive. Is it possible to disable this function?
(There is no way to create a user in Google that is only in lowercase)
Here is my current slapd configuration:
################################################################
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/nis.schema
modulepath /usr/lib/ldap
moduleload back_meta.la
moduleload back_ldap.la
database meta
suffix "dc=proxy"
rootdn "cn=admin,dc=proxy"
rootpw 1234
## example.com
uri "ldap://172.25.3.127:2636/dc=proxy"
suffixmassage "dc=proxy" "dc=example,dc=com"
lastmod off
readonly on
idassert-bind bindmethod=simple
binddn="ChiwewDaw"
credentials="ASk0i9ejiosej9o303"
tls_reqcert=demand
tls_reqsan=demand
starttls=critical
tls_cert=/root/ldapcerts/ldap_cert.crt
tls_key=/root/ldapcerts/ldap_cert.key
tls_cacert=/root/ldapcerts/ca/gtsr1.pem
##################################################################
Thank you for your assistance!
(ps: If anyone knows how to make it work using only the certificate, that
would be great.)
On 02/03/22 20:29, Michael Ströder wrote:
> On 3/2/22 11:49, Francesco Malvezzi wrote:
>> on a consumer I spotted a zombie entry which was deleted on provider.
>
> Which OpenLDAP version are you using?
consumer: openldap-2.5.6
provider: openldap-2.4.56
>
>> Replication is syncrepl:
>>
>> olcSyncrepl: {0}rid=003 provider=ldap://ldap-master.example.org
>> binddn="cn=repluser,ou=agents,dc=example,dc=org" bindmethod=simple
>> credentials="secret" searchbase="ou=people,dc=example,dc=org"
>> type=refreshOnly interval=00:00:01:00 retry="5 5 30 +" timeout=1
>> scope=sub schemachecking=on exattrs=sambaHomeDrive sizelimit=100000
>> timelimit=7200 starttls=yes filter="....."
>
> I cannot really tell what's going on in your deployment.
got it: the procedure is fine but the environment is broken.
I stopped slapd, deleted the mdb files, restarted slapd and in an
acceptable time the users have been all re-synced with all zombies
dropped. It is not elegant at all, so I need to investigate the deployment.
>
> But I wonder why you added sizelimit= to the syncrepl directive. Do you
> really have less than 100000 entries?
yes, the example.edu userbase is really this small (67k users more or
less). Anyhow I removed the sizelimit, even if I think it would hurt me
in the other way (banning users from showing up, not from being removed),
>
> Ciao, Michael.
thank you so much for your time,
Francesco
a bit of additional data which may be relevant:
the consumer synrepl config:
{0}rid=0
provider=ldap://dsa.example.net
starttls=critical
bindmethod=simple
binddn="cn=repl-
content,ou=exo,ou=services,ou=accounts,dc=example,dc=net"
credentials="xxxxx"
searchbase="dc=example,dc=net"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="15 +"
syncdata=accesslog
using ldapsearch on the consumer, against the provider, the replication
dn is able to see the entry in question:
>ldapsearch -xLLLZZH 'ldap://dsa.example.net' -D 'cn=repl-content,ou=exo,ou=services,ou=accounts,dc=example,dc=net' -w 'xxxxx' -b 'cn=test_group,ou=general,ou=groups,dc=example,dc=net' -s base '*' '+'
dn: cn=test_group,ou=general,ou=groups,dc=example,dc=net
objectClass: top
objectClass: groupOfNames
description: test group
cn: test_group
member: uid=dummy_default,ou=dummy_accounts,ou=other,ou=accounts,dc=example,
dc=net
structuralObjectClass: groupOfNames
entryUUID: d68c73e4-10c1-1031-8246-9dfa8daa46e0
creatorsName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=net
createTimestamp: 20120402034404Z
entryCSN: 20120402034404.808333Z#000000#000#000000
modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=net
modifyTimestamp: 20120402034404Z
entryDN: cn=test_group,ou=general,ou=groups,dc=example,dc=net
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
Hello OpenLDAP users,
I’m looking for some advice concerning an OpenLDAP solution I’m about to
deploy between 4 locations in company I work for.
Currently I’ve implemented a LDAP DIT in my country and we’ve had
exquisite results. I’ve integrated RADIUS for wireless authentication,
MIT Kerberos, Samba PDC, dovecot and the list can continue but that’s
not the scope of this message.
We have some global services located in one of the countries that all
other 3 countries use ( trac, svn, web2project, alfresco ).
We want that each country to have it’s own LDAP DIT ( we don’t want to
have a global LDAP with slaves in each country because some of us want
locally significant objects ( for authorization purposes ) and having a
slave LDAP means read-only ). That’s why I thought of using
multi-n-master on each of the four LDAP servers.
The ideea I had was that each country will have only a portion of the
DIT being sent to the others ( we narrow the searchbase in syncrepl ):
Country 1 sends ou=COUNTRY-1,dc=example,dc=com
Country 2 sends ou=COUNTRY-2,dc=example,dc=com
Country 3 sends ou=COUNTRY-3,dc=example,dc=com
Country 4 sends ou=COUNTRY-4,dc=example,dc=com
In each ou=COUNTRY-{1..4} they will have ou=People and ou=Groups.
Basically that’s the only thing I want to be consistent across all LDAP
DITs.
I’ve tested the solution using some virtual machines and besides the
starttls and some things each administrator will have to be cautious
about things went smoothly.
I've also read something about slapo-translucent - will now test to see
how it works.
Can I get some suggestions / maybe a whole new architecture for my needs
in case I didn’t foresee problems ?
Thx!
--
Andrei BĂNARU
Internal Support
CCNA Security, CCIP
StreamWIDE Romania
>On Sun, Jul 10, 2011 at 5:41 PM, Dan White <dwhite(a)olp.net> wrote:
>>> ldapsearch -x -w PASSWORD -D uid=user,ou=people,dc=my,dc=domain -b
>>> uid=user,ou=people,dc=my,dc=domain
>>>
>>> And everyting works ok.
>>> My doubt is:
>>>
>>> who is performing the password checking? The openldap server
>>> daemon (slapd) ou the ldapsearch ?
>>
>> When userPassword is configured with '{SASL}user@domain', you are using
>> SASL pass-through authentication. See section 14.5 (Pass-Through
>> authentication) of the OpenLDAP Administrator's Guide for documentation.
>>
>> In such a scenario, authentication is ultimately handled by the libsasl2
>> glue layer, and is controlled by the configuration of your sasl slapd.conf
>> file, which is typically found in /usr/lib/sasl2/slapd.conf.
>>
>> Presumably you've configured pass-through authentication because of a need
>> to authenticate against a saslauthd daemon (pwcheck_method: saslauthd).
On 10/07/11 17:56 -0300, Friedrich Locke wrote:
>Thanks for your response!
>
>But who is doing the comunication with saslauthd, the slap daemon
>process or the ldapsearch process ?
>
>Thanks once more!
slapd will be communicating with saslauthd (or your configured
pwcheck_method) via libsasl2.
With your ldapsearch command, the dn and password will be transmitted in
clear text over the wire to your openldap/slapd server, for authentication,
unless you've configured ldaps or starttls encryption for protection.
--
Dan White
--On Tuesday, June 25, 2013 2:01 PM -0400 Rodney Simioni
<rodney.simioni(a)verio.net> wrote:
>
> Comment below.
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Tuesday, June 25, 2013 12:27 PM
> To: Rodney Simioni; openldap-technical(a)openldap.org
> Subject: RE: openldap and MozNSS
>
> --On Tuesday, June 25, 2013 11:40 AM -0400 Rodney Simioni
> <rodney.simioni(a)verio.net> wrote:
>
>> I'm getting further, I went to http://ltb-project.org and downloaded a
>> newer version of openldap. BTW, thank you, it's a nice site.
>>
>> But when I do a 'ldapsearch -d -1 -x -LLL -ZZ', I'm getting "
>> unsupported extended operation"
>>
>> Does anybody have a clue?
>
> I would advise you to specifically use -H <URI> so it is clear what you
> are connecting to and how. For example, -ZZ requests startTLS, but if
> you are using an ldaps:// URI, that makes no sense, because they are
> mutually exclusive. [[Rod's comment]] I'm using '-H', I'm still getting
> 'unsupported extended operation', but thanks.
My point was, show an EXACT ldapsearch command where it is not pulling in
crap from a local or system ".ldaprc" or "ldap.conf" file. Until you do
that, god knows what those files are setting.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
We have a client server that is failing on the ssl handshake using TLS.
The following is from the server log when the client is trying to connect.
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from
IP=172.17.1.10:55469 (IP=0.0.0.0:389)
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid=
err=0 text=
Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS
negotiation failure)
On the client when I run the following:
openssl s_client -showcerts -connect tntest-ldap.oreillyauto.com:389
I get this on the client
CONNECTED(00000003)
139669033973408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 226 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
If I do the same command on port 636 I can see the certificate. All of our
applications that use ldap are all set for TLS. Even if I force them to
port 636 they fail.
Any ideas to look at are appreciated.
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
On Mar 8, 2014, at 08.50, Joshua Schaeffer <jschaeffer0922(a)gmail.com> wrote:
> I'm in the process of setting up my slapd server to operate over LDAPS and having trouble when using a CA certificate (being my own certificate authority). I've been able to setup LDAPS when using a self-signed server certificate:
please use ldap+starttls, not ldaps.
> This works fine and I'm able to authenticate clients. However if I use a CA certificate (again, being my own CA) to sign my server certificate and then change olcTLSVerifyClient to demand and add olcTLSCACertificateFile then I can no longer authenticate. I've installed my CA certificate on the client machine and pointed both ldap.conf and nslcd.conf to the CA certificate. However I get the following when debugging:
why are you setting olcTLSVerifyClient when changing from a self signed cert to a properly signed cert? did you read the description of this setting in man 5 slapd-config? it has nothing to do with use of a self-signed vs a regular cert. be methodical when doing an exercise like this. first switch from your self signed cert to your proper cert. test. then, modify olcTLSVerifyClient and see what happens.
> Why would the client not send the certificate if I've pointed TLS_CACERT in ldap.conf and tls_cacertfile to that cert?
TLS_CACERT and tls_cacertfile point to the ca cert. why would this cert be sent anywhere by the client? the server already has this cert. those settings allow the client to establish a chain of trust to the certificate presented by the server. it’s a “bootstrapping” mechanism, so to speak. you tell the client [by way of those settings] to implicitly trust, no questions asked, certain ca certificates. then when the client is presented a certificate by a server, it can be deemed “trustworthy”, even though it had no prior knowledge of this particular cert.
-ben
Bryan Payne skrev, on 20-02-2008 16:10:
> Thank you for your help. I added the pwdPolicySubentry to a user to no
> avail. I did find this in the logfile though:
>
> Feb 20 09:01:13 ldapserver slapd[6709]: conn=95289 op=4 SEARCH RESULT
> tag=101 err=50 nentries=0 text=Operations are restricted to
> bind/unbind/abandon/StartTLS/modify password
>
> So it looks like it's trying to do something but cannot. While I'm
> concerned about password strength, I'm more concerned (at this point)
> with just having the machine prompt for a password change. I'm running
> centos 4.6 and openldap 2.3.39. I compiled it with the following:
>
> ./configure --enable-crypt --enable-ppolicy --with-tls
> --prefix=/opt/openldap/
>
> Once again, thanks for any help.
I'd strongly advise you to chuck out your self-built 2.3.39 and install
the rpms at http://staff.telkomsa.net/packages/rhel4/openldap/$basearch.
You need both libldap and openldap.
Shouldn't be difficult if you install to /opt (you an old Solaris
person? Or other SYSV?) These will install to LFH locations; however,
being rpms you can always chuck them off again if they don't please
(which they will ;) ).
Then take it again from the beginning. These are Buchan Milne's rpms and
have their own discrete, patched db4 4.2.52 which will not conflict with
the db4 4.2.52 which you have from CentOS. Moreover everything including
sonames is named differently from Red Hat's, so it all takes a bit of
getting used to. But when you have, you'll never look back.
Best,
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
Hello :)
Hopefully I'm not completly wrong on this ml, as its not only ldap
related, but also samba related.
I work at a Chair of a german university.
University uses a central LDAP-system for all students, employees,
scientists, scientific guests, etc., providing an unique UID for all
these peoples, plus many more information.
My idea was: setting-up a local OpenLDAP-proxy, so that people of our
Chair get access to ressources (eg. via samba) using their unique UID
and password, but without setting-up an AD.
Many system here are owned by the Chair or University, but lots of
students are using their own laptop, so using a AD (and adding them) is
not very handy for them ... so, something like a stand-alone
samba-server with authentification versus ldap.
Is there a chance to get this running? There is no chance to add the
schema on a proxy?
What I did so far:
- I can establish a connection to the central LDAP-system using
/etc/pam_ldap.conf
uri ldaps://ldap.DOMAIN.de
host ldap.DOMAIN.de
base ou=CHAIR,ou=hosts,dc=DOMAIN,dc=de
ldap_version 3
binddn cn=CHAIRCODE,ou=SECURITY,dc=DOMAIN,dc=de
bindpw PASSWORD
pam_password crypt
ssl start_tls
ssl on
- I configured /etc/libnss-ldap.conf, and a 'getent passwd' shows all
local users plus the members
uri ldaps://ldap.DOMAIN.de
host ldap.DOMAIN.de
base ou=CHAIR,ou=hosts,dc=DOMAIN,dc=de
ldap_version 3
binddn cn=CHAIRCODE,ou=SECURITY,dc=DOMAIN,dc=de
bindpw PASSWORD
- I also configured /etc/ldap/slapd.conf for proxy usage (I think I did
...), but I learned 2 days ago I can't add any schemata on a proxy ...
# Schema includes
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
#
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/openldap.schema
#
#
# Module
modulepath /usr/lib/ldap
moduleload back_ldap.la
moduleload back_hdb.la
moduleload back_mdb
moduleload rwm
moduleload pcache.la
moduleload memberof.la
#
# Main settings
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
conn_max_pending 1000
sockbuf_max_incoming 4194303
logfile /var/log/ldap/logfile.log
#loglevel stats conns filter
loglevel any
sizelimit unlimited
limits * size.pr=0 size.prtotal=none
tool-threads 1
#
readonly on
access to *
by * read
#
# Database defs (proxy to AD)
database ldap
chase-referrals no
rootdn ou=CHAIR,ou=hosts,dc=DOMAIN,dc=de
suffix "dc=DOMAIN,dc=de"
uri ldap://localhost/
uri ldap://ldap.DOMAIN.de/
uri ldaps://ldap.DOMAIN.de/
acl-bind bindmethod=simple
binddn="cn=CHAIRCODE,ou=SECURITY,dc=DOMAIN,dc=de" credentials="PASSWORD"
starttls=yes
idassert-bind bindmethod=simple
binddn="cn=CHAIRCODE,ou=SECURITY,dc=DOMAIN,dc=de" credentials="PASSWORD"
starttls=yes
#cancel abandon
overlay pcache
#proxycache hdb 100000 3 1000 100
proxycache mdb 100000 3 1000 100
pcachePersist TRUE
proxyAttrset 0 mail uid gecos
proxyTemplate (sn=) 0 3600
proxyTemplate (&(sn=)(givenName=)) 0 3600
#cachesize 20
index objectClass eq
index cn,sn,uid,mail pres,eq,sub
pcacheAttrset 0 1.1
pcacheTemplate (&(|(objectClass=))) 0 3600
pcacheTemplate (objectClass=*) 0 3600
pcacheAttrset 1 displayname
pcacheTemplate (objectClass=*) 1 3600
pcacheAttrset 2 memberOf
pcacheTemplate (objectClass=*) 2 3600
conn-ttl 3600
#
directory /var/lib/ldap
Testing the config works:
root@ldap:~# /usr/sbin/slapd -Tt -f /etc/ldap/slapd.conf
config file testing succeeded
62398f56 mdb_opinfo_get: err Permission denied(13)
root@ldap:~#
(I have no idea which Permission is denied)
slapd can be started via
/usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf
ldapsearch works fine using '-h localhost' or '-H
ldap://ldap.DOMAIN.de', so I think the basic config is not bad at all ...
Thanks in advance!
Cheers,
Torsten
