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.)
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
2011/7/4 Cyril Grosjean <cgrosjean(a)janua.fr>:
>
> I have a problem with OpenLDAP 2.4.24 and ApacheDirectoryStudio 1.5.3.
> I connect to OpenLDAP with a usual user account for who pwdReset is set to
> TRUE.
> And I have the following default password policy:
>
> dn: cn=default,ou=policies,dc=.....
> cn: default
> objectClass: top
> objectClass: person
> objectClass: pwdPolicy
> pwdAllowUserChange: TRUE
> pwdAttribute: userPassword
> pwdCheckQuality: 2
> pwdExpireWarning: 0
> pwdFailureCountInterval: 0
> pwdGraceAuthNLimit: 0
> pwdInHistory: 0
> pwdMaxAge: 0
> pwdMaxFailure: 0
> pwdMinAge: 0
> pwdMinLength: 8
> pwdMustChange: TRUE
> pwdSafeModify: FALSE
> sn: policy
>
> When opening the connection, I see the following messages in the
> ApacheDirectoryStudio logs window:
>
> #!SEARCH RESULT DONE (95) ERROR
> #!CONNECTION ldap://rhvtq:389
> #!DATE 2011-07-04T13:55:42.026
> #!ERROR [LDAP: error code 50 - Operations are restricted to
> bind/unbind/abandon/StartTLS/modify password]
> # numEntries : 0
>
> I can see the Root DSE entry and I can not browse the DIT, but I don't have
> any popup to explain me that the
> user account I use to connect must change his password.
>
> In the OpenLDAP access log, I see the following:
>
> SRCH base="" scope=0 deref=3 filter="(objectClass=*)"
> Jul 4 13:55:42 rhvtq slapd[19581]: conn=1075 op=1 SRCH
> attr=subschemaSubentry
> Jul 4 13:55:42 rhvtq slapd[19581]: conn=1075 op=1 SEARCH RESULT tag=101
> err=0 nentries=1 text=
>
>
> When testing against a Sun Directory Server 6 with the same data and the
> same password policy, I get a popup window
> on the client side, with the following error, when I try to see the root DSE
> entry :
>
> [LDAP: error code 53 - Password was reset and must be changed.]
>
> In the Sun DS access log, I have the following:
>
> SRCH base="" scope=0 filter="(objectClass=*)" attrs="subschemaSubentry"
> [04/Jul/2011:14:17:53 +0200] conn=51 op=1 msgId=2 - RESULT err=53 tag=101
> nentries=0 etime=0, Password was reset and must be changed.
>
> Of course, in both cases, the access control rules are the same and allow
> access to the root DSE entry at least.
>
> Also, when testing against OpenLDAP with an ldapsearch client with the "-e
> ppolicy " option, I get the following result:
>
> ldap_bind: Success (0); Password must be changed
> Insufficient access (50)
> Additional information: Operations are restricted to
> bind/unbind/abandon/StartTLS/modify password
>
>
> Is there a way I can configure OpenLDAP or my data to get the same behaviour
> with ApacheDirectoryStudio ? That is, I'd like
> to be clearly notified the user password must be changed. Since I get a 50
> error code, has something to be changed in the OpenLDAP access control
> rules ?
>
> If you think it's a client side problem, when using my own custom client
> applications, what request(s) must be sent to OpenLDAP ?
>
Hi Cyril,
password policy is very implementation specific. I noticed also some
differences between OpenLDAP and SUN implementation. For example, when
using password policy and doing a wrong authentication, OpenLDAP sends
the password policy control back with the bind response (with error
49), and SUN do not (it only send back the bind response without
ppolicy control).
For your problem, you need to manage it on client side : if you use
the password policy control, both OpenLDAP and SUN will return back
the password policy control with the flag "password must be reset",
the only difference is that the main error code is not the same (50
for OpenLDAP, 53 for SUN). Just test the ppolicy control in this case.
Clément.
>>> William Brown <wibrown(a)redhat.com> schrieb am 17.11.2017 um 06:31 in Nachricht
<1510896691.4395.140.camel(a)redhat.com>:
> On Thu, 2017-11-16 at 21:25 -0800, Quanah Gibson-Mount wrote:
>> --On Friday, November 17, 2017 12:53 PM +1000 William Brown
>> <wibrown(a)redhat.com> wrote:
>>
>> Hi William,
>>
>> > Hey mate,
>> >
>> > Just want to point out there are some security risks with ssf
>> > settings.
>> > I have documented these here:
>> >
>> > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht
>> > ml
>> >
>> > This is a flaw in the ldap protocol and can never be resolved
>> > without
>> > breaking the standard. The issue is that by the time the ssf check
>> > is
>> > done, you have already cleartexted sensitive material.
>>
>> I think what you mean is: There is no way with startTLS to prevent
>> possible
>> leakage of credentials when using simple binds. ;) Your blog
>> certainly
>> covers this concept well, but just wanted to be very clear on what
>> the
>> actual issue is. ;) I've been rather unhappy about this for a long
>> time as
>> well, and have had a discussion going on the openldap-devel list
>> about
>> LDAPv4 and breaking backwards compatibility to fix this protocol bug.
>
> Absolutely. I think it's just better to say look, expect leakage. Do it
> right, once, and guarantee your behaviours. It's not just simple bind
> though,
>
> An example here though, is because of how minssf works, we have to
> accept anonymous binds on ssf=0, because we expect starttls next - even
> then, you can leak things like "search mail=secret@secret". If they
> don't want to leak phone numbers, mail etc. So we have a dataleak in
> the form of the query, before the ssf check can reject our request.
>
> Sure, we aren't leaking entries, but we shouldn't leak *anything* if we
> are in this kind of environment,
Hi!
BTW: Does anyone know the backgraound of SUSE Linux Enterprise Server (SLES) moving from OpenLDAP to Redhat's directory server in ist next release?
Regards,
Ulrich
>
> Again coming back to LDAPS is the only way to really guarantee this
> connection is truly encrypted from the first byte to the last :)
>
>>
>> Another note -- The reason GSSAPI shows up as an SSF of 56 is because
>> it
>> has been hard coded that way in cyrus-sasl. Starting with cyrus-
>> sasl
>> version 2.1.27, which is near release, the actual SASL SSF is
>> finally
>> passed back into the caller. It may be worthwhile noting this in
>> your blog
>> post. ;)
>
> Yeah, the krb devs told me about this change recently, I should go and
> update this :) I've just been busy lately :)
>
> Thanks mate,
>
>>
>> Warm regards,
>> Quanah
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Product Architect
>> Symas Corporation
>> Packaged, certified, and supported LDAP solutions powered by
>> OpenLDAP:
>> <http://www.symas.com>
>>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
Am 14.04.2010 09:36, schrieb Götz Reinicke - IT-Koordinator:
> Dieter Kluenter schrieb:
>
>> Götz Reinicke - IT-Koordinator<goetz.reinicke(a)filmakademie.de> writes:
>>
>>
>>> Hi folks,
>>>
>> [...]
>>
>>> My consumer server should bind to the provider using sasl with the
>>> saslmech external. (Red Hat 5.x, cyrus-sasl-2.1.22, openldap-2.3.43-3 )
>>>
>>> I'v changed the slapd.conf files on both servers:
>>>
>>> consumer:
>>>
>>> syncrepl ...
>>> bindmethod=sasl
>>> saslmech=EXTERNAL
>>> starttls=yes
>>>
>>> provider:
>>>
>>> authz-regexp
>>> "dn=email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it
>>> officenet,o=filmakademie baden-wuerttemberg
>>> gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de"
>>> "cn=replicator,dc=filmakademie,dc=de"
>>>
from first sight, looks like wrong authz-regexp:
dn=email= ....
>>> after restarting both servers I do get the error:
>>>
>>> <==slap_sasl2dn: Converted SASL name to<nothing>
>>> SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such
>>> file or directory
>>>
>> [...]
>>
>> I don't see a configuration for client certs, as an example I provide
>> my slapd.conf
>>
>> syncrepl rid=042
>> provider=ldap://rubin.avci.de
>> sizelimit=unlimited
>> bindmethod=sasl
>> saslmech=external
>> starttls=yes
>> tls_cert=/etc/openldap/certs/replicator.pem
>> tls_key=/etc/openldap/certs/replicator-key.pem
>> tls_cacert=/etc/openldap/certs/avciCA.pem
>> tls_reqcert=demand
>> searchbase="o=avci,c=de"
>> scope=sub
>> [...]
>>
>
> Hi Dieter,
>
> it looks like I still have some misunderstanding of where to set some
> options after following my manual.... Maybe your book is better ;-)
>
> I added the tls_* options to my consumer slapd.conf and started both
> servers again. Now I still get messages on the provider which confuse
> me, in particular the line "Converted SASL name to<nothing>"
>
> do_sasl_bind: dn (cn=replicator,dc=filmakademie,dc=de) mech EXTERNAL
>
> ==>slap_sasl2dn: converting SASL name
> email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it
> officenet,o=filmakademie baden-wuerttemberg
> gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de to a DN
>
> slap_authz_regexp: converting SASL name
> email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it
> officenet,o=filmakademie baden-wuerttemberg
> gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de
>
> <==slap_sasl2dn: Converted SASL name to<nothing>
>
> SASL Authorize [conn=0]: proxy authorization allowed authzDN=""
> send_ldap_sasl: err=0 len=-1
> do_bind: SASL/EXTERNAL bind:
> dn="email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it
> officenet,o=filmakademie baden-wuerttemberg
> gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de" sasl_ssf=0
>
>
> Any suggestions? Thanks for your response,
>
> /Götz
>
>
Hello, all.
I have an instance of OpenLDAP in which I use groups to manage access
controls, similar to the way the FAQ and admin guide describe it.
My DIT layout:
uid=userildr1,ou=people,o=gdAA,dc=example,dc=com
uid=userildr2,ou=people,o=gdAA,dc=example,dc=com
...
cn=readINT,ou=groups,o=gdAA,dc=example,dc=com
cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com
cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com
...
ou=people,o=INT,dc=example,dc=com
...
ou=groups,o=INT,dc=example,dc=com
Outside of the DIT, my slapd.conf file (yes, I know) contains:
access to dn.sub="o=INT,dc=example,dc=com"
by self write
by group/groupOfUniqueNames/uniqueMember="cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com" write
by group/groupOfUniqueNames/uniqueMember="cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com" write
by group/groupOfUniqueNames/uniqueMember="cn=readINT,ou=groups,o=gdAA,dc=example,dc=com" read
The uid=userildr1,ou=people,o=gdAA,dc=example,dc=com entry is in the readINT
group yet seems unable to run a search. I get an error 50 ("Operations are
restricted to bind/unbind/abandon/StartTLS/modify password") and cannot
figure out why this is happening. If anyone can tell me what's going on,
I would appreciate it.
I'm seeing "config_back_db_open: line 0: warning: cannot assess the validity of
the ACL scope within backend naming context" in the log files but this looks
harmless.
This is OpenLDAP 2.5.14 running on RHEL 8, with the LTB packages.
Logs and the configuration file are available if necessary.
Emmanuel
--On Monday, November 2, 2020 9:32 PM +0000 "Heinemann, Peter G"
<phei(a)isc.upenn.edu> wrote:
>
> Good Day,
>
>
> Working on moving from RHEL6 to RHEL8. Given the drop in support for
> openldap in RHEL8 I've installed the symas-openldap distros.
Hi Peter,
You haven't provided any configuration information, so that makes it
difficult to assist. I would note that TLS works just fine for me with
RHEL8 and the 2.4.55 packages.
First, with startTLS:
ldapsearch -LLL -ZZ -x -H ldap://127.0.0.1
No such object (32)
Second, with 636:
ldapsearch -LLL -x -H ldaps://127.0.0.1:636
No such object (32)
openssl version
OpenSSL 1.1.1c FIPS 28 May 2019
nmap --script ssl-enum-ciphers -p 636 localhost -Pn
Starting Nmap 7.70 ( https://nmap.org ) at 2020-11-02 23:51 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE
636/tcp open ldapssl
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 4096) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 4096) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Key exchange (secp256r1) of lower strength than certificate key
|_ least strength: A
Nmap done: 1 IP address (1 host up) scanned in 0.78 seconds
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
This feels like a lame question, but I'm out of ideas, so...
I'm moving samba service between a couple of FreeBSD systems (9.3 to
10.2), and I'm stuck on getting samba on the new machine to connect to
our openldap server over ssl - frustrating since I've been running
samba+ldap for 15 years or so; feel sure I'm missing something basic!
The smbd-to-ldap connection works fine with no encryption, but I get
errors when using either TLS to port 389 ("Failed to issue the StartTLS
instruction: Connect error") or SSL to 636.
However I'm pretty certain it's not a certificate or CA validation
issue. All my other ldap clients on that server are working as expected,
including a simple "ldapsearch -ZZ". Both openssl s_client and
gnutls-cli show the ldap server certificate validating.
Maximum debugging on the ldap server gave me:
connection_read(3): TLS accept failure error=-1 id=1042, closing
conn=1042 fd=3 closed (TLS negotiation failure)
Running smbd under gbd shows ldap_start_tls_s (ldap_struct, NULL, NULL)
in smb_ldap_start_tls is returning -11 (LDAP_CONNECT_ERROR). That
doesn't give me any ideas, sadly!
Capturing the packet exchange between smbd and slapd, I'm seeing the
(smbd) client sends a "decrypt error" (TLS alert code 51) to the ldap
server after receiving the certificate, while the working "ldapsearch
-ZZ" moves on to client key exchange etc.
Besides all my other ldap clients working successfully, I think I'd
expect to see a TLS alert more like 42-48 if it were a cert validation
problem.
I'm not sure where to try looking next for the cause, would welcome any
suggestions...
Thanks, Graham
Am Fri, 19 Feb 2016 09:19:28 +0100
schrieb Michael Ströder <michael(a)stroeder.com>:
> Dieter Klünter wrote:
> > Am Thu, 18 Feb 2016 22:20:16 -0700
> >> Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from
> >> IP=10.1.10.12:55750 (IP=0.0.0.0:389) Feb 18 22:19:04 baneling
> >> slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18
> >> 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS Feb 18
> >> 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0
> >> text= Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS
> >> established tls_ssf=256 ssf=256
> > [...]
> >
> > You still have a overall security ssf=256 and it seems your TLS
> > session used a key length lower than 256 bit, check your TLS
> > configuration.
>
> Dieter, the log lines say: tls_ssf=256
>
> => TLS seems to be ok.
might be, but I think that security strength factor is just a
requirement for a given session, but doesn't say anything about
configured and used ciphers.
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
