Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 3 months
Segfault
by Edward Z. Yang
We've had ns-slapd segfault on us recently twice; we don't have
a core dump (since the daemon script turns off core dumps, but
hopefully we'll have one next time it happens) and I was wondering
if anyone had seen this before:
ns-slapd[2725]: segfault at 10a3000010af ip 0000003d58c95785 sp 00007ff2abf04040 error 4 in libcrypto.so.0.9.8n[3d58c00000+15b000]
ns-slapd[2727]: segfault at 10a3000010af ip 0000003d58c95785 sp 00007ff2aab02040 error 4 in libcrypto.so.0.9.8n[3d58c00000+15b000]
Cheers,
Edward
13 years, 2 months
NSMMReplicationPlugin - Can't resurrect tombstone
by Chun Tat David Chu
Hi all,
I am hitting some problem with my replicated directory server. I saw the
following error messages from the errors log file.
[17/Sep/2010:09:47:51 -0400] NSMMReplicationPlugin - conn=1 op=4
csn=4c9363a9000000020000: Can't resurrect tombstone
ou=test,dc=example,dc=com to glue reason 'deletedEntryHasChildren', error=68
Can anyone tell me what could cause this problem and how to prevent it from
happening again?
Thanks!
David
13 years, 2 months
Chaining woes again...
by Gerrard Geldenhuis
Hi
I have setup chaining but it is not working at all and I am not sure how to debug it further.
I am using:
389-admin-1.1.11-0.6.rc2.el5
389-admin-console-1.1.5-1.el5
389-admin-console-doc-1.1.5-1.el5
389-adminutil-1.1.8-4.el5
389-console-1.1.4-1.el5
389-ds-1.2.1-1.el5
389-ds-base-1.2.6-0.11.rc7.el5
389-ds-console-1.2.3-1.el5
389-ds-console-doc-1.2.3-1.el5
389-dsgw-1.1.5-1.el5
The setup is 4 servers, two multimasters and two consumers. Client can only speak to the consumers and thus referrals won't work.
I have used the following ldif to setup chaining:
dn: cn=chainingBackend,cn=chaining database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: extensibleObject
objectClass: nsBackendInstance
cn: chainingBackend
nsslapd-suffix: dc=mycompany
nsmultiplexorbinddn: cn=replication manager,cn=config
nsusestarttls: on
nsfarmserverurl: ldaps://masterfqdn1:636 masterfqdn2:636/
nsmultiplexorcredentials: {SSHA}blah
nsbindconnectionslimit: 5
nsconcurrentoperationslimit: 5
nsconnectionlife: 130
nsbindtimeout: 3
nsbindretrylimit: 3
nsmaxresponsedelay: 3
nsmaxtestresponsedelay: 5
dn: cn=dc\3dmycompany,cn=mapping tree,cn=config
changetype: modify
add: nsslapd-backend
nsslapd-backend: chainingBackend
-
replace: nsslapd-state
nsslapd-state: backend
-
replace: nsslapd-distribution-plugin
nsslapd-distribution-plugin: /usr/lib64/dirsrv/plugins/libreplication-plugin.so
-
replace: nsslapd-distribution-funct
nsslapd-distribution-funct: repl_chain_on_update
dn: cn=config,cn=chaining database,cn=plugins,cn=config
changetype: modify
add: nsTransmittedControls
nsTransmittedControls: 2.16.840.1.113730.3.4.12
The ACI has been created to allow the Replication Manager user proxy access.
When I run the following on the client:
dn: uid=john,ou=people,dc=mycompany
changetype: modify
add: mobile
mobile: 1234
The entry gets added but only locally, it thus seems to be completely ignoring the chaining I have setup. I see the following in the consumer log after creation:
[29/Sep/2010:13:00:11 +0000] start_tls - Received extended operation request with OID 1.3.6.1.4.1.1466.20037
[29/Sep/2010:13:00:11 +0000] start_tls - Start TLS extended operation request confirmed.
[29/Sep/2010:13:00:11 +0000] start_tls - Start TLS request accepted.Server willing to negotiate SSL.
[29/Sep/2010:13:00:11 +0000] start_tls - Starting SSL Handshake.
[29/Sep/2010:13:00:11 +0000] NS7bitAttr - MODIFY begin
[29/Sep/2010:13:00:11 +0000] NSMMReplicationPlugin - Purged state information from entry uid=rytis,ou=People,dc=betfair up to CSN 4c99ec08000000010000
[29/Sep/2010:13:00:12 +0000] roles-plugin - --> roles_post_op
[29/Sep/2010:13:00:12 +0000] roles-plugin - --> roles_cache_change_notify
[29/Sep/2010:13:00:12 +0000] roles-plugin - <-- roles_cache_change_notify: not a role entry
[29/Sep/2010:13:00:12 +0000] roles-plugin - <-- roles_post_op
There is some other replay failure errors which I am not sure is related. Having done the the test twice I did not see the replay errors again in the master log. I am going to simplify my test environment as I currently have 4 servers which all are verbal about replication and I multimaster netscapedb which adds to the complications.
I have enabled Replication and Plug-ins for the error log, is there any other recommended logs that I should enable that can assist me in debugging chaining issues.
Best Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 2 months
nsView problem
by Procunier, Greg
Hello,
I have tried creating test directory similar to the example given from
Red Hat in this image:
http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/images/virv
iew3.png
The goal was to have a nsViewFilter reach into the global user bucket
(ou=People,dc=mgt,dc=ont,dc=srv) and populate a lower level branch with
relevant user information
(ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv).
This does not work at all; the nsViewFilter only works if that filter is
on the same level as the objects it needs to search which is
contradictory to the image Red hat has pushed out.
I was under the impression that container structures (such as
organization units or organizations) with nsViewFilter attributes recurs
the root of the directory to create their abstractions. If that were
the case then the Red Hat image would be correct. As it is right now it
does not seem to be the case.
I am using Red Hat Directory server 8.2 (redhat-ds-8.2.0-2) on RHEL5.
I am hoping I am doing something terribly wrong and some one can point
it out for me.
--- SNIP (test.ldif) ---
dn: dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: domain
dc: mgt
dn: ou=People,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: People
dn: uid=doe_john,ou=People,dc=mgt,dc=ont,dc=srv
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
gidNumber: 65534
givenName: John
sn: Doe
displayName: John Doe
uid: doe_john
homeDirectory: /home/domain_users/doe_john
gecos: Test User 1
loginShell: /bin/bash
shadowFlag: 0
shadowMin: 0
shadowMax: 99999
shadowWarning: 0
shadowInactive: 99999
shadowLastChange: 12011
shadowExpire: 99999
cn: John Doe
uidNumber: 48465
dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
gidNumber: 65534
givenName: Jane
sn: Doe
displayName: doe_jane
uid: doe_jane
homeDirectory: /home/domain_users/doe_jane
gecos: Test User 2
loginShell: /bin/bash
shadowFlag: 0
shadowMin: 0
shadowMax: 99999
shadowWarning: 0
shadowInactive: 99999
shadowLastChange: 12011
shadowExpire: 99999
cn: doe_jane
uidNumber: 31388
dn: ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: Projects
dn: ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: A
dn: ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: B
dn: ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=48465)
dn: ou=People,ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=31388)
-- SNIP (ldapsearch output) --
[root@directory]# ldapsearch -b ou=Projects,dc=mgt,dc=ont,dc=srv -x
objectclass=\*
# extended LDIF
#
# LDAPv3
# base <ou=Projects,dc=mgt,dc=ont,dc=srv> with scope subtree
# filter: objectclass=*
# requesting: ALL
#
# Projects, mgt.ont.srv
dn: ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: Projects
# A, Projects, mgt.ont.srv
dn: ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: A
# B, Projects, mgt.ont.srv
dn: ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: B
# People, A, Projects, mgt.ont.srv
dn: ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=48465)
# People, B, Projects, mgt.ont.srv
dn: ou=People,ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=31388)
# search result
search: 2
result: 0 Success
# numResponses: 6
# numEntries: 5
-- SNIP --
13 years, 2 months
Multi-Master setup
by Reinhard Nappert
Hi,
I have seen the following message in the errors log file, when I set MMR agreements up:
[10/Aug/2010:11:46:44 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=base: 1
[10/Aug/2010:11:46:44 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=base is going offline; disabling replication
[10/Aug/2010:11:46:46 -0400] - somehow, there are still 20 entries in the entrycache. :/
[10/Aug/2010:11:46:46 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[10/Aug/2010:11:46:48 -0400] - BAD CACHE ASSERTION at ../ldap/servers/slapd/back-ldbm/cache.c/765: e->ep_refcnt > 0
[10/Aug/2010:11:46:52 -0400] - Fedora-Directory/1.1.2 B2009.090.1643 starting up
[10/Aug/2010:11:46:52 -0400] - Detected Disorderly Shutdown last time DirectoryServer was running, recovering database.
After I re-initialize the database from the supplier (setting attribute nsds5BeginReplicaRefresh to start of the agreement object), the database gets correctly imported.
Any idea, what is going on?
Thanks,
-Reinhard
13 years, 2 months
Re: [389-users] shadowLast Change NOT updating was Re: ldappasswd and shadowLastChange attribute
by Morris, Patrick
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(a)3.am>
Sent: Wednesday, September 29, 2010 11:55 AM
To: 389-users(a)lists.fedoraproject.org <389-users(a)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||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(a)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(a)3.am
>>>>>>> http://3.am
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ===================================================================
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>
>>>>>>
>>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>>>> up(a)3.am
>>>>>> http://3.am
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> ====================================================================
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users(a)lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>
>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>> up(a)3.am
>>>> http://3.am
>>>> =
>>>> =
>>>> =
>>>> ======================================================================
>>>> --
>>>> 389 users mailing list
>>>> 389-users(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>> up(a)3.am
>> http://3.am
>> =========================================================================
>
James Smallacombe PlantageNet, Inc. CEO and Janitor
up(a)3.am http://3.am
=========================================================================
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
13 years, 2 months
Segfault & Core Dumps
by Dael Maselli
Hi,
I'm experiencing a lot of segmentation fault on my installations, I have
the latest release on EPEL on SL 5.4 (389-Directory/1.2.5 B2010.012.2034).
I'm trying to get core dumps but without success. Is there a specific
configuration that prevents/allows 389-ds to core dump?
The default on linux, you know, is to have core dump soft limit to 0, so
I changed it for 389 in /etc/sysconfig/dirsrv, adding the line:
ulimit -c unlimited
and now I get:
# more /proc/`pidof ns-slapd`/limits | grep core
Max core file size unlimited unlimited bytes
Kernel parameters are at default:
# sysctl -a | grep kernel.core
kernel.core_pattern = core
kernel.core_uses_pid = 1
So, I expected a core dump in /proc/`pidof ns-slapd`/cwd/, right?
But when it segfaults no file is created in cwd.
Can you help me, please?
Thank you.
Best regards,
Dael Maselli.
13 years, 2 months
User insert fails... because of pwpolicy?
by Gerrard Geldenhuis
Hi
Adding a user with the following ldif file:
dn: uid=SystemAuthentication,ou=Service Accounts,dc=mycompany
givenName: System
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Authentication
cn: SystemAuthentication
uid: SystemAuthentication
userPassword: {SSHA}blah
fails with:
ldapadd: Object class violation (65)
additional info: single-valued attribute "passwordExpirationTime" has multiple values
Does this fail because the enabled password policy is also trying to add a value?
Is there a way to override this other than doing a ldapmodify after adding the users?
Best Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 2 months
Re: [389-users] shadowLast Change NOT updating was Re: ldappasswd and shadowLastChange attribute
by James Smallacombe
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(a)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(a)3.am
>>>>>>> http://3.am
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ===================================================================
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>
>>>>>>
>>>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>>>> up(a)3.am
>>>>>> http://3.am
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> ====================================================================
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users(a)lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>
>>>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>>>> up(a)3.am
>>>> http://3.am
>>>> =
>>>> =
>>>> =
>>>> ======================================================================
>>>> --
>>>> 389 users mailing list
>>>> 389-users(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> James Smallacombe PlantageNet, Inc. CEO and Janitor
>> up(a)3.am
>> http://3.am
>> =========================================================================
>
James Smallacombe PlantageNet, Inc. CEO and Janitor
up(a)3.am http://3.am
=========================================================================
13 years, 2 months