subject:"Re\: ppolicy"

Re: ppolicy

2010-04-22 Thread Ralf Haferkamp

Hi,

Am Mittwoch 21 April 2010 17:50:31 schrieb Frank Swasey:
> We are setting up a new service that is going to actually hold
> passwords in the OpenLDAP database instead of using Kerberos (via
> sasl and saslauthd).  To that end, I'm investigating ppolicy.
> 
> However, what I haven't found in the man page (slapo-ppolicy), or the
> Admin Guide, or the FAQ-O-Matic is whether I need to configure ppolicy
> on the master and the replicas or just the master.
> 
> My assumption is that I need to set up ppolicy on the replicas as well
> as the master -- otherwise those pwd* operational attributes are not
> going to be legal on the replica and I'll get in trouble.  I haven't
> set up a test environment with a replica yet -- so, I'm asking here.
Yes you have to set it up on every server.
 
> I also see in the FAQ that ppolicy only works on OpenLDAP versions
> greater than 2.3 (item 2 of the ppolicy checklist).  So, I'm sensing
> that ppolicy in OpenLDAP v2.3.x is not really completely functional?
Hm, to my knowledge ppolicy was working fine with 2.3.x. But if you are 
setting up a new service it would be wise to go with the latest stable 
release IMO.

> Am I reading too much into the entry in the FAQ?
Hm, I think that entry it's plain wrong. Unless somebody else vetos I am 
going to remove that entry.

-- 
Ralf

Re: ppolicy

2010-04-22 Thread Buchan Milne

On Wednesday, 21 April 2010 16:50:31 Frank Swasey wrote:
> We are setting up a new service that is going to actually hold passwords
> in the OpenLDAP database instead of using Kerberos (via sasl and
> saslauthd).  To that end, I'm investigating ppolicy.
> 
> However, what I haven't found in the man page (slapo-ppolicy), or the
> Admin Guide, or the FAQ-O-Matic is whether I need to configure ppolicy
> on the master and the replicas or just the master.

Both. Ignoring the "upstream" replication of state attributes, to use ppolicy 
effectively at all, any server which receives simple binds must have ppolicy 
active.

> My assumption is that I need to set up ppolicy on the replicas as well
> as the master -- otherwise those pwd* operational attributes are not
> going to be legal on the replica and I'll get in trouble.

I think have ppolicy schema loaded would be sufficient to allow the attributes, 
but do you want DNs that have been locked out to be able to authenticate on 
your replicas? If not, you need ppolicy active on them.

> I haven't set
> up a test environment with a replica yet -- so, I'm asking here.
> 
> I also see in the FAQ that ppolicy only works on OpenLDAP versions
> greater than 2.3 (item 2 of the ppolicy checklist).  So, I'm sensing
> that ppolicy in OpenLDAP v2.3.x is not really completely functional?  Am
> I reading too much into the entry in the FAQ?

ppolicy does work on 2.3.x. However, the recent ppolicy_forward_updates option 
on replicas (since 2.4.17 I think) may make things quite a bit easier.

Regards,
Buchan

Re: PPOlicy Keeps On Throwing Segfault

2009-06-11 Thread Greek Ordono

Try to rebuild the deb package and use openssl instead of gnutls.

--

Greek Ordono 

myppa: launchpad.net/~grexk/+archive/ppa

--- On Tue, 6/9/09, Carlo Camerino  wrote:

From: Carlo Camerino 
Subject: PPOlicy Keeps On Throwing Segfault
To: [email protected]
Date: Tuesday, June 9, 2009, 2:31 PM

Hi, 

I keep on getting  segfault when I try to configure ppolicy for ubuntu 8.10. I 
don't know what's wrong but it just keeps on crashing everytime i try to login 
to openldap.

the configuration i set are as follows.



moduleload ppolicy.la

overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=nodomain"

i keep on getting this error. can anyone help me?
thanks




Jun  9 15:58:27 sxi-ubuntu2 slapd[5733]: hdb_db_open: database "dc=nodomain": 
unclean shutdown detected; attempting recovery.
Jun  9 15:58:27 sxi-ubuntu2 slapd[5733]: slapd starting
Jun  9 16:00:34 sxi-ubuntu2 kernel: [3718103.656090] slapd[5735]: segfault at 
b6935ef0 ip b7eec017 sp b6935ec0 error 6 in slapd[b7e45000+127000]


Jun  9 16:01:40 sxi-ubuntu2 slapd[5799]: @(#) $OpenLDAP: slapd 2.4.11 (Nov  8 
2008 09:42:18) $ 
^ibui...@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd
Jun  9 16:01:40 sxi-ubuntu2 slapd[5801]: slapd starting


Jun  9 16:01:49 sxi-ubuntu2 kernel: [3718178.424949] slapd[5803]: segfault at 
b6a50ef0 ip b8007017 sp b6a50ec0 error 6 in slapd[b7f6+127000]
Jun  9 16:03:56 sxi-ubuntu2 slapd[5856]: @(#) $OpenLDAP: slapd 2.4.11 (Nov  8 
2008 09:42:18) $ 
^ibui...@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd


Jun  9 16:03:56 sxi-ubuntu2 slapd[5857]: slapd starting
Jun  9 16:04:04 sxi-ubuntu2 kernel: [3718314.043966] slapd[5859]: segfault at 
b68d5ef0 ip b7e8c017 sp b68d5ec0 error 6 in slapd[b7de5000+127000]

Re: PPOlicy Keeps On Throwing Segfault

2009-06-11 Thread Carlo Camerino

i got a new package from ubuntu ppa and it worked.i had to upgrade to a
newer version

On Thu, Jun 11, 2009 at 1:07 PM, Greek Ordono  wrote:

> Try to rebuild the deb package and use openssl instead of gnutls.
>
> --
> Greek Ordono
> myppa: launchpad.net/~grexk/+archive/ppa
>
> --- On *Tue, 6/9/09, Carlo Camerino * wrote:
>
>
> From: Carlo Camerino 
> Subject: PPOlicy Keeps On Throwing Segfault
> To: [email protected]
> Date: Tuesday, June 9, 2009, 2:31 PM
>
>
> Hi,
>
> I keep on getting  segfault when I try to configure ppolicy for ubuntu
> 8.10. I don't know what's wrong but it just keeps on crashing everytime i
> try to login to openldap.
>
> the configuration i set are as follows.
>
> moduleload ppolicy.la
>
> overlay ppolicy
> ppolicy_default "cn=default,ou=policies,dc=nodomain"
>
> i keep on getting this error. can anyone help me?
> thanks
>
>
> Jun  9 15:58:27 sxi-ubuntu2 slapd[5733]: hdb_db_open: database
> "dc=nodomain": unclean shutdown detected; attempting recovery.
> Jun  9 15:58:27 sxi-ubuntu2 slapd[5733]: slapd starting
> Jun  9 16:00:34 sxi-ubuntu2 kernel: [3718103.656090] slapd[5735]: segfault
> at b6935ef0 ip b7eec017 sp b6935ec0 error 6 in slapd[b7e45000+127000]
> Jun  9 16:01:40 sxi-ubuntu2 slapd[5799]: @(#) $OpenLDAP: slapd 2.4.11 (Nov
> 8 2008 09:42:18) $ ^ibui...@palmer
> :/build/buildd/openldap-2.4.11/debian/build/servers/slapd
> Jun  9 16:01:40 sxi-ubuntu2 slapd[5801]: slapd starting
> Jun  9 16:01:49 sxi-ubuntu2 kernel: [3718178.424949] slapd[5803]: segfault
> at b6a50ef0 ip b8007017 sp b6a50ec0 error 6 in slapd[b7f6+127000]
> Jun  9 16:03:56 sxi-ubuntu2 slapd[5856]: @(#) $OpenLDAP: slapd 2.4.11 (Nov
> 8 2008 09:42:18) $ ^ibui...@palmer
> :/build/buildd/openldap-2.4.11/debian/build/servers/slapd
> Jun  9 16:03:56 sxi-ubuntu2 slapd[5857]: slapd starting
> Jun  9 16:04:04 sxi-ubuntu2 kernel: [3718314.043966] slapd[5859]: segfault
> at b68d5ef0 ip b7e8c017 sp b68d5ec0 error 6 in slapd[b7de5000+127000]
>
>
>

Re: PPOlicy Keeps On Throwing Segfault

2009-06-11 Thread Michael Ströder

Carlo Camerino wrote:
> 
> I keep on getting  segfault when I try to configure ppolicy for ubuntu
> 8.10. I don't know what's wrong but it just keeps on crashing everytime
> i try to login to openldap.
> [..]
> Jun  9 16:01:40 sxi-ubuntu2 slapd[5799]: @(#) $OpenLDAP: slapd 2.4.11

Not sure whether that fixes your particular problem. But you really
should try first whether a more recent OpenLDAP release compiled from
source also crashes. As for now the latest official source release is
2.4.16.
(Currently you might even try with CVS branch OPENLDAP_REL_ENG_2_4 since
it's right before the upcoming release 2.4.17.)

Ciao, Michael.

Re: ppolicy force account expiration

2009-04-18 Thread Daniel Durgin


Thank you for the input.

-dan

Guillaume Rousse wrote:

Daniel Durgin a écrit :

Hello,

Does any one know how to force the expiration of an account within the 
slapo-ppolicy overlay?


For instance, says that an employee's last day with the organization 
ends at 5PM, is there a flag I can set to deactivate an account at 
that time.

Everything depends what you define by 'deactivate' exactly.

You can use shadowAccount class shadowExpire attribute to a given date 
to make pam reject logins attempts after this date. But that is only a 
client-side effect for a specific application.


You can use ppolicy pwdAccountLockedTime attribute to 0101Z 
value to make all bind operation fails, but using an external mean, such 
as a cron task, as it is impossible to set a date in the future and hope 
ppolicy will start honours it once this time is reached.


You could also use the smbkrb5 overlay, and rely on kerberos-specific 
password expiration date to make autentication fails server-side, this 
time after a given date.


In both case, the account will still exists in the directory, meaning 
the user will still be part of mailing list whose membership is based on 
ldap requests, for instance.


I'd like also to have a way to first lock password server-side, the same 
way pwdAccountLockedTime does, but with a fixed date, AND have a boolean 
flag valid/invalid for easy selection of valid account in queries.

Re: ppolicy force account expiration

2009-04-16 Thread Guillaume Rousse


Daniel Durgin a écrit :

Hello,

Does any one know how to force the expiration of an account within the 
slapo-ppolicy overlay?


For instance, says that an employee's last day with the organization 
ends at 5PM, is there a flag I can set to deactivate an account at that 
time.

Everything depends what you define by 'deactivate' exactly.

You can use shadowAccount class shadowExpire attribute to a given date 
to make pam reject logins attempts after this date. But that is only a 
client-side effect for a specific application.


You can use ppolicy pwdAccountLockedTime attribute to 0101Z 
value to make all bind operation fails, but using an external mean, such 
as a cron task, as it is impossible to set a date in the future and hope 
ppolicy will start honours it once this time is reached.


You could also use the smbkrb5 overlay, and rely on kerberos-specific 
password expiration date to make autentication fails server-side, this 
time after a given date.


In both case, the account will still exists in the directory, meaning 
the user will still be part of mailing list whose membership is based on 
ldap requests, for instance.


I'd like also to have a way to first lock password server-side, the same 
way pwdAccountLockedTime does, but with a fixed date, AND have a boolean 
flag valid/invalid for easy selection of valid account in queries.

--
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62

Re: ppolicy force account expiration

2009-04-16 Thread Craig Squires

Set the pwdAccountLockedTime attribute to 0101Z.

Craig

On Wed, 2009-04-15 at 22:04 -0400, Daniel Durgin wrote:
> Hello,
> 
> Does any one know how to force the expiration of an account within the 
> slapo-ppolicy overlay?
> 
> For instance, says that an employee's last day with the organization 
> ends at 5PM, is there a flag I can set to deactivate an account at that 
> time.
> 
> I know that I could write a cronjob that would do this.
> 
> Thanks,
> Dan

Re: ppolicy password lockout

2008-08-23 Thread Dieter Kluenter

<[EMAIL PROTECTED]> writes:

> Does anyone know if there is at least a way to confirm that a given
> overlay is "loaded" or "in use" somehow?

ldapsearch -b cn=overlays,cn=monitor +

-Dieter
-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy password lockout

2008-08-22 Thread andylockran

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
> Does anyone know if there is at least a way to confirm that a given
> overlay is "loaded" or "in use" somehow?
> 
> Thanks,
> Paul
> 

Paul,

I recall someone posted something on the FAQ about ppolicy not so long
ago, which included how to tell if it was active.

I'd check that.

Regards,

Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIruOGauMjEM4rxIQRAqpFAKCLZiRcdrbcMslbI0gTfpe8R13jRACaAysJ
goUEBvxPEqRFMJUhy+Ibioo=
=wpMW
-END PGP SIGNATURE-

RE: ppolicy password lockout

2008-08-22 Thread discip


Does anyone know if there is at least a way to confirm that a given
overlay is "loaded" or "in use" somehow?

Thanks,
Paul

-Original Message-
From: DiSciascio, Paul 
Sent: Wednesday, August 20, 2008 9:38 AM
To: DiSciascio, Paul; [EMAIL PROTECTED]
Cc: [email protected]; [EMAIL PROTECTED]
Subject: RE: ppolicy password lockout


I'm not sure if it's worth mentioning that I am seeing the following in
syslog when I start up slapd:

   Aug 20 09:44:18 dir01alt slapd[14600]: WARNING: No dynamic config
support for overlay ppolicy.

It says it's a warning, but I'm not sure I believe it.

~Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of [EMAIL PROTECTED]
Sent: Monday, August 18, 2008 7:31 AM
To: [EMAIL PROTECTED]
Cc: [email protected]; [EMAIL PROTECTED]
Subject: Re: ppolicy password lockout


Yes, i recreated the user after putting the overly in the config.
-Original Message-
From: Adam Leach [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 15, 2008 10:46 AM
To: DiSciascio, Paul
Cc: [EMAIL PROTECTED]; [email protected]
Subject: Re: [Probable SPAM] Re: ppolicy password lockout


Did you add this user _after_ putting the overlay ppolicy in your config
or before?  In my past experience only entries that were added after the
fact were affected.


On Fri, Aug 15, 2008 at 9:12 AM, <[EMAIL PROTECTED]> wrote:

Here are the results after multiple bad attempts to bind to the LDAP
server. Additionally, I changed the password for the user before I
started, and I don't see attributes related to that either

[EMAIL PROTECTED]:~> ldapsearch -D "cn=manager,dc=pjm,dc=com" -Wx -b
"dc=pjm,dc=com" "(uid=testuser)" + Enter LDAP Password: # extended LDIF
# # LDAPv3 # base  with scope subtree # filter:
(uid=testuser) # requesting: + #

# testuser, People, Test, External, pjm.com
dn: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
structuralObjectClass: inetOrgPerson
entryUUID: e15065de-f814-102c-85ad-6b504a287112
creatorsName: cn=manager,dc=pjm,dc=com
createTimestamp: 20080806150541Z
entryCSN: 20080813115547Z#00#00#00
modifiersName: cn=stoat,dc=pjm,dc=com
modifyTimestamp: 20080813115547Z
entryDN: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

-Original Message-
From: Andrew Findlay [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2008 2:46 PM
To: DiSciascio, Paul
Cc: [email protected]
Subject: [Probable SPAM] Re: ppolicy password lockout


On Thu, Aug 14, 2008 at 07:58:44AM -0400, [EMAIL PROTECTED] wrote:

>   I don't see any pwdFailureTime attributes ever show up for the user 
> in question, and the password never locks after bad password attempts.

When reading the user entry are you requesting the operational
attributes? You need to do that to see things like failure times. Add
'+' to the end of the ldapsearch command and see what you get.

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 |
---





-- 
Adam Leach
BS Computer/Electrical Engineering
West Virginia University
System Administrator - Raytheon
(304)677-4455

RE: ppolicy password lockout

2008-08-20 Thread discip

I'm not sure if it's worth mentioning that I am seeing the following in
syslog when I start up slapd:

   Aug 20 09:44:18 dir01alt slapd[14600]: WARNING: No dynamic config
support for overlay ppolicy.

It says it's a warning, but I'm not sure I believe it.

~Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of [EMAIL PROTECTED]
Sent: Monday, August 18, 2008 7:31 AM
To: [EMAIL PROTECTED]
Cc: [email protected]; [EMAIL PROTECTED]
Subject: Re: ppolicy password lockout


Yes, i recreated the user after putting the overly in the config.
-Original Message-
From: Adam Leach [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 15, 2008 10:46 AM
To: DiSciascio, Paul
Cc: [EMAIL PROTECTED]; [email protected]
Subject: Re: [Probable SPAM] Re: ppolicy password lockout


Did you add this user _after_ putting the overlay ppolicy in your config
or before?  In my past experience only entries that were added after the
fact were affected.


On Fri, Aug 15, 2008 at 9:12 AM, <[EMAIL PROTECTED]> wrote:

Here are the results after multiple bad attempts to bind to the LDAP
server.
Additionally, I changed the password for the user before I started, and
I don't see attributes related to that either

[EMAIL PROTECTED]:~> ldapsearch -D "cn=manager,dc=pjm,dc=com" -Wx -b
"dc=pjm,dc=com" "(uid=testuser)" +
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=testuser)
# requesting: +
#

# testuser, People, Test, External, pjm.com
dn: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
structuralObjectClass: inetOrgPerson
entryUUID: e15065de-f814-102c-85ad-6b504a287112
creatorsName: cn=manager,dc=pjm,dc=com
createTimestamp: 20080806150541Z
entryCSN: 20080813115547Z#00#00#00
modifiersName: cn=stoat,dc=pjm,dc=com
modifyTimestamp: 20080813115547Z
entryDN: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

-Original Message-
From: Andrew Findlay [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2008 2:46 PM
To: DiSciascio, Paul
Cc: [email protected]
Subject: [Probable SPAM] Re: ppolicy password lockout


On Thu, Aug 14, 2008 at 07:58:44AM -0400, [EMAIL PROTECTED] wrote:

>   I don't see any pwdFailureTime attributes ever show up for the user
> in question, and the password never locks after bad password attempts.

When reading the user entry are you requesting the operational
attributes? You need to do that to see things like failure times. Add
'+' to the end of the ldapsearch command and see what you get.

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 |
---





-- 
Adam Leach
BS Computer/Electrical Engineering
West Virginia University
System Administrator - Raytheon
(304)677-4455

Re: ppolicy password lockout

2008-08-18 Thread discip

Yes, i recreated the user after putting the overly in the config.

-Original Message-
From: Adam Leach [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 15, 2008 10:46 AM
To: DiSciascio, Paul
Cc: [EMAIL PROTECTED];
[email protected]
Subject: Re: [Probable SPAM] Re: ppolicy password lockout


Did you add this user _after_ putting the overlay ppolicy in
your config or before?  In my past experience only entries that were
added after the fact were affected.


On Fri, Aug 15, 2008 at 9:12 AM, <[EMAIL PROTECTED]> wrote:


Here are the results after multiple bad attempts to bind
to the LDAP
server.
Additionally, I changed the password for the user before
I started, and
I don't see attributes related to that either

[EMAIL PROTECTED]:~> ldapsearch -D
"cn=manager,dc=pjm,dc=com" -Wx -b
"dc=pjm,dc=com" "(uid=testuser)" +
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=testuser)
# requesting: +
#

# testuser, People, Test, External, pjm.com
dn:
uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
structuralObjectClass: inetOrgPerson
entryUUID: e15065de-f814-102c-85ad-6b504a287112
creatorsName: cn=manager,dc=pjm,dc=com
createTimestamp: 20080806150541Z
entryCSN: 20080813115547Z#00#00#00
modifiersName: cn=stoat,dc=pjm,dc=com
modifyTimestamp: 20080813115547Z
entryDN:
uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

-Original Message-
From: Andrew Findlay
[mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2008 2:46 PM
To: DiSciascio, Paul
Cc: [email protected]
    Subject: [Probable SPAM] Re: ppolicy password lockout


On Thu, Aug 14, 2008 at 07:58:44AM -0400, [EMAIL PROTECTED]
wrote:

>   I don't see any pwdFailureTime attributes ever show
up for the user
> in question, and the password never locks after bad
password attempts.

When reading the user entry are you requesting the
operational
attributes? You need to do that to see things like
failure times. Add
'+' to the end of the ldapsearch command and see what
you get.

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 |

---






-- 
Adam Leach
BS Computer/Electrical Engineering
West Virginia University
System Administrator - Raytheon
(304)677-4455

Re: ppolicy password lockout

2008-08-18 Thread discip

Here are the results after multiple bad attempts to bind to the LDAP
server.  
Additionally, I changed the password for the user before I started, and
I don't see attributes related to that either

[EMAIL PROTECTED]:~> ldapsearch -D "cn=manager,dc=pjm,dc=com" -Wx -b
"dc=pjm,dc=com" "(uid=testuser)" + Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=testuser)
# requesting: + 
#

# testuser, People, Test, External, pjm.com
dn: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
structuralObjectClass: inetOrgPerson
entryUUID: e15065de-f814-102c-85ad-6b504a287112
creatorsName: cn=manager,dc=pjm,dc=com
createTimestamp: 20080806150541Z
entryCSN: 20080813115547Z#00#00#00
modifiersName: cn=stoat,dc=pjm,dc=com
modifyTimestamp: 20080813115547Z
entryDN: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

-Original Message-
From: Andrew Findlay [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 14, 2008 2:46 PM
To: DiSciascio, Paul
Cc: [email protected]
Subject: [Probable SPAM] Re: ppolicy password lockout


On Thu, Aug 14, 2008 at 07:58:44AM -0400, [EMAIL PROTECTED] wrote:

>   I don't see any pwdFailureTime attributes ever show up for the user 
> in question, and the password never locks after bad password attempts.

When reading the user entry are you requesting the operational
attributes? You need to do that to see things like failure times. Add
'+' to the end of the ldapsearch command and see what you get.

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: [Probable SPAM] Re: ppolicy password lockout

2008-08-15 Thread Adam Leach

Did you add this user _after_ putting the overlay ppolicy in your config or
before?  In my past experience only entries that were added after the fact
were affected.

On Fri, Aug 15, 2008 at 9:12 AM, <[EMAIL PROTECTED]> wrote:

> Here are the results after multiple bad attempts to bind to the LDAP
> server.
> Additionally, I changed the password for the user before I started, and
> I don't see attributes related to that either
>
> [EMAIL PROTECTED]:~> ldapsearch -D "cn=manager,dc=pjm,dc=com" -Wx -b
> "dc=pjm,dc=com" "(uid=testuser)" +
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: (uid=testuser)
> # requesting: +
> #
>
> # testuser, People, Test, External, pjm.com
> dn: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
> structuralObjectClass: inetOrgPerson
> entryUUID: e15065de-f814-102c-85ad-6b504a287112
> creatorsName: cn=manager,dc=pjm,dc=com
> createTimestamp: 20080806150541Z
> entryCSN: 20080813115547Z#00#00#00
> modifiersName: cn=stoat,dc=pjm,dc=com
> modifyTimestamp: 20080813115547Z
> entryDN: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
> subschemaSubentry: cn=Subschema
> hasSubordinates: FALSE
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> -Original Message-
> From: Andrew Findlay [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 14, 2008 2:46 PM
> To: DiSciascio, Paul
> Cc: [email protected]
> Subject: [Probable SPAM] Re: ppolicy password lockout
>
>
> On Thu, Aug 14, 2008 at 07:58:44AM -0400, [EMAIL PROTECTED] wrote:
>
> >   I don't see any pwdFailureTime attributes ever show up for the user
> > in question, and the password never locks after bad password attempts.
>
> When reading the user entry are you requesting the operational
> attributes? You need to do that to see things like failure times. Add
> '+' to the end of the ldapsearch command and see what you get.
>
> 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 |
> ---
>
>


-- 
Adam Leach
BS Computer/Electrical Engineering
West Virginia University
System Administrator - Raytheon
(304)677-4455

RE: [Probable SPAM] Re: ppolicy password lockout

2008-08-15 Thread discip

Here are the results after multiple bad attempts to bind to the LDAP
server.  
Additionally, I changed the password for the user before I started, and
I don't see attributes related to that either

[EMAIL PROTECTED]:~> ldapsearch -D "cn=manager,dc=pjm,dc=com" -Wx -b
"dc=pjm,dc=com" "(uid=testuser)" +
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=testuser)
# requesting: + 
#

# testuser, People, Test, External, pjm.com
dn: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
structuralObjectClass: inetOrgPerson
entryUUID: e15065de-f814-102c-85ad-6b504a287112
creatorsName: cn=manager,dc=pjm,dc=com
createTimestamp: 20080806150541Z
entryCSN: 20080813115547Z#00#00#00
modifiersName: cn=stoat,dc=pjm,dc=com
modifyTimestamp: 20080813115547Z
entryDN: uid=testuser,ou=People,ou=Test,ou=External,dc=pjm,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

-Original Message-
From: Andrew Findlay [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 14, 2008 2:46 PM
To: DiSciascio, Paul
Cc: [email protected]
Subject: [Probable SPAM] Re: ppolicy password lockout


On Thu, Aug 14, 2008 at 07:58:44AM -0400, [EMAIL PROTECTED] wrote:

>   I don't see any pwdFailureTime attributes ever show up for the user 
> in question, and the password never locks after bad password attempts.

When reading the user entry are you requesting the operational
attributes? You need to do that to see things like failure times. Add
'+' to the end of the ldapsearch command and see what you get.

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 password lockout

2008-08-14 Thread Andrew Findlay

On Thu, Aug 14, 2008 at 07:58:44AM -0400, [EMAIL PROTECTED] wrote:

>   I don't see any pwdFailureTime attributes ever show up for the user in
> question, and the password never locks after bad password attempts.

When reading the user entry are you requesting the operational attributes?
You need to do that to see things like failure times.
Add '+' to the end of the ldapsearch command and see what you get.

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 locking and replication

2008-08-13 Thread Buchan Milne

On Wednesday 13 August 2008 15:51:30 Jiri Netolicky wrote:
> Hi,
>
> I have a one master and two slaves servers 2.3.27 from RHEL 5.2.
> Replication is done by syncrepl. Now I have to use password policy overlay
> and account locking after few unsuccessful bind. When the bind is on master
> server, everything
> works ok - the lock i replicated to the slaves. But when the user
> binds on slave,
> the lock is only on the slave and the account on master and second slave
> is unlocked.
> What is the best solution of this problem? I think some kind of
> multiple-master replication of pwdAccountLockedTime and pwdFailureTime from
> slaves? But multiple-master is since 2.4 version isnt' it?

A multi-master environment may *still* have non-master slaves.

IMHO, pwdAccountLockedTime needs to be chained back to the master, and 
pwdFailureTime on slaves needs to be removed on password reset.

At present is necessary to script around the pwdAccountLockedTime issue, but 
there is no hope for pwdFailureTime (so many of my users get locked out again 
very soon if they happen to have failed a few times against a slave).

Regards,
Buchan

Re: ppolicy pwdReset

2008-07-29 Thread greek ordono

Thank you very much its working now.

--- On Mon, 7/28/08, Buchan Milne <[EMAIL PROTECTED]> wrote:
From: Buchan Milne <[EMAIL PROTECTED]>
Subject: Re: ppolicy pwdReset
To: [email protected], [EMAIL PROTECTED]
Date: Monday, July 28, 2008, 7:53 PM

On Saturday 26 July 2008 07:52:16 greek ordono wrote:
> Hello,
>
> I getting the following error:
> "LDAP password information update failed: Insufficient access
> Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
>
> when I try to add pwdReset on users. 
>
> LDAP: 2.4.9
> SLAPD ACL: http://pastebin.com/m45ad1781

You only later mentioned that you were using smbk5pwd. Since you are, please 
look at ITS #5569. You should upgrade to 2.4.11. In the changelog for 2.4.11, 
you will find:

Fixed slapo-ppolicy modify with internal ops (ITS#5569)

Regards,
Buchan

Re: ppolicy pwdReset

2008-07-28 Thread Buchan Milne

On Saturday 26 July 2008 07:52:16 greek ordono wrote:
> Hello,
>
> I getting the following error:
> "LDAP password information update failed: Insufficient access
> Operations are restricted to bind/unbind/abandon/StartTLS/modify password"
>
> when I try to add pwdReset on users. 
>
> LDAP: 2.4.9
> SLAPD ACL: http://pastebin.com/m45ad1781

You only later mentioned that you were using smbk5pwd. Since you are, please 
look at ITS #5569. You should upgrade to 2.4.11. In the changelog for 2.4.11, 
you will find:

Fixed slapo-ppolicy modify with internal ops (ITS#5569)

Regards,
Buchan

Re: ppolicy pwdReset

2008-07-28 Thread greek ordono

Hi,

Ok, I'll just read again that FAQ. Check this complete log of ppolicy 
with/without smbk5pwd overlay. Or maybe just another pam_ldap bug

1. change passwd before entering new password
# passwd techsupport
Enter login(LDAP) password:

smbk5pwd+ppolicy log: http://pastebin.com/m7dce205a
ppolicy log: http://pastebin.com/m18f72eb6

2. enter new password
New password:
Re-enter new password:
LDAP password information update failed: Insufficient access
Operations are restricted to bind/unbind/abandon/StartTLS/modify password
passwd: Permission denied
passwd: password unchanged

smbk5pwd+ppolicy log: http://pastebin.com/m4f98884e
ppolicy log: http://pastebin.com/m2fe93f63

If you look into step 1 anomymous is applied as well, without smbk5pwd and 
pwdReset update is successful. In step 2 there you can see the difference, if 
its acl problem can someone suggest a working acl(minimal) with 
smbk5pwd+ppolicy+pwdReset...

thanks
grexk
--- On Mon, 7/28/08, Dieter Kluenter <[EMAIL PROTECTED]> wrote:
From: Dieter Kluenter <[EMAIL PROTECTED]>
Subject: Re: ppolicy pwdReset
To: [email protected]
Date: Monday, July 28, 2008, 3:06 PM

greek ordono <[EMAIL PROTECTED]> writes:

> Hello,

>   

> I've changed my acl like this:

> access to
attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange

> by dn="cn=nssldap,ou=DSA,dc=moldex,dc=group" write  

> by anonymous auth 

> by self write 

>   

> access to *   

> by self write 

> by * read 

>   

> <= acl_mask: [3] applying auth(=xd) (stop) 

> <= acl_mask: [3] mask: auth(=xd)   

> => slap_access_allowed: read access denied by auth(=xd)

> => access_allowed: no more rules   

The answer is obvious, your rule "by anonymous auth" is applied.
You should prabably read
http://www.openldap.org/faq/data/cache/189.html
in order to design access rules

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy pwdReset

2008-07-28 Thread Dieter Kluenter

greek ordono <[EMAIL PROTECTED]> writes:

> Hello,
>   
>   
>   
> I've changed my acl like this:
>   
> access to 
> attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange
> 
> by dn="cn=nssldap,ou=DSA,dc=moldex,dc=group" write
>   
> by anonymous auth 
>   
> by self write 
>   
>   
>   
> access to *   
>   
> by self write 
>   
> by * read 
>   
>   
>   

> <= acl_mask: [3] applying auth(=xd) (stop)
>   
> <= acl_mask: [3] mask: auth(=xd)  
>   
> => slap_access_allowed: read access denied by auth(=xd)   
>   
> => access_allowed: no more rules  
>   

The answer is obvious, your rule "by anonymous auth" is applied.
You should prabably read
http://www.openldap.org/faq/data/cache/189.html
in order to design access rules

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy pwdReset

2008-07-28 Thread greek ordono

Hello,

I've changed my acl like this:
access to 
attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange
    by dn="cn=nssldap,ou=DSA,dc=moldex,dc=group" write
    by anonymous auth
    by self write

access to *
    by self write
    by * read

and still get.
=> access_allowed: read access to "uid=techsupport,ou=Users,dc=moldex,dc=group" 
"userPassword" requested
=> acl_get: [1] attr userPassword
=> slap_access_allowed: result not in cache (userPassword)
=> acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", attr
 "userPassword" requested
=> acl_mask: to value by "", (=0) 
<= check a_dn_pat: cn=nssldap,ou=dsa,dc=moldex,dc=group
<= check a_dn_pat: self
<= check a_dn_pat: anonymous
<= acl_mask: [3] applying auth(=xd) (stop)
<= acl_mask: [3] mask: auth(=xd)
=> slap_access_allowed: read access denied by auth(=xd)
=> access_allowed: no more rules

this only happend if smbk5pwd is enabled. My pam_ldap config looks like this:
base dc=moldex,dc=group
uri ldap://127.0.0.1
ldap_version 3
rootdn cn=nssldap,ou=dsa,dc=moldex,dc=group
referrals yes
timelimit 30
bind_timelimit 30
bind_policy hard
nss_reconnect_tries 1
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 2
nss_reconnect_maxconntries 1
nss_base_passwd ou=Users,dc=moldex,dc=group?one
nss_base_passwd ou=Computers,dc=moldex,dc=group?one
nss_base_shadow ou=Users,dc=moldex,dc=group?one
nss_base_group 
 ou=Groups,dc=moldex,dc=group?one
nss_initgroups_ignoreusers
backup,bin,daemon,dhcp,games,gnats,irc,klog,libuuid,list,lp,mail,man,news,openldap,proxy,root,sshd,sync,sys,syslog,uucp,www-data

ssl off
pam_lookup_policy yes
pam_password exop

Thanks,
greek

--- On Sat, 7/26/08, Dieter Kluenter <[EMAIL PROTECTED]> wrote:
From: Dieter Kluenter <[EMAIL PROTECTED]>
Subject: Re: ppolicy pwdReset
To: [email protected]
Date: Saturday, July 26, 2008, 5:28 PM

greek ordono <[EMAIL PROTECTED]> writes:

> I'm getting this error:   

>   

> => access_allowed: read access to
"uid=techsupport,ou=Users,dc=moldex,dc=group"
"userPassword" requested 
> => acl_get: [1] attr userPassword  

> => slap_access_allowed: result not in cache (userPassword) 

> => acl_mask: access to entry
"uid=techsupport,ou=Users,dc=moldex,dc=group", attr
"userPassword" requested
> => acl_mask: to value by "", (=0)

> <= check a_dn_pat: cn=replicator,ou=dsa,dc=moldex,dc=group 

> <= check a_dn_pat: *   

> <= acl_mask: [2] applying +0 (break)   

> <= acl_mask: [2] mask: =0  

> => acl_get: [2] attr userPassword  

> => slap_access_allowed: result not in cache (userPassword) 

> => acl_mask: access to entry
"uid=techsupport,ou=Users,dc=moldex,dc=group", attr
"userPassword" requested
> => acl_mask: to value by "", (=0)

> <= check a_dn_pat: cn=samba,ou=dsa,dc=moldex,dc=group  

> <= check a_dn_pat: cn=nssldap,ou=dsa,dc=moldex,dc=group

> <= check a_dn_pat: cn=squid,ou=dsa,dc=moldex,dc=group  

> <= check a_dn_pat: self

> <= check a_dn_pat: anonymous   

> <= acl_mask: [5] applying auth(=xd) (stop) 

> <= acl_mask: [5] mask: auth(=xd)   

> => slap_access_allowed: read access denied by auth(=xd)

> => access_allowed: no more rules   

> send_search_entry: conn 9 access to attribute userPassword, value #0 not
allowed 

For this search your rule no. 5 is applicable, and this rule disallows
read access to attribute userPassword.
Change your access rules accordingly.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy pwdReset

2008-07-26 Thread Dieter Kluenter

greek ordono <[EMAIL PROTECTED]> writes:

> I'm getting this error:   
>
>   
>
> => access_allowed: read access to 
> "uid=techsupport,ou=Users,dc=moldex,dc=group" "userPassword" requested 
> => acl_get: [1] attr userPassword 
>
> => slap_access_allowed: result not in cache (userPassword)
>
> => acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", 
> attr "userPassword" requested
> => acl_mask: to value by "", (=0) 
>
> <= check a_dn_pat: cn=replicator,ou=dsa,dc=moldex,dc=group
>
> <= check a_dn_pat: *  
>
> <= acl_mask: [2] applying +0 (break)  
>
> <= acl_mask: [2] mask: =0 
>
> => acl_get: [2] attr userPassword 
>
> => slap_access_allowed: result not in cache (userPassword)
>
> => acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", 
> attr "userPassword" requested
> => acl_mask: to value by "", (=0) 
>
> <= check a_dn_pat: cn=samba,ou=dsa,dc=moldex,dc=group 
>
> <= check a_dn_pat: cn=nssldap,ou=dsa,dc=moldex,dc=group   
>
> <= check a_dn_pat: cn=squid,ou=dsa,dc=moldex,dc=group 
>
> <= check a_dn_pat: self   
>
> <= check a_dn_pat: anonymous  
>
> <= acl_mask: [5] applying auth(=xd) (stop)
>
> <= acl_mask: [5] mask: auth(=xd)  
>
> => slap_access_allowed: read access denied by auth(=xd)   
>
> => access_allowed: no more rules  
>
> send_search_entry: conn 9 access to attribute userPassword, value #0 not 
> allowed 

For this search your rule no. 5 is applicable, and this rule disallows
read access to attribute userPassword.
Change your access rules accordingly.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy pwdReset

2008-07-26 Thread greek ordono

I'm getting this error: 

=> access_allowed: read access to "uid=techsupport,ou=Users,dc=moldex,dc=group" 
"userPassword" requested
=> acl_get: [1] attr userPassword
=> slap_access_allowed: result not in cache (userPassword)
=> acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", 
attr "userPassword" requested
=> acl_mask: to value by "", (=0)
<= check a_dn_pat: cn=replicator,ou=dsa,dc=moldex,dc=group
<= check a_dn_pat: *
<= acl_mask: [2] applying +0 (break)
<= acl_mask: [2] mask: =0
=> acl_get: [2] attr userPassword
=> slap_access_allowed: result not in cache (userPassword)
=> acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", 
attr "userPassword" requested
=> acl_mask: to value by "", (=0)
<= check a_dn_pat: cn=samba,ou=dsa,dc=moldex,dc=group
<= check a_dn_pat: cn=nssldap,ou=dsa,dc=moldex,dc=group
<= check a_dn_pat: cn=squid,ou=dsa,dc=moldex,dc=group
<= check a_dn_pat: self
<= check a_dn_pat: anonymous
<= acl_mask: [5] applying auth(=xd) (stop)
<= acl_mask: [5] mask: auth(=xd)
=> slap_access_allowed: read access denied by auth(=xd)
=> access_allowed: no more rules
send_search_entry: conn 9 access to attribute userPassword, value #0 not allowed


--- On Sat, 7/26/08, Dieter Kluenter <[EMAIL PROTECTED]> wrote:
From: Dieter Kluenter <[EMAIL PROTECTED]>
Subject: Re: ppolicy pwdReset
To: [email protected]
Date: Saturday, July 26, 2008, 3:06 PM

Hi,

greek ordono <[EMAIL PROTECTED]> writes:

> Hello,
>   
> I getting the following error:
> "LDAP password information update failed: Insufficient access

> Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
>   
> when I try to add pwdReset on users.  

Run slapd -d acl

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy pwdReset

2008-07-26 Thread Dieter Kluenter

Hi,

greek ordono <[EMAIL PROTECTED]> writes:

> Hello,
>   
> I getting the following error:
> "LDAP password information update failed: Insufficient access 
> Operations are restricted to bind/unbind/abandon/StartTLS/modify password"
>   
> when I try to add pwdReset on users.  

Run slapd -d acl

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy/value #0 not allowed

2008-07-01 Thread Michael Ströder


Jeff Adams wrote:
I'm using CentOS 5 with openldap 2.3, built from SRPMS to get the 
overlays. The first time I tried to create policies for ppolicy, it 
complained about the syntax. Google led me in the right direction and

I replaced "userPassword" in the ldif file with the UID, 2.5.4.35 .
But now the password policies are not working and I get this message
in the logs:
send_search_entry: conn 102 access to attribute userPassword, value #0 
not allowed


Which operation did you try? Any access control in effect? You don't 
provide enough information.


Ciao, Michael.

Re: ppolicy+syncrpl: pwd* attributes lost

2008-06-26 Thread Chris G. Sellers

Thanks folks - I missed that in the doco.   I'll make those  
adjustments :)


Best wishes.

Sellers

On Jun 26, 2008, at 4:53 PM, Quanah Gibson-Mount wrote:



--On June 26, 2008 4:01:50 PM -0400 "Chris G. Sellers" <[EMAIL PROTECTED] 
> wrote:



Ok, I did find part of my error.  It was not explicitly named in the
syncrepl statement.  I added pwdChangedTime and pwdHistory to the
syncrepl attrs line and it does sync them now -- but only if they  
already
exist.  The account does not have a pwdChangedTime, and you change  
the

password on servera, serverb does not get the attribute populated.  I
will have to monitor the logs to see.



Why are you setting the attrs= line at all?  Looks to me like you  
should just be using the default value (attrs="*,+"), and leaving it  
out of your syncrepl configuration entirely.  You should only ever  
set the attrs= line in the syncrepl stanza if you want partial  
replication done.


--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: ppolicy+syncrpl: pwd* attributes lost

2008-06-26 Thread Quanah Gibson-Mount



--On June 26, 2008 4:01:50 PM -0400 "Chris G. Sellers" 
<[EMAIL PROTECTED]> wrote:



Ok, I did find part of my error.  It was not explicitly named in the
syncrepl statement.  I added pwdChangedTime and pwdHistory to the
syncrepl attrs line and it does sync them now -- but only if they already
exist.  The account does not have a pwdChangedTime, and you change the
password on servera, serverb does not get the attribute populated.  I
will have to monitor the logs to see.



Why are you setting the attrs= line at all?  Looks to me like you should 
just be using the default value (attrs="*,+"), and leaving it out of your 
syncrepl configuration entirely.  You should only ever set the attrs= line 
in the syncrepl stanza if you want partial replication done.


--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: ppolicy+syncrpl: pwd* attributes lost

2008-06-26 Thread Chris G. Sellers

Ok, I did find part of my error.  It was not explicitly named in the  
syncrepl statement.  I added pwdChangedTime and pwdHistory to the  
syncrepl attrs line and it does sync them now -- but only if they  
already exist.  The account does not have a pwdChangedTime, and you  
change the password on servera, serverb does not get the attribute  
populated.  I will have to monitor the logs to see.


Thanks for making me think different about the problem.


--line changed --
   
attrs 
= 
"*,structuralObjectClass 
,entryUUID 
,entryCSN 
,creatorsName 
,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"



   
attrs 
= 
"*,structuralObjectClass 
,entryUUID 
,entryCSN 
,creatorsName 
,createTimestamp 
,modifiersName 
,modifyTimestamp,pwdPolicySubentry,pwdChangedTime,pwdHistory"



On Jun 26, 2008, at 9:07 AM, Gavin Henry wrote:


Chris G. Sellers wrote:

I have n-way multimaster replication setup.  Works great.
I have slapo_ppolicy setup, it too works.
the problem I appear to have is that whichever server does the  
password change, the pwd* attributes are set, and then removed from  
the other server.
So, if I do a password change on server1, the record for user A on  
server1 shows pwdChangedTime
The record for user A on server2 shows the modificationTime but the  
pwdChangedTime is deleted

The same goes if I use server2 and look at server1.
At first, I thought it may be due to the clear_hash setting, but  
that didn't seem to make an impact.  Any ideas?  I know I must have  
something missing but I'm just not seeing it.

---
password-hash   {SSHA}
###
databasebdb
suffix  "dc=nitle,dc=org"
rootdn  "cn=MASTERUSER,dc=nitle,dc=org"
rootpw  {SSHA}WAYTOOSECRETFORYOU
directory   /home/ldap/openldap/var/openldap-data
serverID 1
limits dn.exact="cn=mirroruser,ou=ou,dc=nitle,dc=org"  
size=unlimited time=unlimited
syncrepl rid=010 provider=ldap://ldapserveronoe.nitle.org:9  
binddn="cn=mirroruser,ou=ou,dc=nitle,dc=org" bindmethod=simple
credentials=O searchbase="dc=nitle,dc=org"  
type=refreshAndPersist scope=sub
interval=00:00:00:10 retry="15 5 300 +" timeout=1  
schemachecking=off starttls=yes
attrs 
= 
"*,structuralObjectClass 
,entryUUID 
,entryCSN 
,creatorsName 
,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"

#  syncdata=accesslog
syncrepl rid=011 provider=ldap://ldapserverTwo.nitle.org:9  
binddn="cn=ldap`1,dc=nitle,dc=org" bindmethod=simple
  credentials=O searchbase="dc=nitle,dc=org"  
type=refreshAndPersist schemachecking=off scope=sub

  interval=00:00:00:10 retry="15 5 300 +" timeout=1 starttls=yes
   
attrs 
= 
"*,structuralObjectClass 
,entryUUID 
,entryCSN 
,creatorsName 
,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"

#   syncdata=accesslog
overlay syncprov
mirrormode true
## INDICES TO MAINTAIN
index   objectClass eq
index   cn,mail,surname,givenname
eq,subinitial

index   uidNumber,gidNumber,memberuid,member,uniqueMember   eq
## PASSWORD POLICY OVERLAY ##
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=nitle,dc=org"
ppolicy_hash_cleartext
# ppolicy_use_lockout
++
Chris G. Sellers |  Internet Engineer  |   NITLE
734.661.2318 |  [EMAIL PROTECTED] 
Jabber: [EMAIL PROTECTED]   | AIM:  
imthewherd



Where are your ACLs?

--
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E [EMAIL PROTECTED]

Community developed LDAP software.

http://www.openldap.org/project/


++
Chris G. Sellers|  Internet Engineer  |   NITLE
734.661.2318|  [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]  | AIM: imthewherd

Re: ppolicy+syncrpl: pwd* attributes lost

2008-06-26 Thread Gavin Henry


> Ok, I did find part of my error.  It was not explicitly named in the
> syncrepl statement.  I added pwdChangedTime and pwdHistory to the
> syncrepl attrs line and it does sync them now -- but only if they
> already exist.  The account does not have a pwdChangedTime, and you
> change the password on servera, serverb does not get the attribute
> populated.  I will have to monitor the logs to see.
>
> Thanks for making me think different about the problem.
>
>
> --line changed --
>
> attrs
> =
> "*,structuralObjectClass
> ,entryUUID
> ,entryCSN
> ,creatorsName
> ,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"
>
>

Why not just leave it as default:

"The attrs list defaults to "*,+" to return all user and operational
attributes, and attrsonly is unset by default."

-- 
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E [EMAIL PROTECTED]

Community developed LDAP software.

http://www.openldap.org/project/

Re: ppolicy+syncrpl: pwd* attributes lost

2008-06-26 Thread Gavin Henry

2008/6/26 Chris G. Sellers <[EMAIL PROTECTED]>:
> I thought about that, but checked and I think they are okay.
>
> The last entry in the ACL list has an entry like this
>
> access to *
>by dn.exact="cn=repluser,ou=ou,dc=nitle,dc=org" write
>by dn.exact="cn=mirroruser,ou=ou,dc=nitle,dc=org" write

Remember it's top down when they get assessed:

and add

by * break


-- 
http://www.suretecsystems.com/services/openldap/

Re: ppolicy+syncrpl: pwd* attributes lost

2008-06-26 Thread Chris G. Sellers


I thought about that, but checked and I think they are okay.

The last entry in the ACL list has an entry like this

access to *
by dn.exact="cn=repluser,ou=ou,dc=nitle,dc=org" write
by dn.exact="cn=mirroruser,ou=ou,dc=nitle,dc=org" write



where the replication users are given write access
You think maybe I need to be explicit since their are EAs ?


On Jun 26, 2008, at 9:07 AM, Gavin Henry wrote:


Chris G. Sellers wrote:

I have n-way multimaster replication setup.  Works great.
I have slapo_ppolicy setup, it too works.
the problem I appear to have is that whichever server does the  
password change, the pwd* attributes are set, and then removed from  
the other server.
So, if I do a password change on server1, the record for user A on  
server1 shows pwdChangedTime
The record for user A on server2 shows the modificationTime but the  
pwdChangedTime is deleted

The same goes if I use server2 and look at server1.
At first, I thought it may be due to the clear_hash setting, but  
that didn't seem to make an impact.  Any ideas?  I know I must have  
something missing but I'm just not seeing it.

---
password-hash   {SSHA}
###
databasebdb
suffix  "dc=nitle,dc=org"
rootdn  "cn=MASTERUSER,dc=nitle,dc=org"
rootpw  {SSHA}WAYTOOSECRETFORYOU
directory   /home/ldap/openldap/var/openldap-data
serverID 1
limits dn.exact="cn=mirroruser,ou=ou,dc=nitle,dc=org"  
size=unlimited time=unlimited
syncrepl rid=010 provider=ldap://ldapserveronoe.nitle.org:9  
binddn="cn=mirroruser,ou=ou,dc=nitle,dc=org" bindmethod=simple
 credentials=O searchbase="dc=nitle,dc=org"  
type=refreshAndPersist scope=sub
 interval=00:00:00:10 retry="15 5 300 +" timeout=1  
schemachecking=off starttls=yes
  
attrs 
= 
"*,structuralObjectClass 
,entryUUID 
,entryCSN 
,creatorsName 
,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"

#  syncdata=accesslog
syncrepl rid=011 provider=ldap://ldapserverTwo.nitle.org:9  
binddn="cn=ldap`1,dc=nitle,dc=org" bindmethod=simple
   credentials=O searchbase="dc=nitle,dc=org"  
type=refreshAndPersist schemachecking=off scope=sub

   interval=00:00:00:10 retry="15 5 300 +" timeout=1 starttls=yes

attrs 
= 
"*,structuralObjectClass 
,entryUUID 
,entryCSN 
,creatorsName 
,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"

#   syncdata=accesslog
overlay syncprov
mirrormode true
## INDICES TO MAINTAIN
index   objectClass eq
index   cn,mail,surname,givenname
eq,subinitial

index   uidNumber,gidNumber,memberuid,member,uniqueMember   eq
## PASSWORD POLICY OVERLAY ##
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=nitle,dc=org"
ppolicy_hash_cleartext
# ppolicy_use_lockout
++
Chris G. Sellers |  Internet Engineer  |   NITLE
734.661.2318 |  [EMAIL PROTECTED] 
Jabber: [EMAIL PROTECTED]   | AIM:  
imthewherd



Where are your ACLs?

--
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E [EMAIL PROTECTED]

Community developed LDAP software.

http://www.openldap.org/project/


++
Chris G. Sellers|  Internet Engineer  |   NITLE
734.661.2318|  [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]  | AIM: imthewherd

Re: ppolicy+syncrpl: pwd* attributes lost

2008-06-26 Thread Gavin Henry


Chris G. Sellers wrote:

I have n-way multimaster replication setup.  Works great.

I have slapo_ppolicy setup, it too works.

the problem I appear to have is that whichever server does the password 
change, the pwd* attributes are set, and then removed from the other server.


So, if I do a password change on server1, the record for user A on 
server1 shows pwdChangedTime
The record for user A on server2 shows the modificationTime but the 
pwdChangedTime is deleted


The same goes if I use server2 and look at server1.

At first, I thought it may be due to the clear_hash setting, but that 
didn't seem to make an impact.  Any ideas?  I know I must have something 
missing but I'm just not seeing it.


---

password-hash   {SSHA}


###
databasebdb
suffix  "dc=nitle,dc=org"
rootdn  "cn=MASTERUSER,dc=nitle,dc=org"
rootpw  {SSHA}WAYTOOSECRETFORYOU
directory   /home/ldap/openldap/var/openldap-data

serverID 1
limits dn.exact="cn=mirroruser,ou=ou,dc=nitle,dc=org" size=unlimited 
time=unlimited


syncrepl rid=010 
provider=ldap://ldapserveronoe.nitle.org:9 binddn="cn=mirroruser,ou=ou,dc=nitle,dc=org" 
bindmethod=simple
  credentials=O searchbase="dc=nitle,dc=org" 
type=refreshAndPersist scope=sub
  interval=00:00:00:10 retry="15 5 300 +" timeout=1 schemachecking=off 
starttls=yes

  
attrs="*,structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"
#  syncdata=accesslog

syncrepl rid=011 
provider=ldap://ldapserverTwo.nitle.org:9 binddn="cn=ldap`1,dc=nitle,dc=org" 
bindmethod=simple
credentials=O searchbase="dc=nitle,dc=org" 
type=refreshAndPersist schemachecking=off scope=sub

interval=00:00:00:10 retry="15 5 300 +" timeout=1 starttls=yes
   
 attrs="*,structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimestamp,modifiersName,modifyTimestamp,pwdPolicySubentry"

#   syncdata=accesslog

overlay syncprov
mirrormode true

## INDICES TO MAINTAIN
index   objectClass eq
index   cn,mail,surname,givenname   
eq,subinitial

index   uidNumber,gidNumber,memberuid,member,uniqueMember   eq

## PASSWORD POLICY OVERLAY ##
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=nitle,dc=org"
ppolicy_hash_cleartext
# ppolicy_use_lockout

++
Chris G. Sellers |  Internet Engineer  |   NITLE
734.661.2318 |  [EMAIL PROTECTED] 
Jabber: [EMAIL PROTECTED]   | AIM: imthewherd




Where are your ACLs?

--
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E [EMAIL PROTECTED]

Community developed LDAP software.

http://www.openldap.org/project/

Re: ppolicy by group

2008-06-23 Thread Gavin Henry


Jeroen van Aart wrote:

Howard Chu wrote:


Read the manpage yourself, it's all explained there already.


Thanks for the advice. I did that already and upon closer re-reading 
indeed it answers some of my questions:


"pwdPolicySubentry

This attribute refers directly to the pwdPolicy subentry that is to be 
used for this particular directory user. If pwdPolicySubentry exists, it 
must contain the DN of a valid pwdPolicy object. If it does not exist, 
the ppolicy module will enforce the default password policy rules on the 
user associated with this authenticating DN. If there is no default, or 
 the referenced subentry does not exist, then no policy rules will be 
enforced."


However I have been unable to verify that if I reconfigure slapd to use 
ppolicy then its current functionality will not be influenced? I assume 
that is the case given the above quote. But it'd be nice to have it 
confirmed.


Thank you,
Jeroen


If you don't have a default ppolicy defined and no pwdPolicySubentry 
then slapd will perform as it is currently configured.


--
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E [EMAIL PROTECTED]

Community developed LDAP software.

http://www.openldap.org/project/

Re: ppolicy by group

2008-06-18 Thread Jeroen van Aart


Howard Chu wrote:


Read the manpage yourself, it's all explained there already.


Thanks for the advice. I did that already and upon closer re-reading 
indeed it answers some of my questions:


"pwdPolicySubentry

This attribute refers directly to the pwdPolicy subentry that is to be 
used for this particular directory user. If pwdPolicySubentry exists, it 
must contain the DN of a valid pwdPolicy object. If it does not exist, 
the ppolicy module will enforce the default password policy rules on the 
user associated with this authenticating DN. If there is no default, or 
 the referenced subentry does not exist, then no policy rules will be 
enforced."


However I have been unable to verify that if I reconfigure slapd to use 
ppolicy then its current functionality will not be influenced? I assume 
that is the case given the above quote. But it'd be nice to have it 
confirmed.


Thank you,
Jeroen

Re: ppolicy by group

2008-06-18 Thread Howard Chu


Jeroen van Aart wrote:

Gavin Henry wrote:

man slapo-ppolicy:

"Every account that should be subject to password policy control should
have a pwdPolicySubentry attribute containing the DN of a valid
pwdPolicy entry, or they can simply use the configured default. In this
way different users may be managed according to different policies."


Is it safe to conclude from that that if there is no default policy
configured then unless an account has a pwdPolicySubentry containing the
DN of a valid pwdPolicy entry it will not be subject to password policy?


Read the manpage yourself, it's all explained there already.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: ppolicy by group

2008-06-18 Thread Jeroen van Aart


Gavin Henry wrote:

man slapo-ppolicy:

"Every account that should be subject to password policy control should
have a pwdPolicySubentry attribute containing the DN of a valid 
pwdPolicy entry, or they can simply use the configured default. In this 
way different users may be managed according to different policies."


Is it safe to conclude from that that if there is no default policy 
configured then unless an account has a pwdPolicySubentry containing the 
DN of a valid pwdPolicy entry it will not be subject to password policy?


Also is it generally safe to configure the policy overlay in a currently 
running and used openldap server? This would not affect current 
authentication for example? Having not configured a default, if the 
above is true, one could by hand switch on the policy by setting 
pwdPolicySubentry?


Thank you,
Jeroen

Re: ppolicy by group

2008-06-17 Thread Michael Ströder


Andy Loughran wrote:
Is there a way to add the pwdPolicySubentry: field to a Group - rather 
than a user.  So that any user in the group will have to abide by the 
policy - rather than having to apply a different policy to the user?


pwdPolicySubentry applys only to this particular entry to which it was 
added. I don't know any configuration which allows what you're after.


Ciao, Michael.

Re: ppolicy by group

2008-06-17 Thread Andy Loughran


Gavin,

Sorry, in the excitement of being shown how to apply multiple policies - I 
missed how to actually do this by group.


Is there a way to add the pwdPolicySubentry: field to a Group - rather than 
a user.  So that any user in the group will have to abide by the policy - 
rather than having to apply a different policy to the user?


Regards,

Andy
- Original Message - 
From: "Gavin Henry" <[EMAIL PROTECTED]>

To: "Andy Loughran" <[EMAIL PROTECTED]>
Cc: ; "Adam Leach" <[EMAIL PROTECTED]>
Sent: Tuesday, June 17, 2008 11:47 AM
Subject: Re: ppolicy by group



Andy Loughran wrote:

Gavin,

Ah, so that would suggest that adding a:

pwdPolicySubentry: cn: lesser,ou=ppolicy,dc=example,dc=com

to users of a specific group would allow the entire group to be managed 
by that particular policy.




"Every account that should be subject to password policy control should
have a pwdPolicySubentry attribute containing the DN of a valid
pwdPolicy entry, or they can simply use the configured default. In
this way different users may be managed according to different policies."

That's what it says ;-)

--
Kind Regards,

Gavin Henry.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [EMAIL PROTECTED]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.

Re: ppolicy by group

2008-06-17 Thread Andy Loughran


Gavin,

Ah, so that would suggest that adding a:

pwdPolicySubentry: cn: lesser,ou=ppolicy,dc=example,dc=com

to users of a specific group would allow the entire group to be managed by 
that particular policy.


Thanks.

Andy


- Original Message - 
From: "Gavin Henry" <[EMAIL PROTECTED]>

To: "andylockran" <[EMAIL PROTECTED]>
Cc: "Adam Leach" <[EMAIL PROTECTED]>; 
Sent: Tuesday, June 17, 2008 11:18 AM
Subject: Re: ppolicy by group



andylockran wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Guys,

Sorry to be a pain, but is there just this one #default ppolicy - and
exceptions need to be made on an individual basis?



There's one configurable default:

database bdb
suffix dc=example,dc=com
overlay ppolicy
ppolicy_default cn=Standard,ou=Policies,dc=example,dc=com"


man slapo-ppolicy:

"Every account that should be subject to password policy control should
have a pwdPolicySubentry attribute containing the DN of a valid pwdPolicy 
entry, or they can simply use the configured default. In this way 
different users may be managed according to different policies."



--
Kind Regards,

Gavin Henry.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [EMAIL PROTECTED]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.

Re: ppolicy by group

2008-06-17 Thread Gavin Henry


Andy Loughran wrote:

Gavin,

Ah, so that would suggest that adding a:

pwdPolicySubentry: cn: lesser,ou=ppolicy,dc=example,dc=com

to users of a specific group would allow the entire group to be managed 
by that particular policy.




"Every account that should be subject to password policy control should
have a pwdPolicySubentry attribute containing the DN of a valid
pwdPolicy entry, or they can simply use the configured default. In
this way different users may be managed according to different policies."

That's what it says ;-)

--
Kind Regards,

Gavin Henry.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [EMAIL PROTECTED]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.

Re: ppolicy by group

2008-06-17 Thread Gavin Henry


andylockran wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Guys,

Sorry to be a pain, but is there just this one #default ppolicy - and
exceptions need to be made on an individual basis?



There's one configurable default:

database bdb
suffix dc=example,dc=com
overlay ppolicy
ppolicy_default cn=Standard,ou=Policies,dc=example,dc=com"


man slapo-ppolicy:

"Every account that should be subject to password policy control should
have a pwdPolicySubentry attribute containing the DN of a valid 
pwdPolicy entry, or they can simply use the configured default. In this 
way different users may be managed according to different policies."



--
Kind Regards,

Gavin Henry.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [EMAIL PROTECTED]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.

Re: ppolicy by group

2008-06-16 Thread andylockran

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Guys,

Sorry to be a pain, but is there just this one #default ppolicy - and
exceptions need to be made on an individual basis?

Regards,

Andy Loughran


Adam Leach wrote:
> As far as I know you can only set it by person.  By adding the
> pwdPolicySubentry object to the person and have it's value equal
> the dn of the policy you want to enforce upon it.  If it is
> possible by group, I'd like to know.
>
> Adam
>
> On Thu, Jun 12, 2008 at 9:49 AM, Andy Loughran <[EMAIL PROTECTED]
> > wrote:
>
> When ppolicy is set as default, it applies globally to the entire
> LDAP tree:
>
> dn: cn=default,ou=policies,dc=zednax,dc=com
>
> Is it possible to set the ppolicy by group?
>
> Regards,
>
> Andy
>
>
>
>
> -- Adam Leach BS Computer/Electrical Engineering West Virginia
> University System Administrator - Raytheon (304)677-4455

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhW7VoACgkQauMjEM4rxIRapACffiBqDFqsnDDi8rwf7eOPe1lJ
yzkAoKa4hpagLu0GunjIbRkPIg0xelut
=vjXn
-END PGP SIGNATURE-

Re: ppolicy by group

2008-06-12 Thread Adam Leach

As far as I know you can only set it by person.  By adding the
pwdPolicySubentry object to the person and have it's value equal the dn of
the policy you want to enforce upon it.  If it is possible by group, I'd
like to know.

Adam

On Thu, Jun 12, 2008 at 9:49 AM, Andy Loughran <[EMAIL PROTECTED]> wrote:

> When ppolicy is set as default, it applies globally to the entire LDAP
> tree:
>
> dn: cn=default,ou=policies,dc=zednax,dc=com
>
> Is it possible to set the ppolicy by group?
>
> Regards,
>
> Andy
>

-- 
Adam Leach
BS Computer/Electrical Engineering
West Virginia University
System Administrator - Raytheon
(304)677-4455

Re: PPolicy Questions

2008-04-17 Thread Gavin Henry


Chris G. Sellers wrote:

Your slapd.conf file should include a schema for password policy

something like

include /home/ldap/openldap/etc/openldap/schema/ppolicy.schema


Then, you should be able to use the pwdPolicy schema.  You may want to 
read up on


man slapo_ppolicy
(http://developer.apple.com/documentation/Darwin/Reference/ManPages/man5/slapo-ppolicy.5.html) 



and the ppolicy.schema
(http://www.opensource.apple.com/darwinsource/Current/OpenLDAP-106/OpenLDAP/servers/slapd/schema/ppolicy.schema) 


Please read our own hosted documention or what is documentation and 
schemas are bundled with your version:


http://www.openldap.org/software/man.cgi?query=slapo-ppolicy&apropos=0&sektion=0&manpath=OpenLDAP+2.3-Release&format=html


--
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E [EMAIL PROTECTED]

Community developed LDAP software.

http://www.openldap.org/project/

Re: PPolicy Questions

2008-04-17 Thread Chris G. Sellers

Your slapd.conf file should include a schema for password policy

something like

include /home/ldap/openldap/etc/openldap/schema/ppolicy.schema

Then, you should be able to use the pwdPolicy schema. You may want to
read up on

man slapo_ppolicy
(http://developer.apple.com/documentation/Darwin/Reference/ManPages/man5/slapo-ppolicy.5.html
)

and the ppolicy.schema
(http://www.opensource.apple.com/darwinsource/Current/OpenLDAP-106/OpenLDAP/servers/slapd/schema/ppolicy.schema
)

You should have a copy of that schema in your LDAP distribution as
well, so you can read the latest version on your harddrive of your
server.

Sellers

On Apr 17, 2008, at 4:59 AM, Todd Merrill wrote:

Hello,

I hope this is the place to send such questions. I'm having problems
getting started with ppolicy.

I am trying to specify a specific ppolicy entry for users without
using the slapd.conf default policy. Our OpenLDAP deployment
environment in Red Hat uses version 2.3.33.

From what I have read (elsewhere since the manual is missing the

ppolicy config info), I must first add a new policy of objectclass
'pwdPolicy" in the policy list. I have done that without problem. I
must then indicate for the users that use that policy, the DN of the
new policy in the field 'pwdPolicySubentry'.

My problem at this point is that I see no objectclass that contains
this field. In reading the ppolicy.schema file I see that the type
'pwdPolicySubentry' is described there, but commented out. The odd
thing though, is that even though it is commented out, I can see the
type in my LDAP browser when I look for a list of types, and I see no
description of it in the other .schema files.

I did read on someone's site that the user entry should be an
objectclass of 'pwdPolicy' and then the 'pwdPolicySubentry' field can
be entered, but in the ppolicy.schema document, 'pwdPolicySubentry' is
not described in the list of fields for objectclass 'pwdPolicy'.

Do I have to edit the ppolicy.schema to get the overlay to work this
way? I'm new to LDAP so perhaps I'm not understanding something
basic.

Any help or suggestions would be very helpful.

-Todd Merrill

__
Chris G. Sellers| NITLE - Technology Team
734.661.2318| [EMAIL PROTECTED]
AIM: imthewherd | GoogleTalk: [EMAIL PROTECTED]

Re: ppolicy

2008-04-14 Thread Rick Stevens


Pierangelo Masarati wrote:

Rick Stevens wrote:

 I'm a bit surprised that neither the slapd parser nor slaptest
caught it.  Ah, well.


If you used -d config with slap* from OpenLDAP 2.3, you would have gotten

slapd.conf: line 11:  extra cruft after  ignored.

If you used OpenLDAP 2.4, you would have gotten an error

slapd.conf: line 11:  extra cruft after .
slaptest: bad configuration file!

since 2.4 is much less forgiving about unrecognized statements in 
slapd.conf.  Strengthening those checks was deferred to 2.4 to avoid 
changing the traditionally forgiving behavior many people seem to 
appreciate at mid-life of 2.3.


Ah.  My test box is 2.3.39 (F8).  The two live servers are 2.2.13 (RHEL
4.4) and 2.3.27 (CentOS 5.1).  Soon, all servers will be CentOS 5.1 and
I may install OpenLDAP 2.4.8 on them to replace the 2.3.37 stuff.
--
- Rick Stevens, Unix Geek  [EMAIL PROTECTED] -
--
-  "Very funny, Scotty. Now beam down my clothes."   -
--

Re: ppolicy

2008-04-12 Thread Pierangelo Masarati


Rick Stevens wrote:

 I'm a bit surprised that neither the slapd parser nor slaptest
caught it.  Ah, well.


If you used -d config with slap* from OpenLDAP 2.3, you would have gotten

slapd.conf: line 11:  extra cruft after  ignored.

If you used OpenLDAP 2.4, you would have gotten an error

slapd.conf: line 11:  extra cruft after .
slaptest: bad configuration file!

since 2.4 is much less forgiving about unrecognized statements in 
slapd.conf.  Strengthening those checks was deferred to 2.4 to avoid 
changing the traditionally forgiving behavior many people seem to 
appreciate at mid-life of 2.3.


p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   [EMAIL PROTECTED]
---

Re: ppolicy

2008-04-12 Thread Rick Stevens


Rick Stevens wrote:

Ralf Haferkamp wrote:

On Freitag, 11. April 2008, Rick Stevens wrote:

Howard Chu wrote:

Chris G. Sellers wrote:

Rick,

try

ldapsearch -{normal stuff here}  cn=  '*' '+'

And then man ldapsearch and read the 'operational' section of the
manpage (near the top)

On Apr 10, 2008, at 6:35 AM, Gavin Henry wrote:

Rick Stevens wrote:

I've got a question regarding the ppolicy overlay.  I've read
the docs I
can find for it on the web, but there's a couple of holes in
them and in
my knowledge.
I've got the config set up (schema, module load, external check
library)
and such.  I've got the default policy DN in the database and
such. From slapd.conf:
overlay ppolicy
ppolicy_default \
"cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext

If the above extract from slapd.conf was quoted exactly, then it is
wrong. Read the slapd.conf(5) manpage.

The "ppolicy_default" stuff is on one line.  I reformatted it for my
mail client.

The indentation is the problem. The slapd.conf(5) manpage states this:

 "If  a  line begins with white space, it is considered a continuation 
  of the previous line."


All the ppolicy statements have to be on separate lines as they are 
separate config options.


Oh.  The example code showed indentations, I believe.  I'll reformat
and give it a whirl.

I really do appreciate the help.  I'll keep the list posted.


As I promised, here's an update:

It was indeed the syntax of the slapd.conf.  The indentations were the
culprit.  I'm a bit surprised that neither the slapd parser nor slaptest
caught it.  Ah, well.

The inability to specify the pwdCheckModule attribute for the policy
also caused me grief until I realized that I had to include
"objectClass: pwdPolicyChecker" to my policies.  I don't recall seeing
that in my google searches, but I'm a bit punch drunk from this whole
thing.

Just wanted to extend my immense gratitude to all the help I've received
on the list.  As they'd say in 1920's Chicago, "Youse mugs is great!"
--
- Rick Stevens, Unix Geek  [EMAIL PROTECTED] -
--
-I'm afraid my karma just ran over your dogma-
--

Re: ppolicy

2008-04-11 Thread Rick Stevens


Ralf Haferkamp wrote:

On Freitag, 11. April 2008, Rick Stevens wrote:

Howard Chu wrote:

Chris G. Sellers wrote:

Rick,

try

ldapsearch -{normal stuff here}  cn=  '*' '+'

And then man ldapsearch and read the 'operational' section of the
manpage (near the top)

On Apr 10, 2008, at 6:35 AM, Gavin Henry wrote:

Rick Stevens wrote:

I've got a question regarding the ppolicy overlay.  I've read
the docs I
can find for it on the web, but there's a couple of holes in
them and in
my knowledge.
I've got the config set up (schema, module load, external check
library)
and such.  I've got the default policy DN in the database and
such. From slapd.conf:
overlay ppolicy
ppolicy_default \
"cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext

If the above extract from slapd.conf was quoted exactly, then it is
wrong. Read the slapd.conf(5) manpage.

The "ppolicy_default" stuff is on one line.  I reformatted it for my
mail client.

The indentation is the problem. The slapd.conf(5) manpage states this:

 "If  a  line begins with white space, it is considered a continuation 
  of the previous line."


All the ppolicy statements have to be on separate lines as they are 
separate config options.


Oh.  The example code showed indentations, I believe.  I'll reformat
and give it a whirl.

I really do appreciate the help.  I'll keep the list posted.
--
- Rick Stevens, Unix Geek  [EMAIL PROTECTED] -
--
-Working with Linux is like wrestling with a worthy opponent.-
-   Working with Windows is like picking on an annoyed child with a  -
-loaded handgun. -
--

Re: ppolicy

2008-04-11 Thread Ralf Haferkamp

On Freitag, 11. April 2008, Rick Stevens wrote:
> Howard Chu wrote:
> > Chris G. Sellers wrote:
> >> Rick,
> >>
> >> try
> >>
> >> ldapsearch -{normal stuff here}  cn=  '*' '+'
> >>
> >> And then man ldapsearch and read the 'operational' section of the
> >> manpage (near the top)
> >>
> >> On Apr 10, 2008, at 6:35 AM, Gavin Henry wrote:
> >>> Rick Stevens wrote:
>  I've got a question regarding the ppolicy overlay.  I've read
>  the docs I
>  can find for it on the web, but there's a couple of holes in
>  them and in
>  my knowledge.
>  I've got the config set up (schema, module load, external check
>  library)
>  and such.  I've got the default policy DN in the database and
>  such. From slapd.conf:
>  overlay ppolicy
>  ppolicy_default \
>  "cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
>  ppolicy_use_lockout
>  ppolicy_hash_cleartext
> >
> > If the above extract from slapd.conf was quoted exactly, then it is
> > wrong. Read the slapd.conf(5) manpage.
>
> The "ppolicy_default" stuff is on one line.  I reformatted it for my
> mail client.
The indentation is the problem. The slapd.conf(5) manpage states this:

 "If  a  line begins with white space, it is considered a continuation 
  of the previous line."

All the ppolicy statements have to be on separate lines as they are 
separate config options.

-- 
Ralf

Re: ppolicy

2008-04-11 Thread Rick Stevens


Howard Chu wrote:

Chris G. Sellers wrote:

Rick,

try

ldapsearch -{normal stuff here}  cn=  '*' '+'

And then man ldapsearch and read the 'operational' section of the
manpage (near the top)

On Apr 10, 2008, at 6:35 AM, Gavin Henry wrote:

Rick Stevens wrote:

I've got a question regarding the ppolicy overlay.  I've read the
docs I
can find for it on the web, but there's a couple of holes in them
and in
my knowledge.
I've got the config set up (schema, module load, external check
library)
and such.  I've got the default policy DN in the database and such.
 From slapd.conf:
overlay ppolicy
ppolicy_default \
"cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext


If the above extract from slapd.conf was quoted exactly, then it is wrong.
Read the slapd.conf(5) manpage.


The "ppolicy_default" stuff is on one line.  I reformatted it for my
mail client.
--
- Rick Stevens, Unix Geek  [EMAIL PROTECTED] -
--
- "OK, so you're a Ph.D. Just don't TOUCH anything!" -
--

Re: ppolicy

2008-04-11 Thread Rick Stevens


Gavin Henry wrote:

Rick Stevens wrote:

I've got a question regarding the ppolicy overlay.  I've read the docs I
can find for it on the web, but there's a couple of holes in them and in
my knowledge.

I've got the config set up (schema, module load, external check library)
and such.  I've got the default policy DN in the database and such.

 From slapd.conf:
overlay ppolicy
ppolicy_default \
"cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext




Are you searching for operational attributes by adding '+' onto you 
ldapsearch? Most of the ppolicy attributes are operational.


Whoops!  Meant to send this to the list, but Thunderbird defaults to the
original sender.  Grrr!

Ah!  No, I hadn't added the '+' bit.  D'oh!  Yes, I see at least the
"pwdChanged" attribute on the new entry, but I don't see the
"pwdHistory" stuff that I'd expect.
--
- Rick Stevens, Unix Geek  [EMAIL PROTECTED] -
--
- If you can't beat your computer at chess...try kickboxing! -
--

Re: ppolicy

2008-04-10 Thread Howard Chu


Chris G. Sellers wrote:

Rick,

try

ldapsearch -{normal stuff here}  cn=  '*' '+'

And then man ldapsearch and read the 'operational' section of the
manpage (near the top)

On Apr 10, 2008, at 6:35 AM, Gavin Henry wrote:

Rick Stevens wrote:

I've got a question regarding the ppolicy overlay.  I've read the
docs I
can find for it on the web, but there's a couple of holes in them
and in
my knowledge.
I've got the config set up (schema, module load, external check
library)
and such.  I've got the default policy DN in the database and such.
 From slapd.conf:
overlay ppolicy
ppolicy_default \
"cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext


If the above extract from slapd.conf was quoted exactly, then it is wrong.
Read the slapd.conf(5) manpage.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: ppolicy

2008-04-10 Thread Chris G. Sellers


Rick,

try

ldapsearch -{normal stuff here}  cn= '*' '+'

And then man ldapsearch and read the 'operational' section of the  
manpage (near the top)


On Apr 10, 2008, at 6:35 AM, Gavin Henry wrote:

Rick Stevens wrote:
I've got a question regarding the ppolicy overlay.  I've read the  
docs I
can find for it on the web, but there's a couple of holes in them  
and in

my knowledge.
I've got the config set up (schema, module load, external check  
library)

and such.  I've got the default policy DN in the database and such.
From slapd.conf:
overlay ppolicy
   ppolicy_default \
   "cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
   ppolicy_use_lockout
   ppolicy_hash_cleartext



Are you searching for operational attributes by adding '+' onto you  
ldapsearch? Most of the ppolicy attributes are operational.

Gavin.
--
Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [EMAIL PROTECTED]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/


__
Chris G. Sellers|   NITLE  - Technology Team
734.661.2318|   [EMAIL PROTECTED]
AIM: imthewherd |   GoogleTalk: [EMAIL PROTECTED]

Re: ppolicy

2008-04-10 Thread Gavin Henry


Rick Stevens wrote:

I've got a question regarding the ppolicy overlay.  I've read the docs I
can find for it on the web, but there's a couple of holes in them and in
my knowledge.

I've got the config set up (schema, module load, external check library)
and such.  I've got the default policy DN in the database and such.

 From slapd.conf:
overlay ppolicy
ppolicy_default \
"cn=DefaultPassword,ou=Policies,dc=billing,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext




Are you searching for operational attributes by adding '+' onto you 
ldapsearch? Most of the ppolicy attributes are operational.

Gavin.
--
Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [EMAIL PROTECTED]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Re: ppolicy: unlock users who are locked out with pwdMaxFailure?

2008-03-04 Thread Buchan Milne

On Wednesday 05 March 2008 03:38:57 Zhang Weiwu wrote:
> Dear all
>
> By googling around I saw a lot of questions were asked for this, but
> either not answered or gets answered without practical how-to:
>
> http://archives.devshed.com/forums/networking-100/question-pertaining-to-pp
>olicy-overlay-feature-1334235.html
> http://www.mail-archive.com/[email protected]/msg08718.html
> http://www.openldap.org/lists/openldap-software/200509/msg00219.html
>
> Let's say, the admin user wishes to unlock an user, without changing his
> password or resetting his password, what should he do?
> should he deletes all pwdLockedTime for the locked user?
> should he deletes pwdAccountLockedTime for the locked user?

I actually just had to do this, as I locked myself out while testing, deleting 
pwdAccountLockedTime works on 2.3.40, though the schema definition for the 
attribute in the slapo-ppolicy man page seems to indicate it can't be 
modified while the one used in the ppolicy.c source indicates it can):

{   "( 1.3.6.1.4.1.42.2.27.8.1.17 "
"NAME ( 'pwdAccountLockedTime' ) "
"DESC 'The time an user account was locked' "
"EQUALITY generalizedTimeMatch "
"ORDERING generalizedTimeOrderingMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 "
"SINGLE-VALUE "
#if 0
/* Not until MANAGEDIT control is released */
"NO-USER-MODIFICATION "
#endif

Regards,
Buchan

Re: ppolicy: invalid value for attributeType pwAttribute -- for "userPassword"

2008-02-29 Thread Chris G. Sellers

Can someone verify this is correct.   I seem to be able to use  
pwdAttribute with the only acceptable value of userPassword.


Thanks
sellers

On Feb 29, 2008, at 10:54 AM, Chris Shenton wrote:



On Feb 23, 2008, at 3:11 AM, Dieter Kluenter wrote:


Chris Shenton <[EMAIL PROTECTED]> writes:


I'm running 2.3.39 and using ppolicy to enforce our password
policy. Got an LDIF file:

dn: cn=npg2810,ou=policies,dc=nasascience,dc=nasa,dc=gov
cn: npg2810
objectClass: top
objectClass: pwdPolicy
objectClass: organizationalRole
objectClass: pwdPolicyChecker
description: OpenLDAP ppolicy to implement NPG2810-like restrictions
pwdAttribute:   userPassword


pwdAttribute value should contain the OID of attribute type  
userpassword,

which is 2.5.4.35


Thanks, that got me going.  I could swear I used "userPassword" in a  
previous version of OpenLDAP.


Perhaps the docs and LDIF file should mention that you need to use  
the OID rather than the name?
Both the man page for slapo-ppolicy and draft-behera-ldap-password- 
policy-xx.txt say "userPassword".


Thanks.



__
Chris G. Sellers|   NITLE  - Technology Team
734.661.2318|   [EMAIL PROTECTED]
AIM: imthewherd |   GoogleTalk: [EMAIL PROTECTED]

Re: ppolicy: invalid value for attributeType pwAttribute -- for "userPassword"

2008-02-29 Thread Howard Chu


Dieter Kluenter wrote:

Hi,

Chris Shenton<[EMAIL PROTECTED]>  writes:


On Feb 23, 2008, at 3:11 AM, Dieter Kluenter wrote:


Chris Shenton<[EMAIL PROTECTED]>  writes:


I'm running 2.3.39 and using ppolicy to enforce our password
policy. Got an LDIF file:

[...]

pwdAttribute:   userPassword

pwdAttribute value should contain the OID of attribute type
userpassword,
which is 2.5.4.35

Thanks, that got me going.  I could swear I used "userPassword" in a
previous version of OpenLDAP.


Yes. That is intended to work; the ppolicy overlay installs a handler to map 
attribute names to their OIDs so that the main slapd code will recognize them.



Perhaps the docs and LDIF file should mention that you need to use the
OID rather than the name?
Both the man page for slapo-ppolicy and draft-behera-ldap-password-
policy-xx.txt say "userPassword".


The only reference I have at hand right now is my own documentation,
but I could swear that the original information had been in some
documentation, either man slapo-ppolicy,
draft-behera-ldap-password-policy or in ppolicy.c. But someone with
more detailed inside knowledge may comment on this issue and clarify.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: ppolicy: invalid value for attributeType pwAttribute -- for "userPassword"

2008-02-29 Thread Dieter Kluenter

Hi,

Chris Shenton <[EMAIL PROTECTED]> writes:

> On Feb 23, 2008, at 3:11 AM, Dieter Kluenter wrote:
>
>> Chris Shenton <[EMAIL PROTECTED]> writes:
>>
>>> I'm running 2.3.39 and using ppolicy to enforce our password
>>> policy. Got an LDIF file:
[...]
>>> pwdAttribute:   userPassword
>>
>> pwdAttribute value should contain the OID of attribute type
>> userpassword,
>> which is 2.5.4.35
>
> Thanks, that got me going.  I could swear I used "userPassword" in a
> previous version of OpenLDAP.
>
> Perhaps the docs and LDIF file should mention that you need to use the
> OID rather than the name?
> Both the man page for slapo-ppolicy and draft-behera-ldap-password-
> policy-xx.txt say "userPassword".

The only reference I have at hand right now is my own documentation,
but I could swear that the original information had been in some
documentation, either man slapo-ppolicy,
draft-behera-ldap-password-policy or in ppolicy.c. But someone with
more detailed inside knowledge may comment on this issue and clarify. 

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy: invalid value for attributeType pwAttribute -- for "userPassword"

2008-02-29 Thread Chris Shenton



On Feb 23, 2008, at 3:11 AM, Dieter Kluenter wrote:


Chris Shenton <[EMAIL PROTECTED]> writes:


I'm running 2.3.39 and using ppolicy to enforce our password
policy. Got an LDIF file:

dn: cn=npg2810,ou=policies,dc=nasascience,dc=nasa,dc=gov
cn: npg2810
objectClass: top
objectClass: pwdPolicy
objectClass: organizationalRole
objectClass: pwdPolicyChecker
description: OpenLDAP ppolicy to implement NPG2810-like restrictions
pwdAttribute:   userPassword


pwdAttribute value should contain the OID of attribute type  
userpassword,

which is 2.5.4.35


Thanks, that got me going.  I could swear I used "userPassword" in a  
previous version of OpenLDAP.


Perhaps the docs and LDIF file should mention that you need to use the  
OID rather than the name?
Both the man page for slapo-ppolicy and draft-behera-ldap-password- 
policy-xx.txt say "userPassword".


Thanks.

Re: ppolicy: invalid value for attributeType pwAttribute -- for "userPassword"

2008-02-23 Thread Tony Earnshaw


Dieter Kluenter skrev, on 23-02-2008 09:11:


I'm running 2.3.39 and using ppolicy to enforce our password
policy. Got an LDIF file:

dn: cn=npg2810,ou=policies,dc=nasascience,dc=nasa,dc=gov
cn: npg2810
objectClass: top
objectClass: pwdPolicy
objectClass: organizationalRole
objectClass: pwdPolicyChecker
description: OpenLDAP ppolicy to implement NPG2810-like restrictions
pwdAttribute:   userPassword


pwdAttribute value should contain the OID of attribute type userpassword,
which is 2.5.4.35


Well, it works (now, it didn't the first time) with userPassword on my 
(production) rigs, too. Both should work, but if I (now) put the OID 
value into the ldif, it magically gets transformed into the string 
userPassword.


Best,

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

Re: ppolicy: invalid value for attributeType pwAttribute -- for "userPassword"

2008-02-23 Thread Tony Earnshaw


Chris Shenton skrev, on 22-02-2008 23:53:

I'm running 2.3.39 and using ppolicy to enforce our password policy. Got 
an LDIF file:


I run ppolicy too at my sites.


dn: cn=npg2810,ou=policies,dc=nasascience,dc=nasa,dc=gov
cn: npg2810
objectClass: top
objectClass: pwdPolicy
objectClass: organizationalRole
objectClass: pwdPolicyChecker
description: OpenLDAP ppolicy to implement NPG2810-like restrictions
pwdAttribute:   userPassword

When I try to slapadd it, I get an error indicating it doesn't like 
"userPassword":


sudo sbin/slapadd -l ldifs/6_policies.ldif
str2entry: invalid value for attributeType pwdAttribute #0 (syntax 
1.3.6.1.4.1.1466.115.121.1.38)

slapadd: could not parse entry (line=51)


I had this on my FC6 test machine the first time I ever tried out 
ppolicy. But I'd run the tests in the build directory after building 
Buchan's srpm and all tests had passed, including test022-ppolicy. 
Running that test again populated $BUILD_DIR/{testdata,testrun} with 
data for that test and I noticed that the ldif used for the test used 
the OID 2.5.4.35 for userPassword, rather than the string. So I put that 
in my ldif and it worked.


If you notice, you also get 1.3.6.1.4.1.1466.115.121.1.38 for the 
syntax. According to my present OL 2.4.8 setup, using gq, the correct 
syntax is 1.3.6.1.4.1.1466.115.121.1.40{128} (with length).


I've never had it since, have no idea why it ever occurred in the first 
place.



The ppolicy.schema file says:

#5.2.1  pwdAttribute
#
#   This holds the name of the attribute to which the password policy is
#   applied.  For example, the password policy may be applied to the
#   userPassword attribute.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.1
  NAME 'pwdAttribute'
  EQUALITY objectIdentifierMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )


Ah. This is interesting, read on ...

And my slapd.conf includes ppolicy.schema in addition to core.schema, 
cosine.schema, and inetorgperson.schema.


Oddly, replacing the "userPassword" value with a random number, like 
"42" or "3.14159" causes no error.


I cannot find userPassword defined in any of the schemas, tho it is 
commented out in core.schema.   If I uncomment it from core.schema it 
complains that it's a dupe:


sbin/slapadd -l ldifs/6_policies.ldif
schema/core.schema: line 244: Duplicate attributeType: "2.5.4.35"
slapadd: bad configuration file!


This is because it's built into slapd as a hard-coded entry in 
$BUILD_DIR/servers/slapd/schema_prep.c. There it is defined as:


   { "userPassword", "( 2.5.4.35 NAME 'userPassword' "
"DESC 'RFC4519/2307: password of user' "
"EQUALITY octetStringMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )"

Notice the syntax? How it differs from the schema definition?


What am I missing?


That would have to be 1: experience and 2: inventiveness.

FWIW I read draft-behera thoroughly and through the whole draft it 
stresses that user password MUST be a single value attribute, while the 
above stanza makes it into a multi-value attribute. In accord with the 
IETF definition. I filed an ITS about this to which Howard replied words 
to the effect of "Probably ...". I'd noticed that if a user had access 
to a GUI such as phpldapAdmin or gq he could give himself whatever extra 
passwords he wanted and all would work. That is not what I, as admin, 
want. So I now patch schema_prep.c for all my builds, thus:


{ "userPassword", "( 2.5.4.35 NAME 'userPassword' "
 "DESC 'RFC4519/2307 adapted for draft behera: password of user' "
 "EQUALITY octetStringMatch "
 "SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} SINGLE-VALUE )"

On the one hand IETF decrees that userPassword MUST be multi-value and 
on the other single-valued, go figure: "let not thy left hand know what 
thy right hand doeth".


Best,

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

Re: ppolicy: invalid value for attributeType pwAttribute -- for "userPassword"

2008-02-23 Thread Dieter Kluenter

Chris Shenton <[EMAIL PROTECTED]> writes:

> I'm running 2.3.39 and using ppolicy to enforce our password
> policy. Got an LDIF file:
>
> dn: cn=npg2810,ou=policies,dc=nasascience,dc=nasa,dc=gov
> cn: npg2810
> objectClass: top
> objectClass: pwdPolicy
> objectClass: organizationalRole
> objectClass: pwdPolicyChecker
> description: OpenLDAP ppolicy to implement NPG2810-like restrictions
> pwdAttribute:   userPassword

pwdAttribute value should contain the OID of attribute type userpassword,
which is 2.5.4.35

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6

Re: ppolicy "check_password" needs include files not available in install

2008-01-10 Thread Howard Chu


Chris Shenton wrote:

I'm finding the ppolicy overlay very useful for implementing our
enterprise's password policies.  The build process is a bit of a
nuisance tho.



But those includes, and the files they include in turn, do not exist
in the installed LDAP include files.  So in order to build this
little check_password.c program I have to untar and then ./configure
all the OpenLDAP source again.

I realize that check_password.c is not an official part of OpenLDAP
but would it be possible to put the include files that overlays like
this need into the installed locations so overlays wouldn't need to
get and config OpenLDAP all over again?


If you're building from source you're welcome to edit the Makefiles and 
install whatever files you want wherever you want. If you're using a binary 
distribution of OpenLDAP, contact whoever assembled the package for you. 
OpenLDAP only distributes source code, so this really isn't something for us 
to address.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: ppolicy + slapcat = ldif vulnerability?

2007-12-04 Thread Scott Classen



On Dec 4, 2007, at 7:06 AM, Clowser, Jeff (Contractor) wrote:

I'm not sure if this is truly a vulnerability, but I thought I'd  
put it

out there for discussion.


I have set up so a default ppolicy such that 3 old passwords are  
stored

in a users pwdHistory attribute.


When I back up the bdb database via slapcat -l backup.ldif the

userPassword field looks to be Base64

hashed.

userPassword:: e1NTSEF9VWFTNDNVDRWEx1QzEyWjASGVWc0VZHRNTmt4M1c=

but the passwd history leaves the passwd hashes visible.

pwdHistory:
20071203220105Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA} 
wAuvjfMkMyKKHcMV1

Tg7qiG0x4


Obviously these backup LDIF files are keep as secure as possible, and

these are OLD passwds, but

should the pwdHistory attribute also be hashed when being slapcated?


Keep in mind that base 64 encoded hashing is NOT any form of  
encryption
- i.e. it's reversible, and you don't have to "know" anything  
secret to

decode it, so the fact that one is base64 hashed and one is not really
provides no true security benefit (other than very minimal  
obscuring so

that you can't see passwords at a quick glance) and doesn't create any
real security hole.  The main reason for base64 encoding attributes in
LDAP, as far as I've ever heard, is just to ensure binary values are 7
bit ascii text file safe for import/export.  Base64 is definitely not
something to consider as a security mechanism.  The ssha hash is what
"protects" the password (i.e. it IS encryption).  You want to prevent
people from seeing that hash (i.e. acl's to prevent seeing it via LDAP
lookups, secure the slapcat output, etc) because it is possible to  
come
up with a valid password using the ssha hash (brute forcing it  
offline,

or I'm sure there are huge precomputed db's of ssha hashes out there,
etc), but the base64 encoding itself is a minimum to none barrier  
to any

of this.

My biggest question would be why these 2 attributes are treated
differently - i.e. are userpassword and pwdhistory different types or
something to trigger different behaviour, or does slapcat just  
hardcode

userpassword as an attribute to base64 hash, etc?

 - Jeff




Aha, I see. I guess a simple google search could have told me that  
base64 is not an encryption algorithm.

I appreciate the responses.

Scott

:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
Scott Classen, Ph.D.
SIBYLS Beamline 12.3.1
Advanced Light Source
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS6R2100
c) 510.206.4418
o) 510.495.2697
beamline) 510.495.2134
:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:

RE: ppolicy + slapcat = ldif vulnerability?

2007-12-04 Thread Hallvard B Furuseth

Clowser, Jeff (Contractor) writes:
> My biggest question would be why these 2 attributes are treated
> differently - i.e. are userpassword and pwdhistory different types or
> something to trigger different behaviour, or does slapcat just
> hardcode userpassword as an attribute to base64 hash, etc?

slapcat and ldapsearch (via liblutil/ldif.c) hardcode that userPassword
is base64-encoded.  So are ';binary', attribute values which
contain 8-bit characters, and some other special cases.

-- 
Regards,
Hallvard

RE: ppolicy + slapcat = ldif vulnerability?

2007-12-04 Thread Clowser, Jeff (Contractor)

>I'm not sure if this is truly a vulnerability, but I thought I'd put it
out there for discussion.
>
>I have set up so a default ppolicy such that 3 old passwords are stored
in a users pwdHistory attribute.
>
>When I back up the bdb database via slapcat -l backup.ldif the
userPassword field looks to be Base64
> hashed.
>
>userPassword:: e1NTSEF9VWFTNDNVDRWEx1QzEyWjASGVWc0VZHRNTmt4M1c=
>
>but the passwd history leaves the passwd hashes visible.
>
>pwdHistory:
20071203220105Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}wAuvjfMkMyKKHcMV1
Tg7qiG0x4
>
>Obviously these backup LDIF files are keep as secure as possible, and
these are OLD passwds, but 
>should the pwdHistory attribute also be hashed when being slapcated?

Keep in mind that base 64 encoded hashing is NOT any form of encryption
- i.e. it's reversible, and you don't have to "know" anything secret to
decode it, so the fact that one is base64 hashed and one is not really
provides no true security benefit (other than very minimal obscuring so
that you can't see passwords at a quick glance) and doesn't create any
real security hole.  The main reason for base64 encoding attributes in
LDAP, as far as I've ever heard, is just to ensure binary values are 7
bit ascii text file safe for import/export.  Base64 is definitely not
something to consider as a security mechanism.  The ssha hash is what
"protects" the password (i.e. it IS encryption).  You want to prevent
people from seeing that hash (i.e. acl's to prevent seeing it via LDAP
lookups, secure the slapcat output, etc) because it is possible to come
up with a valid password using the ssha hash (brute forcing it offline,
or I'm sure there are huge precomputed db's of ssha hashes out there,
etc), but the base64 encoding itself is a minimum to none barrier to any
of this.

My biggest question would be why these 2 attributes are treated
differently - i.e. are userpassword and pwdhistory different types or
something to trigger different behaviour, or does slapcat just hardcode
userpassword as an attribute to base64 hash, etc?

 - Jeff

Re: ppolicy + slapcat = ldif vulnerability?

2007-12-04 Thread Hallvard B Furuseth

Scott Classen writes:
> I'm not sure if this is truly a vulnerability, but I thought I'd put
> it out there for discussion.
> (...)
> When I back up the bdb database via slapcat -l backup.ldif the
> userPassword field looks to be Base64 hashed.
> (...)
> but the passwd history leaves the passwd hashes visible.

If you can get at the base64 representation, you can also base64-decode
it.  However if a userPassword contains a plaintext password and is not
base64-encoded, you can then accidentally display the password for
others to see.  I think that's why userPassword is displayed in base64.

I don't remember if pwdHistory can contain a currently active password?
Otherwise it doesn't seem much of a problem.

But this reminds me - there are also back-config attributes which
contain passwords, in particular olcRootPW.  I'm not sure that is a
problem though.  Hopefully people are more careful with who is looking
when they are playing with cn=config, in particular if they have
plaintext passwords there.  And base64-encoding it could frustrate
people who _want_ to read it.  I don't know whether the best approach is
to base64 those attributes or leave them alone.

-- 
Regards,
Hallvard

Re: ppolicy + slapcat = ldif vulnerability?

2007-12-04 Thread Aaron Richton

I imagine the question would be if this is successful or not -- i.e., if 
you have a userPassword -> pwdHistory value with high characters and 
attempt to reuse it later, does this allow the password to be improperly 
reused? If you've got some data where this is happening and can run that 
experiment, that'd be a good data point.


On Mon, 3 Dec 2007, Scott Classen wrote:


I'm not sure if this is truly a vulnerability, but I thought I'd put it out 
there for discussion.

openldap 2.4.6
bdb backend
ppolicy overlay

I have set up so a default ppolicy such that 3 old passwords are stored in a 
users pwdHistory attribute.

When I back up the bdb database via slapcat -l backup.ldif the userPassword 
field looks to be Base64 hashed.

userPassword:: e1NTSEF9VWFTNDNVDRWEx1QzEyWjASGVWc0VZHRNTmt4M1c=

but the passwd history leaves the passwd hashes visible.

pwdHistory: 
20071203220105Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}wAuvjfMkMyKKHcMV1Tg7qiG0x4

Obviously these backup LDIF files are keep as secure as possible, and these are 
OLD passwds, but should the pwdHistory attribute also be hashed when being 
slapcated?

Scott

Re: ppolicy help

2007-08-14 Thread Joshua M. Miller

Please note that the pwdLockoutDuration is in seconds...so if you get 
locked out, it's only for 15 seconds in your case.  You may want to 
increase this value to something like 15 minutes (900 seconds) for testing.


HTH,
--
Joshua M. Miller - RHCE,VCP


Scott Phelps wrote:



* defaultPolicy.ldif

dn: cn=defaultPolicy,ou=policies,#SECRET##
cn: defaultPolicy
objectClass: organizationalRole
objectClass: pwdPolicy
objectClass: top
pwdLockout: TRUE
pwdMaxFailure: 3
pwdAttribute: userPassword
pwdGraceAuthNLimit: 3
pwdLockoutDuration: 15
pwdAllowUserChange: TRUE



So with this all in place I get no errors starting slapd (the module
gets loaded.)  I run the following command 4 times:
ldapsearch -P 3 -x  -LLL -e ppolicy -D
"uid=ppolictest,ou=people,#SECRET##" -W "(objectclass=*)"
Entering an incorrect password each time, however the account never gets
locked out and the operational attributes never change.

Re: ppolicy help

2007-08-14 Thread Buchan Milne

On Monday 13 August 2007 23:25:58 Scott Phelps wrote:

[...]

> databasebdb
>
> # Overlay Directives
> overlay ppolicy
> ppolicy_default "cn=defaultPolicy,ou=policies,#SECRET###"
> ppolicy_use_lockout
>
> directory   "/var/lib/ldap"
> # For the Debian package we use 2MB as default but be sure to update this
> # value if you have plenty of RAM
> dbconfig set_cachesize 0 2097152 0
> # Sven Hartge reported that he had to set this value incredibly high
> # to get slapd running at all. See http://bugs.debian.org/303057
> # for more information.
> # Number of objects that can be locked at the same time.
> dbconfig set_lk_max_objects 1500
> # Number of locks (both requested and granted)
> dbconfig set_lk_max_locks 1500
> # Number of lockers
> dbconfig set_lk_max_lockers 1500
> # Indexing options for database #1
> index   objectClass eq
> # Save the time that the entry gets modified, for database #1
> lastmod on
>
> access to dn.children="ou=people,#SECRET##" attrs=userPassword
> by group/groupOfNames/member="#SECRET##" write
> by self write
> by * auth
>


This database has no rootdn set. AFAIK, you need a rootdn to be configured for 
the internal writes by ppolicy to work (I can't be sure as all my databases 
with ppolicy have rootdn's).

> * defaultPolicy.ldif
> 
> dn: cn=defaultPolicy,ou=policies,#SECRET##
> cn: defaultPolicy
> objectClass: organizationalRole
> objectClass: pwdPolicy
> objectClass: top
> pwdLockout: TRUE
> pwdMaxFailure: 3
> pwdAttribute: userPassword
> pwdGraceAuthNLimit: 3
> pwdLockoutDuration: 15
> pwdAllowUserChange: TRUE
>
> * ppolicytest.ldif
> =
> dn: uid=ppolicytest,ou=people,#SECRET##
> uid: ppolicytest
> uidNumber: 1012
> gidNumber: 100
> homeDirectory: /home/ppolicytest
> loginShell: /bin/bash
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: top
> structuralObjectClass: inetOrgPerson
> entryUUID: e4c33596-d832-102b-8c70-39998be84848
> creatorsName: #SECRET##
> createTimestamp: 20070806063457Z
> pwdPolicySubentry: cn=defaultPolicy,ou=policies,#SECRET##
> userPassword: {MD5}Gh3JHJBzJcaScd3wyUS8cg==
> pwdChangedTime: 20070806070643Z
> cn: ppolicytest
> entryCSN: 20070806070815Z#00#00#00
> modifiersName: #SECRET##
> modifyTimestamp: 20070806070815Z
> entryDN: uid=ppolicytest,ou=people,#SECRET##
> subschemaSubentry: cn=Subschema
> hasSubordinates: FALSE
>
>
> So with this all in place I get no errors starting slapd (the module
> gets loaded.)  I run the following command 4 times:
> ldapsearch -P 3 -x  -LLL -e ppolicy -D
> "uid=ppolictest,ou=people,#SECRET##" -W "(objectclass=*)"
> Entering an incorrect password each time, however the account never gets
> locked out and the operational attributes never change.


Regards,
Buchan

Re: ppolicy and others attributes

2007-06-06 Thread Howard Chu


Raphaël 'SurcouF' Bordet wrote:
Hi, 


 Can we use ppolicy with another attribut than userPassword,
userCertificate by example ?


Using userCertificate would make no sense. Currently the ppolicy code 
only works with the userPassword attribute.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: ppolicy and others attributes

2007-06-06 Thread Gabriel Stein


Raphael,

Reading the man of PPOLICY, you can use  the  attributes  from pwdPolicy
object class to defines policies about userPassword attribute.

But userCertificate, I never see someone using this.

Cheers.

On 6/6/07, Raphaël 'SurcouF' Bordet <[EMAIL PROTECTED]> wrote:


Hi,

Can we use ppolicy with another attribut than userPassword,
userCertificate by example ?

Regards,

--
Raphaël 'SurcouF' Bordet






--
/\
Gabriel Stein
[EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
Administrador de Redes -
Network Administrador
Linux User #223750
51-92796310
Porto Alegre - RS - Brasil

Re: ppolicy and others attributes

2007-06-06 Thread Buchan Milne

On Wednesday, 6 June 2007, Raphaël 'SurcouF' Bordet wrote:
> Hi,
>
>  Can we use ppolicy with another attribut than userPassword,
> userCertificate by example ?

That wouldn't make sense, as:
-certificates have expiry times
-if you want to prevent use of the certificate before the expiry time, revoke 
it (and ensure the updated CRL is available whereever you need it)
-you can
-you can't change a certificate via exop (and they key should never cross the 
wire anyway)

Or, are you really looking for a PKI that can store data in  LDAP?

-- 
Buchan Milne
ISP Systems Specialist - Monitoring/Authentication Team Leader
B.Eng,RHCE(803004789010797),LPIC-2(LPI74592)


pgpMcnPIJwDfl.pgp
Description: PGP signature

Re: ppolicy pwdreset problem

2007-04-27 Thread Svend Sorensen


On 4/26/07, aleem bagwan  wrote:

  I m using openldap-2.3.4 version with ppolicy enabled. I have a problem
with the reset feature. If i set pwdReset and pwdMustChange attribute for a
user, say testuser, I can see that it works as expected using ldapsearch
command ie  it never allows u to login & asks u to modify the password.


Here you binding and attempting a search with a reset password...


Now
for the problem: At the client side(say PHP), If i bind to the server using
testuser and resetted password, i m allowed to log in..How is that
possible...it should not work that way..right..It should emulate
ldapsearch..am i right?


..and here you are just binding, I expect.  With pwdReset set, you can
bind (and change your password), but you cannot perform searches.

Re: Ppolicy DIGEST-MD5 ignore expired password

2007-04-25 Thread Howard Chu


Jiri Netolicky wrote:

Jiri Netolicky wrote:

Have a nice day.

I have to implement password policy in our OpenLdap. During testing futures
of ppolicy module I found that they ignore expired password when I authenticate
user by SASL DIGEST-MD5.
When I try on exprired account:

Correct. Password policies as currently defined in LDAP only affect
Simple Binds.



Many thanks for quick answer.

Do you plan in near future implement password policy in other
authentication methods? If not the only way for me is disable SASL
authentication
and force bind authentication secured by SSL or TLS.


It is certainly desirable, but pushing the SASL specification is really 
outside the scope of LDAP. So yes, we are pushing for this, but have no 
idea how long it will take.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: Ppolicy DIGEST-MD5 ignore expired password

2007-04-25 Thread Jiri Netolicky

Jiri Netolicky wrote:
> Have a nice day.
>
> I have to implement password policy in our OpenLdap. During testing futures
> of ppolicy module I found that they ignore expired password when I 
authenticate
> user by SASL DIGEST-MD5.
> When I try on exprired account:

Correct. Password policies as currently defined in LDAP only affect
Simple Binds.

Many thanks for quick answer.

Do you plan in near future implement password policy in other
authentication methods? If not the only way for me is disable SASL
authentication
and force bind authentication secured by SSL or TLS.

Re: Ppolicy DIGEST-MD5 ignore expired password

2007-04-25 Thread Howard Chu


Jiri Netolicky wrote:

Have a nice day.

I have to implement password policy in our OpenLdap. During testing futures
of ppolicy module I found that they ignore expired password when I authenticate
user by SASL DIGEST-MD5.
When I try on exprired account:


Correct. Password policies as currently defined in LDAP only affect 
Simple Binds.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: PPolicy

2007-04-24 Thread Aaron Richton


See the "tests" directory in the OpenLDAP distribution.

On Tue, 24 Apr 2007, Greg Ryan wrote:


Has anyone ever gotten ppolicy to work? I have been trying for weeks and
just cant get it to work at all. Does anyone have any config examples
from a working ppolicy config?

Re: PPolicy

2007-04-24 Thread Joshua M. Miller

I have ppolicy partially working, pieced together from examples on the 
web from Howard and others.  Please find my sanitized slapd.conf attached.


Here is my ppolicy DIT entry:

# default, Policies, example.com
dn: cn=default,ou=Policies,dc=example,dc=com
cn: default
objectClass: pwdPolicy
objectClass: device
pwdAttribute: userPassword
pwdMaxAge: 2592000

This is merely to expire user logins after the specified number of 
seconds (password aging)...


The problems that I'm having though:
1. getting the provider to replicate changes to the password policy to 
the consumer.
2. the password policies dont take effect until people change their 
passwords!  (good and bad to this...)


Thanks,
--
Joshua M. Miller - RHCE,VCP


Greg Ryan wrote:
Has anyone ever gotten ppolicy to work? I have been trying for weeks and 
just cant get it to work at all. Does anyone have any config examples 
from a working ppolicy config?
# slapd.conf
include /usr/share/openldap/schema/core.schema
include /usr/share/openldap/schema/cosine.schema
include /usr/share/openldap/schema/inetcomperson.schema
include /usr/share/openldap/schema/nis.schema
include /usr/share/openldap/schema/corba.schema
include /usr/share/openldap/schema/java.schema
include /usr/share/openldap/schema/krb5-kdc.schema
include /usr/share/openldap/schema/kerberosobject.schema
include /usr/share/openldap/schema/misc.schema
include /usr/share/openldap/schema/openldap.schema
include /usr/share/openldap/schema/autofs.schema
include /usr/share/openldap/schema/samba.schema
include /usr/share/openldap/schema/kolab.schema
include /usr/share/openldap/schema/evolutionperson.schema
include /usr/share/openldap/schema/calendar.schema
include /usr/share/openldap/schema/sudo.schema
include /usr/share/openldap/schema/dnszone.schema
include /usr/share/openldap/schema/dhcp.schema
include /usr/share/openldap/schema/ppolicy.schema
#
pidfile /var/run/ldap/slapd.pid
argsfile/var/run/ldap/slapd.args
loglevel256

# Setup TLS/SSL stuff
TLSCipherSuite HIGH:MEDIUM:+SSLv2:RSA
TLSCertificateFile /etc/openldap/ssl/host.example.com.crt
TLSCertificateKeyFile /etc/openldap/ssl/host.pem
TLSCACertificateFile /usr/share/ssl/certs/cacert.crt
TLSVerifyClient never

# Require TLS even on port 389
security ssf=168 tls=168 update_ssf=168 update_tls=168 simple_bind=128

# Setup password hash requirement
password-hash {crypt}

# Setup ACLs
access to attrs=userPassword
  by dn.exact="uid=replicator,ou=People,dc=example,dc=com"  read
  by self write
  by * auth
access to *
  by dn.exact="uid=replicator,ou=People,dc=example,dc=com"  read
by * write
by self auth
access to *
  by * read
  by anonymous auth

# Load appropriate modules
moduleload /usr/lib/openldap/syncprov.la
moduleload /usr/lib/openldap/ppolicy.la
moduleload /usr/lib/openldap/unique.la
moduleload /usr/lib/openldap/back_ldap.la
moduleload /usr/lib/openldap/lastmod.la
#
databasebdb
suffix  "dc=example,dc=com"
rootdn  "cn=manager,dc=example,dc=com"
rootpw  "secret"
directory   /var/lib/ldap
checkpoint 256 5

#
# Setup syncrep replication
#
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
#
index   objectClass,uid,dc,o,ou  eq
index   cneq,subinitial
index   uidNumber eq
index   gidNumber eq
index   entryCSN  eq
index   entryUUID   eq
index   nisNetgroupTriple eq
index   memberUid,uniqueMember eq

# Replicas running syncrepl as non-rootdn need unrestricted size/time limits:
limits group="cn=replicators,ou=Group,dc=example,dc=com"
 size=unlimited
 time=unlimited

# password policy
overlay ppolicy
ppolicy_default "cn=default,ou=Policies,dc=example,dc=com"

Re: ppolicy and sync replication

2007-04-04 Thread Craig Squires

On Tue, 2007-04-03 at 14:43 -0700, Howard Chu wrote:
> Craig Squires wrote:
> > This is a followup to a thread from a couple of months ago. The issue is
> > interaction between ppolicy and syncrepl overlays. The message I want to
> > start at is:
> 
> There is no "syncrepl overlay". (Possibly there should be, but that work 
> got stalled.) The syncrepl consumer is intrinsic to slapd, not a 
> separate overlay.

oops. I meant syncprov. I guess I'm confused about the relation between
syncrepl and the syncprov overlay.

> >> 1 - I did bind to the master server 3 times using wrong password. I
> >> failed to bind using the right password after that and failed. 
> >> Expected
> >> 2- I did bind to the consumer server using the right password. 
> >> Failed. Expected.
> > 
> > I note that in my experience, for this to work the "overlay ppolicy"
> > statement in the consumer's slapd.conf must precede the "overlay
> > syncrepl" statement. Without that, the consumer doesn't seem to respect
> > the account lock.
> 
> This statement makes no sense, since there is no syncrepl overlay for 
> the consumer.

...again, I meant syncprov.

[...]
> I think you're running into the same crash I found in ITS#4904, fixed 
> yesterday. The fix will be in 2.3.35. Since it's only a one-line fix, 
> you can easily patch your 2.3.34 source if you need it right away.

Thanks!

> > [here's the rest of Sadique's message]
> >> 3- I did bind to the consumer server using the wrong password three 
> >> times. I failed to bind to the consumer using the right password 
> >> after that. Failed. Expected
> >> 4 - I did bind to the master server using the right password. 
> >> Success. Not expected before elapsing 90 seconds.
> >>
> >> I know the consumer server is not supposed to update the master 
> >> server database, but is there any work around? Does openldap support 
> >> multi master replication? Is this a limitation. Does this mean a 
> >> client locked on consumer server - as set by the policy - would be 
> >> able to bind to the master server overriding the policy.
> 
> I guess it would be possible to arrange for the consumer to chain the 
> ppolicy updates back to the master. I haven't tried that. OpenLDAP 2.4 
> has multimaster support so that would be another possibility. We 
> probably should have a config keyword to govern that behavior. In very 
> widely distributed directories it doesn't make sense to replicate login 
> events in one corner of the world to every other installation.

I might have a look at chaining. A keyword would be good. In some
distributed authentication contexts it would be nice to be able to track
multiple logins across e.g. different applications which happen to use
different replicas of the same data.

Re: ppolicy and sync replication

2007-04-03 Thread Howard Chu


Craig Squires wrote:

This is a followup to a thread from a couple of months ago. The issue is
interaction between ppolicy and syncrepl overlays. The message I want to
start at is:


There is no "syncrepl overlay". (Possibly there should be, but that work 
got stalled.) The syncrepl consumer is intrinsic to slapd, not a 
separate overlay.



http://www.openldap.org/lists/openldap-software/200701/msg00131.html

which didn't get a direct reply. Here's a quote of the relevant context:


From: Sadique Puthen <[EMAIL PROTECTED]>

I did a bit more testing about this.

I set up password policy as below. Only relevant part given.

pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 90

1 - I did bind to the master server 3 times using wrong password. I
failed to bind using the right password after that and failed. 
Expected
2- I did bind to the consumer server using the right password. 
Failed. Expected.


I note that in my experience, for this to work the "overlay ppolicy"
statement in the consumer's slapd.conf must precede the "overlay
syncrepl" statement. Without that, the consumer doesn't seem to respect
the account lock.


This statement makes no sense, since there is no syncrepl overlay for 
the consumer.



After 90 seconds everything works fine.


At this point I'm having some further problems:

2a- I bind with the right password on the consumer after the lockout
duration and the pwdFailureTime and pwdAccountLockedTime attributes
are deleted on the consumer, as expected. However, related to Sadique's
next step, those attributes still exist on the provider because
obviously no info gets pushed back from the consumer. This isn't
necessarily a problem for me, but the following is:

2b- I bind with the right password on the provider after the lockout
duration and the attributes are now deleted there. But the consumer
now crashes and is not recoverable. Oddly, if I bind incorrectly on
the provider first and then bind correctly the crash does not occur.
With the new incorrect bind after the lockout duration the
pwdAccountLockedTime attribute is deleted while the old pwdFailureTime
attributes are not. They are deleted with the following correct bind. So
there's something specific about the LockedTime attr that's at issue.



I'm running 2.3.34 on RHEL AS4 (both provider and consumer) using Buchan
Milne's RPMs (thanks Buchan!!). The same issue existed in 2.3.31. I
should also note that I'm doing delta syncrepl... and haven't tried this
with regular syncrepl. I've noticed asides at a couple of places in the
archives that suggest that at least some ppolicy related attrs aren't
supposed to be replicated, yet there's some suggestion at others that
they are. In particular, Pierangelo Masarati states, in a reply to the
original message from Sadique, that: "In general, ppolicy related 
state values are not replicated; each replica is on its own as far as 
state-related attributes in enforcing password policy. [...]"


I think you're running into the same crash I found in ITS#4904, fixed 
yesterday. The fix will be in 2.3.35. Since it's only a one-line fix, 
you can easily patch your 2.3.34 source if you need it right away.



[here's the rest of Sadique's message]
3- I did bind to the consumer server using the wrong password three 
times. I failed to bind to the consumer using the right password 
after that. Failed. Expected
4 - I did bind to the master server using the right password. 
Success. Not expected before elapsing 90 seconds.


I know the consumer server is not supposed to update the master 
server database, but is there any work around? Does openldap support 
multi master replication? Is this a limitation. Does this mean a 
client locked on consumer server - as set by the policy - would be 
able to bind to the master server overriding the policy.


I guess it would be possible to arrange for the consumer to chain the 
ppolicy updates back to the master. I haven't tried that. OpenLDAP 2.4 
has multimaster support so that would be another possibility. We 
probably should have a config keyword to govern that behavior. In very 
widely distributed directories it doesn't make sense to replicate login 
events in one corner of the world to every other installation.



Cheers, Craig


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: Ppolicy overlay password checking module

2007-01-30 Thread Howard Chu


[EMAIL PROTECTED] wrote:

Hi !

A pair days ago I finished the same.
And it works ...



paroles_rez:

  /* Allocate  */
message = (char *)malloc(sizeof(char) * (strlen(retmsg)+1));


A comment on style: The C language spec defines sizeof(char) == 1. Explicitly 
multiplying by "sizeof(char)" in C code is redundant, distracting, and confusing.


It would have been better just to use strdup() here.


  /* Copy the contents of the string. */
strcpy(message, retmsg);

  *ppErrStr=message;

return pwqr;

}



Only my returned error message slapd shows in log file and doesn't
forward to client.


That is by design. These errors are only meant for system administrators to 
view. Passing them back to the client would allow an attacker to discover the 
policy, and assist in password cracking attempts.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc
  OpenLDAP Core Teamhttp://www.openldap.org/project/

RE: Ppolicy overlay password checking module

2007-01-30 Thread Andris.Eiduks


Hi !

A pair days ago I finished the same.
And it works ...


Slapd.conf :
.
include /usr/local/etc/openldap/schema/ppolicy.schema

modulepath  /usr/sbin/openldap

moduleload ppolicy.la

overlay ppolicy
ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=tm"
ppolicy_hash_cleartext
ppolicy_use_lockout




Ppolicy_example.ldif :

dn: ou=ppolicy, ou=users, ou=tm
ou: ppolicy
objectClass: organizationalUnit

dn: cn=std, ou=ppolicy, ou=users, ou=tm
pwdCheckModule: check_password.so
pwdMaxFailure: 6
pwdMustChange: TRUE
pwdAttribute: userPassword
pwdMinLength: 7
pwdSafeModify: FALSE
pwdInHistory: 4
pwdGraceAuthNLimit: 3
pwdCheckQuality: 1
objectClass: pwdPolicy
objectClass: top
objectClass: device
objectClass: pwdPolicyChecker
pwdLockoutDuration: 1800
cn: std
pwdAllowUserChange: TRUE
pwdExpireWarning: 2591900
pwdLockout: TRUE
pwdMaxAge: 2592000





And checking function :

.../openldap-2.3.32/servers/slapd/overlays/check_password.c : 

#include 
#include 
#include 
#include 
#include "portable.h"
#include "slap.h"



int init_module()
{
return 0;
}

int check_password(char *pPasswd, char **ppErrStr, Entry *pEntry)
{
char pwqr=0;
char retmsg[255];
char *message;




pwqr = 0; 

if (strstr( pPasswd, " ") != NULL)
{
pwqr = 1; 
strcpy(retmsg , "1:Password contains SPACE ...");
goto paroles_rez;
}
//
..
// other controls 
..  
//

return 0;

paroles_rez:

  /* Allocate  */
message = (char *)malloc(sizeof(char) * (strlen(retmsg)+1));
  /* Copy the contents of the string. */
strcpy(message, retmsg);

  *ppErrStr=message;

return pwqr;
}




.../openldap-2.3.32/servers/slapd/overlays/Makefile:
...
check_password:
gcc -fPIC -c -I../../../include -I.. check_password.c
gcc -shared -o check_password.so check_password.o
cp -f check_password.so /usr/sbin/openldap
.




Only my returned error message slapd shows in log file and doesn't
forward to client.



Jan 30 09:05:39 KS-Test-1 slapd[11959]: check_password_quality: module
error: (check_password.so) 1:Password contains SPACE [1]
Jan 30 09:05:39 KS-Test-1 slapd[11959]: send_ldap_result: conn=4 op=5
p=3
Jan 30 09:05:39 KS-Test-1 slapd[11959]: send_ldap_result: err=19
matched="" text="Password fails quality checking policy"
Jan 30 09:05:39 KS-Test-1 slapd[11959]: send_ldap_response: msgid=6
tag=103 err=19
Jan 30 09:05:39 KS-Test-1 slapd[11959]: conn=4 op=5 RESULT tag=103
err=19 text=Password fails quality checking policy

  




Andris Eiduks




 


-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
.org] On Behalf Of Metcalf, Roger
Sent: Monday, January 29, 2007 5:51 PM
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Ppolicy overlay password checking module


Hi John,

I didn't find a response to your query (pasted below).  I'm about to try
cooking up something similar.  Did you ever get help or find the magic
combination of ingredients to get pwdCheckModule working?  If so, please
share the recipe!  

Thanks,
Roger Metcalf

# # # # #

Hi all,

I don't know if this is the right list, but i'm hoping the author of the
overlay or somebody equally knowledgeable is on this list and will be
able to help me.

I'm attempting to use the password policy overlay with a custom password
strength checker. The docs say the following on the subject:

"pwdCheckModule This attribute names a user-defined loadable module that
must instantiate the check_password() function. This function will be
called to further check a new password if pwdCheckQuality is set to one
(1) or two (2), after all of the built-in password compliance checks
have been passed. This function will be called according to this
function prototype:

int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry);

...

Note: The user-defined loadable module named by pwdCheckModule must be
in slapd's standard executable search PATH. Note: pwdCheckModule is a
non-standard extension to the LDAP password policy proposal

Now, i'm a little unclear on how exactly to compile such a module or
where to place it so as to load it. "standard executable search PATH"
seems to imply it should go where binaries go (for example
/usr/local/bin) but i'm wondering if maybe it's the modulepath in the
slapd.conf. I've tried both so i'm assuming i'm not compiling it up
correctly

The following is my simple program using cracklib (untested but i
believe should work). The file is called ldap_cracklib.c

#include 
#include 
#include 

int  check_password  (char  *pPasswd, char **ppErrStr, Entry *pEntry);

int check_password( char *pPasswd, char **ppErrStr, Entry *pentry) {
char *ret;
ret = (char *) FascistCheck( pPasswd,
'/usr/local/libdata/cracklib/pw_dict' );
if (ret == NULL)
{
return 0;
}
*ppErrStr = ret;

Re: Ppolicy overlay password checking module

2007-01-29 Thread Howard Chu


Metcalf, Roger wrote:

Hi John,

I didn't find a response to your query (pasted below).  I'm about to try
cooking up something similar.  Did you ever get help or find the magic
combination of ingredients to get pwdCheckModule working?  If so, please
share the recipe!


Yes, it depends on the modulepath. And yes, a module is a DLL or shared 
library, just like a backend module or overlay module, and building it with 
libtool is probably the smartest approach.


Unlike other modules which are loaded once and then stay loaded, this module 
is loaded when referenced, then unloaded again after the call completes.




Thanks,
Roger Metcalf

# # # # #

Hi all,

I don't know if this is the right list, but i'm hoping the author of the
overlay or somebody equally knowledgeable is on this list and will be
able to help me.

I'm attempting to use the password policy overlay with a custom password
strength checker. The docs say the following on the subject:

"pwdCheckModule This attribute names a user-defined loadable module that
must instantiate the check_password() function. This function will be
called to further check a new password if pwdCheckQuality is set to one
(1) or two (2), after all of the built-in password compliance checks
have been passed. This function will be called according to this
function prototype:

int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry);

...

Note: The user-defined loadable module named by pwdCheckModule must be
in slapd's standard executable search PATH. Note: pwdCheckModule is a
non-standard extension to the LDAP password policy proposal

Now, i'm a little unclear on how exactly to compile such a module or
where to place it so as to load it. "standard executable search PATH"
seems to imply it should go where binaries go (for example
/usr/local/bin) but i'm wondering if maybe it's the modulepath in the
slapd.conf. I've tried both so i'm assuming i'm not compiling it up
correctly

The following is my simple program using cracklib (untested but i
believe should work). The file is called ldap_cracklib.c

#include 
#include 
#include 

int  check_password  (char  *pPasswd, char **ppErrStr, Entry *pEntry);

int check_password( char *pPasswd, char **ppErrStr, Entry *pentry)
{
char *ret;
ret = (char *) FascistCheck( pPasswd,
'/usr/local/libdata/cracklib/pw_dict' );
if (ret == NULL)
{
return 0;
}
*ppErrStr = ret;
return 1;
}

I've compiled it to an object file with gcc -c (and a whole bunch of
other arguments for includes, etc) and also to a library using libtool
(i took the makefile for smbk5pwd and modified it). I've then tried
modifying the pwdCheckModule to ldap_cracklib.o and ldap_cracklib.so
respectively (after copying the relevant files to both /usr/local/bin
and our module path, /usr/local/libexec/openldap).

I'm using the following command to try and change my password:

ldappasswd -x -W -A -H ldaps://ldapservername.fully.qualified.domain -D
"uid=allmanj,ou=people,dc=fully,dc=qualified,dc=domain"

It prompts me for my old password twice, once for my new and then says:

ldap_bind: Invalid credentials (49)

I can confirm that my (old) password is correct by using ldapwhoami.

So should i be making a library? Should i be making a basic compiled
object? Should i be making something else? Please bear in mind that i'm
an administrator not a programmer so i am a little ignorant.

I've tried boosting the ldap log level and looking for errors but i dont
see anything.

Any help would be greatly appreciated.

Thanks,

John




--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc
  OpenLDAP Core Teamhttp://www.openldap.org/project/

Re: Ppolicy - password history

2007-01-19 Thread Buchan Milne

On Friday 19 January 2007 10:32, [EMAIL PROTECTED] wrote:
> Then do You recommend use only clearteaxt password from *client* side ?

If you store encrypted passwords in userPassword, and do simple binds, you 
*have* to send the cleartext password to authenticate. Sending it to change 
passwords is no additional disclosure.

Of course, if you use simple binds, you want to protect the transport 
(TLS/SSL) anyway (e.g. require all connections to be of a sufficient ssf, or 
have the ACLs on userPassword require a sufficient ssf).

> And if *client" perform password encryption, then password history must
> be stored and compared by * client* side soft ?

Yes, since the client could use different encryption types each time (and use 
the same password 3 or more times).

Regards,
Buchan

-- 
Buchan Milne
ISP Systems Specialist - Monitoring/Authentication Team Leader
B.Eng,RHCE(803004789010797),LPIC-2(LPI74592)

pgp2AMwhZoMHC.pgp
Description: PGP signature

RE: Ppolicy - password history

2007-01-19 Thread Andris.Eiduks



Then do You recommend use only clearteaxt password from *client* side ?

And if *client" perform password encryption, then password history must
be stored and compared by * client* side soft ?


Andris 




-Original Message-
From: Howard Chu [mailto:[EMAIL PROTECTED] 
Subject: Re: Ppolicy - password history


[EMAIL PROTECTED] wrote:
> Hi,
> 
> Very strange, because ppolicy by parameter ppolicy_hash_cleartext 
> store also encrypted password value. Then where is the problem store 
> recieved ecrypted passwords and also check from pwdHistory this 
> encrypted value?

The difference is that when the *server* encrypts it, it has a chance to

validate the cleartext first. When the *client* encrypts it, no such 
opportunity exists for the server.

> Otherwise we have a problem with PCI DSS requirements:
>  
> 8.4 Encrypt all passwords during transmission and storage on all 
> system components.

The obvious solution to meet this requirement is to make sure that all 
connections are encrypted (using TLS, SASL, or IPSEC).
> 
> 8.5.12 Do not allow an individual to submit a new password that is the

> same as any of the last four passwords he or she has used
> 
> 
> Andris
> 
> -Original Message-
> From: Pierangelo Masarati [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 18, 2007 5:48 PM
> To: Eiduks Andris
> Cc: [email protected]
> Subject: Re: Ppolicy - password history
> 
> 
> [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> I try password history checking in OpenLDAP 2.3.32 and change user
>> password using LDAP browser.
>>
>> When I enterer repaeted cleartext password then ppolicy returned
>> expected decline "Password is in history of old passwords". But by 
>> password changing to any encrypted value ( the same password two and 
>> more times) OpenLDAP doesn't verify old password.
>>
>> In log-file I found similar info about password changing for both
>> cases:
>>
>> Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory:
>> modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: 
>> internal mod pwdHistory: modify access granted
>> Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete
>> pwdHistory
>> Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add
>> pwdHistory
>> Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type
>> "pwdHistory"
>>
>>
>> Slapd.conf :
>> 
>> 
>>
>> moduleload ppolicy.la
>> overlay ppolicy
>> ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm"
>> ppolicy_hash_cleartext
>> ppolicy_use_lockout
> 
> Encrypted values can't be decrypted to check history.  Ppolicy needs 
> the
> 
> cleartext password to save the history.
> 
> p.
> 
> 
> 


-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sunhttp://highlandsun.com/hyc
   OpenLDAP Core Teamhttp://www.openldap.org/project/

Re: Ppolicy - password history

2007-01-19 Thread Howard Chu


[EMAIL PROTECTED] wrote:


Then do You recommend use only clearteaxt password from *client* side ?


Yes. Specifically, the client should always use the PasswordModify extended 
operation, it should not use LDAPModify on the userPassword attribute. (For 
one thing, there are no guarantees that a particular server even uses the 
userPassword attribute for anything.)


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc
  OpenLDAP Core Teamhttp://www.openldap.org/project/

Re: Ppolicy - password history

2007-01-19 Thread Howard Chu


[EMAIL PROTECTED] wrote:
Hi, 


Very strange, because ppolicy by parameter ppolicy_hash_cleartext store
also encrypted password value.
Then where is the problem store recieved ecrypted passwords and also
check from pwdHistory this encrypted value?


The difference is that when the *server* encrypts it, it has a chance to 
validate the cleartext first. When the *client* encrypts it, no such 
opportunity exists for the server.



Otherwise we have a problem with PCI DSS requirements:
 
8.4 Encrypt all passwords during transmission and storage on all system

components.


The obvious solution to meet this requirement is to make sure that all 
connections are encrypted (using TLS, SASL, or IPSEC).


8.5.12 Do not allow an individual to submit a new password that is the
same as any of the last
four passwords he or she has used


Andris 


-Original Message-
From: Pierangelo Masarati [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 18, 2007 5:48 PM

To: Eiduks Andris
Cc: [email protected]
Subject: Re: Ppolicy - password history


[EMAIL PROTECTED] wrote:

Hi,

I try password history checking in OpenLDAP 2.3.32 and change user 
password using LDAP browser.


When I enterer repaeted cleartext password then ppolicy returned 
expected decline "Password is in history of old passwords". But by 
password changing to any encrypted value ( the same password two and 
more times) OpenLDAP doesn't verify old password.


In log-file I found similar info about password changing for both 
cases:


Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: 
modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: 
internal mod pwdHistory: modify access granted

Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete
pwdHistory
Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add
pwdHistory
Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type
"pwdHistory"


Slapd.conf :



moduleload ppolicy.la
overlay ppolicy
ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm"
ppolicy_hash_cleartext
ppolicy_use_lockout


Encrypted values can't be decrypted to check history.  Ppolicy needs the

cleartext password to save the history.

p.






--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc
  OpenLDAP Core Teamhttp://www.openldap.org/project/

RE: Ppolicy - password history

2007-01-19 Thread Andris.Eiduks

Hi, 

Very strange, because ppolicy by parameter ppolicy_hash_cleartext store
also encrypted password value.
Then where is the problem store recieved ecrypted passwords and also
check from pwdHistory this encrypted value?

Otherwise we have a problem with PCI DSS requirements:
 
8.4 Encrypt all passwords during transmission and storage on all system
components.

8.5.12 Do not allow an individual to submit a new password that is the
same as any of the last
four passwords he or she has used


Andris 

-Original Message-
From: Pierangelo Masarati [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 18, 2007 5:48 PM
To: Eiduks Andris
Cc: [email protected]
Subject: Re: Ppolicy - password history


[EMAIL PROTECTED] wrote:
> Hi,
> 
> I try password history checking in OpenLDAP 2.3.32 and change user 
> password using LDAP browser.
> 
> When I enterer repaeted cleartext password then ppolicy returned 
> expected decline "Password is in history of old passwords". But by 
> password changing to any encrypted value ( the same password two and 
> more times) OpenLDAP doesn't verify old password.
> 
> In log-file I found similar info about password changing for both 
> cases:
> 
> Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: 
> modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: 
> internal mod pwdHistory: modify access granted
> Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete
> pwdHistory
> Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add
> pwdHistory
> Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type
> "pwdHistory"
> 
> 
> Slapd.conf :
> 
> 
> 
> moduleload ppolicy.la
> overlay ppolicy
> ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm"
> ppolicy_hash_cleartext
> ppolicy_use_lockout

Encrypted values can't be decrypted to check history.  Ppolicy needs the

cleartext password to save the history.

p.

Re: Ppolicy - password history

2007-01-18 Thread Pierangelo Masarati


[EMAIL PROTECTED] wrote:
Hi, 


I try password history checking in OpenLDAP 2.3.32 and change user
password using LDAP browser.

When I enterer repaeted cleartext password then ppolicy returned
expected decline "Password is in history of old passwords". But by
password changing to any encrypted value ( the same password two and
more times) OpenLDAP doesn't verify old password. 


In log-file I found similar info about password changing for both cases:

Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory:
modify access granted
Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory:
modify access granted
Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete
pwdHistory
Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add
pwdHistory
Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type
"pwdHistory"


Slapd.conf : 




moduleload ppolicy.la
overlay ppolicy
ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm"
ppolicy_hash_cleartext
ppolicy_use_lockout


Encrypted values can't be decrypted to check history.  Ppolicy needs the 
cleartext password to save the history.


p.

Re: ppolicy and sync replication

2007-01-18 Thread Pierangelo Masarati


Sadique Puthen wrote:

Hi,

Is it possible to replicate password policy related attributes using 
sync replication while using ppolicy overlay?


I am specifically asking about replicating pwdChangedTime, 
pwdAccountLockedTime, pwdHistory and etc... not about password 
configuration related attributes,


In general, ppolicy related state values are not replicated; each 
replica is on its own as far as state-related attributes in enforcing 
password policy.  I recall discussion about if and how this type of info 
should be replicated or somehow shared on the IETF ldapext list, but the 
conclusion sounded like "replication and password policy are two 
separate things with some overlap; if we bundle them, consensus on the 
draft will be harder to achieve, so let's keep them separate (and leave 
them to implementors, I guess)".  I hope my short and incomplete summary 
of the discussion is not too short and incomplete.


p.

Re: ppolicy and sync replication

2007-01-16 Thread Sadique Puthen


I did a bit more testing about this.

I set up password policy as below. Only relevant part given.

pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 90

1 - I did bind to the master server 3 times using wrong password. I 
failed to bind using the right password after that and failed. Expected
2- I did bind to the consumer server using the right password. Failed. 
Expected.


After 90 seconds everything works fine.

3- I did bind to the consumer server using the wrong password three 
times. I failed to bind to the consumer using the right password after 
that. Failed. Expected
4 - I did bind to the master server using the right password. Success. 
Not expected before elapsing 90 seconds.


I know the consumer server is not supposed to update the master server 
database, but is there any work around? Does openldap support multi 
master replication? Is this a limitation. Does this mean a client locked 
on consumer server - as set by the policy - would be able to bind to the 
master server overriding the policy.


One more doubt: where the failure counts are stored?

Regards,
Sadique

Sadique Puthen wrote:

Hi,

Is it possible to replicate password policy related attributes using 
sync replication while using ppolicy overlay?


I am specifically asking about replicating pwdChangedTime, 
pwdAccountLockedTime, pwdHistory and etc... not about password 
configuration related attributes,


Regards,
Sadique

Re: ppolicy - getting to work

2006-11-24 Thread Prakash Velayutham

Thanks again. Makes sense.

Now that I am locked out for SSH access, I will just ask questions of
interest without actually trying things out. For all the different
ppolicy-related things to work, I am guessing the following is the
procedure. Please correct me.

a) Editing slapd.conf and adding "include", "modulepath", "loadmodule
ppolicy.la", "overlay", "ppolicy_use_lockout", "ppolicy_default"
statements.
b) Adding necessary policy-related objects to LDAP (policy object and
standard policy sub-object). These will inherit from pwdPolicy
objectclass.
c) Adding the users that will be managed by the password policy to the
directory. Do I have to add "objectClass=pwdPolicy" attribute to all the
users that need to be managed by ppolicy and leave it out for the other
users?

I will try all these out on monday.

Prakash

>>> Aaron Richton <[EMAIL PROTECTED]> 11/24/06 8:06 PM >>>
Note that I build static modules, so this may need 
verification/clarification, but I'll try:

The .la files are libtool archives. If you examine them (e.g. cat(1)), 
then you'll see that they point to .so files (among other details). A 
libtool-aware application--note that slapd(8) should be one of them--can

parse the .la file, which allegedly offers advantages (mostly platform 
independence). So, following a 'make install', you should be able to 
specify in slapd.conf

> moduleload /path/to/ppolicy.la

and that should parse OK. At least, that's the way I remember it...

Then again, you should be able to moduleload the .so also. If the .la 
doesn't work out, try that.

On Fri, 24 Nov 2006, Prakash Velayutham wrote:

> Thanks Aaron. So I built openldap with:
>
> $ ./configure --with-tls=no --with-cyrus-sasl=no --enable-slurpd=no
> --enable-ipv6=no --enable-ppolicy=mod --enable-hdb=yes
--enable-modules
> --enable-bdb=no --enable-ldif=no --enable-monitor=no --enable-relay=no
> --enable-syncprov=no
>
> Why do I have a ppolicy*.so and a ppolicy*.la file in the install
> location? When do you use the ppolicy*.so?
>
> I have temporarily lost access to the system because of PAM. Will have
> access again on monday.
>
> Thanks,
> Prakash
>
 Prakash Velayutham 11/24/06 5:13 PM >>>
 Aaron Richton <[EMAIL PROTECTED]> 11/24/06 4:04 PM >>>
> configure --enable-hdb --enable-ppolicy={yes|mod} should handle it.
> "yes" will build it into slapd, "mod" will give you a module. (You can
> do
> the same for --enable-hdb.)
>
> On Fri, 24 Nov 2006, Prakash Velayutham wrote:
>
>> Hello All,
>>
>> I am trying to get ppolicy working on my openldap-2.3.29 server. I
> want
>> this setup to work with hdb backend and either static or dynamic
> ppolicy
>> module. What compile time options would be sufficient?
>>
>> Thanks,
>> Prakash
>

Re: ppolicy - getting to work

2006-11-24 Thread Aaron Richton

Note that I build static modules, so this may need 
verification/clarification, but I'll try:


The .la files are libtool archives. If you examine them (e.g. cat(1)), 
then you'll see that they point to .so files (among other details). A 
libtool-aware application--note that slapd(8) should be one of them--can 
parse the .la file, which allegedly offers advantages (mostly platform 
independence). So, following a 'make install', you should be able to 
specify in slapd.conf



moduleload /path/to/ppolicy.la


and that should parse OK. At least, that's the way I remember it...


Then again, you should be able to moduleload the .so also. If the .la 
doesn't work out, try that.


On Fri, 24 Nov 2006, Prakash Velayutham wrote:


Thanks Aaron. So I built openldap with:

$ ./configure --with-tls=no --with-cyrus-sasl=no --enable-slurpd=no
--enable-ipv6=no --enable-ppolicy=mod --enable-hdb=yes --enable-modules
--enable-bdb=no --enable-ldif=no --enable-monitor=no --enable-relay=no
--enable-syncprov=no

Why do I have a ppolicy*.so and a ppolicy*.la file in the install
location? When do you use the ppolicy*.so?

I have temporarily lost access to the system because of PAM. Will have
access again on monday.

Thanks,
Prakash


Prakash Velayutham 11/24/06 5:13 PM >>>
Aaron Richton <[EMAIL PROTECTED]> 11/24/06 4:04 PM >>>

configure --enable-hdb --enable-ppolicy={yes|mod} should handle it.
"yes" will build it into slapd, "mod" will give you a module. (You can
do
the same for --enable-hdb.)

On Fri, 24 Nov 2006, Prakash Velayutham wrote:


Hello All,

I am trying to get ppolicy working on my openldap-2.3.29 server. I

want

this setup to work with hdb backend and either static or dynamic

ppolicy

module. What compile time options would be sufficient?

Thanks,
Prakash

Re: ppolicy - getting to work

2006-11-24 Thread Prakash Velayutham

Thanks Aaron. So I built openldap with:

$ ./configure --with-tls=no --with-cyrus-sasl=no --enable-slurpd=no
--enable-ipv6=no --enable-ppolicy=mod --enable-hdb=yes --enable-modules
--enable-bdb=no --enable-ldif=no --enable-monitor=no --enable-relay=no
--enable-syncprov=no

Why do I have a ppolicy*.so and a ppolicy*.la file in the install
location? When do you use the ppolicy*.so?

I have temporarily lost access to the system because of PAM. Will have
access again on monday.

Thanks,
Prakash

>>> Prakash Velayutham 11/24/06 5:13 PM >>>
>>> Aaron Richton <[EMAIL PROTECTED]> 11/24/06 4:04 PM >>>
configure --enable-hdb --enable-ppolicy={yes|mod} should handle it. 
"yes" will build it into slapd, "mod" will give you a module. (You can
do 
the same for --enable-hdb.)

On Fri, 24 Nov 2006, Prakash Velayutham wrote:

> Hello All,
>
> I am trying to get ppolicy working on my openldap-2.3.29 server. I
want
> this setup to work with hdb backend and either static or dynamic
ppolicy
> module. What compile time options would be sufficient?
>
> Thanks,
> Prakash

Re: ppolicy - getting to work

2006-11-24 Thread Aaron Richton

configure --enable-hdb --enable-ppolicy={yes|mod} should handle it. 
"yes" will build it into slapd, "mod" will give you a module. (You can do 
the same for --enable-hdb.)


On Fri, 24 Nov 2006, Prakash Velayutham wrote:


Hello All,

I am trying to get ppolicy working on my openldap-2.3.29 server. I want
this setup to work with hdb backend and either static or dynamic ppolicy
module. What compile time options would be sufficient?

Thanks,
Prakash

Re: ppolicy implementation questions

2006-11-02 Thread Howard Chu


Lee Sheridan wrote:

I'm a little confused about a couple of things with ppolicy, I would
appreciate somone helping me to sort it out.

Here's my problem.  I have a pwdMinAge set to some number X.  The reason
is that the password policy I'm implementing says that passwords must
not be reused until some N days and Y number of changes have elapsed.

Thus, pwdMinAge is approximately N / Y, which means that even if a user
changes their password every X days, they won't go through all Y
passwords until all N days have passed.  Clearly not the best option.


If you policy is N days AND Y number of changes, then it seems to me 
that you just need to set pwdMinAge to N and pwdInHistory to Y. Your use 
of pwdMinAge = N / Y would equate to N OR Y.



So my first question is this:  I see that the pwdHistory attribute
stores time the password was used within it.  Is there some way for
ppolicy to check if a password that is being reused has been reused in <
X days?


Not at present.


Failing in that (which would allow me to get rid of using pwdMinAge)...
When I set a user password with the rootdn or similar, the user can not
reset their password because it is too young.  I can see no way to
modify pwdChangedTime.  How exactly is this handled?


You would need to use something like the Relax Rules (formerly 
ManageDIT) control.

http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-relax-00.txt
As an administrator you would set this control and delete the 
pwdChangedTime attribute.



Third, apparently only the rootdn can set a password when the password
is < pwdMinAge.  Users with an ACL that allows write access to
userPassword also go through the ppolicy policies (which makes sense).
Is there a way to exclude them also from ppolicy constraints when
setting another user's password?


Not at present.

You're welcome to submit patches to the ITS implementing the features 
you're interested in.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc
  OpenLDAP Core Teamhttp://www.openldap.org/project/

1 2 >

1 - 100 of 122 matches

Mail list logo