You can override group account attributes on the local Unix host. This allows you to use the group information from Active Directory but modify individual attributes on certain hosts as needed. Group overrides are specified in the /etc/opt/quest/vas/group-override configuration file. Overrides are specified as follows:
DOMAIN\sAMAccountName:<Group Name>:<GID Number>:<Group Membership>
DOMAIN\sAMAccountName must refer to a valid Active Directory group account. You can omit any of the Unix account fields. If a field is not specified it will get the default value for that group. The group membership field consists of a comma-separated list of Active Directory user accounts specified in DOMAIN\sAMAccountName format. For examples, refer to the /etc/opt/quest/vas/group-override.sample file.
You can manage group overrides using Group Policy. (See Account override policies for more information.)
On Unix, a user or group is identified by a 32-bit ID number. This is usually sufficient for individual Unix hosts or NIS environments. As more and more Unix hosts are brought into the Active Directory domain, the possibility for conflicting user and group IDs increases. Ideally, each Unix-enabled Active Directory user or group is assigned a unique ID number and this ID is used across all Unix hosts. In practice, this is difficult to achieve because Unix hosts are often managed independently and user accounts are populated organically which leads to many conflicting or duplicated accounts. Authentication Services provides several mechanisms to help alleviate this problem.
The Authentication Services MMC snapin provides a Unix Account tab for users and groups. The Unix Account dialog checks UID and GID numbers against the Global Catalog to ensure the value is unique in the forest. In addition, Authentication Services has updated the default method used to generate unique UID and GID numbers. The generated values are based on a hash of the object GUID of the account. This results in a unique number with the added benefit that the same object always generates the same number.
To avoid conflicting with existing local accounts, Authentication Services provides UID and GID ranges that you can configure in Control Center. The Authentication Services management tools do not allow you to set the UID or GID on an Active Directory object to a value that is outside of the configured range.
Using Management Console for Unix, you can gather all of the disparate local account information into one console to consolidate and map local users to the appropriate Active Directory account without disrupting normal operation of the Unix hosts.
Once you have mapped all of the local accounts to Unix-enabled Active Directory users, you can use the Ownership Alignment Tool (OAT) to take the final step of adjusting local file permissions and eliminating the local user (and group) accounts. (See Managing local file permissions for more information about using OAT.)
The Authentication Services LAM module has the ability to service a number of user attributes beyond the standard Unix identity attributes (UID, GID, Shell,etc). For example, you can store user-specific ulimit attributes, such as fsize, core, cpu, and so forth. There many other attributes you can service with the Authentication Services LAM module.
To store all of these attributes in an LDAP directory, IBM provides a user object schema extension. Authentication Services does not require this schema extension to service these extended attributes. Instead, the Authentication Services LAM module stores this extended attribute data in a local database. In this way the Authentication Services module is a hybrid module; it serves core identity information (UID) from Active Directory, while storing and serving these extended user attributes locally. Since extended attributes are stored locally on each AIX server, you must make extended attribute changes for user accounts on every AIX server.
Use the chuser command to set an extended attribute on a Authentication Services user, as follows:
bash$ chuser fsize=3000000 jdoe
You can set any number of attributes in this fashion.
After setting the value, you can view it using the lsuser command:
bash$ lsuser jdoe jdoe id=5000 pgrp=jdgroup home=/home/jdoe shell=/bin/bash gecos= registry=VAS fsize=3000000
You can set a large number of attributes this way, however you can not set attributes that have either a static value returned by the Authentication Services LAM module or a read-only value served out of Active Directory.
These are the attributes you can not set through the Authentication Services LAM module (chuser):
Use the rmuser command to remove all of the extended attributes from a Authentication Services user. The rmuser command usually deletes a user, but when used on a Authentication Services user, it only removes attributes stored locally on the AIX server. It never modifies anything in Active Directory.
bash$ rmuser jdoe bash$ lsuser jdoe jdoe id=5000 pgrp=jdgroup home=/home/jdoe shell=/bin/bash gecos= registry=VAS
Notice in the above example that you can still list the user. The only thing missing is the fsize attribute that was just set using chuser.
The Unix Account Import Wizard is a versatile tool that helps migrate Unix account information to Active Directory. It is especially well suited to small, one-shot import tasks such as importing all the local user accounts from a specific Unix host. The Unix Account Import Wizard can import Unix data as new user and group objects or use the data to Unix-enable existing users and groups. In Unix Personality Mode, you can use account information to create and link personality objects.
The Unix Account Import Wizard provides several different ways to import Unix account data into Active Directory. You can import Unix account information from various sources such as local files, remote Unix hosts and NIS servers. Once it has imported the source data, the wizard uses customizable rules to match the source accounts with existing accounts in Active Directory or uses the information to create new accounts in Active Directory.