Level: Intermediate Yantian Lu (ylu@us.ibm.com), Ph.D., Software Engineer, IBM
Uma Chandolu (uchandol@in.ibm.com), Software Engineer, IBM
19 Feb 2008 Managing users and controlling their access in a centralized LDAP environment is a challenging task in a
heterogeneous environment. Some platforms may lose their operating system-specific functionality due to the lack of schema support from the LDAP server. This article presents a solution for some non-IBM® LDAP servers to support full AIX® user management functionality by providing the AIX schema for these server types and the steps to update these LDAP server types with the schema.
Scope, assumptions, and the environment
The scope of this article is to extend some non-IBM LDAP servers with AIX LDAP schema and to configure AIX to work with such servers. It is
assumed that the reader of this paper has medium to high knowledge level of directory
service concepts and management experience.
The solution described in this article has been tested and has been proven to be working in our test environments. It is presented as working example
to interested parties who have the need to support AIX systems with non-IBM LDAP servers.
We recommend that you experiment with this
solution in a test environment to make sure it works and serves your needs as desired before implementing it in a production environment.
Please note that the solution and steps described in this article are provided as-is, they may be updated when necessary, and they are not officially supported by IBM.
Introduction
Using a directory to store user and group information has the advantage of centralizing databases in a single location for reducing user and
group management complexity. Many vendors have implemented their LDAP solution to take
advantage of directory services, which have
matured over the past decade. Objects in a directory are defined by objectclasses and their associated attributes. The term "LDAP schema"
usually refers to the collection of LDAP attributes and objectclasses.
RFC 2307 defines a standard set of schema for Network Information Services (NIS), which covers users, groups, and other NIS objects.
AIX supports RFC 2307, and therefore is fully compatible with an RFC 2307 LDAP
environment. Besides the attributes defined in RFC 2307,
AIX also has additional attributes to support extended AIX user functionality. These
additional AIX attributes may not be available from third-party LDAP servers, and if configured as a client to such a server, AIX would not be able to set the extended user specific attributes in that
environment. The cause of the issue is the lack of AIX LDAP schema support in these
servers. This article documents the way to make a
non-IBM LDAP server behave similarly to an AIX LDAP server in terms of supporting AIX user management by extending these LDAP
servers with AIX LDAP schema.
Terms
| IBM LDAP schema | The whole set of schema that IBM defines |
|---|
| AIX LDAP schema | A subset of the IBM schema that supports AIX LDAP functionality |
|---|
| SFU schema | Windows® UNIX®-support schema included in the Windows Service For UNIX package. |
|---|
| Windows 2003 R2 schema | The built-in UNIX-support schema included in the Windows 2003 R2 CDs. |
|---|
| UNIX-enabling users and groups | Referring to the process of enabling users and groups on
Windows to support UNIX systems, by selecting a
UNIX domain from the UNIX tab of the user (or group) property panel. |
|---|
Software requirements
- IBM AIX 5.2 and later for SunOne Directory server.
- IBM AIX 5.3 TL 05 and later for Microsoft® Windows Active Directory with Microsoft Service For UNIX (SFU) schema.
- IBM AIX 5.3 TL 06 and later for Microsoft Windows Active Directory with R2 schema.
- IBM Tivoli® Directory Server software, included with the AIX base CDs and expansion pack CDs. Only the client fileset is required.
- The AIX LDAP schema can be obtained from the links referenced in this article.
LDAP servers tested
The solution described in this article has been tested on the following directory
servers:
- SunOne LDAP server running on Solaris 10
- Microsoft Active Directory (AD) running on Windows 2000 and 2003 with schema from
Microsoft Service For UNIX (SFU) version 3.5.
- Microsoft Active Directory running on Windows 2003 R2 with schema included with
Microsoft Windows 2003 R2.
Configuring SunOne LDAP server to support AIX attributes
The SunOne LDAP server must be configured and running. For details on configuring a
SunOne LDAP server, please refer the Resources section for information on SunOne documentation.
Obtaining the AIX LDAP schema
The AIX LDAP schema file for IPlanet Directory V5.0, aixSchemaForNS5.ldif, is part of
the download file non-IBM_LDAP.zip.
Using the AIX LDAP schema is sufficient to support AIX LDAP user management
functionality, and it is the recommended schema to use for this article.
If you also need more IBM LDAP schema to support other applications, you can download the complete IBM LDAP schema from
http://www.ibm.com/servers/eserver/iseries/ldap/schema/.
Extending the SunOne LDAP server with AIX LDAP schema
Copy the AIX schema file, aixSchemaForNS5.ldif, to the Solaris LDAP server.
Make sure that the LDAP server is started and run the ldapmodifycommand to load the
schema:
# ldapmodify -h <LDAPserver name> -D <Binddn> -w <bind passwd> -c -f
<schema file>
|
For example:
|
#ldapmodify -h myServer.myCompany.com -D "cn=directory manager" -w adminpwd -c -f aixSchemaForNS5.ldif
|
Enabling SunOne
users and groups with the AIX LDAP schema
The AIX LDAP schema includes the aixAuxAccount objectclass for users and the
aixAuxGroup objectclass for groups.
Adding the AIX LDAP schema to the SunOne LDAP server makes the schema available for use, but it does not mean the administrator can
set AIX attributes to existing SunOne users and groups yet. There is one extra step that
must be done -- the users and groups must
be updated with the AIX extended objectclasses.
Each user or group object defined in the SunOne LDAP server has a list of objectclasses that
describe that object. You can run the ldapsearch
command to list the objectclasses for a specific user. Below is an example output showing
the objectclasses for the user foo:
#ldapsearch -h <server> -D <binddn> -w <bindpwd> -b dc=mydomain,dc=com uid=foo
objectclass
uid=foo,ou=People, dc=mydomain,dc=com
objectclass=top
objectclass=person
objectclass=organizationalPerson
objectclass=inetorgperson
objectclass=posixAccount
|
In this example, even after the SunOne LDAP server has been updated with the AIX LDAP
schema, a user object in the SunOne LDAP server is not
automatically updated with the aixAuxAccount objectclass. Similarly, a group object is not automatically updated with the
aixAuxGroup objectclass. As a result, setting AIX attributes for user foo
fails.
The authors of this article are not aware of any existing tool that can be used to update the objectclasses of all the SunOne LDAP users
and groups. The SunOne LDAP server administrator may have to do it manually.
Below is a sample user template ldif file that can be used to update a user with the
aixAuxAccount objectclass.
Simply replace the DN value (in italics) with the actual user DN; save the changes to a
file -- for example, userentry.ldif -- then
run ldapmodify to load the change to the SunOne server. You need to do this for every SunOne user. To find the DN of the SunOne LDAP
users, you can use the ldaplist command on Solaris.
dn: uid=foo,ou=People,dc=mydomain,dc=com
changetype: modify
add: objectclass
objectclass: aixAuxAccount |
# ldapmodify -h <server> -D <binddn> -w <bindpwd> -f userentry.ldif |
Similarly, you will need to do the same steps for every SunOne group, using the following
sample group template file:
dn: cn=grp,ou=group,dc=mydomain,dc=com
changetype: modify
add: objectclass
objectclass: aixAuxGroup
|
With the above templates, you can write a script to query all the user DNs from the SunOne
LDAP server, and update each user using the template.
After modifying every user in SunOne LDAP server, run the ldapsearch command again
on any user to verify that the aixAuxAccount has been added to the user entry.
# ldapsearch -h <server> -D <binddn> -w <bindpwd> -b dc=mydomain,dc=com uid=foo1
objectclass
uid=foo1,ou=People, dc=mydomain,dc=com
objectclass=top
objectclass=person
objectclass=organizationalPerson
objectclass=inetorgperson
objectclass=posixAccount
objectclass=aixAuxAccount |
Configuring or reconfiguring AIX LDAP
If your AIX systems have already been configured as an LDAP client to the SunOne LDAP server, the administrator must reconfigure
AIX with the mksecldap command. The mksecldap command figures out what users in
the SunOne
LDAP server have an
AIX LDAP schema and picks the correct attribute maps to use, and then saves the information to
/etc/security/ldap/ldap.cfg.
To configure or reconfigure the AIX as a LDAP client to the Solaris LDAP server, run the
mksecldap command on AIX:
# mksecldap -c -h <server> -a <binddn> -p <bindpwd> -A ldap_auth
|
If unix_auth is preferred, you may omit the "-A ldap_auth" from this example.
Verify the LDAP client is configured with the SunOne LDAP server by running the following
command:
The ls-secldapclntd command displays the aixAuxAccount objectclass for user
objectclass and aixAuxGroup objectclass group objectclass.
Setting AIX attributes for existing users
Now that the configuration is completed, you can set AIX attributes for SunOne LDAP users and groups using the
chuser and chgroup commands from AIX. In the following example, we set SunOne user foo's nofiles AIX attribute to 1000:
# chuser -R LDAP nofiles=1000 foo |
After user foo logs in to AIX, run the limit command to verify that his file descriptor limit is set to 1000:
$ ulimit -a
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 1000
threads(per process) unlimited
processes(per user) unlimited |
Creating new SunOne users from AIX
You can also create a new SunOne LDAP user or group with AIX-specific attributes from AIX
using the mkuser and mkgroup commands.
The user or group created from AIX is RFC 2307 compatible, and is recognized by Solaris.
For example:
# mkuser -R LDAP nofiles=1000 test1 |
Alternatively, you can create the user using mkuser -R LDAP
test1 first, then set the AIX attributes using the chuser command.
The mkuser and mkgroup commands add the aixAuxAccount objectclass and
aixAuxGroup objectclass to the user and group they create, respectively.
These users and groups are fully AIX aware, and there is no need to enable them with the AIX LDAP schema again.
If you are unable to create a user or group from LDAP with the above commands, check the
SunOne LDAP server log files to find out the reason for the failure.
The SunOne LDAP server log files are located in the
/usr/iplanet/servers/slapd-(server)/logs directory, where (server) is the name
of the LDAP server instance.
Use the lsuser command to verify that the user has been created:
# lsuser -R LDAP test1
test1 id=230 pgrp=staff groups=staff home=/home/test1 shell=/usr/bin/ksh
login=true su=true rlogin=true daemon=true admin=false sugroups=ALL
admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE
umask=22 registry=LDAP SYSTEM=compat or LDAP logintimes= loginretries=0
pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0
minother=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks=
dictionlist= fsize=-1 cpu=-1 data=-1 stack=-1 core=-1 rss=-1 nofiles=1000 roles= |
Verify that the registry and SYSTEM attributes are set to LDAP. If the
SYSTEM attribute is not set as LDAP, then make a
change to the default stanza in the /etc/security/user file as SYSTEM = "LDAP or compat" so that LDAP users as well as local users
are allowed to log in to the system. For more information on how to use the registry and
SYSTEM attributes to control user login, please read the "AIX Security Guide" and
the articles listed in the Resources section.
Now you can set the password for user test1 by running the passwd -R LDAP test1 command, and then verify the user's login.
Creating SunOne users from AIX or not?
By default, AIX creates users with posixaccount, account, aixauxaccount, and
ibm-securityidentities objectclasses.
The SunOne LDAP user uses a slightly different list of objectclasses including
posixaccount, person, organizationalperson, and inetorgperson.
Therefore, users created to the SunOne server from AIX do not support some of the
attributes from the person, organizationalperson, and
inetgorperson objectclasses. This could potentially lead to issues if there are applications that rely on the SunOne server to support such attributes.
If this turns out to be an issue in your environment, you may want to avoid creating users
to the LDAP server from AIX. Create them on Solaris instead. But keep in mind that
the users created from Solaris do not have the AIX LDAP schema, and you need to update the
user with the aixAuxAccount objectclass
using the method described in the Enabling SunOne users and groups with AIX extended
schema section.
There is no such issue creating groups from AIX. Users created from AIX have the same objectclasses as from Solaris.
Configuring a Windows AD server to support AIX attributes
Windows server requirements are as follows:
- Windows 2000/2003
- Must have the UNIX schema installed (schema in MS SFU v3.5).
- Windows 2003 R2 must have the built-in UNIX schema or SFU schema, but not both.
- Windows users and groups must be enabled for UNIX support.
AIX requirements are as follows:
- AIX 5.3 TL05 or later clients for Windows 2000/2003 AD server
- AIX 5.3 TL06 or later clients for Windows 2003 R2 AD server
Obtaining AIX LDAP schema for AD
The AIX LDAP schema Windows Active Directory file, aixSchemaForAD.ldif, is part of
the non-IBM_LDAP.zip file.
Extending AD LDAP server with AIX LDAP schema
Copy the AIX Schema file, aixSchemaForAD.ldif,
to the Windows Active Directory server and run the followiing command to load the schema
to the AD server.
ldifde -i -f aixschemafad.ldf -c "{Forest Root}" "<your windows domain>" -k
|
Replace "<your windows domain>" with your actual domain. In the following example, we
replace it with our test domain of "dc=CIFS2k3,dc=in,dc=ibm,dc=com".
Figure 1. Loading schema
Enabling AD users and groups with AIX LDAP schema
An AD objectclass allows a list of Auxiliary Classes to be specified. Any object
(e.g., a user) of an objectclass type automatically has that objectclass
as well as its auxiliary objectclasses. In other words, to enable AD users with AIX extended schema, all that needs to be done is to add the
AIX aixAuxAccount objectclass to the Auxiliary Classes of the AD's
user objectclass, and add the
AIX aixAuxGroup objectclass to the Auxiliary Classes of the AD's
group objectclass. Once the AD's user and
group objectclasses are updated with the extended AIX objectclasses, all of the AD users and groups are enabled with AIX LDAP
schema automatically, and there is no need to update each user and group object in AD.
AD objectclass modification requires the schema plugin for Microsoft Management
Console (MMC). If you do not have
the schema plugin, you need to install it.
To update the AD user objectclass, start the schema management panel from the MMC
and edit the user objectclass from the property
window. In the relationship tab, click the add Class button, then select the
aixAuxAccount objectclass from the drop-down list
to add it to the Auxiliary classes.
Then edit the group objectclass and add the aixAuxGroup objectclass to its
Auxiliary Classes.
Figure 2 shows the process of adding the AIX aixAuxAccount
objectclass to Auxiliary Classes of the Windows user objectclass.
Figure 2. Adding aixAuxAccount to user
Figure 3 shows the process of adding the AIX aixAuxGroup
objectclass to Auxiliary Classes of the Windows group objectclass
Figure 3. Adding aixAuxGroup to group
Configuring and reconfiguring AIX LDAP
AIX has basic attributes mappings for the AD server that do not cover the AIX extended attributes. To make use of an AD server with
AIX LDAP schema, AIX requires installation of the AD attribute-mapping files with AIX LDAP
schema support. The mapping files, found in the non-IBM_LDAP.zip,
file are:
- sfu30aixuser.map
- sfu30aixgroup.map
- sfur2aixuser.map
- sfur2aixgroup.map
The mksecldap command does not automatically pick the new map file; you must do it
manually after the AIX server is configured as a client to AD. Here are the steps to
configure or reconfigure AIX against a AD server with AIX LDAP schema:
- Download the map files and place the map files in the /etc/security/ldap
directory.
- Configure the AIX LDAP server to use the AD server using mksecldap.
If your AIX system is already configured as a LDAP client to the AD server, skip this step.
# mksecldap -c -h <server> -a <binddn> -p <bindpwd> -A ldap_auth
|
If you prefer unix_auth, omit the "-A ldap_auth" from above.
For unix_auth mode, Windows does not generate the crypt password when an AD user is UNIX-enabled.
As a result, an AD user cannot log in to AIX in unix_auth mode after configuration. You must reset the user's
password from AIX as root. This generates the crypt password in AD. You only need
to reset the password for
the user once from a single AIX system. The change is effective for all other systems.
- Make the following changes in the /etc/security/ldap/ldap.cfg file. If you are
using the SFU schema, find these two lines:
userattrmappath:/etc/security/ldap/sfu30user.map
groupattrmappath:/etc/security/ldap/sfu30group.map
|
and change them to:
userattrmappath:/etc/security/ldap/sfu30aixuser.map
groupattrmappath:/etc/security/ldap/sfu30aixgroup.map
|
if you are using the Windows 2003 R2 schema, find the two lines:
userattrmappath:/etc/security/ldap/sfur2user.map
groupattrmappath:/etc/security/ldap/sfur2group.map |
and change them to:
userattrmappath:/etc/security/ldap/sfur2aixuser.map
groupattrmappath:/etc/security/ldap/sfur2aixgroup.map |
Save the changes.
- Run
restart-secldapclntd
to restart the secldapclntd daemon
to pick up the change:
Setting AIX attributes for existing users
Now you should be able to run the chuser command to set AIX attributes for AD users,
and use the lsuser command to list these AIX attributes. For example:
# chuser -R LDAP nofiles=1500 foo
#
# lsuser -R LDAP -a nofiles foo
foo nofiles=1500
|
After user foo logs in to AIX, run the ulimit command to verify that his file descriptor limit is set to 1500:
$ ulimit -a
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 1500
threads(per process) unlimited
processes(per user) unlimited
|
Creating new AD users and groups from AIX
AIX does not support creating LDAP users and groups from AIX to an AD server, whether
the AD server has the AIX LDAP schema or not.
However, those users and groups created from Windows, when they are UNIX-enabled,
automatically assume the AIX objectclasses (aixAuxAccount and
aixAuxGroup, respectively) and support the AIX attributes.
Download | Description | Name | Size | Download method |
|---|
| Schema and map files for this article | non-IBM_LDAP.zip | 19KB | HTTP |
|---|
Resources Learn
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli, and
WebSphere®.
Discuss
About the authors  | 
| | Tom Lu works as a Software Engineer in the IBM Austin office on the AIX security team. Tom has been involved in software development for over eight years. He specializes in LDAP-related software implementation and is the key architect of LDAP-based user management facility on AIX. Tom is currently playing a key role in implementing some of the AIX security features scheduled for the next major release. You can reach him at ylu@us.ibm.com. |
| 
| | Uma M. Chandolu works as a software engineer on the AIX Development Support Security team in Austin, Texas. He has three years of extensive hands-on experience in AIX environments, and he is one of the focal points in the AIX support security area. He has expertise in AIX system administration and other subsystems and has experience handling customer critical situations. You can reach him at uchandol@in.ibm.com. |
Rate this page
| 
