Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote:
>
> Try fixing the RIDs - use small numbers, all different. The exact values are not important.
> Also try commenting out the second syncrepl clause until you have the others working properly.
> You should be able to merge the first and second clauses as they share a search-base.
I did both of them, now slave configuration looks this way:
---[ slave configuration quotation start ]----------------------------
syncrepl rid=0
provider=ldap://master.example:389
starttls=critical
searchbase="ou=ABC,ou=Sendmail,dc=example"
bindmethod=simple
binddn="uid=replABC,ou=repl,dc=example"
credentials="***"
tls_cacert=/usr/local/etc/openldap/ssl/ca.crt
tls_cert=/usr/local/etc/openldap/ssl/ABC.crt
tls_key=/usr/local/etc/openldap/ssl/ABC.key
tls_reqcert=try
type=refreshAndPersist
retry="60 +"
logbase="cn=example-accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
syncrepl rid=1
provider=ldap://master.example:389
starttls=critical
searchbase="ou=People,dc=example"
bindmethod=simple
binddn="uid=replABC,ou=repl,dc=example"
credentials="***"
filter="(&(objectClass=authorizedServiceObject)(|(authorizedService=mail@foo.bar)(authorizedService=xmpp@foo.bar)))"
attrs="cn,entry,entryCSN,entryUUID,o,uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,userPassword,creatorsName,createTimestamp,modifiersName,modifyTimestamp,mail,rfc822MailMember,sn,authorizedService,mu-mailBox"
tls_cacert=/usr/local/etc/openldap/ssl/ca.crt
tls_cert=/usr/local/etc/openldap/ssl/ABC.crt
tls_key=/usr/local/etc/openldap/ssl/ABC.key
tls_reqcert=try
type=refreshAndPersist
retry="60 +"
logbase="cn=example-accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
---[ slave configuration quotation end ]----------------------------
I separated rid-s and even searchbases, but I still can see complains in
slapd.log file, though now it is only rid=0 which is complained on, not
both of them ...
---[ slave slapd.log quotation start ]--------------------------------
Jun 29 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jun 29 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 (53) Server is unwilling to perform
Jun 29 22:45:30 ABC slapd[12593]: do_syncrepl: rid=000 rc -2 retrying
---[ slave slapd.log quotation end ]--------------------------------
>
> You may also need to put ACLs on the accesslog database.
>
is it something like this?
access to dn.children="cn=example-accesslog"
by dn.children="ou=repl,dc=example" read
by * break
but is not the fact that one replica working confirms, that replication is allowed
and I can see the changes for the objects of rid=1
--
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
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,
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
Hi Ben, Dieter
can we focus on LDAPS because TLS1 is not an option and even if LDAPS is deprecated I should be able to configure it ..
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt
TLSCertificateFile /etc/openldap/ssl/VordelDev.crt
TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key
TLSVerifyClient never
are this entries in the slapd.conf sutable for LDAPS ?
if not whats missing ?
start the server with
/usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
thanks a lot
Axel
AXEL GROSSE
Principal Solution Architect, Sales Solution Center, Axway
P: +61-405-995-768
828 Pacific Highway
Gordon, 2072 NSW
agrosse(a)axway.com
http://www.axway.com
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter
Sent: Thursday, 3 October 2013 6:46 PM
To: openldap-technical(a)openldap.org
Subject: Re: Openldap server with TLS not working
Am Thu, 3 Oct 2013 00:16:28 +0000
schrieb Axel Grosse <agrosse(a)axway.com>:
> Hi ben,
> thanks for the comment.
> agree with you on TLS usage should be perferred
> but the client that is connecting is only capable of LDAPS ... he has
> not implemented TLS Client jet .
>
> But can you please take a look to the error I am facing
>
> openssl s_client -connect 192.168.30.169:389 -showcerts
> -CAfile ./ssl/VordelCA.crt CONNECTED(00000003)
> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:188:
>
> any idea what can cause this ?
>
>
> AXEL GROSSE
> Principal Solution Architect, Sales Solution Center, Axway
> P: +61-405-995-768
> 828 Pacific Highway
> Gordon, 2072 NSW
> agrosse(a)axway.com
> http://www.axway.com
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb
> Sent: Wednesday, 2 October 2013 10:57 PM To:
> openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS
> not working
>
> On 2013.10.02 07.29, Axel Grosse wrote:
>
> > when I test on the server itself ..
> > openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile
> > ./ssl/VordelCA.crt
> > CONNECTED(00000003)
> > 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> > failure:s23_lib.c:188:
>
> ldaps [port 636] is deprecated. use starttls with the standard port
> [389]. to test, just use ldapsearch [see the reference to -Z in the
> man page]
You are connnecting to port 389, but s_client is not able to initiate a
LDAP startTLS session (only SMTP and IMAP), so you have to connect
ldaps and port 636.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
Anyone?
Siddharth Choure
Senior Systems Engineer
On 11/22/13, 4:15 PM, "Choure, Sidd" <schoure(a)apartments.com> wrote:
>Everything is setup on RHEL 6.4 with Openldap 2.4.
>
>I have one provider and one consumer. StartTLS has been enabled and
>everything is working as intended. My only problem arises here -
>When a user is setup with a password and he tries to change his password
>on a consumer pointing client, I get a passwd: Authentication token
>manipulation error. This message is misleading since the password is in
>fact changed on the provider ( I have the olcUpdateRef directive setup).
>This creates a situation where the user can login to consumer pointed
>boxes with his old password and provider pointed boxes with his new
>password. If the user tries to change his password for the second time on
>consumer pointed boxes, I get Password change failed. Server message:
>unwilling to verify old password passwd: Authentication token
>manipulation error which understandably is because the password in the
>actual LDAP db is different from what is being supplied and being
>accepted by the client. What is going on here? Why isn¹t the password not
>getting updated properly in the consumer?
>
>Here are some of the relevant snippets of configs -
>For Syncrepl in olcDatabase={2}bdb.ldif on consumer
>
>
>###For Replication
>
>olcSyncrepl: rid=100
>
> provider="ldap://server.com
>
> type=refreshAndPersist
>
> retry="60 30 300 +"
>
> searchbase=³dc=ex,dc=example,dc=com"
>
> bindmethod=simple
>
> binddn="cn=Manager,dc=ex,dc=example,dc=com"
>
> credentials=secret
>
> starttls=yes
>
> tls_cacert=/etc/pki/CA/cacert.pem
>
> tls_cert=/etc/pki/tls/certs/cert.pem
>
> tls_key=/etc/pki/tls/certs/key.pem
>
>olcUpdateRef: ldap://server.com
>
>
>ACL on provider -
>
>lcAccess: to attrs=userPassword
>
> by self write
>
> by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
>
> by anonymous auth
>
> by * none
>
>olcAccess: to *
>
> by self write
>
> by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
>
> by users read
>
>olcAccess: to attrs=entry
>
> by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
>
> by * read
>
>
>
>Let me know if any more configs are needed and I will post them. Any help
>is appreciated.
>
>Siddharth Choure
>Senior Systems Engineer
>
>
>
>
Hi to all,
is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it
running with 4 server.
I'm installing all 4 server with Ansible so I created a basic configuration:
------------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: sync
olcLogLevel: stats
olcPidFile: /var/symas/run/slapd.pid
olcArgsFile: /var/symas/run/slapd.args
olcToolThreads: 1
olcServerID: 4
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# Read all needed schema from variable in default/main.yml
include: file:///opt/symas/etc/openldap/schema/core.ldif
include: file:///opt/symas/etc/openldap/schema/cosine.ldif
include: file:///opt/symas/etc/openldap/schema/nis.ldif
include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif
include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif
include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif
# Read all modules from variable in default/main.yml
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /opt/symas/lib/openldap
olcModuleLoad: back_mdb
olcModuleLoad: back_monitor
olcModuleLoad: autoca.la
olcModuleLoad: otp.la
olcModuleLoad: argon2.la
olcModuleLoad: syncprov
olcModuleLoad: back_monitor
olcModuleLoad: accesslog.la
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcSizeLimit: 500
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by * break
olcAccess: {1}to dn="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
olcPasswordHash: {ARGON2}
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
by * break
dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to dn.subtree="cn=monitor"
by dn.exact=cn=admin,cn=config read
by dn.exact=cn=admin,dc=example,dc=net read
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcmdbConfig
olcDatabase: {2}mdb
olcSuffix: dc=example,dc=net
olcRootDN: cn=admin,dc=example,dc=net
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcSizeLimit: unlimited
olcTimeLimit: unlimited
olcDbCheckpoint: 512 30
olcDbDirectory: /var/symas/openldap-data
olcDbIndex: default eq
olcDbIndex: objectClass
olcDbIndex: entryUUID
olcDbIndex: entryCSN
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: description pres,eq,sub
olcDbIndex: title pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbMaxSize: 85899345920
olcAccess: {0} to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read
by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
olcAccess: {3} to attrs=userPassword
by anonymous auth by self write by * none
olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net"
time=unlimited
size=unlimited
olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net"
time=unlimited
size=unlimited
------------------
The "ServerID" is different for every server, every thing else is
identical.
Then I created a file to change the serverID:
------------------
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://ldap01.example.net
olcServerID: 2 ldap://ldap02.example.net
olcServerID: 3 ldap://ldap03.example.net
olcServerID: 4 ldap://ldap04.example.net
------------------
and a file to configure the replication:
------------------
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=1
provider=ldap://ldap01.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=2
provider=ldap://ldap02.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=3
provider=ldap://ldap03.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=4
provider=ldap://ldap04.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
-
add: olcMirrorMode
olcMirrorMode: TRUE
------------------
When I configure the server via Ansible (everything in one playbook) the
replication of cn=config is not working. When I only do the basic
configuration via Ansible and then add the change of serverID and then
the replication of cn=config step by step on every single server:
-------------
ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif
ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif
-------------
everything is fine. The two files "serverid.ldif" and "repl_config.ldif"
are the files Ansible created, so the content of the file is the same.
Can it be, that the problem is because Ansible first sets all the
ServerIDs on all servers and then configure the replication of cn=config
on all servers?
For setting up the configuration I took:
https://www.openldap.org/devel/admin/replication.html
Starting at 18.3.3
What I don't understand: Do I realy have to put all Servers in the
replication, even the server it self? So do I realy have to add on
Server-01, the Server "server-01, server-02, server-03 ,server-04" to
the replication? Dosn't it mean that server-01 is replicating to it
self? If it's correct, can someone explain why? O did I understud
something wrong on the webpage?
Stefan
Thanks Rich,
> You should make sure the openldap-debuginfo
On track : I rolled back to simple bindmethod at this
stage and have created a dedicated proxyuser for
replication.
Once I can get this package (internal procedures...),
I'll check and come back on that issue.
Thanks,
---
Olivier
On Fri, Aug 12, 2011 at 4:14 PM, Rich Megginson
<rich.megginson(a)gmail.com> wrote:
> On 08/12/2011 07:17 AM, Olivier wrote:
>>
>> My N-WAY replication works properly with a
>> "bindmethod=simple".
>>
>> However, I don't like keeping a password in clear in
>> a configuration file, then I tryed this :
>>
>> On server "ldap-master1.example.fr" :
>>
>> TLSVerifyClient allow
>>
>> syncrepl rid=101
>> provider=ldap://ldap-master2.example.fr:389
>> searchbase="dc=example,dc=fr"
>> schemachecking=on
>> type=refreshOnly
>> interval=00:00:01:00
>> retry="10 +"
>> bindmethod=sasl
>> saslmech=EXTERNAL
>> starttls=critical
>> tls_cert=/etc/openldap/cacerts/master1/server.crt
>> tls_key=/etc/openldap/cacerts/master1/server.key
>> tls_cacert=/etc/openldap/cacerts/CA.crt
>> tls_reqcert=demand
>>
>> On server "ldap-master2.example.fr" :
>>
>> TLSVerifyClient allow
>>
>> syncrepl rid=201
>> provider=ldap://ldap-master1.example.fr:389
>> searchbase="dc=example,dc=fr"
>> schemachecking=on
>> type=refreshOnly
>> interval=00:00:01:00
>> retry="10 +"
>> bindmethod=sasl
>> saslmech=EXTERNAL
>> starttls=critical
>> tls_cert=/etc/openldap/cacerts/master2/server.crt
>> tls_key=/etc/openldap/cacerts/master2/server.key
>> tls_cacert=/etc/openldap/cacerts/CA.crt
>>
>> I get a segmentation fault :
>>
>> ldap-master1 #$ /usr/sbin/slapd -h ldap:/// -u ldap -d256
>>
>> @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $
>>
>> mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
>> bdb_monitor_db_open: monitoring disabled; configure monitor database to
>> enable
>> <= bdb_inequality_candidates: (entryCSN) not indexed
>> slapd starting
>> slap_client_connect: URI=ldap://ldap-master2.example.fr:389 Error,
>> ldap_start_tls failed (-1)
>> do_syncrepl: rid=101 rc -1 retrying
>> conn=1000 fd=12 ACCEPT from IP=10.1.92.25:47353 (IP=0.0.0.0:389)
>> conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>> conn=1000 op=0 STARTTLS
>> conn=1000 op=0 RESULT oid= err=0 text=
>> conn=1000 fd=12 TLS established tls_ssf=256 ssf=256
>> conn=1000 op=1 BIND dn="" method=163
>> conn=1000 op=1 BIND
>>
>> authcid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr"
>>
>> authzid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr"
>> conn=1000 op=1 BIND
>>
>> dn="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr"
>> mech=EXTERNAL sasl_ssf=0 ssf=256
>> conn=1000 op=1 RESULT tag=97 err=0 text=
>> conn=1000 op=2 SRCH base="dc=example,dc=fr" scope=2 deref=0
>> filter="(objectClass=*)"
>> conn=1000 op=2 SRCH attr=* +
>> conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
>> conn=1000 op=3 UNBIND
>> conn=1000 fd=12 closed
>> Erreur de segmentation
>>
>> The segfault happened when the second server tried to sync with the first
>> one :
>>
>> [root@ldap-master2 cacerts]# /usr/sbin/slapd -h ldap:/// -u ldap -d256
>> @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $
>>
>> mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
>> bdb_monitor_db_open: monitoring disabled; configure monitor database to
>> enable
>> slapd starting
>> conn=1000 fd=12 ACCEPT from IP=10.1.92.24:55208 (IP=0.0.0.0:389)
>> conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>> conn=1000 op=0 STARTTLS
>> conn=1000 op=0 RESULT oid= err=0 text=
>> TLS: error: accept - force handshake failure: errno 2 - moznss error -5938
>> TLS: can't accept: TLS error -5938:Encountered end of file.
>> conn=1000 fd=12 closed (TLS negotiation failure)
>> ^C
>> daemon: shutdown requested and initiated.
>> slapd shutdown: waiting for 0 operations/tasks to finish
>> slapd stopped.
>>
>> Any idea ?
>
> Can you get a core file and a stack trace from the server that gets the seg
> fault?
> I'm assuming from the build that you are running on Fedora 14 or later, or
> RHEL6.1. You should make sure the openldap-debuginfo package is installed
> (e.g. debuginfo-install openldap) and install abrt. This will collect the
> core files in /var/spool/abrt
>>
>> NOTE : if I start the daemon on ldap-master2, that's ldap-master2 that
>> produce the seg fault.
>>
>> ---
>> Olivier
>>
>
>
> But here's an example for cn-config, you'd probably have to adjust for
your own environment.
> dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcRemoteAuthCfg
> olcOverlay: {6}remoteauth
> olcRemoteAuthTLS: starttls=yes tls_reqcert=never
>olcRemoteAuthMapping: default ldaps://ad.example.com:636
> olcRemoteAuthDNAttribute: seeAlso
> olcRemoteAuthDomainAttribute: maildrop
> olcRemoteAuthDefaultDomain: default
> olcRemoteAuthDefaultRealm: ldaps://ad.example.com:636
> olcRemoteAuthStore: FALSE
> olcRemoteAuthRetryCount: 3
I tried loading the example below as a remoteauth.ldif file but I got the
following errors. Guessing the DN is wrong here?
67ac865a.098ae3bb 0x7eff0a2166c0 connection_input: conn=1005 deferring
operation: binding
67ac865a.098c174e 0x7eff0aa176c0 conn=1005 op=1 ADD
dn="olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config"
67ac865a.098cea57 0x7eff0aa176c0 conn=1005 op=1 RESULT tag=105 err=21
qtime=0.000066 etime=0.000133 text=objectClass: value #1 invalid per syntax
ldap_add: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax
67ac865a.098d6d29 0x7eff0a2166c0 conn=1005 op=2 UNBIND
adding new entry "olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config"
Thanks
I've been using the Symas OpenLDAP debian packages, and following the
Quick-Start guide for 2.5:
https://www.openldap.org/doc/admin25/quickstart.html
Following steps 1 - 10 has been straight forward, but when I get to step 11
(Add initial entries to your directory), I run into trouble when running
the ldapadd command:
root@openldap-x:/opt/symas/etc/openldap# ldapadd -x -D
"cn=Manager,dc=example,dc=com" -W -f bootstrap.ldif
Enter LDAP Password:
ldap_bind: Confidentiality required (13)
additional info: confidentiality required
root@openldap-x:/opt/symas/etc/openldap#
I used the provided slapd.ldif.default to seed the cn=config (updating it
with the appropriate domain components), as per the instructions in the
Quick-Start, so slapd isn't yet configured to run with ssl or starttls. Is
there a default SSF factor that I should adjust to get past this
bootstrapping failure? I don't see anything like that explicitly set in the
configs that were rendered into /opt/symas/etc/openldap/slapd.d, from my
slapd.ldif.
I'm not new to openldap, but this is the first time I've used the Symas
packages and also the first time trying to use olc instead of a slapd.conf
based configuration.
Ben
On 10/20/21 09:43, Bastian Tweddell wrote:
> On 19Oct21 18:17+0200, Michael Ströder wrote:
>> Find below ae-slapd.service generated by Æ-DIR's ansible role.
>
>> PIDFile=/run/ae-dir/slapd/slapd.pid
>
> still need a pidfile?
Probably not.
(I'm also following the current discussion on systemd-devel list.)
>> ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 7 -f
>> /opt/ae-dir/etc/openldap/slapd.conf -h
>> 'ldapi://%%2Frun%%2Fae-dir%%2Fslapd%%2Fldapi/????x-mod=0777 ldap://*:389
>> ldaps://*:636' -o slp=off
>
> listening plaintext on all interfaces might be discouraged.
But using StartTLS has to be possible. Æ-DIR does not allow any
clear-text connections because slapd.conf contains:
security ssf=128
>> LimitNOFILE=96
>
> this could be too low, depending on use case. it limits nr of incoming
> connections.
Yes, a deliberately slow test value, see my other answer.
Ciao, Michael.
On Mon, 28 May 2012, Michael Ströder wrote:
> Peter Marschall wrote:
> > how do the openldap tools technically verfify certificates with ldapi:// ?
>
> Which certs do you want to verify?
I assume the answer is "the one the server returns when you do StartTLS on
the ldapi:// connection".
It's pretty unusual to do that, of course. The normal solution for
authenticating the server in the ldapi case is to put the socket somewhere
that only the trusted user can write to, so you know that the socket you
connected to is trusted.
If that's not a sufficient option, and verifying certs is required, then
it appears the code will treat the socket path as the hostname to verify
for. For OpenSSL, for example, that means it'll compare it against any
DNS: subjectAltNames as well as against the last CN component of the cert
subject.
(A related question is what slapd will use as your authentication id for
SASL EXTERNAL if you do TLS with a client cert on an ldapi socket: will it
use the cert's subject or the "gidNumber=%d+uidNumber=%d,...etc" DN of the
ldapi connection. The former seems like the obvious choice, being the
"more recent" of the two in this case, and a quick look at the slapd code
would seem to confirm that...but I would test it before designing a system
to depend on it...)
Philip Guenther
