Re: rwm bindDN context and ppolicy issues

[Kartik Subbarao]

On 6/23/22 4:29 PM, Quanah Gibson-Mount wrote:
If slapd segfaults, an ITS with clear reproduction steps should 
generally be filed. I would note that you have not specified the 
OpenLDAP release on which you encountered this problem.  There's been 
a lot of (relatively) recent work in fixing segfault items when using 
slapo-rwm, so it would be helpful to know what release you hit this on. 


I found a quick way to reproduce this on 2.5.12 (a small edit to 
tests/scripts/relay and tests/data/slapd-relay.conf) and reported this 
as ITS#9871.


Regards,

    -Kartik

Re: rwm bindDN context and ppolicy issues

[Kartik Subbarao]

On 6/23/22 4:29 PM, Quanah Gibson-Mount wrote:

[...]
I'm mulling over how much additional time to spend on this. rwm is a very
elegant solution to a current issue that could save me a bunch of 
time to

set up additional LDAP servers with the renamed data. If this is an
isolated bug for which a quick fix might be possible, I might 
investigate

further.

But if it's a thorny issue or just the tip of the iceberg of things 
where

rwm might break unexpectedly, then it may be better for me to consider
other options. OpenLDAP developers, what do your instincts say on this?


If slapd segfaults, an ITS with clear reproduction steps should 
generally be filed. I would note that you have not specified the 
OpenLDAP release on which you encountered this problem.  There's been 
a lot of (relatively) recent work in fixing segfault items when using 
slapo-rwm, so it would be helpful to know what release you hit this on.


Sorry -- I'm running 2.4.57+dfsg-2ubuntu1.

Regards,

    -Kartik

Re: rwm bindDN context and ppolicy issues

[Quanah Gibson-Mount]

--On Thursday, June 23, 2022 5:21 PM -0400 Kartik Subbarao 
 wrote:



I'm able to specify rwm bindDN rules without password-policy enabled just
fine, like this one:

rwm-rewriteContext bindDN
rwm-rewriteRule "^([^=]+)=([^@]+)@olddomain.com(.+),dc=olddomain,dc=com$"
"$1=$2...@newdomain.com$3,dc=newdomain,dc=com" ":@"

However, when I enable password policy (which also works fine on its
own), slapd segfaults.

I'm mulling over how much additional time to spend on this. rwm is a very
elegant solution to a current issue that could save me a bunch of time to
set up additional LDAP servers with the renamed data. If this is an
isolated bug for which a quick fix might be possible, I might investigate
further.

But if it's a thorny issue or just the tip of the iceberg of things where
rwm might break unexpectedly, then it may be better for me to consider
other options. OpenLDAP developers, what do your instincts say on this?


If slapd segfaults, an ITS with clear reproduction steps should generally 
be filed. I would note that you have not specified the OpenLDAP release on 
which you encountered this problem.  There's been a lot of (relatively) 
recent work in fixing segfault items when using slapo-rwm, so it would be 
helpful to know what release you hit this on.


Regards,
Quanah

rwm bindDN context and ppolicy issues

[Kartik Subbarao]

I'm able to specify rwm bindDN rules without password-policy enabled 
just fine, like this one:


rwm-rewriteContext bindDN
rwm-rewriteRule 
"^([^=]+)=([^@]+)@olddomain.com(.+),dc=olddomain,dc=com$" 
"$1=$2...@newdomain.com$3,dc=newdomain,dc=com" ":@"


However, when I enable password policy (which also works fine on its 
own), slapd segfaults. From doing a backtrace and stepping through the 
code, it looks like the crux of the issue is that the mdb_info struct 
ends up with garbage data:


struct mdb_info *mdb = (struct mdb_info *) op->o_bd->be_private;

mi_dbenv_home and mi_monitor have random stuff in them.

I'm mulling over how much additional time to spend on this. rwm is a 
very elegant solution to a current issue that could save me a bunch of 
time to set up additional LDAP servers with the renamed data. If this is 
an isolated bug for which a quick fix might be possible, I might 
investigate further.


But if it's a thorny issue or just the tip of the iceberg of things 
where rwm might break unexpectedly, then it may be better for me to 
consider other options. OpenLDAP developers, what do your instincts say 
on this?


Regards,

    -Kartik

Re: ppolicy issues

[Quanah Gibson-Mount]

--On Tuesday, November 3, 2020 5:30 PM +0100 Kresimir Petkovic 
 wrote:




password-hash {CLEARTEXT}


As documented in slapd.conf(5), this is a GLOBAL configuration option that 
applies to all databases.  You'd need to set up two different slapd 
instances for this case.


Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

ppolicy issues

[Kresimir Petkovic]

Hi guys,

I'm having issues trying to setup multiple databases with different 
password hash algos.


My first db has to have plaintext passwords and I'm using

password-hash {CLEARTEXT}
overlay ppolicy
ppolicy_hash_cleartext

and my second one needs to use SHA for password hash. I have it like 
this in slapd.conf


password-hash {SHA}
overlay ppolicy
ppolicy_hash_cleartext

When I insert user in ldap via ldapadd it stores plaintext password for 
that user in userPassword attribute.


Can I have different password-hash directives for each database? Or my 
ppolicy overlay doesn't work.



Thanks in advance.


BR,

Kreso

Re: ppolicy issues

[Andrew Findlay]

On Tue, Aug 08, 2017 at 07:46:02PM +0200, Michael Ströder wrote:

> Yes, slapo-ppolicy config can be different per database.
> Also consider setting password-hash / password-crypt-salt-format per database.

Be aware that you must put ppolicy entries (including default entries)
in the same database as the entries that they will govern. Thus you need
at least one policy entry in each backend DB.

See ITS#7262 for details:

http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7262;selectid=7262

Andrew
-- 
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---

Re: ppolicy issues

[Quanah Gibson-Mount]

--On Tuesday, August 08, 2017 8:46 PM +0200 Michael Ströder 
 wrote:



r0m5 wrote:

1) I use "olcPPolicyHashCleartext: TRUE" so the clients send cleartext
passwords and slapd hashes it before writing in database for security
reasons (and slapd can perform password quality checks).


There's a nasty issue with this configuration option when using
slapo-accesslog:

If the client sends the clear-text 'userPassword' value but the password
quality check fails and therefore the modify request fails with
constraintViolation the clear-text 'userPassword' value will be written
to accesslog DB. In case of successful modification only the hashed
'userPassword' value is written to accesslog DB. :-/


Is there an ITS on this?  If not, there should be.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: ppolicy issues

[Michael Ströder]

r0m5 wrote:
> 1) I use "olcPPolicyHashCleartext: TRUE" so the clients send cleartext 
> passwords and
> slapd hashes it before writing in database for security reasons (and slapd 
> can perform
> password quality checks).

There's a nasty issue with this configuration option when using slapo-accesslog:

If the client sends the clear-text 'userPassword' value but the password 
quality check
fails and therefore the modify request fails with constraintViolation the 
clear-text
'userPassword' value will be written to accesslog DB. In case of successful 
modification
only the hashed 'userPassword' value is written to accesslog DB. :-/

> But I need exceptions for that. Indeed for some reason I have
> to use EAP-MD5 and EAP-MD5 makes it mandatory to store cleartext passwords in 
> LDAP. So I
> would like to find a way to use "olcPPolicyHashCleartext: TRUE" on some OUs, 
> but not on
> others. Any way to do that ?

AFAIK not feasible within the same database.

BTW: I'd also like to see those slapo-ppolicy parameters along with slapd.conf 
directives
password-hash / password-crypt-salt-format to be read from the 'pwdPolicy' 
entry for
exactly this reason.

> Maybe setting up a second mdb database with a different ppolicy overlay 
> configuration 
> ("olcPPolicyHashCleartext: FALSE") and the same olcSuffix than the existing 
> database ?
> A search on the base DN would then need to cover the two databases.

Yes, slapo-ppolicy config can be different per database.
Also consider setting password-hash / password-crypt-salt-format per database.

> 2) syncrepl of (for example) |pwdChangedTime|. This attribute is not synced 
> to my
> consumers,

Works for me (with LTB builds of OpenLDAP 2.4.45 on Debian Jessie).

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

ppolicy issues

[r0m5]

Hello ! 

I have two issues regarding ppolicy. I use debian jessie backports
(slapd 2.4.44). 

1) I use "olcPPolicyHashCleartext: TRUE" so the clients send cleartext
passwords and slapd hashes it before writing in database for security
reasons (and slapd can perform password quality checks). But I need
exceptions for that. Indeed for some reason I have to use EAP-MD5 and
EAP-MD5 makes it mandatory to store cleartext passwords in LDAP. So I
would like to find a way to use "olcPPolicyHashCleartext: TRUE" on some
OUs, but not on others. Any way to do that ? 

Maybe setting up a second mdb database with a different ppolicy overlay
configuration ("olcPPolicyHashCleartext: FALSE") and the same olcSuffix
than the existing database ? A search on the base DN would then need to
cover the two databases. 

2) syncrepl of (for example) pwdChangedTime. This attribute is not
synced to my consumers, even though the schema is imported on the
consumer, the module is configured and the overlay is also configured.
Syncrepl for attributes non related to ppolicy works fine. Somehow
ppolicy is working on the consumers though, since after a failed bindind
on the consumer I can see pwdFailureTime on this consumer. Any idea ? (I
tried slapd -d -1 but didn't find something relevant, I can paste the
resuslts here if needed) 

Regards, 

* provider 

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 fb6dde8c
dn: olcOverlay={1}ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr
olcPPolicyHashCleartext: TRUE
structuralObjectClass: olcPPolicyConfig
entryUUID: 3528350a-0f9a-1037-89da-e5a4ba1189f6
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170807085738Z
entryCSN: 20170807085738.529346Z#00#000#00
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170807085738Z 

* provider 

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 295fad94
dn: cn=module{2}
objectClass: olcModuleList
cn: module{2}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}ppolicy.la
structuralObjectClass: olcModuleList
entryUUID: 6e4da4de-0a3e-1037-9174-b1e488f02d8a
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170731131804Z
entryCSN: 20170731131804.891811Z#00#000#00
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170731131804Z 

* consumer 

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 4758a296
dn: olcOverlay={0}ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr
olcPPolicyHashCleartext: TRUE
structuralObjectClass: olcPPolicyConfig
entryUUID: e5a3785a-0d8c-1037-908e-d903a2095e18
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170804181719Z
entryCSN: 20170804181719.336420Z#00#000#00
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170804181719Z 

* consumer 

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 d0060305
dn: cn=module{1}
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}ppolicy.la
structuralObjectClass: olcModuleList
entryUUID: e560e800-0d8c-1037-908d-d903a2095e18
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20170804181718Z
entryCSN: 20170804181718.900179Z#00#000#00
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170804181718Z 

* consumer 

olcSyncrepl: {0}rid=2 provider=ldap://ldap-provider-dev.acme
starttls=critical 
tls_reqcert=demand bindmethod=simple
binddn="cn=replication,ou=Applications
,dc=acme,dc=fr" credentials=xxx searchbase="dc=acme,dc=fr" schemache
cking=off type=refreshAndPersist filter="(objectClass=*)" attrs="*"
scope=s
ub retry="60 +"

Re: PAM authentication and PPolicy issues

[Clément OUDOT]

2012/6/19 Francesco Belli francesco.be...@vegaspace.com:
 Hi Everybody,

 I'm have some RHEL6 machines that use an LDAP server to authenticate. I need 
 to introduce in the server some checks on passwords using PPolicy. PPolicy 
 works fine, the problem is that to use pwdCheckQuality and pwdInHistory I 
 need to save passwords in clear text in the LDAP server. I did a search to 
 find out if there is a way to let PAM to use clear text password to 
 authenticate but it seems that it sends SHA hashes, so authentication fails. 
 Do you have any suggestion?

Do man pam_ldap and search for pam_password parameter.

Clément.

Re: PAM authentication and PPolicy issues

[Clément OUDOT]

2012/6/20 Francesco Belli francesco.be...@vegaspace.com:
 Hi Clement,
 I already used pam_password directive, I set it to cleartext, but this 
 parameter is used for password change and not for authentication. As man 
 pam_ldap says Specifies the password change protocol to use, so not the 
 authentication method. Now my situation is that I have some users in the LDAP 
 server that they have a SHA hash in the userPassword field, and they are 
 correctly authenticated, others that have a clear text password and cannot be 
 authenticated via PAM.

Password scheme used in LDAP directory do not prevent any application
to authenticate to LDAP. Dig into logs to see what is the real reason
of your problem.

Clément.

Re: PAM authentication and PPolicy issues

[Patrick Hemmer]

Sent: Wed Jun 20 2012 04:36:03 GMT-0400 (EDT)
From: Clément OUDOT clem.ou...@gmail.com
To: Francesco Belli francesco.be...@vegaspace.com 
openldap-technical@openldap.org

Subject: Re: PAM authentication and PPolicy issues

2012/6/20 Francesco Bellifrancesco.be...@vegaspace.com:

Hi Clement,
I already used pam_password directive, I set it to cleartext, but this parameter is used 
for password change and not for authentication. As man pam_ldap says Specifies the 
password change protocol to use, so not the authentication method. Now my situation 
is that I have some users in the LDAP server that they have a SHA hash in the 
userPassword field, and they are correctly authenticated, others that have a clear text 
password and cannot be authenticated via PAM.


Password scheme used in LDAP directory do not prevent any application
to authenticate to LDAP. Dig into logs to see what is the real reason
of your problem.

Clément.
In addition, it is not true that the password must be stored in 
cleartext for pwdCheckQuality and pwdInHistory to work. Storing 
passwords in cleartext is bad.


-Patrick

Re: PAM authentication and PPolicy issues

[Clément OUDOT]

2012/6/20 Patrick Hemmer openl...@stormcloud9.net:


 Sent: Wed Jun 20 2012 04:36:03 GMT-0400 (EDT)
 From: Clément OUDOT clem.ou...@gmail.com
 To: Francesco Belli francesco.be...@vegaspace.com
 openldap-technical@openldap.org

 Subject: Re: PAM authentication and PPolicy issues

 2012/6/20 Francesco Belli francesco.be...@vegaspace.com:

 Hi Clement,
 I already used pam_password directive, I set it to cleartext, but this
 parameter is used for password change and not for authentication. As man
 pam_ldap says Specifies the password change protocol to use, so not the
 authentication method. Now my situation is that I have some users in the
 LDAP server that they have a SHA hash in the userPassword field, and they
 are correctly authenticated, others that have a clear text password and
 cannot be authenticated via PAM.

 Password scheme used in LDAP directory do not prevent any application
 to authenticate to LDAP. Dig into logs to see what is the real reason
 of your problem.

 Clément.

 In addition, it is not true that the password must be stored in cleartext
 for pwdCheckQuality and pwdInHistory to work. Storing passwords in cleartext
 is bad.

They can be stored hashed, but they must be sent as clear text in the
modification operation so that OpenLDAP can check the quality (min
size for example). The ppolicy overlay is then able to hash them when
storing accepted password in database.

Clément.

RE: PAM authentication and PPolicy issues

[Francesco Belli]

Sorry Patric,
Maybe the reference that I have is wrong, I'm using the book Mastering 
OpenLDAP by Matt Butcher that in chapter 6 at pag 323 says if you store 
password in plain text in the directory then the policy overlay can be 
configured to maintain a password history. Now I'm using 
http://www.openldap.org/software/man.cgi?query=slapo-ppolicyapropos=0sektion=5manpath=OpenLDAP+2.3-Releaseformat=html
 as reference for ppolicy. My authentication error was a trivial problem on an 
objectClass: posixAccount. Now I'm testing with SHA stored passwords the 
pwdInHistory directive. Thanks for the suggestions,
Regards
Francesco



From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Patrick Hemmer
Sent: 20 June 2012 14:17
To: openldap-technical@openldap.org
Subject: Re: PAM authentication and PPolicy issues



Sent: Wed Jun 20 2012 04:36:03 GMT-0400 (EDT)
From: Clément OUDOT clem.ou...@gmail.commailto:clem.ou...@gmail.com
To: Francesco Belli 
francesco.be...@vegaspace.commailto:francesco.be...@vegaspace.com 
openldap-technical@openldap.orgmailto:openldap-technical@openldap.org
Subject: Re: PAM authentication and PPolicy issues

2012/6/20 Francesco Belli 
francesco.be...@vegaspace.commailto:francesco.be...@vegaspace.com:

Hi Clement,

I already used pam_password directive, I set it to cleartext, but this 
parameter is used for password change and not for authentication. As man 
pam_ldap says Specifies the password change protocol to use, so not the 
authentication method. Now my situation is that I have some users in the LDAP 
server that they have a SHA hash in the userPassword field, and they are 
correctly authenticated, others that have a clear text password and cannot be 
authenticated via PAM.



Password scheme used in LDAP directory do not prevent any application

to authenticate to LDAP. Dig into logs to see what is the real reason

of your problem.



Clément.
In addition, it is not true that the password must be stored in cleartext for 
pwdCheckQuality and pwdInHistory to work. Storing passwords in cleartext is bad.

-Patrick

Re: PAM authentication and PPolicy issues

[Andrew Findlay]

On Wed, Jun 20, 2012 at 01:44:05PM +, Francesco Belli wrote:

 Now I’m using http://
 www.openldap.org/software/man.cgi?query=slapo-ppolicyapropos=0sektion=5
 manpath=OpenLDAP+2.3-Releaseformat=html as reference for ppolicy. My

The 2.3 release series is very old now. You should be using 2.4 and
the 2.4 manuals:

http://www.openldap.org/software/man.cgi

 I’m testing with SHA stored passwords the pwdInHistory directive.

SHA is much better than plaintext, but best practice is to use a
salted hash - SSHA in this case. The use of salt frustrates attempts
to build a dictionary to invert stolen password records. If LinkedIn
had used salt in their password hashes they would now be in less
trouble as a result of the recent disclosure...


https://community.qualys.com/blogs/securitylabs/2012/06/08/lessons-learned-from-cracking-2-million-linkedin-passwords

Andrew
-- 
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---

PAM authentication and PPolicy issues

[Francesco Belli]

Hi Everybody,

I'm have some RHEL6 machines that use an LDAP server to authenticate. I need to 
introduce in the server some checks on passwords using PPolicy. PPolicy works 
fine, the problem is that to use pwdCheckQuality and pwdInHistory I need to 
save passwords in clear text in the LDAP server. I did a search to find out if 
there is a way to let PAM to use clear text password to authenticate but it 
seems that it sends SHA hashes, so authentication fails. Do you have any 
suggestion?

Thanks,
Francesco