SEO

Uppal, Indermohan wrote:
> Hi Erik,
>
> I have setup a SUN one LDAP server version 5.2
> I am successfully able to do OS user authentication from AIX 5.3 client
>
> But AIX 4.3.3 client doesn't seem to work.
>
> Will it possible for you to send me the /etc/security/ldap/ldap.cfg file
> from AIX 4.3.3 client
> ( after removing your company specific data)

Hi Uppal,

OK, the trickery is not in /etc/security/ldap/ldap.cfg because the AIX
4.3 through AIX 5.1 LDAP client cannot be configured at all, except for
the suffix. The real trickery should be in your LDAP directory, where
you should do almost everything to "succumb" to the wishes of the AIX
4.3-5.1 LDAP client. These wishes are:

1) Use the AIX specific AIXaccount/AIXAccessGroup schema available from
IBM's (Directory Server) website. This consists of the objectclasses
top, account, eAccount and AIXaccount for Unix users and top, ???,
AIXAccessGroup for Unix groups.

2) Write all attributes in your SunONE directory server in lowercase:
i.e. change userPassword to userpassword. This was a killer that took us
several months. The AIX 4.3-5.1 LDAP client is "written against" IBM's
Directory Server which seems to always use all lowercase for all
attribute-names. So the AIX 4.3-5.1 LDAP client does not recognize
userPassword as a valid attribute containing the users password, while
is does with userpassword.
SunONE directory server will use the case provided in your query or use
what's in it's definition when not asked for specific attributes. So
"ldapsearch .... "(filter)" uid userPassword" gets you "userPassword:
{Crypt}blathibla" and "ldapsearch ...."(filter)" uid userpassword" gets
you "userpassword: {Crypt}blathibla" but "ldapsearch ...."(filter)" "
(i.e. without requesting specific attributes) gets you the case that's
in the 00core.ldif through 99user.ldif files.
Maybe you can get away with just "lowercasing" userPassword, but we
haven't tested this. I'd love to hear the results if you do.

3) Use the tree-layout needed by the AIX LDAP client. You can only
specify the AIX tree-suffix in ldap.cfg. This suffix should end in
cn=aixsecdb, so something like cn=aixsecdb,ou=UnixAuthentication,o=Myorg
or cn=aixsecdb,ou=UnixAuthentication,dc=MyOrg,dc=com will do. Below this
the AIX 4.3-5.1 LDAP client expects 2 containers: ou=aixuser and
ou=aixgroup. These contain the user and group entries respectively.

4) Use Unix' {Crypt} as the password encryption algorithm and allow the
AIX LDAP client admin DN's to read the userpassword attribute. This is
needed because the AIX LDAP clients read the Unix crypted password and
locally compare it with the encrypted version of the user-provided
password. This also goes for AIX 5.2 BTW. Only in AIX 5.3 can you use
so-called "ldap_auth" to have the client Bind to the LDAP server to
verify the password, thus giving you the unified, LDAP-server provided
password (expiration)-policy.

5) Be careful if you allow password-updates from AIX systems. We don't
because of 2 reasons:
5.1) The new password is written to the directory using the adminDN's
bindDN and password, and these are in clear-text in
/etc/security/ldap/ldap.cfg (though only readable to root). You weigh
your risk on this one.
5.2) The new password is encrypted ({Crypt}) by the AIX LDAP client, but
send to the LDAP-server without the {Crypt} prefix. On our SunONE
installation we had {Crypt} as the default algorithm, and SunONE
directory server would happily apply that again to encrypt the what it
thought was an unencrypted password, resulting in double-encryption for
passwords updated from these clients.
Because of 5.1) we haven't tested whether AIX 5.2 also does not prefix
the password with {Crypt}. With AIX 5.3 and ldap_auth password updates
work OK, and also are not written to the directory by the system's
adminDN but by the user him/herself, allowing you to make the password
unreadable to the AIX 5.3 LDAP clients just like with Sun's Native LDAP
clients, and allowing you to use the SunONE provided "Password
SelfService" ACI to grant the appropriate access-permissions.

6) Now for the real trickery with SunONE directory server we already had
a "normal" rfc2307bis tree-layout for all Solaris and AIX 5.2 LDAP
clients and wanted to have at lease password-synchronization between
those and AIX 4.3. So I used SunONE Directory Server's Class of Service
(CoS) feature with indirect-CoS to sync as much attributes as possible
from the ou=People,o=MyOrg entry to the
username=unixusr1,ou=aixuser,cn=aixsecdb,ou=xxxx,o =MyOrg entry. I have
the latter entry pointing back to the former with the seeAlso attribute
in the latter. The indirect CoS template specifies seeAlso as the
attribute leading it back to the entry to take the attribute-values for
the virtual (=CoS provided) attributes from. So it look like this:

dn: uid=unixusr1,ou=People,o=MyOrg
userpassword={Crypt}blathibla
uid=unixusr1
cn=Users Complete Common Name
gecos=We use Users Complete Common Name for this too.
sn=Users SurName
homedirectory=/home/unixusr1
....
loginshell=/usr/bin/ksh
groupNumber=1234
uidNumber=4567

The basic entry for AIX 4.3 before CoS kicks in (you'll never actually
see this unless CoS makes your LDAP server so slow you will)

dn: username=unixusr1,ou=aixuser,cn=aixsecdb,ou=xxxx,o =MyOrg
username=unixuser1 # Needed because provides DN
cn=dummy, will be overwritten by CoS # Needed, MUST in schema
sn=dummy, will be overwritten by CoS # Needed, MUST in schema
seeAlso=uid=unixusr1,ou=People,o=MyOrg # Needed for "linkback"
objectclass=top
objectclass=account
objectclass=eAccount
objectclass=AIXAccount
objectclass= whatever you wanna add

And because most attributes in de CoS-Template are specified to be
overwritten with the values from the ou=People,o=MyOrg entry the seeAlso
attributes links back to, cn and sn get overwritten, and gecos,
homedirectory. loginshell, userpassword and alot of others get added by
CoS so the entry becomes:

dn: username=unixusr1,ou=aixuser,cn=aixsecdb,ou=xxxx,o =MyOrg
username=unixuser1 # Needed because provides DN
cn=Users Complete Common Name
sn=Users SurName
seeAlso=uid=unixusr1,ou=People,o=MyOrg # Needed for "linkback"
objectclass=top
objectclass=account
objectclass=eAccount
objectclass=AIXAccount
objectclass= whatever you wanna add
userpassword={Crypt}blathibla
homedirectory=/home/unixusr1
....
loginshell=/usr/bin/ksh
gecos=We use Users Complete Common Name for this too.

One thing to note is that it's no use syncing uid, uidNumber and
gidNumber this way because the AIXAccount schema uses uid for the Unix
useridnumber instead of uidNumber and uses gid for the primary groups
number instead of gidNumber. So syncing uid will actually harm you, and
syncing gidNumber has no use. So these should be synced manually
somehow. But userpassword, homedirectory, loginshell and gecos can be
synced. All in all we also sync quite a bunch of other attributes from
additional (organization specific) user-related objectclasses, making
for a total of 80+ synced attributes.

Off course with this sync working only one way (from ou=People to
ou=aixuser only) you only want clients reading uid=*,ou=People,o=MyOrg
to update the passwords, so the issues in 5.1) and 5.2) are no problem
anymore. We have users change their password from Solaris 8+ and AIX
5.3+ systems only. AIX 5.2 systems do read the entries in ou=People but
are still "vulnarable" to 5.1) so those are excluded in our setup too.

HTH, Erik.