Archive

Posts Tagged ‘ldap’

Resolved – change ldap expiration policy how to

August 15th, 2012 No comments

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

Categories: IT Architecture Tags:

reset ldap proxyagent password before expiration on iplanet Directory Server

July 26th, 2012 No comments

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

Categories: IT Architecture, Linux, Systems Tags:

ldap password never expires – objectClass organizationalPerson and inetOrgPerson

July 4th, 2012 No comments

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:

posixAccount-shadowAccount

using objectClass posixAccount shadowAccount

organizationalPerson-inetOrgPerson

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
Categories: IT Architecture Tags:

modify sudoers_debug in ldap.conf to debug sudo on linux and solaris

May 22nd, 2012 No comments

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)=0x422

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,0x03)
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)=0x04
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.

change ldap client to bind to another ldap server

May 10th, 2012 No comments

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 #or nscd -i hosts

NB:

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

Add netgroup on linux & solaris boxes

April 17th, 2011 No comments

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

  • For linux

edit /etc/security/access.conf

+:@your-ng :ALL

Then run pwconv

2.Add a single user

  • For Linux

If you want to give access to test01 for server linux01 for example, edit /etc/security/access.conf, add line below:

+:test01 :ALL

And then run pwconv

  • For solaris

vi /etc/passwd

+test01:x:::::

Then run pwconv

To know which ldap server the client is using:

  • For solaris using iplanet DS, check /var/ldap/ldap_client_file. If it's ip addresses, use nslookup xxx.xxx.xxx.xxx(the ipaddress) to check the server name
  • For linux using openldap, check /etc/ldap.conf.

Remember to test the user account when you finish your job.

That’s all about that. :D

PS:

Here's something about linux/solaris +/- syntax(compat mode).

Interaction with +/- syntax (compat mode)
Linux libc5 without NYS does not have the name service switch but does
allow the user some policy control. In /etc/passwd you could have
entries of the form +user or +@netgroup (include the specified user
from the NIS passwd map), -user or -@netgroup (exclude the specified
user), and + (include every user, except the excluded ones, from the
NIS passwd map). Since most people only put a + at the end of
/etc/passwd to include everything from NIS, the switch provides a
faster alternative for this case ('passwd: files nis') which doesn't
require the single + entry in /etc/passwd, /etc/group, and /etc/shadow.
If this is not sufficient, the NSS 'compat' service provides full +/-
semantics. By default, the source is 'nis', but this may be overridden
by specifying 'nisplus' as source for the pseudo-databases passwd_com-
pat, group_compat and shadow_compat. This pseudo-databases are only
available in GNU C Library.
The Linux libc5 with NYS support and the GNU C Library 2.x (libc.so.6)
contain a cleaner solution of this problem. It is designed after a
method used by Sun Microsystems in the C library of Solaris 2. We fol-
low their name and call this scheme "Name Service Switch" (NSS). The
sources for the "databases" and their lookup order are specified in the
/etc/nsswitch.conf file.

This means that, in solaris, if you add the following in /etc/nsswitch.conf:

passwd: files ldap

This will add all ldap accounts to the host. Whilst if you add the following in /etc/nsswitch.conf:

passwd_compat:files ldap

passwd:compat

This means you can now use +/- syntax(compat mode) in /etc/passwd.

In linux, we usually use /etc/security/access.conf to control access(include ldap) to the host.(You can also use /etc/passwd to control ldap users).

Categories: IT Architecture, Linux, Systems, Unix Tags: