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@xxxx> > Sent: Wednesday, September 29, 2010 11:55 AM > To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx <389-users@xxxxxxxxxxxxxxxxxxxxxxx> > 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||shadowMin||shadowMax||shadowWarning||shadowInactive||shadowExpire||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@xxxxxxxxxxx >>>>>>> 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@xxxx >>>>>>>> http://3.am >>>>>>>> = >>>>>>>> = >>>>>>>> = >>>>>>>> = >>>>>>>> = >>>>>>>> = >>>>>>>> =================================================================== >>>>>>>> -- >>>>>>>> 389 users mailing list >>>>>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>>>> >>>>>>> >>>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor >>>>>>> up@xxxx >>>>>>> http://3.am >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ==================================================================== >>>>>>> -- >>>>>>> 389 users mailing list >>>>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> >>>>>> -- >>>>>> 389 users mailing list >>>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> >>>>> >>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor >>>>> up@xxxx >>>>> http://3.am >>>>> = >>>>> = >>>>> = >>>>> ====================================================================== >>>>> -- >>>>> 389 users mailing list >>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>>> -- >>>> 389 users mailing list >>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>> >>> James Smallacombe PlantageNet, Inc. CEO and Janitor >>> up@xxxx >>> http://3.am >>> ========================================================================= >> > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up@xxxx http://3.am > ========================================================================= > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > James Smallacombe PlantageNet, Inc. CEO and Janitor up@xxxx http://3.am ========================================================================= -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
