Overriding UNIX group information
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. For more information, see For more information, see Account Override policies..
Local account migration to Active Directory
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. Safeguard Authentication Services provides several mechanisms to help alleviate this problem.
The Safeguard 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, Safeguard 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, Safeguard Authentication Services provides UID and GID ranges that you can configure in Control Center. The Safeguard 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.
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. For more information about using OAT, see Managing local file permissions.
AIX extended attribute support
The Safeguard Authentication Services LAM module has the ability to service a number of user attributes beyond the standard UNIX identity attributes (UID, GID, Shell, and so on). For example, you can store user-specific ulimit attributes, such as fsize, core, or cpu. There are many other attributes you can service with the Safeguard Authentication Services LAM module.
To store all of these attributes in an LDAP directory, IBM provides a user object schema extension. Safeguard Authentication Services does not require this schema extension to service these extended attributes. Instead, the Safeguard Authentication Services LAM module stores this extended attribute data in a local database. In this way, the Safeguard 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 Safeguard Authentication Services user, as follows:
bash$ chuser fsize=3000000 user1
You can set any number of attributes in this fashion.
After setting the value, you can view it using the lsuser command:
bash$ lsuser user1
user1 id=5000 pgrp=jdgroup home=/home/user1 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 Safeguard Authentication Services LAM module or a read-only value served out of PowerShell.
These are the attributes you can not set through the Safeguard Authentication Services LAM module (chuser).
Table 14: AIX extended attributes
SYSTEM |
account_locked |
auth1 |
auth2 |
gecos |
groups |
groupsids |
home |
id |
pgid |
pgrp |
pwdwarntime |
registry |
shell |
unsuccessful_login_count |
logintimes |
expires |
maxage |
minage |
Use the rmuser command to remove all of the extended attributes from an Safeguard Authentication Services user. The rmuser command usually deletes a user, but when used on an Safeguard Authentication Services user, it only removes attributes stored locally on the AIX server. It never modifies anything in PowerShell.
Notice in the following example that you can still list the user. The only thing missing is the fsize attribute that was just set using chuser.
bash$ rmuser user1
bash$ lsuser user1
user1 id=5000 pgrp=jdgroup home=/home/user1 shell=/bin/bash gecos= registry=VAS
Unix Account Import Wizard
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 the wizard has imported the source data, it 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.