지금 지원 담당자와 채팅
지원 담당자와 채팅

Safeguard Authentication Services 6.0.1 - Administration Guide

Privileged Access Suite for UNIX Introducing One Identity Safeguard 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
Safeguard Authentication Services Group Policy
Group Policy Concepts UNIX policies One Identity policies
Display specifiers Troubleshooting Glossary

Maintaining netgroup data

The vasd daemon maintains the netgroup cache data regardless of whether netgroup data is resolved through the name service module or through NIS (vasyp).

You can configure netgroup-mode in the vas.conf file. For more information, see the vas.conf man page.

Automount support

Safeguard Authentication Services provides automount maps from Active Directory (AD).

Automount maps can be imported from NIS into Active Directory with the RFC 2307 NIS Map Import Wizard. The imported automount maps are represented using the generic map classes provided in RFC 2307: nisMap and nisObject.

You can configure automount support in the vas.conf file on the client machine with the following variables:

  • automount-mode: Enables or disables the caching of automount data.

  • automount-search-base: Specifies the search base for automount data in AD.

  • automount-update-interval: Enables or disables automatic updates to the automount cache. Setting the value to 0 disables automatic update.

TIP: For more information about the available automount configuration variables, see the vas.conf man page.

To enable automount support before joining Active Directory

  1. Create a vas.conf configuration file.

  2. Set the automount-mode variable to true.

  3. Enter the Organizational Unit under which the automount maps were imported into the automount-search-base variable.

  4. Join AD.

NOTE: If the variables are included in the vas.conf file before the machine is joined, the automount data will be cached on the client machine during join.

Example: Enabling automount before joining AD
# /opt/quest/bin/vastool configure vas vasd automount-mode true
				
# /opt/quest/bin/vastool configure vas vasd automount-search-base ou=nis,dc=example,dc=com
				
# /opt/quest/bin/vastool -u admin -w password join –fw example.com

To enable automount support if the client is already joined

  1. Set the automount-mode variable to true.

  2. Enter the Organizational Unit under which the automount maps were imported into the automount-search-base variable.

  3. To apply the changes, run the vastool flush automount command.

Example: Enabling automount support if a client is already joined
# /opt/quest/bin/vastool configure vas vasd automount-mode true 

# /opt/quest/bin/vastool configure vas vasd automount-search-base ou=nis,dc=example,dc=com 

# /opt/quest/bin/vastool flush automount

All automount data is obtained and cached by vasd. vasd searches for nisObjects whose nisMapName attribute begins with the string "auto", and retrieves the nisMapName, cn, and nisMapEntry attributes of the objects found.

You can use the following vastool search command example to see what will be included in the automount cache:

# /opt/quest/bin/vastool -u admin -w password search 
-b "ou=nis,dc=example,dc=com" "(&(objectCategory=nisObject)(nisMapName=auto*))" nisMapName cn nisMapEntry

The nisMapName attribute contains the name of the file into which the values of the cn and nisMapEntry attributes are written. vasd always takes the /etc directory as the location of these files. If such a file does not exist there, vasd creates it. However, if a file exists with this name, vasd enters the changes at the beginning of the file, not at the end. If the same mount point is used in two different entries, vasd overwrites the already existing mount point. Therefore, the first entry is used by the automount command, and the second entry is ignored.

After writing the data obtained from AD to the /etc/auto* files, vasd runs the following script:

/opt/quest/libexec/vas/scripts/vas_automount.sh

The purpose of the script is to have the new information used by the autofs processes. The script contains a suitable command for all platforms and can be modified or supplemented, if required.

To disable automount support

  1. Set the automount-mode variable to false:

    # /opt/quest/bin/vastool configure vas vasd automount-mode false

    NOTE: You can also delete the automount-mode variable.

  2. Run vastool flush automount:

    # /opt/quest/bin/vastool flush automount

Automount support is automatically disabled, (that is, the entries written into the /etc/auto* files are removed) if the client is unjoined or if Safeguard Authentication Services is uninstalled. If the file contained only entries written by Safeguard Authentication Services, it is removed.

NOTE: Only vasd and vastool participate in the operation of the automount function, vasypd does not.

Managing access control

Safeguard Authentication Services extends the native access control capabilities of Active Directory to non-Windows systems, providing centralized access control. Safeguard Authentication Services allows non-Windows systems to become full citizens in Active Directory. Once you have joined your UNIX, Linux, and macOS systems to the Active Directory domain, you can easily control which Active Directory users are permitted to authenticate to your non-Windows systems.

Safeguard Authentication Services includes the industry’s largest collection of highly flexible access control options and integrates with your existing technology. This section discusses each of these options in detail:

  • Host access control

  • Access control using the "Logon To" functionality

  • Configuring local file-based access control

  • Access control based on service (PAM only)

About host access control

Administrators commonly want to restrict access to sensitive machines on the network to selected users and groups. This is especially true of UNIX machines which are used to host business critical applications.

It is possible to have fine-grained control over which Active Directory users can log in using Safeguard Authentication Services.

NOTE: Computer access control functionality does not work with local user accounts; it only works with Active Directory user accounts.

By default, each time a user successfully authenticates, the Safeguard Authentication Services authentication module checks to see if it should allow access using one of two methods: file-based access control or policy-based access control.

File-based access control involves checking access control rules stored locally on each workstation in /etc/opt/quest/vas/users.allow and /etc/opt/quest/vas/users.deny. (You can change the default location for these files with the users-allow-file and the users-deny-file options in vas.conf.)

Policy-based access control involves using Safeguard Authentication Services Group Policy, which allows you to apply the following native Windows access policies under the User Rights Assignments settings in the Windows Security Policy:

  • Access this computer from the network

  • Deny access to this computer from the network

  • Allow Log on Locally

  • Deny Log on Locally

To enable application of Windows access control policies, add the option ApplyWindowsHostAccess = true under the [policy] section of the /etc/opt/quest/vgp/vgp.conf file.

NOTE: The four native Windows access policies listed above are the only native Windows group policy settings that Safeguard Authentication Services Group Policy applies and Safeguard Authentication Services enforces on the client. All other native Windows policy settings are applied by Windows to the server which then enforces the policy on itself.

Safeguard Authentication Services always performs access control by checking local files unless you explicitly enable application of Windows access control policies on UNIX hosts. If the ApplyWindowsHostAccess option is set to true in the vgp.conf file, Safeguard Authentication Services ignores local file-based access control. This means listing a user in the /etc/opt/quest/vas/users.allow or /etc/opt/quest/vas/users.deny file has no effect.

You can centrally manage both methods of access control through Active Directory using Safeguard Authentication Services Group Policy. For more information, see For more information, see Managing UNIX hosts with Group Policy..

Regardless of the method you choose for managing access, locking down a machine does not require you to deny everyone access explicitly. If you define only an "allow access" policy (that is, use only a users.allow file), only users granted access through that file have access. This simplifies the process significantly.

Both access control methods allow you to specify users or groups that you want to allow or deny. If a user is specified in more than one way, the most specific reference to the user takes precedence.

For example, suppose Bob is a member of the Domain Admins group. If the Domain Admins group is allowed access to a machine, but Bob is explicitly denied, he will NOT be granted access. For additional information about the System Access Rules, see the table in Resolving conflicts between the allow and deny files.

Safeguard Authentication Services honors the Logon To workstation list (on the Account tab in the ADUC snap-in) as an additional security measure in both access control modes.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택