Chat now with support
Chat with Support

Safeguard Authentication Services 4.1.5 - Administration Guide

One Identity Privileged Access Suite for Unix Introducing One Identity Authentication Services Unix administration and configuration Identity management Migrating from NIS Managing access control Managing local file permissions Certificate Autoenrollment Integrating with other applications Managing Unix hosts with Group Policy
Authentication Services Group Policy
Group Policy Concepts Unix policies One Identity policies
Integrating with GPMC
Display specifiers Troubleshooting

Blackout period

It is not uncommon for systems to generate hundreds of user and group lookup requests per second. Because of this, Authentication Services enforces a "blackout period" during which all name service requests are resolved from the local cache. By default, the blackout period is set to 10 minutes. This means that changes to Unix account information in Active Directory may take up to 10 minutes to propagate to Authentication Services clients.

There are two events that cause Authentication Services to update the local cache:

  1. A user logs in
  2. The blackout period expires

You can adjust the blackout period by changing the update-interval setting in the [vasd] section of vas.conf. For an example, refer to the vas.conf man page. (See Using Authentication Services manual pages (man pages) for information about accessing the vas.conf man page.) In small installations (less than 100 hosts or less than 100 users) you can safely reduce the blackout period. In larger installations it is recommended that the blackout period remain at the default value or set to 30 minutes or 1 hour.

Regardless of the blackout period, you can reset the blackout period timer by signaling vasd with SIGHUP, using the vasd init script to restart vasd, or by executing vastool flush.

To force Authentication Services to update the cache immediately regardless of the blackout period, run this command:

vastool flush -f {users|groups}

Disconnected authentication

Authentication Services provides the ability to authenticate an Active Directory user to a Unix system even when Active Directory is unavailable. For example, because Authentication Services supports disconnected authentication, you can still log into your laptop when you are traveling and your laptop does not have connectivity to Active Directory.

Authentication Services supports several options for disconnected authentication. Two types of disconnected authentication modes are the default disconnected authentication mode and permanent-disconnected authentication mode.

Default Disconnected Authentication Mode

By default, Authentication Services relies on a previous successful authentication attempt when the computer was not in disconnected mode. The successful authentication caches a sha256 hash of the user’s password. Authentication Services uses this hash to validate the user’s password when it is in disconnected mode for one of the following reasons:

  • The computer is physically disconnected from the network or the network is down.
  • The computer object has been deleted.

    Note: If the host's computer object has been deleted then Authentication Services can no longer authenticate with Active Directory. The solution to this problem is to recreate the computer object, then restart vasd.

  • The host keytab file (/etc/opt/quest/vas/host.keytab) is missing or invalid.

    Note: If the host keytab is deleted or becomes corrupt then Authentication Services can no longer authenticate with Active Directory. The solution to this problem is to delete then recreate the computer object and restart vasd.

  • The Active Directory server is down or object unreachable.

You can disable the default disconnected authentication mode by setting allow-disconnected-auth to false in the vas.conf (see the vas.conf man page for more details).

Permanent-Disconnected Authentication Mode

There are situations where a Unix system administrator may be responsible for a large number of Unix systems. In the default mode, you need to log into every Unix system at least once to be able to log into the systems in a disconnected state. In a large environment with hundreds or thousands of Unix systems this requirement would be impractical. Authentication Services has added a feature called Permanent-Disconnected Authentication Mode. This mode does not require a previously successful authentication, that is, users or group of users can log into a Unix system in a disconnected state even if they had never logged into the Unix system in the past.

Before you configure Permanent-Disconnected Authentication mode in the vas.conf file, you must first set the service principal name (SPN) for each user who will authenticate using this mode. You can set the SPN by using a tool like the Microsoft Active Directory® Service Interfaces Editor (ADSI Edit), or by issuing a vastool command such as the following:

vastool <username> setattrs - u <username> servicePrincipalName "user/<username>@<DomainName>"

Note: The content of the service principal name is unimportant; it just needs to conform to the format of servicePrincipalName.

Configure the Permanent-Disconnected Authentication mode in addition to the default disconnected authentication mode on a per user/group basis by specifying perm-disconnected-users in the vas.conf (see the vas.conf man page for more details). These perm-disconnected-users have encrypted credentials pre-cached when the Authentication Services caching daemon starts the first time (immediately upon join if the users are configured as perm-disconnected-users by means of group policy). Typically you configure permanent-disconnected authentication mode to ensure that a certain group of system administrators can access a system even if the first time they attempt access, it is disconnected from the network.

Authentication Services continues to operate normally in disconnected mode, thus it may be difficult to know whether Authentication Services is in disconnected mode. Authentication Services creates log entries in the system log each time the connection mode changes.

Working with read-only domain controllers

Read-only Domain Controllers (RODCs) are a new feature in Microsoft Server 2008. Authentication Services supports read-only domain controllers as long as the Unix attributes for users and groups are not in the RODC filtered attribute set. You can set the RODC_FILTERED flag on any attribute in the Active Directory schema to add it to the RODC-filtered attribute set. If this flag is set on an attribute, it is not replicated to an RODC. If RODC_FILTERED is set on the attributes used for UID Number, GID Number, Comment (GECOS), Home Directory or Login Shell, no groups or users are cached because Authentication Services cannot identify any Unix-enabled users.

Cross-forest authentication

Authentication Services supports cross-forest authentication as long as a trust exists between the two forests. You must configure both forests for Authentication Services. (For more information, refer to the Authentication Services Installation Guide.)

In addition, you must configure the cross-forest-domains setting in vas.conf. (For details about that, see to the vas.conf man page.)

Note: When using Unix Personality Management in a cross-forest environment, the user or group to which a personality links must be in the same forest as the personality.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating