If you want to change the default expiration time to 90 days, here’s the steps:

1. Find subject DN cn=posix_account_password_policy,ou=People, dc=doxer,dc=org(search parameters,  objectClass=ldapsubentry under ou=People, dc=doxer,dc=org)
2. Change passwordMaxAge parameter to ’7776000′  (value mentioned in seconds equals to 30 days)
3. If your ldap server has replication, have a check of whether the replication syncs the modification.
4. Create a new account, and test it through ldapsearch. For example:

[root@doxer ~]# ldapsearch -x -W -D cn=”Directory Manager” -h ldap.doxer.org -b ou=people,dc=doxer,dc=org uid=testme passwordexpirationtime
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=doxer,dc=org> with scope subtree
# filter: uid=testme
# requesting: passwordexpirationtime
#

# testme, People, doxer.org
dn: uid=testme,ou=People,dc=doxer,dc=org
passwordexpirationtime: 20121113011623Z #(today is 20120815, meaning that it’s the result we want!)

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

proxyagent is the user that all hosts that bound to solaris iplanet Directory Server uses to authenticate queries against the server. If the password expires then all the clients ldap requests fail(and there’s no way to set it not to expire).
The process to update the password is outlined below and only takes a few minutes to complete(applied to solaris iplanet Directory Server, but this may also help you if you use other DS like OpenLDAP etc):
1.Log on Sun Java Web Console for iplanet LDAP with system’s root password.
2.Click on “Directory Service Control Center (DSCC)” under “Services” legend. Note that at some point you are prompted for a password, this is the LDAP Configuration password this time.
3.Choose the tab “Directory Servers”
4.Choose a master to work from (click on the server name)
5.Choose the tab “Entry Management”

In the DN list double click ou=profile
In the next DN list double click cn-proxyagent
In here reset the password using the same password as before (check password tool or /etc/ldap.conf on any LDAP client box)
Click ok

6.Completed, now retry LDAP access

Let’s assume that your application software like IBM websphere was using ldap for authentication, and you don’t want the user “wasadm” in a position that it’s password expires someday as a result of conforming to PAM policy. To do this, you should consider using ldap objectClass organizationalPerson and inetOrgPerson(this is sub of organizationalPerson) instead of posixAccount and shadowAccount.

If you’re using ldap tool JXplorer to communicate with ldap server, you’ll find there’re ldap Attributes such as userPassword, shadowLastChange etc when you are using objectClass posixAccount and shadowAccount for the entry. But after you removed objectClass posixAccount and shadowAccount, and add organizationalPerson and inetOrgPerson for the entry, you’ll find these Attributes evaporate which implicate the password will no longer needed for this entry. After this, our goal of setting account never expire has been achived.

Here’s two snapshots:

using objectClass posixAccount shadowAccount

using objectClass organizationalPerson and inetOrgPerson

PS:

1.  Here’s a resource where you can check hierarchy of ldap Attributes, objectClass and their description. http://www.zytrax.com/books/ldap/ape/
2. For full LDAP info, I would recommend you read the following online book: http://www.zytrax.com/books/ldap/
3. Here’s a good document about ldap with details on integration ldap with sendmail/squid etc. download ldap integration.zip

If you encountered some problem when doing sudoCommand, you will be happy if there’s debug info showed in console. To show detailed debug info when doing sudo, modify /etc/ldap.conf(for both solaris ldap and linux ldap):

# verbose sudoers matching from ldap
sudoers_debug 2

sudoers_debug setting to 1 will show moderate debugging, setting to 2 will show the results of the matches themselves. For example, if you have set sudoers_debug to 2 and when you execute sudoCommand, info you’ll get will like the following:

$ sudo -i
LDAP Config Summary
===================
uri ldaps://testLdapServer/
ldap_version 3
sudoers_base ou=SUDOers,dc=doxer,dc=org
binddn cn=proxyAgent,ou=profile,dc=doxer,dc=org
bindpw password
bind_timelimit 120000
timelimit 120
ssl on
tls_cacertdir /etc/openldap/cacerts
===================
sudo: ldap_initialize(ld, ldaps://testLdapServer/)
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: tls_cacertdir -> /etc/openldap/cacerts
sudo: ldap_set_option: timelimit -> 120
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 120)
sudo: ldap_set_option(LDAP_OPT_X_TLS, LDAP_OPT_X_TLS_HARD)
sudo: ldap_simple_bind_s() ok
sudo: found:cn=defaults,ou=SUDOers,dc=doxer,dc=org
sudo: ldap sudoOption: ‘ignore_local_sudoers’
sudo: ldap search ‘(|(sudoUser=liandy)(sudoUser=%linuxsupport)(sudoUser=%linux)(sudoUser=ALL))’
sudo: found:cn=LDAPpwchange,ou=sudoers,dc=doxer,dc=org
sudo: ldap sudoHost ‘server01′ … not
sudo: ldap sudoHost ‘server02′ … not
sudo: ldap search ‘sudoUser=+*’
sudo: found:cn=test-su,ou=SUDOers,dc=doxer,dc=org
sudo: ldap sudoUser netgroup ‘+sysadmin-ng’ … not
sudo: found:cn=dba-su,ou=SUDOers,dc=doxer,dc=org
sudo: ldap sudoUser netgroup ‘+dba-ng’ … not
sudo: ldap sudoUser netgroup ‘test01′ … not
sudo: ldap sudoUser netgroup ‘test02′ … not
sudo: found:cn=Linux-Team-root,ou=SUDOers,dc=doxer,dc=org
sudo: ldap sudoUser netgroup ‘+linuxadmins’ … MATCH!
sudo: ldap sudoHost ‘ALL’ … MATCH!
sudo: ldap sudoorgmand ‘ALL’ … MATCH!
sudo: Perfect Matched!
sudo: ldap sudoOption: ‘!authenticate’
sudo: user_matches=-1
sudo: host_matches=-1
sudo: sudo_ldap_check(0)=0×422

So from above debugging outputs, you’ll know that the account to be sudo authenticated belongs to linuxadmins netgroup and this netgroup is in the sudoUser’s scope of Linux-Team-root SUDOers. As Linux-Team-root has sudoCommand for “ALL” and sudoHost for “ALL” and also has sudoOption “!authenticate”, then the user will successfully get root access with no password prompt.

Now let’s go through a failed authentication to see the debugging information:

$ sudo hastatus -sum
LDAP Config Summary
===================
host testLdapServer
port 389
ldap_version 3
sudoers_base ou=SUDOers,dc=doxer,dc=org
binddn (anonymous)
bindpw (anonymous)
===================
ldap_init(testLdapServer,389)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0×03)
ldap_bind() ok
found:cn=defaults,ou=SUDOers,dc=doxer,dc=org
ldap sudoOption: ‘ignore_local_sudoers’
ldap search ‘(|(sudoUser=liandy)(sudoUser=%normaluser)(sudoUser=%normaluser)(sudoUser=%patop)(sudoUser=ALL))’
ldap search ‘sudoUser=+*’
found:cn=test-su,ou=SUDOers,dc=doxer,dc=org
ldap sudoUser netgroup ‘+sysadmin-ng’ … not
found:cn=tstwas-su,ou=SUDOers,dc=doxer,dc=org
ldap sudoUser netgroup ‘+linux-team-ng’ … not
found:cn=normal-su,ou=SUDOers,dc=doxer,dc=org
ldap sudoUser netgroup ‘+normaluser-ng’ … MATCH!
ldap sudoHost ‘all’ … MATCH!
ldap sudoCommand ‘/opt/OV/bin/OpC/opcagt -start’ … not
ldap sudoCommand ‘/opt/OV/bin/OpC/opcagt -status’ … not
ldap sudoCommand ‘/opt/OV/bin/OpC/opcagt -stop’ … not
ldap sudoCommand ‘/opt/OV/bin/OpC/opcagt -kill’ … not
user_matches=-1
host_matches=-1
sudo_ldap_check(0)=0×04
Password:

From here we can see that although the user to be authenticated is in “normal-su” SUDOers, and the host is in it’s sudoHost, but as there’s no “hastatus -sum” defined for sudoCommand, so at last the authentication failed(user_matches=-1, host_matches=-1) and prompts for sudo password.

If you want to change ldap client(linux) to bind to another ldap server, here’s the basic steps for you:

1.update /etc/ldap.conf to change where sudoers is authenticating(note that /etc/ldap.conf will only control sudoers)
From:
uri ldap://ldapserver1/ ldap://ldapserver2/
To:
uri ldap://ldapserver2/ ldap://ldapserver1/

2.update /etc/openldap/ldap.conf to change where logins are authenticating
From:
uri ldap://ldapserver1/ ldap://ldapserver2/
To:
uri ldap://ldapserver2/ ldap://ldapserver1/

3.restart nscd
/etc/init.d/nscd restart

NB:

For ldap client which is running solaris, you’ll need to know something about commands ldap_cachemgr, ldapclient and their mechanism.

1.Add Netgroup

When you have defined netgroup, sudo group and sudo command on your ldap server,  the next thing you should do is to add netgroup to your client server(which use ldap as authentication) on your linux or solaris box.

Method as follows:

• For solaris

Edit /etc/passwd, add line(you should change name according to your requirements):

+@your-ng:x:::::

And then run pwconv

Read more…