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
Re: Syncrepl and multipe values
by Quanah Gibson-Mount
--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio
Morais <matheus_morais(a)sicredi.com.br> wrote:
>
>
>
> Issue 8559 opened.
>
>
>
> I'm trying to work on a patch but I'm not sure if the best solution is to
> fix accesslog to avoid duplicated values or if the sample LDIF (in its
> description) should result in a constraint violation. What do you think?
The accesslog should never write an operation that can't be replicated. If
the MOD is a valid LDAP operation (which I think it is), then it should be
accepted at the frontend. The issue may be more in delta-syncrepl's
handling of the write op than anything else.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 9 months
[Q] what is the best practice or right way to change schemas order for cn=config case?
by Zeus Panchenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
what is the best practice or right way to change schemas order for cn=config case?
1. to move file?
2. to ldapmodify?
for the one used to slapd.conf both of ways look weird ... :(
- --
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAlo6mMsACgkQr3jpPg/3oypRzwCdHNMNgUewiolW91I7DB7cK5dE
BqoAn0tXLDIMIBg0W9uG39pwN7LPRPth
=jKuI
-----END PGP SIGNATURE-----
5 years, 10 months
OpenLDAP slave failure in case of master indisponibility
by Matthieu Cerda
Greetings,
I am observing a rather strange issue in the following setup:
* 1 OpenLDAP master server (2.4.31)
* 4 OpenLDAP slave servers (2.4.40)
* The OpenLDAP slaves do forward any update attempt to the master using
the chain overlay / proxyauthz (mainly to update the pwdFailureTime
attribute for ppolicy)
If I try to shut the master down (for maintenance let's say), the slaves
behave properly, then begin to deadlock one after each other after a few
minutes (by deadlock I mean no log output anymore, and any ldapwhoami /
ldapsearch request connects and then times out)
On the attached image, I monitored at the same time one of the slaves
using collectd, to keep an eye on cn=monitor data (the period between
15:24:30 and 15:26:00 has been extrapolated by Grafana, no data is
available at this time since cn=monitor access also deadlocks)
I can see that backload / pending threads and waiters seem to increase
gradually until the server gets unresponsive.
I found nothing on the ML (except
https://www.openldap.org/lists/openldap-technical/200912/msg00112.html)
or searching for clues, Is this predictable behavior or and obvious
misconfiguration, or it is an interesting occastion to dig a bit deeper ?
Thanks in advance,
--
Matthieu Cerda
Infrastructure, BU Means @ NBS System
5 years, 11 months
Error in dnx509Normalize when adding userCertificate value
by Cédric Couralet
Hello all,
I encountered a problem when importing several client certificate in
usercertificate attribute.
The error was :
[15362]: >>> certificateExactNormalize: <0x7f07019a9100, 1745>
[15362]: dnX509Normalize: <(null)> (21)
[15362]: <<< certificateExactNormalize: <0x7f07019a9100, 1745> => <(err)>
[15362]: <= str2entry NULL (ssyn_normalize 21)
[15362]: conn=1591 op=17 RESULT tag=103 err=21
text=userCertificate;binary: value #0 normalization failed
Looking through the certificateExactNormalize in sourcecode, it seems
the problem comes from the normalization of IssuerDn. Sure enough, in
my case the issuer dn is :
CN = Certigna Services CA
2.5.4.97 = NTRFR-48146308100036
OU = 0002 48146308100036
O = DHIMYOTIS
C = FR
Openldap has problem with the "2.5.4.97 = NTRFR-48146308100036" part,
it is declared as organizationIdentifier but don't appear in openldap
core schema (yet ?).
I managed to avoid the error by adding an attribute to schema but I'm
wondering if there is not a better way to do it, and why is the
normalize called here ?
My ldap version is the debian one :
# slapd -V
@(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $
root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
Is an update sufficient?
Thank you for your answers,
Cédric Couralet
5 years, 11 months
LDAP password policies don't seems to work
by André Rodier
Hello all,
I have an LDAP server, that I use for system authentication, emails,
etc, in a domain (homebox.space)
I have the password policies defined in the LDAP database, but they
don't seem to apply to the users when changing a password.
Both "olcPPolicyDefault" and "olcPPolicyHashCleartext" are set up, but
only the last is working, i.e. passwords sent in clear text by an LDAP
client are automatically encrypted.
There is an overlay entry for the domain, example:
olcPPolicyDefault: cn=default,ou=pwpolicies,dc=homebox,dc=space
and a correct entry "pwdPolicySubentry" for each user.
However, when I try change the password with pam_ldap or using the
roundcube password plugin, even the minimal length rule is ignored.
The module configuration:
> dn: cn=module{0},cn=config
> objectClass: olcModuleList
> cn: module{0}
> olcModulePath: /usr/lib/ldap
> olcModuleLoad: {0}back_mdb
> olcModuleLoad: {1}ppolicy.la
> olcModuleLoad: {2}deref.la
> structuralObjectClass: olcModuleList
> entryUUID: acbfbc52-7c3a-1037-9cc1-d74dec6fc011
> creatorsName: cn=admin,cn=config
> createTimestamp: 20171223143824Z
> entryCSN: 20171223143828.930245Z#000000#000#000000
> modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20171223143828Z
The overlay configuration
> dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
> objectClass: olcPPolicyConfig
> objectClass: olcOverlayConfig
> olcOverlay: {0}ppolicy
> olcPPolicyDefault: cn=default,ou=pwpolicies,dc=homebox,dc=space
> olcPPolicyHashCleartext: TRUE
> olcPPolicyUseLockout: FALSE
> olcPPolicyForwardUpdates: FALSE
> structuralObjectClass: olcPPolicyConfig
> entryUUID: affa09e0-7c3a-1037-956b-0f107d4f36ac
> creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> createTimestamp: 20171223143829Z
> entryCSN: 20171223143829.643274Z#000000#000#000000
> modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20171223143829Z
The policy:
> dn: cn=default,ou=pwpolicies,dc=homebox,dc=space
> pwdExpireWarning: 259200
> pwdMaxFailure: 5
> cn: default
> objectClass: pwdPolicy
> objectClass: person
> objectClass: top
> pwdMinLength: 8
> pwdCheckQuality: 0
> pwdAttribute: userPassword
> pwdLockoutDuration: 0
> pwdInHistory: 0
> sn: default
> pwdMaxAge: 31536000
> pwdGraceAuthNLimit: 0
> pwdFailureCountInterval: 300
> structuralObjectClass: person
> entryUUID: b083c4d2-7c3a-1037-956d-0f107d4f36ac
> creatorsName: cn=admin,dc=homebox,dc=space
> createTimestamp: 20171223143830Z
> entryCSN: 20171223143830.545905Z#000000#000#000000
> modifiersName: cn=admin,dc=homebox,dc=space
> modifyTimestamp: 20171223143830Z
Example of one user:
> dn:: Y249QW5kcsOpIFJvZGllcixvdT11c2VycyxkYz1ob21lYm94LGRjPXNwYWNl
> pwdPolicySubentry: cn=default,ou=pwpolicies,dc=homebox,dc=space
> shadowMin: 0
> uid: andre
> objectClass: top
> objectClass: person
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: inetOrgPerson
> loginShell: /bin/bash
> shadowFlag: 0
> uidNumber: 1001
> shadowMax: 999999
> gidNumber: 1001
> homeDirectory: /home/users/andre
> sn: Rodier
> shadowInactive: -1
> mail: andre(a)homebox.space
> givenName:: QW5kcsOp
> shadowWarning: 7
> structuralObjectClass: inetOrgPerson
> cn:: QW5kcsOpIFJvZGllcg==
> entryUUID: b12c4db4-7c3a-1037-9572-0f107d4f36ac
> creatorsName: cn=admin,dc=homebox,dc=space
> createTimestamp: 20171223143831Z
> userPassword:: e1NTSEF9SHllVitOazkyekNHYlIwbVRUdkZJZWFpVUo2WElSVWM=
> pwdChangedTime: 20171223150211Z
> entryCSN: 20171223150211.599058Z#000000#000#000000
> modifiersName: cn=admin,dc=homebox,dc=space
> modifyTimestamp: 20171223150211Z
>
I have the whole source code here: https://github.com/progmaticltd/homebox/
The Ansible tasks I am using to configure the LDAP server are here:
https://github.com/progmaticltd/homebox/blob/master/install/playbooks/rol...
Any help welcome.
Kind regards,
André Rodier.
PS: Merry Christmas / Happy new year / for those concerned.
5 years, 11 months
Re: [Q] what is the best practice or right way to change schemas order for cn=config case?
by Howard Chu
Christian Kratzer wrote:
> Hi,
>
> On Wed, 20 Dec 2017, Zeus Panchenko wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> hi,
>>
>> what is the best practice or right way to change schemas order for cn=config
>> case?
Use ldapmodrdn.
>>
>> 1. to move file?
>> 2. to ldapmodify?
>>
>> for the one used to slapd.conf both of ways look weird ... :(
>
> for those cases that ldapmodify that does not work you can use slapcat
> to dump all of the cn=config database edit it and reimport using slapadd.
>
> Adding -n0 to slapadd and slapcat makes it use the cn=config database.
>
> Greetings
> Christian
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 11 months
Re: uidNumber for Service Accounts?
by Douglas Duckworth
Thanks John and everyone else. It's only performing binds for Apache, and
sssd, as I do not allow anon binds to the LDAP server. This particular
account does not perform any interactive logins on *Nix boxes.
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-6305
F: 212-746-8690
On Wed, Oct 25, 2017 at 9:18 PM, John Lewis <jl(a)hyperbolicinnovation.com>
wrote:
> On Wed, 2017-10-25 at 09:32 -0400, Douglas Duckworth wrote:
> > Hi
> >
> > Do I need uidNumber for Service Accounts used for application /
> > server binding if this user won't actually be resolved by sssd or
> > nslcd?
> >
> > I set a very high uidNumber but eventually this will conflict with
> > users as in my ignorance I didn't put this in a lower range.
> >
> > Thanks,
> >
> > Douglas Duckworth, MSc, LFCS
> > HPC System Administrator
> > Scientific Computing Unit
> > Physiology and Biophysics
> > Weill Cornell Medicine
> > E: doug(a)med.cornell.edu
> > O: 212-746-6305
> > F: 212-746-8690
>
> It depends on weather your service account needs to login to a UNIX
> compliant system or not. If the account doesn't have a uid, it will
> most likely not be able to login as a standard UNIX account via LDAP.
>
> If the binds go directly to an application without going through an OS
> authentication layer, for example a web user login, it probably doesn't
> matter either way whether the account has a uidNumber set or not. If
> you have an interaction with sssd or nslcd in the middle, you are going
> to need the uidNumber attribute set.
>
5 years, 11 months
Re: use-case for clientctrls?
by Howard Chu
Michael Ströder wrote:
> After so many years passing around parameter clientctrls (e.g. in a
> wrapper module) I'm still wondering which use-cases this argument is
> meant for.
>
> I only found [1] but this seems akward today anyway.
Agreed, OID-based controls for client-side library behavior seems rather
unwieldy. I would agree though, that per-request control of library behavior
is a good thing. The C API still has no ldap_search() parameter for alias
deref behavior. It's a bit ridiculous that it's a library-level option, since
the option only has relevance to search requests.
> Any more client controls?
>
> Ciao, Michael.
>
> [1]
> https://tools.ietf.org/html/draft-ietf-ldapext-ldap-c-api-05#section-11.3.1
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 11 months
