Problem with "force user to password reset at first login
by Rajagopal Rc
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
1 month, 1 week
syncrepl with exattrs
by Frank Swasey
I am attempting to set up a replication using delta-syncrepl that will ignore four objectClasses. I am able to prevent the attributes of those objectClasses from being sent, by using @objectClassName in the exattrs value of the statement. However, I also have to set schemachecking off because the objectClass: objectClassName value is still coming over.
I was not able to find any examples of using the exattrs option in the tests/data directory. And, I have failed to find anything relevant from google.
Is there a way to prevent the four possible objectClass values that I don't want to see from being sent so I can leave schemachecking turned on?
Thanks,
- Frank
5 years, 1 month
Upgrading from 2.4.26 to 2.4.41: Stricter checks prevent startup?
by Ulrich Windl
Hi!
I wonder whether there is a summary of additional checks that may prevent 2.4.41 from starting in a 2.4.26 MMR configuration (What I did was upgrading SLES11 SP4 to SLES12 SP3). What I found out is:
1) olcServerID does not longer accept fifferent URIs mapping to the same ID, like here (" slapd[3299]: olcServerID: value #1: <olcServerID> multiple server ID URLs matched, only one is allowed 1"):
olcServerID: 1 ldap://host.domain.org:389
olcServerID: 1 ldaps://host.domain.org:636
(The idea was that whatever URI is used to contact the server, the server ID is the same)
As we do not actually use ldaps for replication that second line could be dropped easily
2) After fixing the first problem, I get another one: "5bd06634 <= str2entry: str2ad(olcAccessLogDB): attribute type undefined". The schema files seem to be the same, and the manual page slapo-accesslog also seems to be the same.
Any instructions fixing all the issues that may prevent 2.4.41 from starting up?
(please no comments on "2.4.41 is obsolete" unless exactly these problems were fixed in a later version)
I'm continuing with BDB, BTW, and also please no comments on "MDB is better", please.
Regards,
Ulrich
5 years, 1 month
question mark at the beggining of the search
by Angel L. Mateo
Hi,
I'm having searchs like this in my openldap logs:
Oct 25 12:46:41 canis30 slapd[25736]: conn=1192458 op=1 SRCH
base="ou=Usuarios,dc=Telematica" scope=2 deref=0
filter="(&(?objectClass=posixGroup)(objectClass=irisInetEntity)...
What does this "?" mean?
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 868888337
5 years, 1 month
Re: ACL contextCSN
by Lirien Maxime
Thanks !!
Have a nice day !!
On Thu, Oct 25, 2018 at 5:02 PM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
> --On Thursday, October 25, 2018 10:25 AM +0200 Lirien Maxime
> <maxime.lirien(a)gmail.com> wrote:
>
> > OK thanks Quanah !
> > I removed the "*" on ACL except for the last rule.
> > I don't understand : it is rejected by the last rule. Why does it not
> > match rule #3 ? Normally it may stop at the first match ?
>
> > Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry
> > "dc=fr", attr "objectClass" requested
>
> Hi Lirien,
>
> It's clearly asking for access to the objectClass attribute in "dc=fr",
> which is not a part of your ACL#3, so it's correctly denied:
>
> # 3) ********* CONTEXTCSN *********
> access to dn.base="dc=fr" attrs=entry,children,contextcsn
> by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read
> by dn.exact="cn=supervision,ou=Comptes Clients,dc=fr" read
> by * none
>
> You need to modify the access to line to include objectClass.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
5 years, 1 month
Re: ACL contextCSN
by Lirien Maxime
OK thanks Quanah !
I removed the "*" on ACL except for the last rule.
I don't understand : it is rejected by the last rule. Why does it not match
rule #3 ? Normally it may stop at the first match ?
Here's my request and the ACL log :
ldapsearch -x -H ldap://127.0.0.1 -b "dc=fr" -D "cn=supervision,ou=Comptes
clients,dc=fr" -s base contextCSN
Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: result not in
cache (userPassword)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: auth access
to "cn=supervision,ou=Comptes Clients,dc=fr" "userPassword" requested
Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [2] attr userPassword
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry
"cn=supervision,ou=Comptes Clients,dc=fr", attr "userPassword" requested
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to value by "", (=0)
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat:
cn=admingdr,ou=comptes admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat:
cn=ldapsynchro,ou=comptes admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: users
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: anonymous
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [4] applying
auth(=xd) (stop)
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [4] mask: auth(=xd)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: auth
access granted by auth(=xd)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: auth access
granted by auth(=xd)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access
to "dc=fr" "entry" requested
Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [3] dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] matched
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] attr entry
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry
"dc=fr", attr "entry" requested
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to all values by
"cn=supervision,ou=comptes clients,dc=fr", (=0)
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat:
cn=ldapsynchro,ou=comptes admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat:
cn=supervision,ou=comptes clients,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [2] applying
read(=rscxd) (stop)
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [2] mask:
read(=rscxd)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: search
access granted by read(=rscxd)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access
granted by read(=rscxd)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access
to "dc=fr" "objectClass" requested
Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [3] dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] matched
Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [5] dc=gouv,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [6] attr objectClass
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry
"dc=fr", attr "objectClass" requested
Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to all values by
"cn=supervision,ou=comptes clients,dc=fr", (=0)
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=root,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: ou=comptes
admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat:
cn=ldapsynchro,ou=comptes admin,dc=fr
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: self
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: users
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [5] applying
none(=0) (stop)
Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [5] mask: none(=0)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: search
access denied by none(=0)
Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: no more rules
On Wed, Oct 24, 2018 at 5:15 PM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
> --On Wednesday, October 24, 2018 5:17 PM +0200 Lirien Maxime
> <maxime.lirien(a)gmail.com> wrote:
>
> ># 2) userPassword accessible by all
> > access to * attrs=userPassword
> > by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read
> > by users auth
> > by anonymous auth
> > by * none
>
> This should be just access to attrs=userPassword, no need for the *.
>
> Similar comment for some of your other ACLs using the same format.
>
> I would generaly advise enabling "acl" level logging to see how things are
> being processed so you can determine what additional access is needed or
> which rule(s) are blocking access.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
5 years, 1 month
two subtrees replication
by Miroslav Misek
Hi,
I am trying setup replication of two subtrees:
olcDatabase={-1}frontend,cn=config
cn=schema,cn=config
I was advised at #openldap channel to set syncrepl for whole cn=config
and restrict it by ACL at provider side.
Which looks like elegant solution to me.
I tried it, but without success. As long, as replication user does not
have access to cn=config, replication fails. And I don`t want replicate
it, because of TLS settings etc.
So I tried this:
olcAccess: {0}to dn.subtree="olcDatabase={-1}frontend,cn=config"
by dn.exact="uid=replicator,dc=ententee,dc=com" read
by * break
olcAccess: {1}to dn.subtree="cn=schema,cn=config"
by dn.exact="uid=replicator,dc=ententee,dc=com" read
by * break
olcAccess: {2}to dn.subtree="cn=config"
by dn.exact="uid=replicator,dc=ententee,dc=com" search
by * break
But it didn`t help either.
Does anyone have any advice please?
Thank you,
Miroslav Misek
5 years, 1 month
ACL contextCSN
by Lirien Maxime
Hi all,
sorry for this second post.
I have a "supervision" account on all my ldap servers. With the plugin
nagios , it check the synchro. I would like this account read only
contextcsn at the top (dc=fr).
And only contextcsn not the other entries.
Quanah helped me (and thanks again) but it not seems to work. It's my bad,
I don't see something...
In the log it seems that "supervision" can't access dc=fr and it starts
browsing from dc=gouv,dc=fr.
Without rule#3, it's ok because of rule #5.
But with rule#3 it's supposed to match contextCSN ?!
Thanks guys.
PS : "supervision" is in "Comptes Admin"
Here are my ACL :
# 1) Admin's branch
access to dn.subtree="ou=Comptes Admin,dc=fr"
by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read
by self auth
by users auth
by anonymous auth
# 2) userPassword accessible by all
access to * attrs=userPassword
by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read
by users auth
by anonymous auth
by * none
*# 3) ********* CONTEXTCSN *********access to dn.base="dc=fr"
attrs=entry,children,contextcsn by dn.exact="cn=Synchro,ou=Comptes
Admin,dc=fr" read by dn.exact="cn=supervision,ou=Comptes Clients,dc=fr"
read by * none*
# 4) Certificate
access to *
attrs=userCertificateAuthentication,userCertificateConfidentiality,userCertificateSigning
by dn.exact="cn=clienttest,ou=Comptes Clients,dc=fr" read
by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read
by * none
# 5) Branch dc=gouv,dc=fr
access to dn.subtree="dc=gouv,dc=fr"
by dn.subtree="ou=Comptes Clients,dc=fr" read
by dn.subtree="ou=Comptes Admin,dc=fr" write
by * none
# 6) All the tree
access to *
by dn.exact="cn=root,dc=fr" write
by dn.subtree="ou=Comptes Admin,dc=fr" read
by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read
by self none
by users none
by anonymous none
by * none
5 years, 1 month
Adding read-only consumers to a Mirror Mode Replication setup?
by Jean-Francois Malouin
Hi,
Is it possible, or even sane to consider adding read-only consumers to a MMR
setup? If so, any recommendations, pitfalls or gotchas? Or should I simply
re-start from scratch -- I'm still not in production.
Just for the record, I'm using 2.4.46 on Debian/Stretch 9.5. Both mirrors
are backends to an HA haproxy server.
Thanks,
jf
5 years, 1 month
Re: Permissions required to perform OU/DN filtering?
by Philip Colmer
So, in the end, it was literally the "ou" attribute that I needed to
grant read access to.
Just in case anyone else needs to do something similar in the future …
Regards
Philip
On Tue, 23 Oct 2018 at 23:05, Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
> Hi Philip,
>
> --On Tuesday, October 23, 2018 2:21 PM +0100 Philip Colmer
> <philip.colmer(a)linaro.org> wrote:
>
> > Yes, I can run slapd in debug mode but this is a production system so
> > that means scheduling a maintenance window in several weeks' time. I
> > was rather hoping to have a solution in place sooner than that thanks
> > to the kind support of this list but, if I don't have it, I'll figure
> > it out for myself.
>
> I don't know the answer off the top of my head, but I would imagine you
> could set up a test/dev server fairly quickly to figure this out? Should
> be pretty straight forward. If you have the cn=config database enabled,
> you could change the loglevel to ACL on the fly (just to note).
>
> Warm regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
5 years, 1 month
