Working with Managed Computers

This chapter explains how to perform common administrative and end-user tasks on managed computers that have the IBM Security Agent installed.

Logging on to Your Computer

You log on to a joined computer in the same way you log on locally. For example, you type a user name and password to start a console session, remote shell session, or a desktop manager. In most cases, you do not have to specify the domain name when you log on. However, you do need to type the Active Directory password for your account and the password must conform to the password policies defined for the domain.

You can use any of the following formats for the user name when you log on:

  • Active Directory samAccountName or Mac OS X short name (jcool)
  • Active Directory userPrincipalName (jcool@acme.com)
  • Windows NTLM format for domain and user name (acme.comjcool)

You can also use any of these formats to locate users in Active Directory.

By default, the IBM Security Agent uses the Active Directory samAccountName attribute or the Mac OS X short name for the UNIX profile user name. You can specify a different form for the UNIX user name by setting the value of the auto.schema.name.format parameter in the /etc/centrifydc/centrifydc.conf configuration file.

Getting Configuration Information

After you log on to a computer, you can use the adinfo command to see information about the Active Directory configuration for the local computer. For example, type adinfo to display a summary similar to the following:

Local host name: QA1  
 Joined to domain: sales.acme.com  
 Joined as: QA1.sales.acme.com  
 Pre-win2K name: QA1  
 Current DC: acme-dc1.sales.acme.com  
 Preferred site: Default-First-Site  
 Zone: Auto Zone  
 Last password set: 2014-04-01 12:01:31 PST  
 CentrifyDCmode: connected  
 Licensed Features: Disabled

For IBM Security Verify Privilege Server Suite Free, licensed features are disabled and the only zone supported is Auto Zone. If you upgrade at a later time, the licensed features will be enabled, and you will be able to use zones to provide secure, granular access control and delegated administration for computers joined to a domain.

Applying Password Policies

The agent enforces all of the password policies you have defined in Active Directory for all valid user accounts in the forest. For example, if your policy requires that new users must change their password the next time they log on, they are prompted to change the password at the next log-on whether they use a Windows or UNIX computer.

The agent also checks passwords to make sure that they conform to Active Directory policies for length and complexity. If a new or changed password meets all of the criteria, the account is updated with the new information in Active Directory and the user logs on successfully.

If you have defined additional policies, such as a maximum duration, reuse policy, failed attempt and account lock out policy, workstation restrictions, and logon hour restrictions, the agent also enforces those policies. Like Windows, the agent displays a warning message each time a user logs on if the user’s password is set to expire in a given number of days.

Changing Passwords

As an administrator, you can set, reset, or change the password for other users using Active Directory or from the UNIX command line. Individual users can also change their own password at any time using the adpasswd command.

Changing Your Own Password

If you attempt to log on but your password has expired, you are prompted to provide your old password, a new password, and to confirm your new password. You can also change your own password at any time using adpasswd.

To change your own password

  1. At the UNIX command line, run the following command:

    adpasswd

  2. Type your old password. When changing your own password, you must always provide your old password.

  3. Type the new password. The password should conform to Active Directory password policies.

  4. Retype the new password.

For more information about using adpasswd, see the adpasswd man page.

Changing Another User’s Password

You can use the adpasswd command to change the password of another Active Directory user if you provide the user name and password of an administrative account with the authority to change another user’s password.

To change the password for another user

  1. At the UNIX command line, run the adpasswd command and specify an Active Directory administrative account name with the authority to change the password for users in the domain. For example, to use the admin user account to change the password for the user jane in the sales.acme.com domain:

    adpasswd --adminuser admin@acme.com jane@sales.acme.com

  2. Type the password for the administrative account. For example:

    Administrator password: xxx

  3. Type the new password for the user specified. Because you are changing another user’s password, you are not prompted for an old password. For example:

    New password:

  4. Retype the new password.

    Repeat password:

For more information about using adpasswd, see the adpasswd man page.

Working in Disconnected Mode

After an Active Directory user logs on to a computer successfully, the authentication is cached on the local computer. These credentials can then be used to authenticate the user in subsequent log on attempts if the user is disconnected from the network or if an Active Directory domain controller is not available.

If there are changes to an account while the account is running in disconnected mode, the changes do not take effect until the user reconnects to Active Directory to start a new session or access a new service. For example, if a user account is disabled or has its password changed in Active Directory while the user is disconnected from the network, the user can still log on and use the old password until reconnected to the network. After the user reconnects to Active Directory, the changes take effect and the user is denied access or prompted to provide an updated password. Because changing the password for an Active Directory account requires a connection to an Active Directory domain controller, users cannot change their own Active Directory password when working in disconnected mode.

If users log out of a session while disconnected from Active Directory, they can be authenticated using the information in the cache when they log back on because they have been successfully authenticated in a previous session. They cannot, however, be authenticated automatically to any additional services after logging back on. To enable automatic authentication for additional services, the user’s credentials must be presented to the Key Distribution Center (KDC) then issued a ticket that can be presented to other services for unprompted, single sign-on authentication. Because the KDC is unavailable when disconnected from Active Directory, single sign-on authentication is also unavailable.

You can configure many aspects of how credentials are handled, including how frequently they are updated or discarded, through parameter settings in the centrifydc.conf configuration file. To configure how credentials are handled using group policies, you must upgrade to a licensed version of IBM Security software.

Mapping Local Accounts to Active Directory

By default, local user accounts are valid on the computers that join the Active Directory domain. In some cases, you may want to manually map a local user account to an Active Directory account instead of using a generated profile. Mapping a local user account to an Active Directory account gives you Active Directory-based control over password policies, such as password length, complexity, and expiration period.

Mac OS X users can always log on using their local account password. Therefore, you cannot enforce Active Directory password policies for local Mac OS X user accounts.

Mapping local accounts to Active Directory is especially useful if you want to preserve access to a user’s current home directory and files. For example, if a local user has a UID of 518 but the IBM Security Agent generates a different UID for the user’s profile, that user will not have file ownership permissions for his home directory and files.

To map a local account to an Active Directory account, you can set the pam.mapuser.username configuration parameter on any individual local computer. To configure account mapping using group policies, you must upgrade to a licensed version of IBM Security software.

Using the pam.mapuser Parameter

To map a local user account to an Active Directory user by modifying the local centrifydc.confconfiguration file:

  1. Create the Active Directory user account to use.

    On your Windows Active Directory computer, open Active Directory Users and Computers (ADUC). Navigate to the Users node, right click and select New > User.

    You should create a user logon name with the same name as the local user.

  2. On the computer with the local account, open the centrifydc.conf configuration file.

  3. Locate the pam.mapuser.username configuration parameter and un-comment the line to change the default setting.

  4. Modify the local account mapping to identify the local user account you want mapped to the Active Directory user you created. For example:

    pam.mapuser.__joe.cool__: __joe.cool__

  5. Save the changes to the configuration file, then run the adreload command to reload the configuration file and have the changes take effect.

Setting a Local Override Account

In most cases, every computer should have at least one account that can be authenticated locally to ensure that you can access the system when the network or Active Directory is not available or adclient is not running. By default, the local override account is set to the root user so that even if you map the root account to an Active Directory account, you can always log on locally using root@localhost and the local root account password.

You can change the default root override account or add additional local users by modifying the computer’s centrifydc.conf configuration file. To configure a local override account using group policies, you must upgrade to a licensed version of IBM Security software.

Using native telnet, ssh, and ftp programs

By default, authorized users can use standard programs and services such as telnet, ssh, and ftp. For telnet and ftp, you can use the packages installed with the operating system. For ssh operations, however, IBM Security recommends that you install the IBM Security-compiled version of OpenSSH instead of using the package provided with the operating system. You can download a free copy of OpenSSH from the IBM Security website.

Using Samba

IBM Security Verify Privilege Server Suite Free supports the adbindproxy package, which contains the components to enable an open-source Samba file server to use the IBM Security Agent and Active Directory to handle identity management and user credentials.

For more information, see the Samba Integration Guide.

Setting Auto Zone Configuration Parameters

IBM Security Verify Privilege Server Suite Free Agents support a set of configuration parameters specifically intended for computers that are connected to a domain through Auto Zone.

Because Auto Zone is a single zone for an entire forest, you can encounter problems such as UID and GID conflicts and slow searches. If you encounter these problems, you may need to modify the default configuration. For information about how to set specific parameters to resolve UID and GID conflicts or improve search performance, see Customizing Operations Using Configuration Parameters.