mmr of cn=config with OpenLDAP 2.6
by Stefan Kania
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
1 year, 11 months
Help on building and configuring openLdap V2.6.0
by Stampfl, Burt
Hi, I'm new to OpenLDAP.
Pulled down the current 2.6 release to a Debian target and am having trouble figuring out how to build the backend modules for dynamic use.
What I did:
1. Downloaded openldap-2.6.0.tgz and extracted the source on my Debian target.
2. configured the 'build' via (output indicated it was successful) :
./configure --enable-sql=no --enable-wt=no --enable-spasswd=yes --enable-passwd=yes --enable-perl=yes --enable-crypt=yes --enable-ldap=yes --enable-slapd=yes --enable-ppolicy=yes --enable-otp=yes --enable-auditlog=yes --enable-modules=yes --with-cyrus-sasl=yes
3. ran 'make depend' (output indicated it was successful).
4. ran 'make' (output indicated it was successful).
5. ran the tests via 'env SLAPD_DEBUG=1 make test' (output indicated it was successful).
6. Installed it via 'su root -c 'make install'
I was able to pretty easily get the slapd server running, create a database (mdb) add users, etc, and access via a remote client.
Once I was able to do that I wanted to enable the ppolicy backend/overlay and have not been able to get this to work. Looking online it appears I need some 'backend' modules like back-mdb.la, ppolicy.la, etc and I cannot find them anywhere in my build tree. I had thought the --enable-xxx directives I used in the config step would have forced this to build them, but I guess not.
How do I create these dynamic backend modules and is there any documentation on how to use them in the newer dynamic configuration schema ?
I've attached a file with the output from the steps I performed above.
Thank you
Burt
Burt Stampfl
AMSC (NASDAQ: AMSC)
W231 N2844 Roundy Circle Suite D, Pewaukee, WI 53072 USA
Work: +1 262.901.6007
Mobile: +1 847.638.1792
burt.stampfl(a)amsc.com<mailto:burt.stampfl@amsc.com>
amsc.com<http://www.amsc.com/>
[Description: Description: cid:image001.jpg@01CC890F.E40B1CB0]
"This e-mail message and any attachments are confidential and may be privileged. If you are not the intended recipient please notify AMSC immediately by replying to this message or by sending a message to postmaster(a)amsc.com and destroy all copies of this message and any attachments. Thank you."
1 year, 11 months
Error with slapadd & syncrepl ldif file
by David White
At last, I'm trying to setup a consumer to replicate data off of a primary ldap server running the Symas-provided v2.6 packages on Ubuntu 20.04.
The following links were very helpful to me:
https://openldap-software.0penldap.narkive.com/VEt6vIEI/syncrepl-ldif-kic...
https://www.openldap.org/pub/hyc/LDAPcon2007s.pdf
I have built an ldif file that I'm trying to slapadd. But when the binddn contains anything other than "cn" attributes, slapadd produces an error.
My Question: Why can I not use a binddn that contains anything other than "cn" attributes, like "uid", "dc", or "ou"?
Specific details with debug below:
The following works perfectly fine:
root@ldapconsumer:/opt/symas/etc/openldap# /opt/symas/sbin/slapadd -l /home/myself/ldap/consumer_sync.ldif -F /opt/symas/etc/openldap/slapd.d/ -w -n0
Closing DB..
root@ldapconsumer:/opt/symas/etc/openldap# cat /home/myself/ldap/consumer_sync.ldif
dn: cn=config
objectClass: olcGlobal
cn: config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW: secret
olcSyncRepl: rid=001 provider=ldap://172.16.2.5 binddn="cn=admin,cn=example,cn=com" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"
Alternatively, this works as the binddn:
cn=ldap.sync,cn=example,cn=com
But the following values in the binddn do NOT work:
- binddn=cn=ldap.sync,dc=example,dc=com
- binddn=uid=sync,ou=People,dc=example,dc=com
In either of the examples above that do NOT work, I'm getting an "invalid bind config value" error message. See below for full stdout with 1 example:
root@ldapconsumer:/opt/symas/etc/openldap# /opt/symas/sbin/slapadd -l /home/myself/ldap/consumer_sync.ldif -F /opt/symas/etc/openldap/slapd.d/ -w -n0
invalid bind config value binddn=uid=ldap.sync,ou=People,dc=example,dc=com
olcSyncrepl: value #0: Error: parse_syncrepl_line: unable to parse "binddn=uid=ldap.sync,ou=People,dc=example,dc=com"
.
failed to add syncinfo
slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=5): Error: parse_syncrepl_line: unable to parse "binddn=uid=ldap.sync,ou=People,dc=example,dc=com"
Closing DB...
If I run this with debug enabled, below is what I see (not sure if this will be helpful or not, but am providing it just in case). Password has been redacted of course.
root@ldapconsumer:/opt/symas/etc/openldap# /opt/symas/sbin/slapadd -l /home/myself/ldap/consumer_sync.ldif -F /opt/symas/etc/openldap/slapd.d/ -w -n0 -d -1
slapadd init: initiated tool.
slap_sasl_init: initialized!
backend_startup_one: starting "cn=config"
ldif_read_file: no entry file "/opt/symas/etc/openldap/slapd.d//cn=config.ldif"
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=32 matched="" text=""
>>> dnNormalize: <cn=Subschema>
<<< dnNormalize: <cn=subschema>
matching_rule_use_init
{snip}
slapadd startup: initiated.
backend_startup_one: starting "cn=config"
config_back_db_open
Backend ACL: access to *
by * none
config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context
config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default
=> str2entry: "dn: cn=config
objectClass: olcGlobal
cn: config
"
>>> dnPrettyNormal: <cn=config>
<<< dnPrettyNormal: <cn=config>, <cn=config>
<= str2entry(cn=config) -> 0x5574eedc21b8
oc_check_required entry (cn=config), objectClass "olcGlobal"
oc_check_allowed type "objectClass"
oc_check_allowed type "cn"
oc_check_allowed type "structuralObjectClass"
ldif_write_entry: wrote entry "cn=config"
=> str2entry: "dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW: secret
olcSyncRepl: rid=001 provider=ldap://172.16.2.5 binddn="uid=ldap.sync,ou=People,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5""
>>> dnPrettyNormal: <olcDatabase={0}config,cn=config>
<<< dnPrettyNormal: <olcDatabase={0}config,cn=config>, <olcDatabase={0}config,cn=config>
>>> dnNormalize: <cn=admin,cn=config>
<<< dnNormalize: <cn=admin,cn=config>
<= str2entry(olcDatabase={0}config,cn=config) -> 0x5574eedc2258
oc_check_required entry (olcDatabase={0}config,cn=config), objectClass "olcDatabaseConfig"
oc_check_allowed type "objectClass"
oc_check_allowed type "olcDatabase"
oc_check_allowed type "olcRootDN"
oc_check_allowed type "olcRootPW"
oc_check_allowed type "olcSyncrepl"
oc_check_allowed type "structuralObjectClass"
config_build_entry: "olcDatabase={-1}frontend"
slap_get_csn: conn=-1 op=0 generated new csn=20220106202401.439197Z#000000#000#000000 manage=0
ldif_read_file: read entry file: "/opt/symas/etc/openldap/slapd.d//cn=config.ldif"
=> str2entry: "# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 fd732ca0
dn: cn=config
objectClass: olcGlobal
cn: config
structuralObjectClass: olcGlobalentryUUID: 54643148-037a-103c-8b74-e78e18fa89a5
creatorsName: cn=config
createTimestamp: 20220106202401Z
entryCSN: 20220106202401.438467Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220106202401Z
"
>>> dnPrettyNormal: <cn=config>
<<< dnPrettyNormal: <cn=config>, <cn=config>
>>> dnNormalize: <cn=config>
<<< dnNormalize: <cn=config>
>>> dnNormalize: <cn=config>
<<< dnNormalize: <cn=config>
<= str2entry(cn=config) -> 0x5574eedc22f8
ldif_write_entry: wrote entry "olcDatabase={-1}frontend,cn=config"
>>> dnPrettyNormal: <cn=admin,cn=config>
<<< dnPrettyNormal: <cn=admin,cn=config>, <cn=admin,cn=config>
>>> dnPrettyNormal: <cn=admin,cn=config>
<<< dnPrettyNormal: <cn=admin,cn=config>, <cn=admin,cn=config>
>>> dnNormalize: <uid=ldap.sync,ou=People,dc=example,dc=com>
invalid bind config value binddn=uid=ldap.sync,ou=People,dc=example,dc=com
olcSyncrepl: value #0: Error: parse_syncrepl_line: unable to parse "binddn=uid=ldap.sync,ou=People,dc=example,dc=com"
.
failed to add syncinfo
syncinfo_free: rid=001
slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=5): Error: parse_syncrepl_line: unable to parse "binddn=uid=ldap.sync,ou=People,dc=example,dc=com"
slapadd shutdown: initiatedslapadd destroy: freeing system resources.
Sent with ProtonMail Secure Email.
1 year, 11 months
OpenLDAP's UB minefield
by openldap-technical＠kolttonen.fi
Someone recently wrote on openldap-bugs:
> The kernel recently got bitten using the same pattern of unaligned
> short pointers through casts. GCC produced code which corrupted
> initramfs during unpacking.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100363.
> OpenLDAP should fix that code.
Correct. That's what I said long time ago, too. I wonder if OpenLDAP
projects' delusions about Undefined Behaviour "not being a bug" still
persist, or are they perhaps going to fix their buggy code? What a
minefield to walk on, it can blow up anytime.
I am very happy to not have to administer this server code anymore, but I
sure am scared for those who do.
best regards,
Unto Sten
1 year, 11 months
slapcat & cn=config database
by David White
I'm starting a new thread on a different topic, as my current issue is veering way off topic from my original thread (c/f https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.or... and c/f https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.or...).
Thanks to Ulrich's suggestion to run slapcat -n0 with debug (-d -1). That did indeed get me some more information, but I still cannot pinpoint why slapcat keeps telling me that it "could not open database".
To recap: I'm currently running the Symas-provided openldap package v2.6, and my ultimate goal is to build a push-based proxy with syncrepl. But this thread is about the cn=config database.
As part of my troubleshooting, I found this quite old thread about the different ways to start slapd: https://openldap-technical.openldap.narkive.com/Y1yq9Qd1/can-not-modify-c...
I stopped slapd with:
systemctl stop slapd
I then manually started it like so, in order to force it to use the ldif directory instead of the slapd.conf file:
/opt/symas/lib/slapd -F /var/symas/openldap-data/slapd.d/
This started right up, and I can confirm slapd is running.
I'm able to run a ldapsearch against: -b "cn=config" like so, where we see all of the various databases, frontend, and Overlays configured. I have redacted the password, and changed the domain to "example" in the following stdout. Given this information, I'm still very confused why slapcat can't open the cn=config database for its own processing. Any help on this would be appreciated.
root@ldap-provider:~# ldapsearch -x -LLL -D cn=config -W -s sub -b "cn=config" "(olcDatabase=*)" '*' '+' -v
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
filter: (olcDatabase=*)
requesting: * +
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcLastBind: TRUE
olcLastBindPrecision: 0
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 047a4d82-01dd-103c-8345-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcDatabase={-1}frontend,cn=config
subschemaSubentry: cn=Subschema
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcLastBind: TRUE
olcLastBindPrecision: 0
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcRootPW: secret
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 047a4fda-01dd-103c-8346-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcDatabase={0}config,cn=config
subschemaSubentry: cn=Subschema
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/symas/openldap-data
olcSuffix: dc=example,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcLastBind: TRUE
olcLastBindPrecision: 0
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: secret
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbMaxReaders: 0
olcDbMaxSize: 10485760
olcDbMode: 0600
olcDbSearchStack: 16
olcDbMaxEntrySize: 0
olcDbRtxnSize: 10000
structuralObjectClass: olcMdbConfig
entryUUID: 047a52be-01dd-103c-8347-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcDatabase={1}mdb,cn=config
subschemaSubentry: cn=Subschema
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
structuralObjectClass: olcSyncProvConfig
entryUUID: 047a54da-01dd-103c-8348-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
subschemaSubentry: cn=Subschema
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 5th, 2022 at 9:40 AM, Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
> Hi!
>
> I meant: The debug output is useless when you leave out "-n0" (the case that
>
> doesn't work for you).
>
> > > > David White dmwhite823(a)protonmail.com schrieb am 05.01.2022 um 15:14 in
>
> Nachricht
>
>
>
> qn5VCvnElSb0fkpWltSUlY7hWAU=(a)protonmail.com>:
>
> > That's the thing.
> >
> > -n0 always returns "unknown database".
> >
> > Only -n1 returns data.
> >
> > Thanks for the suggestion, though. :)
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> >
> > On Wednesday, January 5th, 2022 at 8:11 AM, Ulrich Windl
> >
> > Ulrich.Windl(a)rz.uni-regensburg.de wrote:
> >
> > > It seems you missed "-n0" for slapcat.
> >
1 year, 11 months
Guide to setup syncrepl with proxy-based push config
by David White
Hello,
I have some basic experience interacting with & troubleshooting OpenLDAP as well as 389-ds, but I don't have a whole lot of experience setting them up or configuring an OpenLDAP server.
My goal is to setup replication from a Primary inside a trusted network outwards to a Replica that is in an untrusted network, without allowing the replica any direct access to the primary, due to firewall flows and network requirements. This is true even for the initial connection, so a simple RefreshAndPersist configuration won't work.
I have read that it is possible to setup a push-based replication using a proxy, such that:
- The proxy gets installed as a "hidden" database onto the same server as the primary
- The proxy sets up replication with the primary using RefreshAndPersist
- The proxy is then able to push the data out of the replica
I have skimmed over, and re-read, a lot of portions from this document: https://www.openldap.org/doc/admin24/replication.html
I have also followed this basic guide to setup a Primary with replication capability: https://ubuntu.com/server/docs/service-ldap-replication
What I'm having trouble with, is finding a useful guide that will walk me through the process to setup and configure the proxy as I've described above.
Questions:
- Based on my requirements above, will the proxy with syncrepl meet my needs?
- If I put the proxy onto the same server as the primary, then due to firewall flows, the replica will not have any access to the primary. All communication will need to be initiated outbound
- If I put the proxy into the same network as the replica, well.... that won't work either, for the same reason
- The following URL from the OpenLDAP docs provides some example configs: https://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Proxy
- If I'm reading everything correctly, though, the "new" / "accepted" / "preferred" way to configure the ldap server is to use the `ldapadd`, `ldapmodify`, and related commands. My confusion and question here is.... should I try to configure all of this by editing the old slapd.conf file as the openldap.org docs provide examples, or is there a way to do this using the ldapmodify & related commands?
- If I can / should do this from the command line... are there any guides or tutorials that will take me step-by-step through the process as I try to build this in a lab environment?
Thanks in advance,
David
Sent with ProtonMail Secure Email.
1 year, 11 months
Re: [EXT] Re: openldap ppolicy pwdAccountLockedTime
by kevin martin
Hmm, module loaded. I'm not doing a moduleload of anything ppolicy
related, simply setting the overlay ppolicy, the ppolicy_default, and
ppolicy_use_lockout. What's the module to load as I don't find a ppolicy
la file after compiling? Can you point me to a doc that explains the
proper way to use this now?
On Mon, Jan 3, 2022, 10:41 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Monday, January 3, 2022 9:39 AM -0600 kevin martin <ktmdms(a)gmail.com>
>
> wrote:
>
> >
> > In 2.4 I was still pulling in the schema. In 2.5 ppolicy is compiled as
> > part of the code. Assuming it just works, how does one go about setting
> > pwdAccountLockedTime for a user then? I can't add it as an attribute of
> > the user so I'm not sure how it can be set.
>
> If it has been moduleloaded into the slapd process, the ppolicy schema is
> known to slapd and available for use. If you are finding the attribute to
> not be defined it would suggest you've failed to load the module as
> required. I would note that you want to ensure you're running 2.5.8 or
> later (See ITS#9671).
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
1 year, 11 months
A very simple olcAccess rule doesn't work
by Volodymyr Melnyk
Dear colleagues,
There's a question I posted on ServerFault
(https://serverfault.com/questions/1088252/a-very-simple-olcaccess-rule-do...),
but it seems that asking my question in this mailing list would be a
better idea/
So, long story short, I have a domain (let's call it
`dc=example,dc=org`) .
The domain has a branch
(`ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`).
There's a simpleSecurityObject in this domain
(`uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`).
I need the uid=admin,*** user to have full (manage) access to the
ou=users,*** branch, so I added the following olcAccess record: `to
dn.subtree="ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org"
by
dn.exact="uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org"`.
It has added to the default set of rules:
```
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage
by * break
olcAccess: {1}to attrs=userPassword,shadowLastChange by self write by
dn="cn=a dmin,dc=example,dc=org" write by anonymous auth by * none
olcAccess: {2}to * by self read by dn="cn=admin,dc=example,dc=org" write
by * none
olcAccess: {3}to
dn.subtree="ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=
infra,dc=example,dc=org" by
dn.exact="uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org"
manage
```
But something seems to be wrong. When I run `ldapsearch -D
uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org
-W -b
ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`,
I get the following result:
```
# extended LDIF
#
# LDAPv3
# base
<ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org>
with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
# numResponses: 1
command terminated with exit code 32
```
The object is actually available and `cn=admin,dc=example,dc=org` can
see it without any difficulties, so it seems that my access rule is
wrong. But what exactly it is?
It seems that the default rule #2 (`{2} to * by self read by
dn="cn=admin,dc=example,dc=org" write by * none`) fires up earlier than
the rule I added. Does that mean that I should always add my custom
rules before it?
And why does this rule has `by * none`? Doesn't it contradict the
OpenLDAP documentation? "The default access control policy is allow read
by all clients"
(https://www.openldap.org/doc/admin24/access-control.html).
Thank you in advance.
With best regards,
V.Melnyk
1 year, 11 months
openldap ppolicy pwdAccountLockedTime
by kevin martin
it appears from looking at ppolicy.c that pwdAccountLockedTime is not
supported in openlda. is there another way to lock a users account in
openldap outside of simply changing the users password?
---
Regards,
Kevin Martin
1 year, 11 months
