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
>
>
>
>
>>> "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> schrieb am
19.02.2014 um 20:20 in Nachricht
<201402191921.s1JJL9q9079356(a)boole.openldap.org>:
> Thanks Quanah for your reply. It answered a lot of questions.
>
> I took a back step, and slapcat'd all my cn=configs and main_dbase from
> all three servers, then ran slapadd to put each into place. Taking one of
> the cn=configs (using mm-server2's) I modified it for each server pretty much
> based on your suggestions below to set up Syncreplication with mm-server1 as
> the master (right now). When I brought them up, they were replicating (I was
> so happy!) --> any change I made on mm-server1 was immediately replicated over to
> mm-server2 and 3.
>
> I did learn a great deal over the last week or so. Patience being one of
> them. I will forward to you in a separate email my cn=configs.
>
> When running slapadd, I did run into this error (which I resolved -- but am
> curious about) on mm-server1:
>
> First had this (mm-server1):
> 5304e1ff olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow
> slapadd: could not add entry dn=olcDatabase={1}bdb,cn=config (line=2260)
Shouldn't it be like:
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
>
> Resolution: set olcMirrorMode to FALSE (made this change on the other
> servers' ldifs)
>
> This caused an error when, later, running ldapmodify on the main dbase when
> all servers were running slapd.
>
> ldap_modify: server unwilling to perform (53)
> additional info: shadow context: no update referral
>
> Resolution: Removed olcMirrorMode from all ldifs.
>
> Why, even with it set to FALSE, would MirrorMode cause this issue?
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Wednesday, February 19, 2014 2:02 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> Hi John,
>
> SIDs (server IDs) must be unique across servers.
>
> RIDs (replication IDs) must be unique inside a single server.
>
> So the answer to your question is essentially "no".
>
> If you email me your full cn=config db bits from both servers (minus
> passwords), there's some cleanup on them I can send back.
>
> The serverID: 1 <URI> bit is only necessary if you are doing cn=config
> replication, which you are not doing. If you are going to use the <#> <URI>
> form, then the <URI> must EXACTLY MATCH the arguments slapd is being started
> with.
>
> Personally, since I do not do cn=config replication, and the URIs are
> customizable by customers, I go with the much simpler:
>
> olcServerID: <#>
>
> form. Then each server only has a single value for olcServerID, which is
> its specific serverID. This way I never have to worry that MMR replication
> is going to get mesed up because of URI changes.
>
> --Quanah
>
> --On Tuesday, February 18, 2014 10:09 AM -0500 "Borresen, John - 0442 - MITLL"
> <John.Borresen(a)ll.mit.edu> wrote:
>
>> All,
>>
>> The long weekend didn't help...still at a loss. Question...
>>
>> If the olcServerIDs look like, on all three servers:
>>
>> olcServerID: 1 ldap://mm-server1.example.ldap
>> olcServerID: 2 ldap://mm-server2.example.ldap
>> olcServerID: 3 ldap://mm-server3.example.ldap
>>
>> Should the Replica IDs (rid) in the olcSycnrepl directive be:
>>
>> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
>> provider=mm-server2.example.ldap bindmethod=simple
>> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no
>>
>> OR
>>
>> olcSyncrepl: {0} rid=1 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {1} rid=2 provider=mm-server2.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {0} rid=3 provider=mm-server3.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>>
>> OR
>>
>> Does it matter?
>>
>> Also, should the all three olcSycrepl directives be loaded on all
>> three servers so they look identical. What I mean by that is should
>> each Server "replicate" to itself? There is confusion on this matter.
>> I asked Quanah that back in late January, and he stated that the
>> system knows about itself so it knows what to ignore. Then last week,
>> he asked why I had the master replicating to itself.
>>
>> Also, since I have refreshAndPersist configured do I need an interval
>> as well?
>>
>> Thanks in advance,
>>
>> John
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
>> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 4:28 PM
>> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
>> Subject: RE: Syncrepl and mmr
>>
>> All,
>>
>> I just created an mm-server3, using the config_dbase and main_dbase
>> from
>> mm-server2 -- copied the ldif's I created from mm-server2 then ran
>> slapadd.
>>
>> On mm-server3:
>> olcServerID: 1 ldap://mm-server1.example.ldap
>> olcServerID: 2 ldap://mm-server2.example.ldap
>> olcServerID: 3 ldap://mm-server3.example.ldap
>>
>> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
>> provider=mm-server2.example.ldap bindmethod=simple
>> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no
>>
>> Started slapd, no errors. It immediately sync'd up with mm-server1!
>> Changes that I made on mm-server1 days ago which have never replicated
>> over to mm-server2...replicated to mm-server3 immediately on startup.
>>
>> I had not even got around to adding mm-server3 to mm-server1 (or
>> mm-server2) yet.
>>
>> The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show:
>> olcServerID: 1 ldap://mm-server1.example.ldap
>> olcServerID: 2 ldap://mm-server2.example.ldap
>>
>> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
>> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
>> credentials=<password> interval=01:00:00:00
>> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
>> schemachecking=on type=refreshAndPersist retry="60 +"
> filter="(objectClass=*)" attrs=*,+"
>> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
>> provider=mm-server2.example.ldap bindmethod=simple
>> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
>> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
>> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
>> retry="60
>> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>>
>> So...now, I am at even more of a loss. Why would mm-server1 be
>> replicating to mm-server3 and not 2? When the configs are the same
>> between mm-server2 and 3???
>>
>>
>>
>> Thanks in advance...
>> John
>>
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
>> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 1:34 PM
>> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
>> Subject: RE: Syncrepl and mmr
>>
>> All,
>>
>> If I went off the beaten' path...where did I go wrong? (my config and
>> error messages are in a previous posting)
>>
>> Thanks in advance,
>> John
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
>> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 8:40 AM
>> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
>> Subject: RE: Syncrepl and mmr
>>
>> Thanks Quanah,
>>
>> A few weeks back I asked that question (on 1/30):
>>> All Masters in the chain have the olcServerID's and olcSynRepl for
>>> itself and its partner? I can understand having each knowing about
>>> the others but why itself? It's replicating to itself?
>> -You replied
>> -It knows about itself so it knows what to ignore.
>>
>> Even in the Admin Guide is specifies setting it up that way...each
>> server has all the others and itself listed. I was following the
>> procedures delineated in the Admin Guide and in the man-pages
>> (including how I understood what was put out on the board): From the Admin
> Guide:
>> 8.3.3. N-Way Multi-Master
>>
>> For the following example we will be using 3 Master nodes. Keeping in
>> line with test050-syncrepl-multimaster of the OpenLDAP test suite, we
>> will be configuring slapd(8) via cn=config
>>
>> This sets up the config database:
>>
>> dn: cn=config
>> objectClass: olcGlobal
>> cn: config
>> olcServerID: 1
>>
>> dn: olcDatabase={0}config,cn=config
>> objectClass: olcDatabaseConfig
>> olcDatabase: {0}config
>> olcRootPW: secret
>>
>> second and third servers will have a different olcServerID obviously:
>>
>> dn: cn=config
>> objectClass: olcGlobal
>> cn: config
>> olcServerID: 2
>>
>> dn: olcDatabase={0}config,cn=config
>> objectClass: olcDatabaseConfig
>> olcDatabase: {0}config
>> olcRootPW: secret
>>
>> This sets up syncrepl as a provider (since these are all masters):
>>
>> dn: cn=module,cn=config
>> objectClass: olcModuleList
>> cn: module
>> olcModulePath: /usr/local/libexec/openldap
>> olcModuleLoad: syncprov.la
>>
>> Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc.
>> with your actual ldap urls):
>>
>> dn: cn=config
>> changetype: modify
>> replace: olcServerID
>> olcServerID: 1 $URI1
>> olcServerID: 2 $URI2
>> olcServerID: 3 $URI3
>>
>> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
>> changetype: add
>> objectClass: olcOverlayConfig
>> objectClass: olcSyncProvConfig
>> olcOverlay: syncprov
>>
>> dn: olcDatabase={0}config,cn=config
>> changetype: modify
>> add: olcSyncRepl
>> olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config"
>> bindmethod=simple credentials=secret searchbase="cn=config"
>> type=refreshAndPersist retry="5 5 300 5" timeout=1
>> olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config"
>> bindmethod=simple credentials=secret searchbase="cn=config"
>> type=refreshAndPersist retry="5 5 300 5" timeout=1
>> olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config"
>> bindmethod=simple credentials=secret searchbase="cn=config"
>> type=refreshAndPersist retry="5 5 300 5" timeout=1
>> -
>> add: olcMirrorMode
>> olcMirrorMode: TRUE
>>
>> I followed what is put in the Admin Guide, etc...
>>
>> Thanks
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah
>> Gibson-Mount Sent: Thursday, February 13, 2014 1:57 PM
>> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
>> Subject: Re: Syncrepl and mmr
>>
>> --On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442
>> - MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>>
>>> All,
>>
>> Your configuration is very confused. Why do you have the master
>> replicate to itself, for example?
>>
>> --Quanah
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Architect - Server
>> Zimbra, Inc.
>> --------------------
>> Zimbra :: the leader in open source messaging and collaboration
>>
>>
>>
>>
>
>
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
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
