[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

System Management Guide: Operating System and Devices

Administering Loadable Authentication Modules

Loadable authentication modules allow the system administrator to extend the Identification and Authentication functions of the system. The standard administrative commands, such as mkuser and chuser, may be used to administer user information for these loadable authentication modules as though the users were locally defined. Some loadable authentication modules, such as the DCE module, may only support a limited number of operations, such as logging in, changing user identity or executing remote commands. Others, such as the LDAP module, support the full range of functions provided by the local user databases.

Loadable authentication modules are defined in the /usr/lib/security/methods.cfg file. Each stanza within that file defines a method which may be used by the administrator to create, delete, modify and view a user or group account. Once the accounts have been established, they may be used in the same manner as local accounts defined in the /etc/passwd and the /etc/group files.

Note: Loadable authentication modules may not support all operations. Please refer to the documentation for each module to determine which operations are supported.

Administrative commands support a -R module option which may be used to specify the desired module. Module is the name of a stanza given in the /usr/lib/security/methods.cfg file. When an account is created a module name may be given to specify where the account is created. This module name will be used for all administrative operations performed on the account. Accounts which are unique do not require the use of the -R flag once the account has been created. The command will determine the name of the module for the account and automatically use that module for the operation.

User and group accounts which reside in a loadable authentication module can be administered by Web-based System Manager. The lsuser and lsgroup commands support discovering the name of all accounts provided that the loadable authentication module is capable of producing a list of all known users or groups. Please refer to the documentation for each module to determine if this functionality is provided.

Managing Loadable Authentication Modules

Loadable authentication modules may be either a single loadable module, known as a simple load module, or a pair of loadable modules combined to form a compound load module. Compound load modules combine the data storage functions of one module with the authentication functions of another module.

Simple Load Modules

A simple load module is defined by a single stanza in the methods.cfg file. The stanza defines the name that is used by the administrative commands and the SYSTEM and registry attributes in the /etc/security/user file. The program attribute specifies the location of the loadable module. The program_64 attribute is used for the 64-bit environment.

This example shows the configuration of the LDAP simple loadable authentication module:


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

Compound Load Modules

A compound load module is defined by two or three stanzas in the methods.cfg file. A compound load module is formed when functions from a data storage and retrieval module are combined with functions from an authentication module. Each module can be defined separately and a third stanza can be defined to combine the two.

These examples show how the LDAP module can be combined with the AFS authentication module to provide AFS authentication for LDAP users. The following example adds AFS authentication to the LDAP module.


    program = /usr/lib/security/AFS
    options = authonly
    program = /usr/lib/security/LDAP
    program_64 = /usr/lib/security/LDAP64
    options = auth=AFS

This example shows how the LDAP and AFS modules may be defined separately, then combined in the third stanza to provide the same function as the previous example. This method is used when users are defined in a single database, but are configured to authenticate with more than one authentication mechanism.


    program = /usr/lib/security/AFS
    options = authonly
    program = /usr/lib/security/LDAP
    program_64 = /usr/lib/security/LDAP64
    options = auth=AFS,db=LDAP

Note: User and group accounts may appear to be defined in more than one location if a data storage and retrieval module is used by more than one stanza. To avoid confusion, use the auth= option to change a module's authentication method. If different user's within the module use different authentication methods, consider using the SYSTEM attribute instead of a compound load module.

A module which is referenced by another stanza must have been defined prior to the reference. A stanza which references a stanza which has not yet been defined will be ignored.

A stanza which appears as the target of a db= or auth= option will be excluded from the list of loadable modules to use when a command does not request a specific module. A stanza may be referenced in than one compound module stanza. This may result in accounts appearing to be defined in more than one module.


Each module provides its own security policy for administering user and group accounts. The module may grant administrative privileges to the root user, or it may require that the user acquire privilege in some other manner. Please refer to the documentation for the loadable authentication module for more details.

User and Group Management

Each loadable module defines a set of users and groups. The user and group definitions must be completely self-contained by the loadable module. Group accounts which are referenced by a user account must be defined within the same loadable module. User accounts which are members of group accounts must be defined there as well.

Privileges and access rights are granted based on a process's effective user and group identifier, not the name of the user or group. When multiple methods define the same user or group name the numerical identifier must be the same in all methods.

Creating User and Group Accounts

The same tools used for creating local user and group accounts are used to create user and group accounts. The default module name is stored in the /usr/lib/security/mkuser.default file in the registry attribute. The mkuser and mkgroup commands examine this attribute and, if present, use that module name to create the new account. The web-based system administration tools support account creation in loadable modules using the same mechanism. The default module name may be overriden with the -R flag to both commands. The web-based system administration tools do not support the -R flag and will only create accounts in the default registry.

Viewing User and Group Account Definitions

The lsuser and lsgroup commands display user and group account information. The commands search all available loadable modules for the account and report the information from the first module where the account is stored. A specific module may be requested with the -R flag.

A loadable authentication module may optionally support providing the names of all defined accounts. This is used by the commands when ALL is specified as the account name. This operation may take a considerable amount of time to complete as all account definitions are examined.

All modules provide some amount of support for viewing account information. A module is not required to support all user or group attributes. For a user account the minimum requirement is user name, password, user ID, primary group ID, full name, login directory and login shell. For a group account the minimum requirement is group name, group ID and group membership list.

Managing User and Group Accounts

User and group accounts are managed with a variety of commands. The procedures described in Chapter 4, Users and Groups apply to loadable authentication modules as well. The commands accept an optional -R flag which is used to indicate where the account is defined. If the -R flag is not provided the command will query the registry attribute for the account then use that module for the operation.

Some modules do not support requests to modify account information. Commands which attempt to modify account information will report an error when an attribute is modified. Modules which do not support integrated account management must provide their own tools for administering accounts.

Removing User and Group Accounts

User and group accounts are removed with the rmuser and rmgroup commands. Load modules are not required to support this function. Attempting to remove an account from a loadable authentication module which does not provide this function will result in an error message.

Compound load modules remove an account from both modules when a request is made to remove an account. To remove the account from only one module you must use the -R flag to name the module with the account to be removed.

Related Information

The chuser, lsgroup, lsuser, mkuser, rmgroup, and rmuser commands.

Chapter 4, Users and Groups

[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]