FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 09-27-2010, 07:02 PM
James Smallacombe
 
Default shadowLast Change NOT updating was ldappasswd and shadowLastChange attribute

Sorry for replying to myself, but I wanted to add more that I've tried
since my last post:

from the DirSrv X Console: in Configuration -> Indexes I added the
"shadowLastChange" attribute to userRoot, then NetscapeRoot, still with no
luck. I then put the following in my /etc/ldap.conf

nss_map_objectclass shadowAccount User
pam_password exop

Still no luck. To clarify, the shadowLastChange DOES get propery updated
when you reset a user's password in Webmin's "Users and Groups" module,
but NOT when you use /usr/lib64/mozldap/ldappasswd OR in the Squirrelmail
"Change LDAP Password" plugin. Again, any of these will change the
password no problem, but not that attribute....any pointers would be
appreciated. Here is a sample user:

version: 1
dn: uid=test123,ou=People, dc=some, dc=domain
objectClass: posixAccount
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: shadowAccount
uid: test123
cn:test123
uidNumber: 999
gidNumber: 999
homeDirectory: /home/test123
loginShell: /bin/false
sn: test123
mail: test123@some.domain
shadowLastChange: 13678
shadowMin: 1
shadowMax: 99999
shadowWarning: 14

On Mon, 27 Sep 2010, James Smallacombe wrote:

>
> I finally figured out a working shell script to make LDAP user password
> changes using mozldap/ldappasswd. Unfortunately, I just discovered that
> changing the password using this does not update the "shadowLastChange"
> attribute, so users with expired passwords are still not able to log in,
> even after an admin has reset their password in this manner.
>
> Since we are migrating from traditional shadow passwords to LDAP, the
> attribute we need to get updated by this is "shadowLastChange"
>
> I attempted to work around this in /etc/ldap.conf by adding this:
>
> nss_map_attribute shadowLastChange pwdLastSet
>
> But to no avail. In addition, the "change ldap password" plugin also does
> not update this, although webmin users and groups module does.
>
> What am I missing? Thanks in Advance!
>
> James Smallacombe PlantageNet, Inc. CEO and Janitor
> up@3.am http://3.am
> ================================================== =======================
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am
================================================== =======================
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-27-2010, 10:52 PM
James Smallacombe
 
Default shadowLast Change NOT updating was ldappasswd and shadowLastChange attribute

Thanks for your reply, Jason. I am a bit of a noob here, but I went to
the DirServ console and:

(Example) -> People did a right-click on it, then -> Set Access
Permissions and saw the 6 default ACIs. I edited "Allow self entry
modifications" and checked "shadowLastChange". Since this was only for
"Self" and these mods are done either by root in the shell, or the apache
user in the web plugin, I didn't really expect it to help. So, I create a
custom ACI:

Selected ALL users, then unchecked all targets, then re-checked
"shadowLastChange" and a few others.

Still no luck. Although I'm not up on ACIs, in all cases I am binding to
the server as the Directory Manager, so doesn't that mean the ACI
shouldn't matter?

Thanks again,

On Mon, 27 Sep 2010, Jason Brown wrote:

> I am not sure if there is a huge difference between RHDS and 389, but
> I also had this same issue. I believe it had to do with the ACI's
> preventing the update to that attribute. Once you allow write access
> to shadowLastChange it was able to update it.
>
>
> On Sep 27, 2010, at 3:02 PM, James Smallacombe wrote:
>
>>
>> Sorry for replying to myself, but I wanted to add more that I've tried
>> since my last post:
>>
>> from the DirSrv X Console: in Configuration -> Indexes I added the
>> "shadowLastChange" attribute to userRoot, then NetscapeRoot, still
>> with no
>> luck. I then put the following in my /etc/ldap.conf
>>
>> nss_map_objectclass shadowAccount User
>> pam_password exop
>>
>> Still no luck. To clarify, the shadowLastChange DOES get propery
>> updated
>> when you reset a user's password in Webmin's "Users and Groups"
>> module,
>> but NOT when you use /usr/lib64/mozldap/ldappasswd OR in the
>> Squirrelmail
>> "Change LDAP Password" plugin. Again, any of these will change the
>> password no problem, but not that attribute....any pointers would be
>> appreciated. Here is a sample user:
>>
>> version: 1
>> dn: uid=test123,ou=People, dc=some, dc=domain
>> objectClass: posixAccount
>> objectClass: top
>> objectClass: person
>> objectClass: organizationalPerson
>> objectClass: inetOrgPerson
>> objectClass: shadowAccount
>> uid: test123
>> cn:test123
>> uidNumber: 999
>> gidNumber: 999
>> homeDirectory: /home/test123
>> loginShell: /bin/false
>> sn: test123
>> mail: test123@some.domain
>> shadowLastChange: 13678
>> shadowMin: 1
>> shadowMax: 99999
>> shadowWarning: 14
>>
>> On Mon, 27 Sep 2010, James Smallacombe wrote:
>>
>>>
>>> I finally figured out a working shell script to make LDAP user
>>> password
>>> changes using mozldap/ldappasswd. Unfortunately, I just discovered
>>> that
>>> changing the password using this does not update the
>>> "shadowLastChange"
>>> attribute, so users with expired passwords are still not able to
>>> log in,
>>> even after an admin has reset their password in this manner.
>>>
>>> Since we are migrating from traditional shadow passwords to LDAP, the
>>> attribute we need to get updated by this is "shadowLastChange"
>>>
>>> I attempted to work around this in /etc/ldap.conf by adding this:
>>>
>>> nss_map_attribute shadowLastChange pwdLastSet
>>>
>>> But to no avail. In addition, the "change ldap password" plugin
>>> also does
>>> not update this, although webmin users and groups module does.
>>>
>>> What am I missing? Thanks in Advance!
>>>
>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>> up@3.am http://3.am
>>> =
>>> =
>>> =
>>> =
>>> ================================================== ===================
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>> up@3.am http://3.am
>> =
>> =
>> =
>> ================================================== ====================
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am
================================================== =======================
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-28-2010, 03:43 PM
James Smallacombe
 
Default shadowLast Change NOT updating was ldappasswd and shadowLastChange attribute

Looks like there's already a "Directory Administrators" ACI under
(Company) that has all the attributes checked. I assume we do NOT have to
do this under the "netscape root" tree, right?

What's more, Webmin does correctly update the shadowLastChange attribute
when you change a user's password there. It just doesn't work when using
"ldappasswd" or a squirrelmail plugin for users to change their password,
all of which bind as Directory Manager.

Is there something more that needs be done in /etc/ldap.conf or pam.d/ ?
We use ldap via authconfig (pam.d/systme-auth).

On Tue, 28 Sep 2010, Jason Brown wrote:

> The ACI where it is set is in the top of the tree, not in People.
> This will also prevent Domain Managers the ability to write to this as
> well.
>
>
> On Sep 27, 2010, at 6:52 PM, James Smallacombe wrote:
>
>>
>> Thanks for your reply, Jason. I am a bit of a noob here, but I went
>> to
>> the DirServ console and:
>>
>> (Example) -> People did a right-click on it, then -> Set Access
>> Permissions and saw the 6 default ACIs. I edited "Allow self entry
>> modifications" and checked "shadowLastChange". Since this was only
>> for
>> "Self" and these mods are done either by root in the shell, or the
>> apache
>> user in the web plugin, I didn't really expect it to help. So, I
>> create a
>> custom ACI:
>>
>> Selected ALL users, then unchecked all targets, then re-checked
>> "shadowLastChange" and a few others.
>>
>> Still no luck. Although I'm not up on ACIs, in all cases I am
>> binding to
>> the server as the Directory Manager, so doesn't that mean the ACI
>> shouldn't matter?
>>
>> Thanks again,
>>
>> On Mon, 27 Sep 2010, Jason Brown wrote:
>>
>>> I am not sure if there is a huge difference between RHDS and 389, but
>>> I also had this same issue. I believe it had to do with the ACI's
>>> preventing the update to that attribute. Once you allow write access
>>> to shadowLastChange it was able to update it.
>>>
>>>
>>> On Sep 27, 2010, at 3:02 PM, James Smallacombe wrote:
>>>
>>>>
>>>> Sorry for replying to myself, but I wanted to add more that I've
>>>> tried
>>>> since my last post:
>>>>
>>>> from the DirSrv X Console: in Configuration -> Indexes I added the
>>>> "shadowLastChange" attribute to userRoot, then NetscapeRoot, still
>>>> with no
>>>> luck. I then put the following in my /etc/ldap.conf
>>>>
>>>> nss_map_objectclass shadowAccount User
>>>> pam_password exop
>>>>
>>>> Still no luck. To clarify, the shadowLastChange DOES get propery
>>>> updated
>>>> when you reset a user's password in Webmin's "Users and Groups"
>>>> module,
>>>> but NOT when you use /usr/lib64/mozldap/ldappasswd OR in the
>>>> Squirrelmail
>>>> "Change LDAP Password" plugin. Again, any of these will change the
>>>> password no problem, but not that attribute....any pointers would be
>>>> appreciated. Here is a sample user:
>>>>
>>>> version: 1
>>>> dn: uid=test123,ou=People, dc=some, dc=domain
>>>> objectClass: posixAccount
>>>> objectClass: top
>>>> objectClass: person
>>>> objectClass: organizationalPerson
>>>> objectClass: inetOrgPerson
>>>> objectClass: shadowAccount
>>>> uid: test123
>>>> cn:test123
>>>> uidNumber: 999
>>>> gidNumber: 999
>>>> homeDirectory: /home/test123
>>>> loginShell: /bin/false
>>>> sn: test123
>>>> mail: test123@some.domain
>>>> shadowLastChange: 13678
>>>> shadowMin: 1
>>>> shadowMax: 99999
>>>> shadowWarning: 14
>>>>
>>>> On Mon, 27 Sep 2010, James Smallacombe wrote:
>>>>
>>>>>
>>>>> I finally figured out a working shell script to make LDAP user
>>>>> password
>>>>> changes using mozldap/ldappasswd. Unfortunately, I just discovered
>>>>> that
>>>>> changing the password using this does not update the
>>>>> "shadowLastChange"
>>>>> attribute, so users with expired passwords are still not able to
>>>>> log in,
>>>>> even after an admin has reset their password in this manner.
>>>>>
>>>>> Since we are migrating from traditional shadow passwords to LDAP,
>>>>> the
>>>>> attribute we need to get updated by this is "shadowLastChange"
>>>>>
>>>>> I attempted to work around this in /etc/ldap.conf by adding this:
>>>>>
>>>>> nss_map_attribute shadowLastChange pwdLastSet
>>>>>
>>>>> But to no avail. In addition, the "change ldap password" plugin
>>>>> also does
>>>>> not update this, although webmin users and groups module does.
>>>>>
>>>>> What am I missing? Thanks in Advance!
>>>>>
>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>>> up@3.am http://3.am
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> ================================================== =================
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users@lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>
>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>> up@3.am http://3.am
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> ================================================== ==================
>>>> --
>>>> 389 users mailing list
>>>> 389-users@lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>> up@3.am http://3.am
>> =
>> =
>> =
>> ================================================== ====================
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am
================================================== =======================
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-29-2010, 06:54 PM
James Smallacombe
 
Default shadowLast Change NOT updating was ldappasswd and shadowLastChange attribute

Forgive my noobness to ldap, but I am not binding to the server as any
uid, but as cn=Directory Administrator. I tried an ACI using that, but
still nothing.

I am not sure we're even on the right track, if I understand what this is
supposed to do correctly.

If I use ldapmodify and bind to the server as the DN above, I can change
the shadowLastChanged attribute value just fine. If I use ldappasswd and
bind to the server as the same DN to change a user's password, it changes
the password ok, but the shadowLastChanged attribute value never gets
updated (the password is still expired).

If all I had to do was fix this via shell, I could make a script to do
both (I already did, in fact), but there are other php apps such as that
squirrelmail plugin that need the attribute updated when the password has
been changed.

I'd really appreciate any pointers on this. Thanks!

On Wed, 29 Sep 2010, Jason Brown wrote:

> (targetattr="userPassword||shadowLastChange||shado wMin||shadowMax||shadowWarning||shadowInactive||sh adowExpire||shadowFlag")(version
> 3.0; acl "Allow client-root write on userPassword"; allow(write)
> userdn="ldap:///uid=client-root,ou=profile,dc=domain,dc=com"
>
> This would be set under the Directory tab where your actual domain is listed,
> should be under the netscaperoot.
>
>
>
> On Sep 28, 2010, at 11:43 AM, James Smallacombe wrote:
>
>>
>> Looks like there's already a "Directory Administrators" ACI under (Company)
>> that has all the attributes checked. I assume we do NOT have to do this
>> under the "netscape root" tree, right?
>>
>> What's more, Webmin does correctly update the shadowLastChange attribute
>> when you change a user's password there. It just doesn't work when using
>> "ldappasswd" or a squirrelmail plugin for users to change their password,
>> all of which bind as Directory Manager.
>>
>> Is there something more that needs be done in /etc/ldap.conf or pam.d/ ? We
>> use ldap via authconfig (pam.d/systme-auth).
>>
>> On Tue, 28 Sep 2010, Jason Brown wrote:
>>
>>> The ACI where it is set is in the top of the tree, not in People.
>>> This will also prevent Domain Managers the ability to write to this as
>>> well.
>>>
>>>
>>> On Sep 27, 2010, at 6:52 PM, James Smallacombe wrote:
>>>
>>>>
>>>> Thanks for your reply, Jason. I am a bit of a noob here, but I went
>>>> to
>>>> the DirServ console and:
>>>>
>>>> (Example) -> People did a right-click on it, then -> Set Access
>>>> Permissions and saw the 6 default ACIs. I edited "Allow self entry
>>>> modifications" and checked "shadowLastChange". Since this was only
>>>> for
>>>> "Self" and these mods are done either by root in the shell, or the
>>>> apache
>>>> user in the web plugin, I didn't really expect it to help. So, I
>>>> create a
>>>> custom ACI:
>>>>
>>>> Selected ALL users, then unchecked all targets, then re-checked
>>>> "shadowLastChange" and a few others.
>>>>
>>>> Still no luck. Although I'm not up on ACIs, in all cases I am
>>>> binding to
>>>> the server as the Directory Manager, so doesn't that mean the ACI
>>>> shouldn't matter?
>>>>
>>>> Thanks again,
>>>>
>>>> On Mon, 27 Sep 2010, Jason Brown wrote:
>>>>
>>>>> I am not sure if there is a huge difference between RHDS and 389, but
>>>>> I also had this same issue. I believe it had to do with the ACI's
>>>>> preventing the update to that attribute. Once you allow write access
>>>>> to shadowLastChange it was able to update it.
>>>>>
>>>>>
>>>>> On Sep 27, 2010, at 3:02 PM, James Smallacombe wrote:
>>>>>
>>>>>>
>>>>>> Sorry for replying to myself, but I wanted to add more that I've
>>>>>> tried
>>>>>> since my last post:
>>>>>>
>>>>>> from the DirSrv X Console: in Configuration -> Indexes I added the
>>>>>> "shadowLastChange" attribute to userRoot, then NetscapeRoot, still
>>>>>> with no
>>>>>> luck. I then put the following in my /etc/ldap.conf
>>>>>>
>>>>>> nss_map_objectclass shadowAccount User
>>>>>> pam_password exop
>>>>>>
>>>>>> Still no luck. To clarify, the shadowLastChange DOES get propery
>>>>>> updated
>>>>>> when you reset a user's password in Webmin's "Users and Groups"
>>>>>> module,
>>>>>> but NOT when you use /usr/lib64/mozldap/ldappasswd OR in the
>>>>>> Squirrelmail
>>>>>> "Change LDAP Password" plugin. Again, any of these will change the
>>>>>> password no problem, but not that attribute....any pointers would be
>>>>>> appreciated. Here is a sample user:
>>>>>>
>>>>>> version: 1
>>>>>> dn: uid=test123,ou=People, dc=some, dc=domain
>>>>>> objectClass: posixAccount
>>>>>> objectClass: top
>>>>>> objectClass: person
>>>>>> objectClass: organizationalPerson
>>>>>> objectClass: inetOrgPerson
>>>>>> objectClass: shadowAccount
>>>>>> uid: test123
>>>>>> cn:test123
>>>>>> uidNumber: 999
>>>>>> gidNumber: 999
>>>>>> homeDirectory: /home/test123
>>>>>> loginShell: /bin/false
>>>>>> sn: test123
>>>>>> mail: test123@some.domain
>>>>>> shadowLastChange: 13678
>>>>>> shadowMin: 1
>>>>>> shadowMax: 99999
>>>>>> shadowWarning: 14
>>>>>>
>>>>>> On Mon, 27 Sep 2010, James Smallacombe wrote:
>>>>>>
>>>>>>>
>>>>>>> I finally figured out a working shell script to make LDAP user
>>>>>>> password
>>>>>>> changes using mozldap/ldappasswd. Unfortunately, I just discovered
>>>>>>> that
>>>>>>> changing the password using this does not update the
>>>>>>> "shadowLastChange"
>>>>>>> attribute, so users with expired passwords are still not able to
>>>>>>> log in,
>>>>>>> even after an admin has reset their password in this manner.
>>>>>>>
>>>>>>> Since we are migrating from traditional shadow passwords to LDAP,
>>>>>>> the
>>>>>>> attribute we need to get updated by this is "shadowLastChange"
>>>>>>>
>>>>>>> I attempted to work around this in /etc/ldap.conf by adding this:
>>>>>>>
>>>>>>> nss_map_attribute shadowLastChange pwdLastSet
>>>>>>>
>>>>>>> But to no avail. In addition, the "change ldap password" plugin
>>>>>>> also does
>>>>>>> not update this, although webmin users and groups module does.
>>>>>>>
>>>>>>> What am I missing? Thanks in Advance!
>>>>>>>
>>>>>>> James Smallacombe PlantageNet, Inc. CEO and
>>>>>>> Janitor
>>>>>>> up@3.am
>>>>>>> http://3.am
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ================================================== =================
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users@lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>
>>>>>>
>>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>>>> up@3.am
>>>>>> http://3.am
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> ================================================== ==================
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users@lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users@lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>
>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>> up@3.am
>>>> http://3.am
>>>> =
>>>> =
>>>> =
>>>> ================================================== ====================
>>>> --
>>>> 389 users mailing list
>>>> 389-users@lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>> up@3.am
>> http://3.am
>> ================================================== =======================
>

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am
================================================== =======================
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-29-2010, 07:29 PM
"Morris, Patrick"
 
Default shadowLast Change NOT updating was ldappasswd and shadowLastChange attribute

So... The attribute is there, it's writeable, and it's not being updated when a user changes their password? That really doen't leave much other than PAM configuration.

Have you looked at the server access logs to see if an attempt is being made to change it, and if so, what the result is of that attempt?

It seems likely to me that the reason it's not updating is either PAM's not authenticating as who you think it is, or it's just not trying.

(forgive the top post. Bottom posting is hard when your phone doesn't always download the whole thing)

-----Original Message-----
From: James Smallacombe <up@3.am>
Sent: Wednesday, September 29, 2010 11:55 AM
To: 389-users@lists.fedoraproject.org <389-users@lists.fedoraproject.org>
Subject: Re: [389-users] shadowLast Change NOT updating was Re: ldappasswd and shadowLastChange attribute


Forgive my noobness to ldap, but I am not binding to the server as any
uid, but as cn=Directory Administrator. I tried an ACI using that, but
still nothing.

I am not sure we're even on the right track, if I understand what this is
supposed to do correctly.

If I use ldapmodify and bind to the server as the DN above, I can change
the shadowLastChanged attribute value just fine. If I use ldappasswd and
bind to the server as the same DN to change a user's password, it changes
the password ok, but the shadowLastChanged attribute value never gets
updated (the password is still expired).

If all I had to do was fix this via shell, I could make a script to do
both (I already did, in fact), but there are other php apps such as that
squirrelmail plugin that need the attribute updated when the password has
been changed.

I'd really appreciate any pointers on this. Thanks!

On Wed, 29 Sep 2010, Jason Brown wrote:

> (targetattr="userPassword||shadowLastChange||shado wMin||shadowMax||shadowWarning||shadowInactive||sh adowExpire||shadowFlag")(version
> 3.0; acl "Allow client-root write on userPassword"; allow(write)
> userdn="ldap:///uid=client-root,ou=profile,dc=domain,dc=com"
>
> This would be set under the Directory tab where your actual domain is listed,
> should be under the netscaperoot.
>
>
>
> On Sep 28, 2010, at 11:43 AM, James Smallacombe wrote:
>
>>
>> Looks like there's already a "Directory Administrators" ACI under (Company)
>> that has all the attributes checked. I assume we do NOT have to do this
>> under the "netscape root" tree, right?
>>
>> What's more, Webmin does correctly update the shadowLastChange attribute
>> when you change a user's password there. It just doesn't work when using
>> "ldappasswd" or a squirrelmail plugin for users to change their password,
>> all of which bind as Directory Manager.
>>
>> Is there something more that needs be done in /etc/ldap.conf or pam.d/ ? We
>> use ldap via authconfig (pam.d/systme-auth).
>>
>> On Tue, 28 Sep 2010, Jason Brown wrote:
>>
>>> The ACI where it is set is in the top of the tree, not in People.
>>> This will also prevent Domain Managers the ability to write to this as
>>> well.
>>>
>>>
>>> On Sep 27, 2010, at 6:52 PM, James Smallacombe wrote:
>>>
>>>>
>>>> Thanks for your reply, Jason. I am a bit of a noob here, but I went
>>>> to
>>>> the DirServ console and:
>>>>
>>>> (Example) -> People did a right-click on it, then -> Set Access
>>>> Permissions and saw the 6 default ACIs. I edited "Allow self entry
>>>> modifications" and checked "shadowLastChange". Since this was only
>>>> for
>>>> "Self" and these mods are done either by root in the shell, or the
>>>> apache
>>>> user in the web plugin, I didn't really expect it to help. So, I
>>>> create a
>>>> custom ACI:
>>>>
>>>> Selected ALL users, then unchecked all targets, then re-checked
>>>> "shadowLastChange" and a few others.
>>>>
>>>> Still no luck. Although I'm not up on ACIs, in all cases I am
>>>> binding to
>>>> the server as the Directory Manager, so doesn't that mean the ACI
>>>> shouldn't matter?
>>>>
>>>> Thanks again,
>>>>
>>>> On Mon, 27 Sep 2010, Jason Brown wrote:
>>>>
>>>>> I am not sure if there is a huge difference between RHDS and 389, but
>>>>> I also had this same issue. I believe it had to do with the ACI's
>>>>> preventing the update to that attribute. Once you allow write access
>>>>> to shadowLastChange it was able to update it.
>>>>>
>>>>>
>>>>> On Sep 27, 2010, at 3:02 PM, James Smallacombe wrote:
>>>>>
>>>>>>
>>>>>> Sorry for replying to myself, but I wanted to add more that I've
>>>>>> tried
>>>>>> since my last post:
>>>>>>
>>>>>> from the DirSrv X Console: in Configuration -> Indexes I added the
>>>>>> "shadowLastChange" attribute to userRoot, then NetscapeRoot, still
>>>>>> with no
>>>>>> luck. I then put the following in my /etc/ldap.conf
>>>>>>
>>>>>> nss_map_objectclass shadowAccount User
>>>>>> pam_password exop
>>>>>>
>>>>>> Still no luck. To clarify, the shadowLastChange DOES get propery
>>>>>> updated
>>>>>> when you reset a user's password in Webmin's "Users and Groups"
>>>>>> module,
>>>>>> but NOT when you use /usr/lib64/mozldap/ldappasswd OR in the
>>>>>> Squirrelmail
>>>>>> "Change LDAP Password" plugin. Again, any of these will change the
>>>>>> password no problem, but not that attribute....any pointers would be
>>>>>> appreciated. Here is a sample user:
>>>>>>
>>>>>> version: 1
>>>>>> dn: uid=test123,ou=People, dc=some, dc=domain
>>>>>> objectClass: posixAccount
>>>>>> objectClass: top
>>>>>> objectClass: person
>>>>>> objectClass: organizationalPerson
>>>>>> objectClass: inetOrgPerson
>>>>>> objectClass: shadowAccount
>>>>>> uid: test123
>>>>>> cn:test123
>>>>>> uidNumber: 999
>>>>>> gidNumber: 999
>>>>>> homeDirectory: /home/test123
>>>>>> loginShell: /bin/false
>>>>>> sn: test123
>>>>>> mail: test123@some.domain
>>>>>> shadowLastChange: 13678
>>>>>> shadowMin: 1
>>>>>> shadowMax: 99999
>>>>>> shadowWarning: 14
>>>>>>
>>>>>> On Mon, 27 Sep 2010, James Smallacombe wrote:
>>>>>>
>>>>>>>
>>>>>>> I finally figured out a working shell script to make LDAP user
>>>>>>> password
>>>>>>> changes using mozldap/ldappasswd. Unfortunately, I just discovered
>>>>>>> that
>>>>>>> changing the password using this does not update the
>>>>>>> "shadowLastChange"
>>>>>>> attribute, so users with expired passwords are still not able to
>>>>>>> log in,
>>>>>>> even after an admin has reset their password in this manner.
>>>>>>>
>>>>>>> Since we are migrating from traditional shadow passwords to LDAP,
>>>>>>> the
>>>>>>> attribute we need to get updated by this is "shadowLastChange"
>>>>>>>
>>>>>>> I attempted to work around this in /etc/ldap.conf by adding this:
>>>>>>>
>>>>>>> nss_map_attribute shadowLastChange pwdLastSet
>>>>>>>
>>>>>>> But to no avail. In addition, the "change ldap password" plugin
>>>>>>> also does
>>>>>>> not update this, although webmin users and groups module does.
>>>>>>>
>>>>>>> What am I missing? Thanks in Advance!
>>>>>>>
>>>>>>> James Smallacombe PlantageNet, Inc. CEO and
>>>>>>> Janitor
>>>>>>> up@3.am
>>>>>>> http://3.am
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ================================================== =================
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users@lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>
>>>>>>
>>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>>>> up@3.am
>>>>>> http://3.am
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> ================================================== ==================
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users@lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users@lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>
>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>> up@3.am
>>>> http://3.am
>>>> =
>>>> =
>>>> =
>>>> ================================================== ====================
>>>> --
>>>> 389 users mailing list
>>>> 389-users@lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>> up@3.am
>> http://3.am
>> ================================================== =======================
>

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am
================================================== =======================
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-29-2010, 07:46 PM
James Smallacombe
 
Default shadowLast Change NOT updating was ldappasswd and shadowLastChange attribute

The only mention of the attribute I see in dirsrv/access are a lot of
"SRCH" on it under the shadowAccount objectClass with all the other
"shadow" attributes. I've been suspecting/wondering about PAM as well,
but am uncertain where to look. Here is /etc/pam.d/system-auth (CentOS
5.3). Note that we want both unix and ldap auth present.

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session required pam_unix.so
session optional pam_ldap.so

On Wed, 29 Sep 2010, Morris, Patrick wrote:

> So... The attribute is there, it's writeable, and it's not being updated
> when a user changes their password? That really doen't leave much other
> than PAM configuration.
>
> Have you looked at the server access logs to see if an attempt is being
> made to change it, and if so, what the result is of that attempt?
>
> It seems likely to me that the reason it's not updating is either PAM's
> not authenticating as who you think it is, or it's just not trying.
>
> (forgive the top post. Bottom posting is hard when your phone doesn't
> always download the whole thing)
>
> -----Original Message-----
> From: James Smallacombe <up@3.am>
> Sent: Wednesday, September 29, 2010 11:55 AM
> To: 389-users@lists.fedoraproject.org <389-users@lists.fedoraproject.org>
> Subject: Re: [389-users] shadowLast Change NOT updating was Re: ldappasswd and shadowLastChange attribute
>
>
> Forgive my noobness to ldap, but I am not binding to the server as any
> uid, but as cn=Directory Administrator. I tried an ACI using that, but
> still nothing.
>
> I am not sure we're even on the right track, if I understand what this is
> supposed to do correctly.
>
> If I use ldapmodify and bind to the server as the DN above, I can change
> the shadowLastChanged attribute value just fine. If I use ldappasswd and
> bind to the server as the same DN to change a user's password, it changes
> the password ok, but the shadowLastChanged attribute value never gets
> updated (the password is still expired).
>
> If all I had to do was fix this via shell, I could make a script to do
> both (I already did, in fact), but there are other php apps such as that
> squirrelmail plugin that need the attribute updated when the password has
> been changed.
>
> I'd really appreciate any pointers on this. Thanks!
>
> On Wed, 29 Sep 2010, Jason Brown wrote:
>
>> (targetattr="userPassword||shadowLastChange||shado wMin||shadowMax||shadowWarning||shadowInactive||sh adowExpire||shadowFlag")(version
>> 3.0; acl "Allow client-root write on userPassword"; allow(write)
>> userdn="ldap:///uid=client-root,ou=profile,dc=domain,dc=com"
>>
>> This would be set under the Directory tab where your actual domain is listed,
>> should be under the netscaperoot.
>>
>>
>>
>> On Sep 28, 2010, at 11:43 AM, James Smallacombe wrote:
>>
>>>
>>> Looks like there's already a "Directory Administrators" ACI under (Company)
>>> that has all the attributes checked. I assume we do NOT have to do this
>>> under the "netscape root" tree, right?
>>>
>>> What's more, Webmin does correctly update the shadowLastChange attribute
>>> when you change a user's password there. It just doesn't work when using
>>> "ldappasswd" or a squirrelmail plugin for users to change their password,
>>> all of which bind as Directory Manager.
>>>
>>> Is there something more that needs be done in /etc/ldap.conf or pam.d/ ? We
>>> use ldap via authconfig (pam.d/systme-auth).
>>>
>>> On Tue, 28 Sep 2010, Jason Brown wrote:
>>>
>>>> The ACI where it is set is in the top of the tree, not in People.
>>>> This will also prevent Domain Managers the ability to write to this as
>>>> well.
>>>>
>>>>
>>>> On Sep 27, 2010, at 6:52 PM, James Smallacombe wrote:
>>>>
>>>>>
>>>>> Thanks for your reply, Jason. I am a bit of a noob here, but I went
>>>>> to
>>>>> the DirServ console and:
>>>>>
>>>>> (Example) -> People did a right-click on it, then -> Set Access
>>>>> Permissions and saw the 6 default ACIs. I edited "Allow self entry
>>>>> modifications" and checked "shadowLastChange". Since this was only
>>>>> for
>>>>> "Self" and these mods are done either by root in the shell, or the
>>>>> apache
>>>>> user in the web plugin, I didn't really expect it to help. So, I
>>>>> create a
>>>>> custom ACI:
>>>>>
>>>>> Selected ALL users, then unchecked all targets, then re-checked
>>>>> "shadowLastChange" and a few others.
>>>>>
>>>>> Still no luck. Although I'm not up on ACIs, in all cases I am
>>>>> binding to
>>>>> the server as the Directory Manager, so doesn't that mean the ACI
>>>>> shouldn't matter?
>>>>>
>>>>> Thanks again,
>>>>>
>>>>> On Mon, 27 Sep 2010, Jason Brown wrote:
>>>>>
>>>>>> I am not sure if there is a huge difference between RHDS and 389, but
>>>>>> I also had this same issue. I believe it had to do with the ACI's
>>>>>> preventing the update to that attribute. Once you allow write access
>>>>>> to shadowLastChange it was able to update it.
>>>>>>
>>>>>>
>>>>>> On Sep 27, 2010, at 3:02 PM, James Smallacombe wrote:
>>>>>>
>>>>>>>
>>>>>>> Sorry for replying to myself, but I wanted to add more that I've
>>>>>>> tried
>>>>>>> since my last post:
>>>>>>>
>>>>>>> from the DirSrv X Console: in Configuration -> Indexes I added the
>>>>>>> "shadowLastChange" attribute to userRoot, then NetscapeRoot, still
>>>>>>> with no
>>>>>>> luck. I then put the following in my /etc/ldap.conf
>>>>>>>
>>>>>>> nss_map_objectclass shadowAccount User
>>>>>>> pam_password exop
>>>>>>>
>>>>>>> Still no luck. To clarify, the shadowLastChange DOES get propery
>>>>>>> updated
>>>>>>> when you reset a user's password in Webmin's "Users and Groups"
>>>>>>> module,
>>>>>>> but NOT when you use /usr/lib64/mozldap/ldappasswd OR in the
>>>>>>> Squirrelmail
>>>>>>> "Change LDAP Password" plugin. Again, any of these will change the
>>>>>>> password no problem, but not that attribute....any pointers would be
>>>>>>> appreciated. Here is a sample user:
>>>>>>>
>>>>>>> version: 1
>>>>>>> dn: uid=test123,ou=People, dc=some, dc=domain
>>>>>>> objectClass: posixAccount
>>>>>>> objectClass: top
>>>>>>> objectClass: person
>>>>>>> objectClass: organizationalPerson
>>>>>>> objectClass: inetOrgPerson
>>>>>>> objectClass: shadowAccount
>>>>>>> uid: test123
>>>>>>> cn:test123
>>>>>>> uidNumber: 999
>>>>>>> gidNumber: 999
>>>>>>> homeDirectory: /home/test123
>>>>>>> loginShell: /bin/false
>>>>>>> sn: test123
>>>>>>> mail: test123@some.domain
>>>>>>> shadowLastChange: 13678
>>>>>>> shadowMin: 1
>>>>>>> shadowMax: 99999
>>>>>>> shadowWarning: 14
>>>>>>>
>>>>>>> On Mon, 27 Sep 2010, James Smallacombe wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I finally figured out a working shell script to make LDAP user
>>>>>>>> password
>>>>>>>> changes using mozldap/ldappasswd. Unfortunately, I just discovered
>>>>>>>> that
>>>>>>>> changing the password using this does not update the
>>>>>>>> "shadowLastChange"
>>>>>>>> attribute, so users with expired passwords are still not able to
>>>>>>>> log in,
>>>>>>>> even after an admin has reset their password in this manner.
>>>>>>>>
>>>>>>>> Since we are migrating from traditional shadow passwords to LDAP,
>>>>>>>> the
>>>>>>>> attribute we need to get updated by this is "shadowLastChange"
>>>>>>>>
>>>>>>>> I attempted to work around this in /etc/ldap.conf by adding this:
>>>>>>>>
>>>>>>>> nss_map_attribute shadowLastChange pwdLastSet
>>>>>>>>
>>>>>>>> But to no avail. In addition, the "change ldap password" plugin
>>>>>>>> also does
>>>>>>>> not update this, although webmin users and groups module does.
>>>>>>>>
>>>>>>>> What am I missing? Thanks in Advance!
>>>>>>>>
>>>>>>>> James Smallacombe PlantageNet, Inc. CEO and
>>>>>>>> Janitor
>>>>>>>> up@3.am
>>>>>>>> http://3.am
>>>>>>>> =
>>>>>>>> =
>>>>>>>> =
>>>>>>>> =
>>>>>>>> =
>>>>>>>> =
>>>>>>>> ================================================== =================
>>>>>>>> --
>>>>>>>> 389 users mailing list
>>>>>>>> 389-users@lists.fedoraproject.org
>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>>
>>>>>>>
>>>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>>>>> up@3.am
>>>>>>> http://3.am
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ================================================== ==================
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users@lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users@lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>
>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>>> up@3.am
>>>>> http://3.am
>>>>> =
>>>>> =
>>>>> =
>>>>> ================================================== ====================
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users@lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users@lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>
>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>> up@3.am
>>> http://3.am
>>> ================================================== =======================
>>
>
> James Smallacombe PlantageNet, Inc. CEO and Janitor
> up@3.am http://3.am
> ================================================== =======================
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am
================================================== =======================
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 04:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org