Re: Problem with "force user to password reset at first login
by Rajagopal Rc
Hi Prajith,
Please find the details,
1) let us know the client application are you using.
Apache Directory Studio, Version: 2.0.0.v20150606-M9
2) Paste here your slapd.conf file.
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema
#include /usr/share/doc/openssh-ldap-6.4p1/openssh-lpk-openldap.schema
# Added for policy
include /etc/openldap/schema/ppolicy.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib64/openldap
# Modules available in openldap-servers-overlays RPM package
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
moduleload ppolicy.la
moduleload syncprov.la
moduleload accesslog.la
moduleload auditlog.la
#logging level
loglevel -1
logfile /var/log/slapd.log
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
#TLSCipherSuite
SECURE256:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC
TLSProtocolMin 3.2
TLSCipherSuite HIGH:MEDIUM:+TLSv1.2:!RC4
TLSCertificateFile /etc/openldap/cacerts/ldapsrv.crt
TLSCertificateKeyFile /etc/openldap/cacerts/ldap.key
TLSCACertificateFile /etc/openldap/cacerts/ca.crt
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
disallow bind_anon
access to attrs=userPassword
by self write
by dn.base="cn=mirrormode,dc=rnd,dc=com" read
by dn.base="cn=binduser,dc=rnd,dc=com" read
by * auth
access to *
by dn.base="cn=mirrormode,dc=rnd,dc=com" read
by dn.base="cn=binduser,dc=rnd,dc=com" read
by * break
access to *
by dn="cn=Manager,dc=rnd,dc=com"
by users read
by self write
by * auth
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
# DIT will act as a provider
overlay syncprov
suffix "dc=rnd,dc=com"
rootdn "cn=Manager,dc=rnd,dc=com"
rootpw {SSHA}KOXKk4vkP1X3nF2GY09MQXiaAdxkLyk7
# PPolicy Configuration
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=rnd,dc=com"
ppolicy_use_lockout
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
Thanks & Regards
Raj
From: PRAJITH <prajithpalakkuda(a)gmail.com>
To: Rajagopal Rc <rajagopal.rc(a)tcs.com>
Cc: openldap-technical(a)openldap.org
Date: 11/22/2015 09:55 AM
Subject: Re: Problem with "force user to password reset at first
login
Sent by: "openldap-technical"
<openldap-technical-bounces(a)openldap.org>
Hi Rajagopal,
Can you confirm the below points?
1) let us know the client application are you using.
2) Paste here your slapd.conf file.
On 20 November 2015 at 13:16, Rajagopal Rc <rajagopal.rc(a)tcs.com> wrote:
Hi,
I am trying to force users to change their password at first login or
after
password reset by administrator.
Tried following:
1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
of the
users get prompt to change their password at first login.
2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
prompt
to change the password and didn't allow to login
i observe below messages in log
"slapd[12684]: connection restricted to password changing only
slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are
restricted to bind/unbind/abandon/StartTLS/modify password"
slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
Please help me configure the option to force all users to change their
password
at first login or after pwd reset by administrator.
Thanks & Regards
Raj
Tata Consultancy Services
Mailto: rajagopal.rc(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
9 years, 6 months
Re: What attributes to authenticate (or) How to block the ldap tree for anonymous users
by Holger Schier
Hi Diego,
I tried your ACLs. Here are my entries:
olcAccess: {0}to attrs=shadowLastChange,userPassword
by dn.base="cn=admin,dc=MY,dc=DC" write
by anonymous auth
by self write
by * none
olcAccess: {1}to *
by dn.base="cn=admin,dc=MY,dc=DC" write
by users read
by * none
Then I tried to login and failed. "Login incorrect".
In my messages:
slapd[5527]: slapd starting
login[4786]: pam_ldap: ldap_search_s No such object
login[4786]: FAILED LOGIN 1 FROM /dev/tty1 FOR UNKNOWN, User not known
to the underlying authentication module
If I change the last line of the ACLs to:
by * read
everything works fine.
So, I did some more logging:
-----
slapd[8440]: conn=1 fd=13 ACCEPT from IP=127.0.0.1:41031 (IP=0.0.0.0:389)
slapd[8440]: connection_get(13)
slapd[8440]: conn=1 op=0 EXT oid=1.3.6.1.4.1.1466.20037
slapd[8440]: do_extended: oid=1.3.6.1.4.1.1466.20037
slapd[8440]: conn=1 op=0 STARTTLS
slapd[8440]: conn=1 op=0 RESULT oid= err=0 text=
slapd[8440]: connection_get(13)
slapd[8440]: connection_get(13)
slapd[8440]: conn=1 fd=13 TLS established tls_ssf=256 ssf=256
slapd[8440]: connection_get(13)
slapd[8440]: conn=1 op=1 BIND dn="" method=128
slapd[8440]: send_ldap_result: err=0 matched="" text=""
slapd[8440]: conn=1 op=1 RESULT tag=97 err=0 text=
slapd[8440]: connection_get(13)
slapd[8440]: SRCH "dc=MY,dc=DC" 2 0
slapd[8440]: 1 0 0
slapd[8440]: filter: (&(objectClass=shadowAccount)(uid=schier))
slapd[8440]: attrs:
slapd[8440]: uid
slapd[8440]: userPassword
slapd[8440]: shadowLastChange
slapd[8440]: shadowMax
slapd[8440]: shadowMin
slapd[8440]: shadowWarning
slapd[8440]: shadowInactive
slapd[8440]: shadowExpire
slapd[8440]: shadowFlag
slapd[8440]:
slapd[8440]: conn=1 op=2 SRCH base="dc=MY,dc=DC" scope=2 deref=0
filter="(&(objectClass=shadowAccount)(uid=schier))"
slapd[8440]: conn=1 op=2 SRCH attr=uid userPassword shadowLastChange
shadowMax shadowMin shadowWarning shadowInactive shadowExpire shadowFlag
slapd[8440]: => access_allowed: search access to "dc=MY,dc=DC" "entry"
requested
slapd[8440]: => acl_get: [2] attr entry
slapd[8440]: => acl_mask: access to entry "dc=MY,dc=DC", attr "entry"
requested
slapd[8440]: => acl_mask: to all values by "", (=0)
slapd[8440]: <= check a_dn_pat: cn=admin,dc=MY,dc=DC
slapd[8440]: <= check a_dn_pat: users
slapd[8440]: <= check a_dn_pat: *
slapd[8440]: <= acl_mask: [3] applying none(=0) (stop)
slapd[8440]: <= acl_mask: [3] mask: none(=0)
slapd[8440]: => slap_access_allowed: search access denied by none(=0)
slapd[8440]: => access_allowed: no more rules
slapd[8440]: send_ldap_result: err=32 matched="" text=""
slapd[8440]: conn=1 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text=
slapd[8440]: conn=2 fd=14 ACCEPT from IP=127.0.0.1:41032 (IP=0.0.0.0:389)
slapd[8440]: connection_get(14)
slapd[8440]: conn=2 op=0 EXT oid=1.3.6.1.4.1.1466.20037
slapd[8440]: do_extended: oid=1.3.6.1.4.1.1466.20037
slapd[8440]: conn=2 op=0 STARTTLS
slapd[8440]: conn=2 op=0 RESULT oid= err=0 text=
slapd[8440]: connection_get(14)
slapd[8440]: connection_get(14)
slapd[8440]: conn=2 fd=14 TLS established tls_ssf=256 ssf=256
slapd[8440]: connection_get(14)
slapd[8440]: conn=2 op=1 BIND dn="" method=128
slapd[8440]: send_ldap_result: err=0 matched="" text=""
slapd[8440]: conn=2 op=1 RESULT tag=97 err=0 text=
slapd[8440]: connection_get(14)
slapd[8440]: SRCH "dc=MY,dc=DC" 2 0
slapd[8440]: 1 0 0
slapd[8440]: filter:
(&(objectClass=posixAccount)(objectClass=posixAccount)(uid=schier))
slapd[8440]: attrs:
slapd[8440]:
slapd[8440]: conn=2 op=2 SRCH base="dc=MY,dc=DC" scope=2 deref=0
filter="(&(objectClass=posixAccount)(objectClass=posixAccount)(uid=schier))"
slapd[8440]: => access_allowed: search access to "dc=MY,dc=DC" "entry"
requested
slapd[8440]: => acl_get: [2] attr entry
slapd[8440]: => acl_mask: access to entry "dc=MY,dc=DC", attr "entry"
requested
slapd[8440]: => acl_mask: to all values by "", (=0)
slapd[8440]: <= check a_dn_pat: cn=admin,dc=MY,dc=DC
slapd[8440]: <= check a_dn_pat: users
slapd[8440]: <= check a_dn_pat: *
slapd[8440]: <= acl_mask: [3] applying none(=0) (stop)
slapd[8440]: <= acl_mask: [3] mask: none(=0)
slapd[8440]: => slap_access_allowed: search access denied by none(=0)
slapd[8440]: => access_allowed: no more rules
slapd[8440]: send_ldap_result: err=32 matched="" text=""
slapd[8440]: conn=2 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text=
login[8129]: pam_ldap: ldap_search_s No such object
login[8129]: FAILED LOGIN 1 FROM /dev/tty1 FOR schier, User not known to
the underlying authentication module
Am 04.10.2010 20:30, schrieb Diego Lima:
> Hi Holger,
>
> I'd try with the following ACLs:
>
> access to attrs=userPassword,shadowLastChange
> by dn="cn=admin,dc=example,dc=com" write
> by anonymous auth
> by self write
> by * none
>
> access to *
> by dn="cn=admin,dc=example,dc=com" write
> by users read
> by * none
>
>
> This way you'll be allowing unauthenticated users to log in using
> their password fields and you'll restrict read access on the rest of
> the base to authenticated users. The first ACL also allows users to
> change their own passwords (write in the userPassword and
> shadowLastChange attributes).
Holger
14 years, 8 months
Re: mmr pair stops replicating: "consumer state is newer than provider"
by btb
On 6/27/17 4:55 PM, Quanah Gibson-Mount wrote:
> --On Tuesday, June 27, 2017 5:35 PM -0400 btb <btb(a)bitrate.net> wrote:
>
>> On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote:
>>> --On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote:
>>>> i'm using 2.4.44 on freebsd, built from ports. i can provide any
>>>> config
>>>> details etc - i just didn't want to inundate the post with guesses on
>>>> detail that might not be relevant.
>>>
>>> What is your accesslog purge setting? Do you have long periods of time
>>> with no write activity?
>>
>> there are some extended periods of time with no write activity, yes.
>
> That's one form of a known issue then with using accesslog (ITS#8100).
> I've made a suggestion on how it could be fixed, and Howard agreed that
> would be the correct solution. Just need the fix. :)
>
> In the meantime, you can set up a cronjob that does a modify once a day
> on some object that doesn't really do anything, like if you had:
>
> dn: cn=someobject,dc...
> objectClass: ...
> cn: someobject
> description: blah
>
> you could have a job that does:
> dn: cn=someobject,dc...
> changetype: modify
> replace: description
> description: blah
>
> So it in effect does nothing, but it keeps an active change in the
> accesslog alive.
>
> Basically what happens with the accesslog empty is that it'll end up
> generating its own new contextCSN that differs for that server than the
> one stored in the rootDB, and will be /newer/ than it as well, which is
> why you get that message. You can also fix the problem simply by doing
> a modify on each master, and it'll reset the contextCSNs and things will
> flow (i.e., no need to do a dump/reload, etc).
i see, thanks. i tested this, and did a modify on each, but didn't see
replication resume. emulating the syncrepl connection with a manual
search against each master, there do seem to be accesslog entries now,
on both masters:
ldapsearch -ZZxWLLLH 'ldap://dsa1.example.org/' -D
'uid=dsa2_slapd-repl-content,ou=dsa2.example.org,ou=services,ou=accounts,cd=example,dc=org'
-b 'cn=accesslog' '(&(objectClass=auditWriteObject)(reqResult=0))' reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Enter LDAP Password:
dn: reqStart=20170628033755.000000Z,cn=accesslog
reqType: add
reqDN: cn=project_management_users,ou=general,ou=groups,cd=example,dc=org
reqMod: member:+ uid=jdoe,ou=People,cd=example,dc=org
reqMod: member:+ uid=mkline,ou=People,cd=example,dc=org
reqMod: member:+ uid=astavins,ou=People,cd=example,dc=org
reqMod: cn:+ project_management_users
reqMod: objectClass:+ groupOfNames
reqMod: objectClass:+ top
reqMod: structuralObjectClass:+ groupOfNames
reqMod: entryUUID:+ ea9a8246-effe-1036-966a-9d166400a934
reqMod: creatorsName:+
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=or
g
reqMod: createTimestamp:+ 20170628033755Z
reqMod: entryCSN:+ 20170628033755.410123Z#000000#001#000000
reqMod: modifiersName:+
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:+ 20170628033755Z
entryCSN: 20170628033755.410123Z#000000#001#000000
dn: reqStart=20170628033931.000000Z,cn=accesslog
reqType: modify
reqDN: uid=jdoe,ou=People,cd=example,dc=org
reqMod: givenName:+ john
reqMod: entryCSN:= 20170628033931.892952Z#000000#001#000000
reqMod: modifiersName:=
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:= 20170628033931Z
entryCSN: 20170628033931.892952Z#000000#001#000000
dn: reqStart=20170628034017.000000Z,cn=accesslog
reqType: modify
reqDN: uid=jdoe,ou=People,cd=example,dc=org
reqMod: sn:= doe
reqMod: entryCSN:= 20170628034017.532972Z#000000#001#000000
reqMod: modifiersName:=
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:= 20170628034017Z
entryCSN: 20170628034017.532972Z#000000#001#000000
dn: reqStart=20170628034119.000000Z,cn=accesslog
reqType: modify
reqDN: uid=mkline,ou=People,cd=example,dc=org
reqMod: givenName:+ michael
reqMod: entryCSN:= 20170628034119.327974Z#000000#001#000000
reqMod: modifiersName:=
uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o
rg
reqMod: modifyTimestamp:= 20170628034119Z
entryCSN: 20170628034119.327974Z#000000#001#000000
but the same log messages persist. what can i look at next? are these
the relevant contextcsn values?
dsa1 cn=accesslog:
20161019002438.652359Z#000000#000#000000
20170521175113.974560Z#000000#002#000000
20170530214415.204052Z#000000#001#000000
dsa1 dc=example,dc=org:
20170520031415.276678Z#000000#000#000000
20170530214231.171959Z#000000#002#000000
20170530214415.204052Z#000000#001#000000
dsa2 cn=accesslog:
20170520031415.276678Z#000000#000#000000
20170521175113.974560Z#000000#002#000000
20170628034119.327974Z#000000#001#000000
dsa2 dc=example,dc=org:
20170520031415.276678Z#000000#000#000000
20170619014933.531051Z#000000#002#000000
20170628034119.327974Z#000000#001#000000
if it might be of value, here are the olcsyncrepl attributes from each
master:
dsa1:
{0}rid=000
provider=ldap://dsa2.example.org/
starttls=critical
tls_cacert=/usr/local/etc/pki/trusted_root_authorities/root_ca-cert.pem
bindmethod=simple
binddn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,cd=example,dc=org"
credentials="xxxxxxxxxxxxxxxxxxxxxx"
searchbase="dc=example,dc=org"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="15 +"
syncdata=accesslog
dsa2:
{0}rid=000
provider=ldap://dsa1.example.org/
starttls=critical
tls_cacert=/usr/local/etc/pki/trusted_root_authorities/root_ca-cert.pem
bindmethod=simple
binddn="uid=dsa2_slapd-repl-content,ou=dsa2.example.org,ou=services,ou=accounts,cd=example,dc=org"
credentials="xxxxxxxxxxxxxxxxxxxxxx"
searchbase="dc=example,dc=org"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="15 +"
syncdata=accesslog
thanks
-ben
7 years, 11 months
RE: difference between /etc/ldap.conf /etc/openldap/ldap.conf
by GanGan
I did not touch so I do not think it comes from this files
On Wed, 29 Oct 2008 11:55:29 -0400, Lynn York <lyork(a)inetu.net> wrote:
> Make sure have configured PAM properly. Here is an example of a
> system-auth-ac file that I use that works properly:
>
> [ /etc/pam.d/system-auth-ac ]
> #%PAM-1.0
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
> auth required pam_env.so
> auth sufficient pam_unix.so nullok try_first_pass
> auth sufficient pam_ldap.so use_first_pass
> auth required pam_deny.so
>
> account required pam_unix.so broken_shadow
> account sufficient pam_localuser.so
> account sufficient pam_succeed_if.so uid < 500 quiet
> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
> account required pam_permit.so
>
> password requisite pam_cracklib.so try_first_pass retry=3
> password sufficient pam_unix.so md5 shadow nullok try_first_pass
> use_authtok
> password sufficient pam_ldap.so use_authtok
> password required pam_deny.so
>
> session optional pam_keyinit.so revoke
> session required pam_limits.so
> session [success=1 default=ignore] pam_succeed_if.so service in crond
> quiet use_uid
> session required pam_unix.so
> session optional pam_ldap.so
> [ end /etc/pam.d/system-auth-ac ]
>
>
> -----Original Message-----
> From: openldap-technical-bounces+lyork=inetu.net(a)openldap.org
> [mailto:openldap-technical-bounces+lyork=inetu.net@openldap.org] On
Behalf
> Of
> GanGan
> Sent: Wednesday, October 29, 2008 11:28 AM
> To: Hallvard B Furuseth
> Cc: Openldap technical
> Subject: Re: difference between /etc/ldap.conf /etc/openldap/ldap.conf
>
>
> thank you
>
> I have a problem with my users authentication.
>
> getent passwd
> gives me my 4 users ldap
>
> [...]
>
> videl:x:503:1000:videl:/home/videl:/bin/bash
> azerty:x:501:1000:azerty:/home/azerty:/bin/bash
> wizz:x:515:1000:wizz:/home/wizz:/bin/bash
> shen:x:509:1000:shen:/home/shen:/bin/bash
>
> but impossible to connect.
>
> [root@clitest3 /]# ssh videl(a)srvtest3.test.org
> videl(a)srvtest3.test.org's password:
> Permission denied, please try again.
> videl(a)srvtest3.test.org's password:
> Permission denied, please try again.
> videl(a)srvtest3.test.org's password:
> Permission denied (publickey,password).
>
> log ldap server (srvtest3):
>
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 ACCEPT from
> IP=127.0.0.1:40706 (IP=0.0.0.0:389)
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 STARTTLS
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 TLS established
> tls_ssf=256 ssf=256
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 RESULT oid= err=0
text=
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 BIND dn="" method=128
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 RESULT tag=97 err=0
> text=
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH
> base="ou=user,dc=midian,dc=org" scope=2 deref=0
> filter="(&(objectClass=posixAccount)(uid=videl))"
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH attr=uid
> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
> description objectClass
> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SEARCH RESULT tag=101
> err=0 nentries=0 text=
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH
> base="ou=user,dc=midian,dc=org" scope=2 deref=0
> filter="(&(objectClass=posixAccount)(uid=videl))"
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH attr=uid
> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
> description objectClass
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SEARCH RESULT tag=101
> err=0 nentries=0 text=
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 ACCEPT from
> IP=127.0.0.1:40707 (IP=0.0.0.0:389)
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 STARTTLS
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 RESULT oid= err=0
text=
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 TLS established
> tls_ssf=256 ssf=256
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 BIND dn="" method=128
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 RESULT tag=97 err=0
> text=
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SRCH
> base="ou=user,dc=midian,dc=org" scope=2 deref=0
> filter="(&(host=srvtest3.test.org)(uid=videl))"
> Oct 29 16:25:45 srvtest3 slapd[1947]: <= bdb_equality_candidates: (host)
> index_param failed (18)
> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SEARCH RESULT tag=101
> err=0 nentries=0 text=
>
> I do not understand why it is not working. :(
> any idea ?
--
- GanGan -
www.system-linux.eu merci pour le clique sur la pub :p
16 years, 7 months
Re: Have daemon reload rotated certs
by David Arnold
Cool, I'm getting there! Unfortunately and for good reasons the creator
of ae-dir.com
has restricted modifying access for config (in order to tightly control
runtime config state).
So this is how far as I get:
```
[nix-shell] ➜ aedir-ldap.k8s git:(da-openldap-base) ✗ just mprovider
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /var/run/certs/svid.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /var/run/certs/svid_key.pem
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: operation restricted
command terminated with exit code 53
error: Recipe `mprovider` failed with exit code 5
```
Furthermore, would this dummy change also reload the certificates that
are configured for the syncrepls?
See:
```
dn: olcDatabase={2}mdb,cn=config
olcSyncrepl: rid=001
provider=<ldaps://aedir-0.aedir.aedir-provider.svc.cluster>
.local bindmethod=sasl timeout=5 network-timeout=5 saslmech=EXTERNAL
keepaliv
e=240:10:30 starttls=no tls_cert="/var/run/certs/svid.pem"
tls_key="/var/run/
certs/svid_key.pem" tls_cacert="/var/run/certs/svid_bundle.pem"
tls_reqcert=d
emand
tls_cipher_suite=ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:
ECDH-RSA-AES256-GCM-SHA384:!ADH tls_protocol_min=3.3 tls_crlcheck=none
filter
="(objectClass=*)" searchbase="ou=ae-dir" scope=sub attrs="*,+"
schemacheckin
g=on type=refreshAndPersist retry="30 +"
```
I'm starting to think plain process signalling for reloading the TLS
context would actually be a cleaner, more elegant and stable solution.
Would you be ok if I opened an issue for that?
On Fri, Aug 21, 2020 at 12:00, Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
>
>
> --On Friday, August 21, 2020 2:56 PM -0500 David Arnold
> <dar(a)xoe.solutions <mailto:dar@xoe.solutions>> wrote:
>
>> Since the paths don't actually change (and I have no means to make
>> them
>> change), can I do a dummy modification that would trigger cert
>> reloading?
>
> Yeah, just do a replace op, like:
>
> ldapmodify ...
> dn: cn=config
> changetype: modify
> replace: olcTLS..
> olcTLS...: original value
>
> For the slapd.conf configuration to enable the cn=config db just have:
>
> database config
> rootpw somepassword
>
> and then you can bind to it w/ that password. Alternatively, you can
> set up an authz-regexp, etc.
>
>
> Regards,
> Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com <http://www.symas.com/>>
4 years, 9 months
Re: top-level data entries not replicating, 2.4.15
by Brian Neu
Forgive me if pasting here is bad etiquette.
<consumer slapd.conf>
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/samba.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt
TLSCertificateFile /etc/openldap/keys/victory3cert.pem
TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
database hdb
suffix "dc=srg,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=srg,dc=com"
rootpw {MD5}blah
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
syncrepl rid=0
provider=ldap://victory2.srg.com:389
bindmethod=simple
starttls=critical
binddn="cn=replicator,dc=srg,dc=com"
credentials=blah
searchbase="dc=srg,dc=com"
logbase="cn=accesslog"
schemachecking=on
type=refreshAndPersist
retry="60 +"
syncdata=accesslog
updateref ldaps://victory2.srg.com
database monitor
access to *
by dn.exact="cn=Manager,dc=srg,dc=com" write
by * none
</consumer slapd.conf>
--- On Thu, 8/20/09, Jonathan Clarke <jonathan(a)phillipoux.net> wrote:
> From: Jonathan Clarke <jonathan(a)phillipoux.net>
> Subject: Re: top-level data entries not replicating, 2.4.15
> To: "Brian Neu" <proclivity76(a)yahoo.com>
> Cc: openldap-technical(a)openldap.org
> Date: Thursday, August 20, 2009, 8:02 AM
> On 19/08/2009 19:29, Brian Neu
> wrote:
> > Even with no logfilter on the consumer,
> >
> cn=replicator,dc=domain,dc=com&
> >
> sambaDomainName=SRG,dc=domain,dc=com
> >
> > don't replicate, even after wiping the database and
> restarting. Everything else seems to replicate fine.
> >
> > How do I get top-level data entries to replicate?
>
> This really depends on your syncrepl configuration on the
> consumer.
> If you provide it here, maybe we can take a look.
>
> Aside from that, the latest version, 2.4.17, contains a few
> fixes that
> might help with this problem.
>
> Jonathan
>
15 years, 9 months
Syncrepl on glued databases only replicates the superior and the first subordinate
by Robert Minsk
Openldap version 2.4.35
Our global ldap server has the following naming contexts:
namingContexts: o=global,ou=studios,dc=methodstudios,dc=net
namingContexts: o=chi01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=det01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=la01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=ny01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=lon01,ou=studios,dc=methodstudios,dc=net
namingContexts: o=van01,ou=studios,dc=methodstudios,dc=net
namingContexts: ou=studios,dc=methodstudios,dc=net
namingContexts: ou=login,dc=methodstudios,dc=net
ou=studio,dc=methodstudios,dc=net is the superior database and global,
chi01, det01, la01, ny01, lon01, van01 are all have "subordinate
advertise" and are all sync providers.
The sync provider:
database mdb
suffix "ou=studios,dc=methodstudios,dc=net"
rootdn ...
rootpw ...
directory /var/lib/ldap/studios.methodstudios.net
maxsize 17179869184
serverID 201
overlay glue
overlay syncprov
syncprov-reloadhint TRUE
syncprov-checkpoint 100 5
sync_use_subentry true
...
The sync consumer only has a database for
ou=studios,dc=methodstudios,dc=net.
database mdb
suffix "ou=studios,dc=methodstudios,dc=net"
rootdn ...
rootpw ...
directory /var/lib/ldap/studios.methodstudios.net
maxsize 17179869184
serverID 202
syncrepl rid=201 provider=ldap://<providor host name>
type=refreshAndPersist retry="60 10 300 +"
searchbase="ou=studios,dc=methodstudios,dc=net"
bindmethod=simple starttls=yes
binddn="..."
credentials=... schemachecking=off
sizelimit=unlimited timelimit=unlimited
updateref ldap://<providor host name>
It seems to be only syncing ou=studios,dc=methodstudios,dc=net and
o=global,ou=studios,dc=methodstudios,dc=net. If I change the order of
the provider server so that chi01 comes before global then only syncing
ou=studios,dc=methodstudios,dc=net and
o=chi01,ou=studios,dc=methodstudios,dc=net get sync.
Am I doing anything obviously wrong?
--
Robert Minsk
Systems and Software Engineer
WWW.METHODSTUDIOS.COM <http://www.methodstudios.com>
730 Arizona Ave, Santa Monica, CA 90401
O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501
<tel:+13104346501>
Los Angeles
<http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles>
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
11 years, 5 months
[Solved] AW: Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Hauke Coltzau
Hi all,
Wow, it seems to be done ;-)
To put it in a nutshell:
- apt-get purge MIT-Kerberos*
- apt-get install Heimdal*
- tried and failed, tried and failed, ...
- apt-get purge heimdal*, cyrus*, openldap*
- apt-get libssl-dev and libdb dev packages
- got cyrus, openldap and heimdal tarballs
- configured, compiled, tested, failed, configured, compiled,
tested, failed, conf.......... ...... ......
... --- ... ... --- ...
configured, compiled, succeeded!
- Followed well known configuration instructions
Voila!
ldapsearch -Y GSSAPI works
ldaps works
(without client verification, did not solve that yet,
server verification works fine)
login with kerberos authentication works
(with proxy ticket for the machine, this way I
avoid having PLAIN username/password send to slapd)
su, id, etc. works
Seems, as if doing it by hand is still the best way ;-)
Thanks again for your help,
Hauke
----- Ursprüngliche Mail -----
Von: "Quanah Gibson-Mount" <quanah(a)zimbra.com>
An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de>
CC: openldap-software(a)openldap.org
Gesendet: Montag, 8. September 2008 21:44:16 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
--On Monday, September 08, 2008 9:26 PM +0200 Hauke Coltzau
<hauke.coltzau(a)FernUni-Hagen.de> wrote:
> ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\
> Cyrus SASL - pluggable authentication module
I would highly recommend using Heimdal on the master side. But that's up
to you. ;)
> - In the first approach, the user already has a TGT and asks the KDC for
> a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd?
> Hence, slapd "only" needs access to its keytab to be able to decrypt the
> clients messages?
I believe that is correct, yes. At Stanford, I had to point slapd at the
keytab in a shell script, but I believe that was because I was using
SASL/GSSAPI to do replication as well. It's been a while. ;)
> - And in the second one, the user provides username and password (plain),
> slapd converts the username into a principle (user@REALM) and forwards
> this to saslauthd? So this should be secured via TLS?
You can try securing it via startTLS, but nothing blocks a user from still
doing it in the clear, unfortunately (i.e., you can reject the non-secured
bind, but they'll have already sent their credentials, so anyone sniffing
would be able to get them).
> There used to be a well-known howto for all this at
> http://www.bayour.com/LDAPv3-HOWTO.html but the site is offline for some
> days now.
This howto is completely wrong, and the various folks have asked the author
to take it down for years. I'm glad to hear it is not accessible.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
16 years, 9 months
Multi-master replication (ldap_sasl_bind_s failed)
by Artur Nike
Hi all,
My adventure with LDAP lasts a few months, and I came to the topic of
replication,
namely multiple-master replication.
cn = config is replicated perfectly, but the schema, say, dc = example, dc
= com does not want to: (.
I have two servers slap1 and slap2
I have a standard installation
##Server slap1
whezzy debian 64bit
apt-get install-y slapd ldap-utils
added my scheme
ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / memberof.ldif
ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / refint.ldif
# Add "ldap :/ / ldap1 / in /etc/default/slapd
sed-i "/^ SLAPD_SERVICES/s/=[^]*/=\"ldap:\/\/slap1\//'/etc/default/slapd
ldapmodify-Y EXTERNAL-H ldapi :/ / /-f replica1.ldif
where replica1.ldif (replication configuration)::
dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {1}syncprov.la
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
#only for tests
olcRootPW: 123
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://slap1/
olcServerID: 2 ldap://slap2/
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=ldap://slap1/
binddn="cn=admin,cn=config"
bindmethod=simple credentials=123
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://slap2/
binddn="cn=admin,cn=config"
bindmethod=simple credentials=123
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
This same scenario takes on a server slap2 (the name change slap1 -> slap2)
where replica2.ldif (replication configuration only servers slap2) :
dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 2
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {1}syncprov.la
dn: olcDatabase={0}config,cn=config
changetype: modify
#only for tests
add: olcRootPW
olcRootPW: 123
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://slap1/
olcServerID: 2 ldap://slap2/
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=ldap://slap1/
binddn="cn=admin,cn=config"
bindmethod=simple credentials=123
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://slap2/
binddn="cn=admin,cn=config"
bindmethod=simple credentials=123
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
and it works , the whole configuration is replicated .
Now I want ( I'm trying to add a replication scheme . )
Adds only one server , eg slap2 :
ldapmodify - Y EXTERNAL -H ldapi :/ / / -f rep_schema.ldif
where rep_schema.ldif :
# add replica schema
dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: 123
-
replace: olcRootDN
olcRootDN: cn=admin,dc=example,dc=com
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcLimits
olcLimits: dn.exact="cn=admin,dc=example,dc=com"
time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
-
add: olcSyncRepl
olcSyncRepl: rid=004 provider=ldap://ldap1/
binddn="cn=admin,dc=example,dc=com"
bindmethod=simple credentials="123"
searchbase="dc=example,dc=com"
starttls=no
filter="(objectclass=*)"
attrs="*,+" scope=sub
schemachecking=of
type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5"
timeout=1
olcSyncRepl: rid=005 provider=ldap://ldap2/
binddn="cn=admin,dc=example,dc=com"
bindmethod=simple credentials="123"
searchbase="dc=example,dc=com"
starttls=no
filter="(objectclass=*)"
attrs="*,+" scope=sub
schemachecking=off
type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5"
timeout=1
-
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcMirrorMode
olcMirrorMode: TRUE
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
Configuration replicates and the end, schema does not replicate.
If you try to replicate one of the servers are in the logs I see:
Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=004 rc -1 quitting
Dec 15 23:44:48 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/
DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=005 rc -1 retrying
Dec 15 23:44:58 slap1 slapd[4496]: =>do_syncrepl rid=005
Dec 15 23:44:58 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/
DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
Dec 15 23:44:50 slap2 slapd[4456]: do_syncrepl: rid=004 rc -1 retrying
Dec 15 23:44:54 slap2 slapd[4456]: =>do_syncrepl rid=005
Dec 15 23:44:54 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap2/
DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
Dec 15 23:44:54 slap2 slapd[4456]: do_syncrepl: rid=005 rc -1 quitting
Dec 15 23:45:00 slap2 slapd[4456]: =>do_syncrepl rid=004
Dec 15 23:45:00 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap1/
DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
from server slap2 to search slap1:
ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap1/ -b
dc=example,dc=com -w 123 (working)
from server slap1 to search slap2:
ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap2/ -b
dc=example,dc=com -w 123 (working)
I'm out of ideas...
user : DN="cn=admin,dc=example,dc=com" is created automatically when I
install slapd
Can anyone have any suggestions or experience with this problem.
For all, thank you in advance.
Muniek
11 years, 5 months
RE: [EXTERNAL] RE: OpenLDAP Pass-through Authentication
by Dino Edwards
> You probably need to delete the userPassword attribute?
> This is correct.
Finally got it working. Thanks for all the help!
I was able to piece the solution together. As previously mentioned most
guidance out there focused on configuring it with slapd.conf, however in my
case I was trying to use the Bitnami openldap container which does not use a
slapd.conf but instead uses dynamic runtime configuration which complicated
matters. Here's the config that works for pass-through remoteauth
authentication as well as utilizing argon2 password hashing leveraging the
bitnami openldap container for anyone that may find themselves in this
nightmare in the future:
docker-compose.yml:
openldap:
image: bitnami/openldap:latest
container_name: openldap_app
ports:
- '1389:1389'
- '1636:1636'
environment:
- LDAP_ROOT=dc=local-openldap-domain,dc=local
- LDAP_ADMIN_USERNAME=ldap-admin
- LDAP_ADMIN_PASSWORD=ldap_admin_password
- LDAP_USERS=some-ldap-user
- LDAP_PASSWORDS=some_ldap_user_password
- LDAP_EXTRA_SCHEMAS=cosine,inetorgperson,nis,argon2,remoteauth
- BITNAMI_DEBUG=true
- LDAP_LOG_LEVEL=1
networks:
openldap_net_ext:
ipv4_address: 172.16.xxx.xxx
volumes:
- openldap_data:/bitnami/openldap
-
./schema-argon2.ldif:/opt/bitnami/openldap/etc/schema/schema-argon2.ldif
-
./schema-remoteauth.ldif:/opt/bitnami/openldap/etc/schema/schema-remoteauth.
ldif
- ./custom-argon2.ldif:/custom/custom-argon2.ldif
- ./custom-remoteauth.ldif:/custom/custom-remoteauth.ldif
schema-argon2.ldif:
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /opt/bitnami/openldap/lib/openldap
olcModuleLoad: argon2.so
schema-remoteauth.ldif:
dn: cn=module{2},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /opt/bitnami/openldap/lib/openldap
olcModuleLoad: remoteauth.so
custom-argon2.ldif:
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcPasswordHash
olcPasswordHash: {ARGON2}
custom-remoteauth.ldif:
dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRemoteAuthCfg
olcOverlay: {6}remoteauth
olcRemoteAuthDNAttribute: seeAlso
olcRemoteAuthDomainAttribute: associatedDomain
olcRemoteAuthDefaultDomain: ad-domain
olcRemoteAuthMapping: ad-domain dc01.ad-domain.tld
olcRemoteAuthTLS: starttls=no tls_reqcert=never
olcRemoteAuthRetryCount: 3
Once the container is up, add the custom-argon2.ldif and the
custom-remoteauth.ldif files as follows:
docker exec openldap_app ldapadd -H ldapi:/// -Y EXTERNAL -f
/custom/argon2.ldif
docker exec openldap_app ldapadd -H ldapi:/// -Y EXTERNAL -f
/custom/remoteauth.ldif
For a remoteauth user use the following attributes in to create a user in
openldap where seeAlso is the DN of the user in the remote AD domain. I'm
guessing it should work with just the username on the remote domain:
dn: cn=jsmoe,ou=users,dc=local-openldap-domain,dc=local
objectClass: domainRelatedObject
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
associatedDomain: ad-domain
cn: jsmoe
sn: Smoe
displayName: Joe Smoe
givenName: Joe
mail: jsmoe(a)domain.tld
seeAlso: cn=Joe Smoe,ou=Users,dc=ad-domain,dc=tld
uid: jsmoe
For a local openldap user, I use the following attributes to create a user
in openldap:
dn: cn=mjane,ou=users,dc=local-openldap-domain,dc=local
objectClass: inetOrgPerson
cn: mjane
sn: Jane
displayName: Mary Jane
givenName: Mary
mail: mjane(a)domain.tld
uid: mjane
userPassword:
{ARGON2}$argon2id$v=19$m=7168,t=5,p=1$NaoI0qbKSpD5Hle+WhfncQ$HIWlTiUf02j8+tq
Oattpu2Z9tKyPGXG0YxyrxhmFDFs
3 months, 1 week