dropdown menu


Authentication is the verification of a user and his password during the login process. Sometimes it is separated to Identification and Authentication:
- Identification: verification of user and account settings
- Authentication: referred to as password verification

AIX uses 3 important settings related to authentication: "SYSTEM", "registry", "autchontroldomain".

- SYSTEM attribute controls the login authentication path. It is called path, because more methods could be combined to follow each other.
- registry attribute indicates where a user is administered.
- authcontroldomain is a new attribute since AIX 6.1 TL7, and it overrides the  SYSTEM and registry settings stored locally.

The authenticate subroutine is used to verify a user's name and password. The subroutine reads the SYSTEM line from the user's stanza in the /etc/security/user file. Each module that appears in the SYSTEM line must be configured prior in /usr/lib/security/methods.cfg file.

When a user tries to access an AIX system, the "registry" and "SYSTEM" values will be checked in /etc/security/user file to choose a method for authentication. registry will show where user informations are stored, and SYSTEM will show which methods are needed for a successful authentication..



The  user authentication is controlled by the SYSTEM variable.  At login time, the login process checks for the user's SYSTEM attribute in /etc/security/user file to authenticate the user accordingly. For instance, if it is an LDAP user, the AIX administrator has to set the user's SYSTEM attribute to LDAP for the user to login to the local system through an LDAP server. If a user's SYSTEM attribute is not defined, the default SYSTEM value is used.

The well known methods are compat, files and NONE.

- compat: this is the default setting. It tells the system to use the local database for authentication and, if no resolution is found, the NIS database is tried.
- files: it specifies that only local files are to be used during authentication
- NONE: it turns off method authentication. (To turn off all authentication, the NONE token must appear in the SYSTEM and auth1 lines of the user's stanza.)

Other acceptable tokens for the SYSTEM attribute can be defined in /usr/lib/security/methods.cfg.
The root user is always locally authenticated, so SYSTEM = "compat" must be set for root in /etc/security/user.

The SYSTEM attribute can take more values, so more methods can be combined with AND / OR statements for a successful authentication.( It is called authentication grammar. ) For example if SYSTEM="compat" AND "LDAP, it means both authentication is needed to have a successful login.



AIX user management is controlled by the registry attribute, which specifies where the user is administered and where to log user account activity. It determines where the user informations are stored and which user database (registry) to use when managing users. It takes always just 1 value. (SYSTEM can have more values.)

- files: this is the default setting and it shows it is a local user (user information is stored in /etc/security/user)
- other methods can be like LDAP, NIS, KRB5, PAM

These modules need to be defined in the /usr/lib/security/methods.cfg file in order to use them by the "registry" or "SYSTEM" attributes.



There is an alternative method since AIX 6.1 TL7,: "authcontroldomain". If this attribute is set in /etc/security/login.cfg, the "registry" and "SYSTEM" values will be gathered from the the module defined in "authcontroldomain". For instance, authcontroldomain=LDAP forces the system to look for user's SYSTEM and registry from LDAP to determine the authentication method that was used for the user.
(In this case /etc/security/user file will be not checked for these values.)

The authcontroldomain attribute is not valid for local users and it can be configured like this:
chsec -f /etc/security/login.cfg -s usw -a authcontroldomain=LDAP


/usr/lib/security/methods.cfg (/etc/methods.cfg)

/usr/lib/security/methods.cfg is a link to /etc/methods.cfg, and this file contains stanzas of different authentication methods. The SYSTEM and registry attributes can take its value from this configuration file.

The used methods in the file are configured like this:

program = /usr/lib/security/NIS
program_64 = /usr/lib/security/NIS_64

program = /usr/lib/security/LDAP
program_64 = /usr/lib/security/LDAP64

program = /usr/lib/security/KERBEROS
program_64 = /usr/lib/security/KERBEROS64
options = authonly,db=LDAP


For example if a user account exists both locally and in LDAP, AIX requires both the SYSTEM and registry be set to the same value to work correctly. By setting the SYSTEM and registry differently, one will run into the risk that the user is defined to login through one mechanism, but the user's account activity is logged to a different user database.  It may also result in root managing the wrong account when changing password, locking the account, etc. 

A safe way of avoiding such problems is to set the SYSTEM and registry to the same value, e.g.,
# chuser SYSTEM=LDAP registry=LDAP foo

(The command mksecldap sets SYSTEM and registry attributes to LDAP.)

Careful actions are needed, when configuring the default stanza of the /etc/security/user file. One has to remember to add "registry = files" to the root stanza if the default registry is set to LDAP, otherwise root may not be able to login to the system. Although multiple authentication mechanisms can be configured (through the SYSTEM and registry attributes), it is highly recommended that each system only enable one mechanism to simplify user management and to prevent unauthorized access to resources.

Such unauthorized access to resources can happen due to user id "conflict". For example two user accounts defined in two different registries but they "share" the same numeric user id. When a user login to one of the accounts, he will be able to access the files that are really owned by another
user defined in a different registry. An administrator has to take steps to avoid such conflict when enabling a system for multiple authentication mechanisms


No comments:

Post a Comment