openldap replication and server redirect
Openldap gurus, This maybe a networking issue rather than configuration but I thought I’d run it by you guys to see if this can work. For replication, does ldap care whether I use a server redirect on the /etc/hosts file rather than the actual FQDN or IP address? I have two ldap systems behind a firewall with ldap ports 389 and 636 allowed thru. A redirect was setup to be able to get to these two systems. I set up a third ldap server outside the firewall and could not get it to replicate with other two servers by using the allowed redirect address. The two internal system replicate data just fine. So for example, it is suggested to add the 3 servers FQDN and IP addresses each of their /etc/hosts file and ensure they can see/communicate with eachother. /etc/hosts: Server1.local.srv Server2.local.srv Server3.local.srv My setup looks like this: /etc/hosts Server1andserver2redirect.local.srv (redirect that routes ldap traffic to the two internal servers) Server3.local.srv Can this work? If yes, what am I missing? Thank you, Liz
Re: Secure replication
Quanah, I ran netstat -a | egrep ":ldap" and found that the replication between my two test servers was not ldaps thus me reaching out to this forum. If “ldap://” is secure already then I do not need to proceed further. These are the SLAPD_URLS in the /etc/sysconfig/slapd file: SLAPD_URLS="ldapi:/// ldap:/// ldaps:///" I have TLS enabled everywhere and have encrypted connections between clients and servers. These are the ciphers running on both masters: SSLv3 TLSv1.2 I am using simple binds so I’ll look at SASL/EXTERNAL with authz-regexp mapping. Why is version 2.4.40 unsafe for multi-master replication? I can upgrade at a later time I just wanted to find out how to enable ldaps between the two servers. Thank you, Liz From: Quanah Gibson-Mount <qua...@symas.com> Reply-To: Quanah Gibson-Mount <qua...@symas.com> Date: Saturday, May 6, 2017 at 1:02 PM To: "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov>, "openldap-technical@openldap.org" <openldap-technical@openldap.org> Subject: Re: Secure replication --On Saturday, May 06, 2017 1:56 AM + "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> wrote: The olcSyncRepl directive on both systems needs to go from: olcSyncRepl: rid=001 provider=ldap to: olcSyncRepl: rid=001 provider=ldaps The use of "ldap://; does not mean that you have insecure replication. The "ldaps" designation was developed to allow for SSL encrypted connections as a part of LDAPv2, which did not have a formal design spec for allowing SSL encryption. The LDAPv3 spec, which is what OpenLDAP 2.4 (and much earlier version) implement, specifically has startTLS as a part of that specification, which uses "ldap:///;. I.e., ldaps is a bastardized hack for LDAPv2. The proper way to do TLS encryption with LDAPv3 capable servers such as OpenLDAP 2.[1-4+] is to use the startTLS extended operation over a "ldap:///; URI. In addition, there are other ways to have an encrypted connection between an LDAP client and server without involving TLS at all, such as SASL/GSSAPI. As Michael noted, you can, in addition to enabling TLS encryption between the client and servers, use client cert authentication (SASL/EXTERNAL) so as to remove the requirement for clear text credentials to be stored in the olcSyncRepl attribute (if using simple binds). And again, the usage of SASL/GSSAPI also precludes the neccessity of storing cleartext credentials in the olcSyncRepl attribute. As an aside, I would note that 2.4.40 is completely unsafe to use with multimaster replication. I would generally suggest forming a clear set of requirements for your replication environment, and then asking how to implement them. Your current question is too vague/general to really be answered well. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Secure replication
Hey guys, I’m running multi-master OpenLDAP (version 2.4.40) servers and need to secure replication. Can you point me to where I can find that information? What I found online is old and does not apply to the version I’m running. The olcSyncRepl directive on both systems needs to go from: olcSyncRepl: rid=001 provider=ldap to: olcSyncRepl: rid=001 provider=ldaps Thank you, Liz
Re: OpenLDAP performance and slapindex
Quanah,
I found these entries on both ldap server logs. So do these entries mean that
slapindex needs to be executed?
# less /var/log/ldap.log | grep index
Dec 15 12:22:01 slapd[27852]: <= bdb_equality_candidates: (uid) not indexed
Dec 15 12:22:01 slapd[27852]: <= bdb_equality_candidates: (memberUid) not
indexed
Dec 15 12:22:01 slapd[27852]: <= bdb_equality_candidates: (uid) not indexed
Dec 15 12:22:01 slapd[27852]: <= bdb_equality_candidates: (memberUid) not
indexed
Thank you,
Liz
From: Quanah Gibson-Mount <qua...@symas.com>
Reply-To: Quanah Gibson-Mount <qua...@symas.com>
Date: Wednesday, December 14, 2016 at 1:21 PM
To: "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov>,
"openldap-technical@openldap.org" <openldap-technical@openldap.org>
Subject: Re: OpenLDAP performance and slapindex
--On Wednesday, December 14, 2016 9:05 PM + "Real, Elizabeth (392K)"
<elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> wrote:
Hello,
I'm running OpenLDAP 2.4.40
Upgrade immediately to 2.4.44. The 2.4.40 release was seriously flawed and
had numerous critical bugs around replication.
In looking at ways to improve performance of ldap, is slapindex a tool to
use? Meaning after importing users accounts from an older ldap, should
slapindex be ran? Or is this tool is used when you want to modify/add
entries found in the slapd (cn=config.ldif) and database
((olcDatabase={2}hdb.ldif) configuration files not when users are added
to the ldap database.
Stop using back-hdb. Switch to back-mdb.
<https://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb-and-back-hdb-performance/>
If you already had indices defined for the database when you did the
import, there is no reason to run slapindex. Slapindex should only be used
if you've added a /new/ index to your database. If you are using cn=config
and add a new index, there will be a background thread that will eventually
index the entire DB.
Whether or not you need to add indexing for given attribute(s) can be
discovered by examining the logs generated by slapd, which will file a
complaint if there is a search performed on an unindexed attribute. You
would need to examine the specific search to see what type(s) of indexing
may be required.
If slapindex is not a tool to use to monitor performance, what do you
recommend?
slapindex has never been a tool to monitor anything. It is purely for
(re)generating indices on an existing DB.
Hope that helps!
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: OpenLDAP performance and slapindex
Thank you for the quick response.
I have spent a lot of time configuring version 2.4.40. Is there a guide on how
to upgrade to 2.4.44 and switch to back-mdb? we rolled out 2.4.40 today and
would need to plan the next upgrade.
I did already have indices defined for the database when I did the import.
What tool do you recommend for monitoring ldap performance?
Thank you,
Liz
From: Quanah Gibson-Mount <qua...@symas.com>
Reply-To: Quanah Gibson-Mount <qua...@symas.com>
Date: Wednesday, December 14, 2016 at 1:21 PM
To: "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov>,
"openldap-technical@openldap.org" <openldap-technical@openldap.org>
Subject: Re: OpenLDAP performance and slapindex
--On Wednesday, December 14, 2016 9:05 PM + "Real, Elizabeth (392K)"
<elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> wrote:
Hello,
I'm running OpenLDAP 2.4.40
Upgrade immediately to 2.4.44. The 2.4.40 release was seriously flawed and
had numerous critical bugs around replication.
In looking at ways to improve performance of ldap, is slapindex a tool to
use? Meaning after importing users accounts from an older ldap, should
slapindex be ran? Or is this tool is used when you want to modify/add
entries found in the slapd (cn=config.ldif) and database
((olcDatabase={2}hdb.ldif) configuration files not when users are added
to the ldap database.
Stop using back-hdb. Switch to back-mdb.
<https://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb-and-back-hdb-performance/>
If you already had indices defined for the database when you did the
import, there is no reason to run slapindex. Slapindex should only be used
if you've added a /new/ index to your database. If you are using cn=config
and add a new index, there will be a background thread that will eventually
index the entire DB.
Whether or not you need to add indexing for given attribute(s) can be
discovered by examining the logs generated by slapd, which will file a
complaint if there is a search performed on an unindexed attribute. You
would need to examine the specific search to see what type(s) of indexing
may be required.
If slapindex is not a tool to use to monitor performance, what do you
recommend?
slapindex has never been a tool to monitor anything. It is purely for
(re)generating indices on an existing DB.
Hope that helps!
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
OpenLDAP performance and slapindex
Hello,
I’m running OpenLDAP 2.4.40 on two multi-master servers with replication
enabled. Today we switched over to this instance, imported all users from the
old ldap server, and configured an ldap client to use this instance.
Everything is working well, users are authenticating and able to access their
assigned groups.
However, we noticed that while on the ldap client and as a regular user we type
“w” to see who is logged on this machine, it takes a while before we get a
response with the results. If we type “w” again the response is very fast due
to caching.
In looking at ways to improve performance of ldap, is slapindex a tool to use?
Meaning after importing users accounts from an older ldap, should slapindex be
ran? Or is this tool is used when you want to modify/add entries found in the
slapd (cn=config.ldif) and database ((olcDatabase={2}hdb.ldif) configuration
files not when users are added to the ldap database.
If slapindex is not a tool to use to monitor performance, what do you recommend?
Thank you,
Liz
Re: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent
Ulrich, Yes, I already have nis.ldif loaded. What else do you suggest? Thank you, Liz From: Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> Date: Monday, October 24, 2016 at 11:17 PM To: "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov>, "openldap-technical@openldap.org" <openldap-technical@openldap.org> Subject: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> schrieb am 24.10.2016 um 20:43 in Nachricht <0c90a104-2ef4-4aa6-8748-05b07154a...@jpl.nasa.gov<mailto:0c90a104-2ef4-4aa6-8748-05b07154a...@jpl.nasa.gov>>: Hello, I setup a password policy overlay on my openldap 2.4.40 servers running RHEL7. I need to enforce the following: disable accounts that have been inactive for 180 days. In the past we were able to do this by simply adding the shadowInactive attribute to each account: shadowInactive 180. But with the new openldap, it appears there is no equivalent attribute?? Why didn't you "grep shadowInactive /etc/openldap/schema/*"? It appears in nis.ldif, nis.schema, and rfc2307bis.schema. (I only have SLES11 SP4 here, but there shouldn't be a big difference) Ulrich http://www.openldap.org/doc/admin24/ http://www.zytrax.com/books/ldap/ch6/ppolicy.html Thank you, Liz
Re: openldap 2.4.40 ppolicy module and shadowInactive equivalent
Quanah, I found little information on this contrib nssov overlay: http://www.openldap.org/doc/admin24/guide.html#nssov How do you implement it? Is it similar to adding the ppolicy overlay? Thank you, Liz From: Quanah Gibson-Mount <qua...@symas.com> Reply-To: Quanah Gibson-Mount <qua...@symas.com> Date: Monday, October 24, 2016 at 6:29 PM To: "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov>, "openldap-technical@openldap.org" <openldap-technical@openldap.org> Subject: Re: openldap 2.4.40 ppolicy module and shadowInactive equivalent --On Monday, October 24, 2016 7:43 PM + "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> wrote: I setup a password policy overlay on my openldap 2.4.40 servers running RHEL7. I need to enforce the following: disable accounts that have been inactive for 180 days. In the past we were able to do this by simply adding the shadowInactive attribute to each account: shadowInactive 180. But with the new openldap, it appears there is no equivalent attribute?? OpenLDAP ppolicy has never supported that attribute, as far as I know. I believe you are looking for the contrib nssov overlay, which does support it. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent
Ulrich, Yes, I already have nis.ldif loaded. What else do you suggest? Thank you, Liz From: Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> Date: Monday, October 24, 2016 at 11:17 PM To: "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov>, "openldap-technical@openldap.org" <openldap-technical@openldap.org> Subject: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> schrieb am 24.10.2016 um 20:43 in Nachricht <0c90a104-2ef4-4aa6-8748-05b07154a...@jpl.nasa.gov<mailto:0c90a104-2ef4-4aa6-8748-05b07154a...@jpl.nasa.gov>>: Hello, I setup a password policy overlay on my openldap 2.4.40 servers running RHEL7. I need to enforce the following: disable accounts that have been inactive for 180 days. In the past we were able to do this by simply adding the shadowInactive attribute to each account: shadowInactive 180. But with the new openldap, it appears there is no equivalent attribute?? Why didn't you "grep shadowInactive /etc/openldap/schema/*"? It appears in nis.ldif, nis.schema, and rfc2307bis.schema. (I only have SLES11 SP4 here, but there shouldn't be a big difference) Ulrich http://www.openldap.org/doc/admin24/ http://www.zytrax.com/books/ldap/ch6/ppolicy.html Thank you, Liz
openldap 2.4.40 ppolicy module and shadowInactive equivalent
Hello, I setup a password policy overlay on my openldap 2.4.40 servers running RHEL7. I need to enforce the following: disable accounts that have been inactive for 180 days. In the past we were able to do this by simply adding the shadowInactive attribute to each account: shadowInactive 180. But with the new openldap, it appears there is no equivalent attribute?? http://www.openldap.org/doc/admin24/ http://www.zytrax.com/books/ldap/ch6/ppolicy.html Thank you, Liz
openldap 2.4.40 on RHEL7
Hello, Quick question about replication, I’m setting up an ldapclient to talk to my two LDAP servers which are replicating fine. To be able to talk to both LDAP servers, do I need to scp the server certificate (cert.pem) from both servers into the ldapclient /etc/openldap/cacerts directory? I’m looking at this documentation to configure the ldap client using sssd: https://www.certdepot.net/ldap-client-configuration-authconfig/ Thank you, Liz
Re: ldap user login attempt kills slapd service
I reported the bug to red hat. What is the openldap technical URL where all of the submitted requests are listed on? Thank you, Liz From: Matus Honek <mho...@redhat.com<mailto:mho...@redhat.com>> Date: Wednesday, May 11, 2016 at 4:13 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>>, "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: ldap user login attempt kills slapd service Hello, as OpenLDAP distributed with RHEL uses NSS for crypto (which is deprecated by OpenLDAP upstream community) please contact Red Hat customer support with the issue. There, please supply full debug-level logs from all servers and client. I have noticed the suppressed log lines from journal in logs you have supplied bellow, which is not sufficient. Thank you for your understanding. "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> writes: Openldap gurus: Here is my setup, LDAPSERVERS: I have two ldap servers running RHEL7.2 and openldap 2.4.40. Both servers are configured with multi-master replication. Ldaps is enabled and a ppolicy applied. LDAPCLIENT: My ldap client is running RHEL7.2 as well, sssd 1.13.0, and openldap client 2.4.40. I have been troubleshooting this problem for a while and can’t figure out why everytime I try to login to an ldap client with a test user account the slapd service on only one of my ldap servers gets killed. Both getent and ldapsearch return the expected information when ran on the ldap client: ldapclient ~]# getent passwd realtest realtest:*:1004:312:Liz RealTest:/home/real:/bin/tcsh ldapclient ~]# ldapsearch -x -s sub -b 'ou=People,dc=cluster,dc=sec312' '(uid=realtest)' # extended LDIF # # LDAPv3 # base
Re: ldap user login attempt kills slapd service
Quanah, Because I had an ssh issue while using openldap 2.4.39 and it was suggested I used openldap 2.4.40 that came with rhel72 instead. What do you suggest? Thank you, Liz _ From: Quanah Gibson-Mount <qua...@zimbra.com<mailto:qua...@zimbra.com>> Sent: Tuesday, May 10, 2016 4:03 PM Subject: Re: ldap user login attempt kills slapd service To: <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>>, Real, Elizabeth (392K) <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> --On Tuesday, May 10, 2016 11:58 PM + "Real, Elizabeth (392K)" <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> wrote: > > Openldap gurus: > > > Here is my setup, > > > LDAPSERVERS: I have two ldap servers running RHEL7.2 and openldap 2.4.40. > Both servers are configured with multi-master replication. Ldaps is > enabled and a ppolicy applied. The RHEL packages of OpenLDAP are known broken. Why are you using them? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
ldap user login attempt kills slapd service
Openldap gurus: Here is my setup, LDAPSERVERS: I have two ldap servers running RHEL7.2 and openldap 2.4.40. Both servers are configured with multi-master replication. Ldaps is enabled and a ppolicy applied. LDAPCLIENT: My ldap client is running RHEL7.2 as well, sssd 1.13.0, and openldap client 2.4.40. I have been troubleshooting this problem for a while and can’t figure out why everytime I try to login to an ldap client with a test user account the slapd service on only one of my ldap servers gets killed. Both getent and ldapsearch return the expected information when ran on the ldap client: ldapclient ~]# getent passwd realtest realtest:*:1004:312:Liz RealTest:/home/real:/bin/tcsh ldapclient ~]# ldapsearch -x -s sub -b 'ou=People,dc=cluster,dc=sec312' '(uid=realtest)' # extended LDIF # # LDAPv3 # base
add/load syncprov overlay
Hello,
I am setting up multi-master replication between two openldap servers and when
I try to add syncprov overlay to my second server I get this error:
# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5_addSyncProv.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=syncprov,olcDatabase={0}config,cn=config"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax
Per the documentation
(http://www.openldap.org/doc/admin24/replication.html#N-Way Multi-Master) you
are supposed to add syncprov to the configuration.
Here are the contents of the ldif file:
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
Both servers are running RHEL7 and openldap 2.4.40.
Please advise!
Thank you,
Liz
elizabeth.r...@jpl.nasa.gov
Re: Allow users to change ldap password with passwd
I have reinstalled openldap and applied slapo-ppolicy carefully looking at man pages and the configuration. How do I then apply this to existing openldap accounts? Thank you, Liz From: Michael Ströder <mich...@stroeder.com<mailto:mich...@stroeder.com>> Date: Monday, September 28, 2015 at 10:57 PM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>>, "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: Allow users to change ldap password with passwd Elizabeth, sorry, your wording does not result in any valid interpretation on my side. Especially you obfuscated too much. To see what's really going on you should again carefully examine your configuration, slapd logs and check the command-lines more carefully. Ciao, Michael. Real, Elizabeth (392K) wrote: Michael, I modified the command and was able to implement the password policy using: # ldapadd -x -W -D cn=,dc=,dc= -f passwordPolicy.ldif Verified the policy was applied: # ldapsearch -x -D cn=,dc=,dc= -H ldap:// -b dc=,dc= -W # real, People, . dn: uid=real,ou=People,dc=,dc= uid: real homeDirectory: /home/real memberUid: real … … # policies, . dn: cn=policies,dc=cluster,dc=sec312 objectClass: pwdPolicy objectClass: person objectClass: top cn:: cG9saWNpZXMg sn: policies pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 3600 pwdInHistory: 10 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 7776000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: FALSE pwdSafeModify: FALSE # search result search: 2 result: 0 Success # numResponses: 598 # numEntries: 597 TEST: I reset the password for user ‘real’ an ldap client using passwd, the password was successfully changed. However, the new user password did not change on the ldap server. It appears that the policy is not updating the ou where my user ‘real’ belongs to. Maybe it’s got to do with my ldap tree and where I configured my password policy (cn=policies), this is how it is now: dc=, dc= cn=policies … … ou=People … … Thank you, Liz From: Michael Ströder <mich...@stroeder.com<mailto:mich...@stroeder.com><mailto:mich...@stroeder.com>> Date: Thursday, September 24, 2015 at 11:42 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov><mailto:elizabeth.r...@jpl.nasa.gov>>, "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org><mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org><mailto:openldap-technical@openldap.org>> Subject: Re: Allow users to change ldap password with passwd Real, Elizabeth (392K) wrote: I replaced ou with cn, tried loading the ldif and got this message: # ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f passwordPolicy.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=policies,dc=*,dc=*" ldap_add: Insufficient access (50) additional info: no write access to parent I guess you want to use another bind-DN with -D when writing to your normal DB backend / naming context dc=*,dc=*. And defining -Y and -D together does not make sense. Please consult the man page and look at various bind methods more closely. Ciao, Michael. -- Michael Ströder Klauprechtstr. 11 Dipl.-Inform. D-76137 Karlsruhe, Germany Tel.: +49 721 8304316 Mobil: +49 170 2391920 E-Mail: mich...@stroeder.com<mailto:mich...@stroeder.com> http://www.stroeder.com
Re: Allow users to change ldap password with passwd
Michael, I modified the command and was able to implement the password policy using: # ldapadd -x -W -D cn=,dc=,dc= -f passwordPolicy.ldif Verified the policy was applied: # ldapsearch -x -D cn=,dc=,dc= -H ldap:// -b dc=,dc= -W # real, People, . dn: uid=real,ou=People,dc=,dc= uid: real homeDirectory: /home/real memberUid: real … … # policies, . dn: cn=policies,dc=cluster,dc=sec312 objectClass: pwdPolicy objectClass: person objectClass: top cn:: cG9saWNpZXMg sn: policies pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 3600 pwdInHistory: 10 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 7776000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: FALSE pwdSafeModify: FALSE # search result search: 2 result: 0 Success # numResponses: 598 # numEntries: 597 TEST: I reset the password for user ‘real’ an ldap client using passwd, the password was successfully changed. However, the new user password did not change on the ldap server. It appears that the policy is not updating the ou where my user ‘real’ belongs to. Maybe it’s got to do with my ldap tree and where I configured my password policy (cn=policies), this is how it is now: dc=, dc= cn=policies … … ou=People … … Thank you, Liz From: Michael Ströder <mich...@stroeder.com<mailto:mich...@stroeder.com>> Date: Thursday, September 24, 2015 at 11:42 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>>, "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: Allow users to change ldap password with passwd Real, Elizabeth (392K) wrote: I replaced ou with cn, tried loading the ldif and got this message: # ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f passwordPolicy.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=policies,dc=*,dc=*" ldap_add: Insufficient access (50) additional info: no write access to parent I guess you want to use another bind-DN with -D when writing to your normal DB backend / naming context dc=*,dc=*. And defining -Y and -D together does not make sense. Please consult the man page and look at various bind methods more closely. Ciao, Michael.
Re: Allow users to change ldap password with passwd
I replaced ou with cn, tried loading the ldif and got this message: # ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f passwordPolicy.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=policies,dc=*,dc=*" ldap_add: Insufficient access (50) additional info: no write access to parent Thank you, Liz From: Michael Ströder <mich...@stroeder.com<mailto:mich...@stroeder.com>> Date: Thursday, September 24, 2015 at 11:12 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>>, "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: Allow users to change ldap password with passwd Real, Elizabeth (392K) wrote: This is the passwordPolicy.ldif: dn: ou=policies,dc=*,dc=* objectClass: pwdPolicy objectClass: person objectClass: top cn: policies sn: policies If that is what you want to use you cannot use ou for forming the RDN. Simply use instead dn: cn=policies,dc=*,dc=* to match your entry. Ciao, Michael.
Re: Allow users to change ldap password with passwd
This is the passwordPolicy.ldif: dn: ou=policies,dc=*,dc=* objectClass: pwdPolicy objectClass: person objectClass: top cn: policies sn: policies pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 3600 #pwdFailureCountInterval: 30 #pwdGraceAuthNLimit: 5 pwdInHistory: 10 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 7776000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: FALSE pwdSafeModify: FALSE Thank you, Liz From: Michael Ströder <mich...@stroeder.com<mailto:mich...@stroeder.com>> Date: Thursday, September 24, 2015 at 10:56 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>>, "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: Allow users to change ldap password with passwd Real, Elizabeth (392K) wrote: # ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f passwordPolicy.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "ou=policies,dc=*,dc=*" ldap_add: Object class violation (65) additional info: attribute 'ou' not allowed How does passwordPolicy.ldif look like? What's the set of object classes used? Ciao, Michael.
Allow users to change ldap password with passwd
This is my setup:
Server: Openldap 2.4.39 installed on RHEL7
Ldap clients: RHEL7 and RHEL5
I set up this directive on the ldap clients (/etc/sssd/sssd.conf) to prevent
users with expired accounts to login: ldap_pwd_policy = shadow. This works as
expected.
Now I need to allow users to reset their ldap password after logging in to an
ldap client. This is what is logged when a user attempts to reset their
password using passwd:
rhel7 ldap client:
# passwd
Changing password for user real
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
rhel7 ldap server: /var/log/secure
pam_unix(passwd:chauthtok): user “real” does not exist in the /etc/passwd
pam_sss(passwd:chauthtok): Password change failed for user real: 28
(Module is unknown)
Gkr-pam: couldn’t update the login keyring password: no old password was
Entered
In an attempt to allow users to change their ldap password, i edited my ACL on
the ldap server and added 'shadowLastChange':
dn: olcDatabase={2}hdb,cn=config
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
dn.base="cn=Alien,dc=cluster,dc=sec312" write by anonymous auth by * none
olcAccess: {1}to * by self write by dn.base="cn=Alien,dc=cluster,dc=sec312"
write by * read
However that did not work, on the ldap clients I get this on the logs:
pam_unix(sshd:auth): authentication failure
pam_sss(sshd:auth): authentication failure
pam_sss(sshd:auth): received for user reaL 4 (System error)
This is the /etc/pam.d/system-auth file on the rhel7 ldap client:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authrequired pam_env.so
authsufficientpam_fprintd.so
authsufficientpam_unix.so try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so use_first_pass
authrequired pam_deny.so
account required pam_unix.so broken_shadow
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
passwordrequisite pam_pwquality.so try_first_pass local_users_only
retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 authtok_type=
passwordsufficientpam_unix.so sha512 shadow try_first_pass use_authtok
passwordsufficientpam_sss.so use_authtok
passwordrequired pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet
use_uid
session required pam_unix.so
session optional pam_sss.so
~
What other directive do I need to set to allow users to reset their ldap
password when they call passwd?
Thank you,
Liz
Re: RHEL7 OpenLDAP server is not enforcing password expirations
Dan and openldap tech community: I’m using SSSD (pam_sss.so directives), the service is running and there are no issues there. I can verify that users can reset their passwords, however when an account is set to expire, that user is allowed to login via SSH. SSSD should be able to honor account expirations. I confirmed the SSH configuration is set to PasswordAuthentication YES and UsePAM YES. This is part of the /var/log/secure log from the RHEL7 ldap client: Sep 2 13:53:07 * sshd[2255]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=node22.cluster.sec312 user=real Sep 2 13:53:08 * sshd[2255]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=node22.cluster.sec312 user=real Sep 2 13:53:08 * sshd[2253]: Accepted keyboard-interactive/pam for real from 10.1.1.122 port 43950 ssh2 Sep 2 13:53:08 * sshd[2253]: pam_unix(sshd:session): session opened for user real by (uid=0) Sep 2 13:53:08 * sshd[2269]: error: Failed to allocate internet-domain X11 display socket. Any advise or suggestions will be greatly appreciated. Thank you, Liz From: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> Date: Monday, August 31, 2015 at 4:10 PM To: Dan White <dwh...@olp.net<mailto:dwh...@olp.net>> Cc: "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations Dan, I have RHEL5 ldap clients using pam_unix.so and pam_ldap.so directives and these do honor the ldap user password expiration, no issues at all. The /var/log/secure file shows: error: PAM: User account has expired However, the two RHEL7 ldap clients using the pam_unix.so and pam_sss.so directives do not even see/know that the user ldap password has expired. When I change the directive from pam_sss.so to pam_ldap.so, the client cannot communicate with the ldap server. RHEL5 /ETC/PAM.D/system-auth file: authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid >= 500 quiet authsufficientpam_ldap.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] pam_ldap.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type=LINUX minlen=8 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 passwordsufficientpam_unix.so md5 shadow nullok try_first_pass use_authtok md5 shadow remember=24 passwordsufficientpam_ldap.so use_authtok passwordrequired 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 RHEL7 CLIENTS /ETC/PAM.D/: password-auth file: auth sufficient pam_sss.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so system-auth file: auth sufficient pam_sss.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so Thank you, Liz From: Dan White <dwh...@olp.net<mailto:dwh...@olp.net>> Date: Friday, August 28, 2015 at 7:13 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> Cc: "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations On 08/27/15 22:56 +, Real, Elizabeth (392K) wrote: I’ve done a lot or research and re-read the OpenLDAP configuration guides but I cannot get my OpenLDAP 2.39 server to not allow users with expired passwords to login to ldap enabled clients. What directive in the /etc/pam.d/ files controls the users password expiration attribute? pam_unix or pam_ldap? That depends on your configuration. Consult the pam project's to determine that: http://www.linux-pam.org/ pam_ldap is a 3rd party product, so you'll need to consult it's documentation to see how expiration is handled, if at all. nssov, which is distributed with OpenLDAP, explicitly supports it. In the case you are using, or wish to use, pam_unix with an ldap nss module, expiration might be represented as an attribute underneath the user's DN. See
Re: RHEL7 OpenLDAP server is not enforcing password expirations
One more note, After a user changes their password, the shadowLastChange does not get updated on the ldap server. Thank you, Liz From: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> Date: Wednesday, September 2, 2015 at 1:58 PM To: "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations Dan and openldap tech community: I’m using SSSD (pam_sss.so directives), the service is running and there are no issues there. I can verify that users can reset their passwords, however when an account is set to expire, that user is allowed to login via SSH. SSSD should be able to honor account expirations. I confirmed the SSH configuration is set to PasswordAuthentication YES and UsePAM YES. This is part of the /var/log/secure log from the RHEL7 ldap client: Sep 2 13:53:07 * sshd[2255]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=node22.cluster.sec312 user=real Sep 2 13:53:08 * sshd[2255]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=node22.cluster.sec312 user=real Sep 2 13:53:08 * sshd[2253]: Accepted keyboard-interactive/pam for real from 10.1.1.122 port 43950 ssh2 Sep 2 13:53:08 * sshd[2253]: pam_unix(sshd:session): session opened for user real by (uid=0) Sep 2 13:53:08 * sshd[2269]: error: Failed to allocate internet-domain X11 display socket. Any advise or suggestions will be greatly appreciated. Thank you, Liz From: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> Date: Monday, August 31, 2015 at 4:10 PM To: Dan White <dwh...@olp.net<mailto:dwh...@olp.net>> Cc: "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations Dan, I have RHEL5 ldap clients using pam_unix.so and pam_ldap.so directives and these do honor the ldap user password expiration, no issues at all. The /var/log/secure file shows: error: PAM: User account has expired However, the two RHEL7 ldap clients using the pam_unix.so and pam_sss.so directives do not even see/know that the user ldap password has expired. When I change the directive from pam_sss.so to pam_ldap.so, the client cannot communicate with the ldap server. RHEL5 /ETC/PAM.D/system-auth file: authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid >= 500 quiet authsufficientpam_ldap.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] pam_ldap.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type=LINUX minlen=8 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 passwordsufficientpam_unix.so md5 shadow nullok try_first_pass use_authtok md5 shadow remember=24 passwordsufficientpam_ldap.so use_authtok passwordrequired 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 RHEL7 CLIENTS /ETC/PAM.D/: password-auth file: auth sufficient pam_sss.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so system-auth file: auth sufficient pam_sss.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so Thank you, Liz From: Dan White <dwh...@olp.net<mailto:dwh...@olp.net>> Date: Friday, August 28, 2015 at 7:13 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> Cc: "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations On 08/27/15 22:56 +, Real, Elizabeth (392K) wrote: I’ve done a lot or research and re-read the OpenLDAP configuration guides but I cannot get my OpenLDAP 2.39 server to not allow users with expired passwords to login to ldap enabled clients. What directive in the /e
Re: RHEL7 OpenLDAP server is not enforcing password expirations
Dan, I have RHEL5 ldap clients using pam_unix.so and pam_ldap.so directives and these do honor the ldap user password expiration, no issues at all. The /var/log/secure file shows: error: PAM: User account has expired However, the two RHEL7 ldap clients using the pam_unix.so and pam_sss.so directives do not even see/know that the user ldap password has expired. When I change the directive from pam_sss.so to pam_ldap.so, the client cannot communicate with the ldap server. RHEL5 /ETC/PAM.D/system-auth file: authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid >= 500 quiet authsufficientpam_ldap.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] pam_ldap.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type=LINUX minlen=8 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 passwordsufficientpam_unix.so md5 shadow nullok try_first_pass use_authtok md5 shadow remember=24 passwordsufficientpam_ldap.so use_authtok passwordrequired 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 RHEL7 CLIENTS /ETC/PAM.D/: password-auth file: auth sufficient pam_sss.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so system-auth file: auth sufficient pam_sss.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so Thank you, Liz From: Dan White <dwh...@olp.net<mailto:dwh...@olp.net>> Date: Friday, August 28, 2015 at 7:13 AM To: Elizabeth Real Chavez <elizabeth.r...@jpl.nasa.gov<mailto:elizabeth.r...@jpl.nasa.gov>> Cc: "openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>" <openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations On 08/27/15 22:56 +, Real, Elizabeth (392K) wrote: I’ve done a lot or research and re-read the OpenLDAP configuration guides but I cannot get my OpenLDAP 2.39 server to not allow users with expired passwords to login to ldap enabled clients. What directive in the /etc/pam.d/ files controls the users password expiration attribute? pam_unix or pam_ldap? That depends on your configuration. Consult the pam project's to determine that: http://www.linux-pam.org/ pam_ldap is a 3rd party product, so you'll need to consult it's documentation to see how expiration is handled, if at all. nssov, which is distributed with OpenLDAP, explicitly supports it. In the case you are using, or wish to use, pam_unix with an ldap nss module, expiration might be represented as an attribute underneath the user's DN. See its documentation for details. Setup: Server: RHEL7 OS Software: OpenLdap 2.4.39 server using slapd service Client: RHEL7 OS Software: enabled Ldap via authconfig, using sssd service -- Dan White
RHEL7 OpenLDAP server is not enforcing password expirations
Hello, I’ve done a lot or research and re-read the OpenLDAP configuration guides but I cannot get my OpenLDAP 2.39 server to not allow users with expired passwords to login to ldap enabled clients. What directive in the /etc/pam.d/ files controls the users password expiration attribute? pam_unix or pam_ldap? Setup: Server: RHEL7 OS Software: OpenLdap 2.4.39 server using slapd service Client: RHEL7 OS Software: enabled Ldap via authconfig, using sssd service Thank you, Liz
