Chatta subito con l'assistenza
Chat con il supporto

Safeguard Authentication Services 5.1.2 - 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

Working with read-only domain controllers

Read-only domain controllers (RODCs) are a new feature in Microsoft Server 2008. Safeguard 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 Safeguard Authentication Services cannot identify any Unix-enabled users.

Cross-forest authentication

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

In addition, you must configure the cross-forest-domains setting in vas.conf. For details about that, see 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.

One-way trust authentication

You can enable authentication between domains that do not have a two-way trust between them.

To configure a one-way trust

  1. On the UNIX host joined to domain A (TRUSTING.COM) that trusts domain B (TRUSTED.COM), create a service principal in domain B, as follows:

    vastool -u <DomainAdminUserInDomainB> service create ServiceName/@TRUSTED.COM

    where ServiceName is any unique identifier you choose.

    This creates a keytab file containing the value of the krb5name for your service name.

  2. To list the keytab file, enter the following:

    vastool ktutil -k /etc/opt/quest/vas/ServiceName.keytab list

    The results will look something like:

    Vno     Type                 Principal
    1       arcfour-hmac-md5     unixclient-ServiceName@TRUSTED.COM
    1       arcfour-hmac-md5     ServiceName/unixclient.trusting.com@TRUSTED.COM
    					
  3. Create a trust mapping by adding the service principal name to the vas_host_services section of the vas.conf file, as follows:

    [vas_host_services]
    trusted.com = {
    krb5name = ServiceName/hostname.com@trusted.com
    }

Note: You can also use an interactive script to configure a one-way trust. Run the following:

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

This script prompts you for all of the necessary information and creates the one-way trust configuration for you.

Configuring services

You can use vastool service to create and delete service accounts in Active Directory (AD). An AD service account is a user account that services running on UNIX hosts use.

When you create a service account, a random password is generated for the account and a Kerberos keytab is created for the service.

vastool [vastool options] service create [-c container] [-k keytab] [-A] [-U] {name} [spn...]
vastool [vastool options] service delete [-k keytab] {name}
vastool [vastool options] service list {name}

Each service account has a Service Principal Name (SPN), an optional set of additional Service Principal Names (SPNs), and an optional User Principal Name (UPN).

The SPN is typically service/host@domain, where service matches the type of service running, for example, HTTP/ or FTP/.

The keytab file created for the service is named service.keytab and it is created in the Safeguard Authentication Services configuration directory at /etc/opt/quest/vas. The default permissions on the keytab file is 0600 and root owns the file. To give permission to the corresponding service to read the keytab file, update the ownership of the file.

Creating a service account

To create a service account, you must run vastool service create <name-of-your-service-account> as root. For example, to create the sql service account, run:

vastool -u admin service create sql/

By default, the service account is created in the container of the default computer. To override the location where the service account is created, use the -c option to specify an alternate Organizational Unit (OU).

The name of the service account is generated automatically based on the names of the host and the service. To specify the name of the service account, use the -n option.

If you specify service/ as the Principal Name, the hostname of the machine vastool runs on is used to build a complete Service Principal Name.

You must supply the username and password of an AD user that has permissions to create users. You can also add an optional list of other Service Principal Names to the account.

NOTE: The other Service Principal Names define aliases for the ticket name that can be requested for the service, but they cannot be used as a client name to authenticate as the service itself.

To disable the use of AES encryption in Kerberos tickets for the service, use the -A option.

To suppress the setting of the UPN attribute, use the -U option.

NOTE: Not setting the UPN attribute is useful for accounts made in or migrated to Azure AD where the UPN attribute must be in the Internet-style sign-in format (for example, user@contoso.com) and not in service/host@domain format.

Deleting a service account

To delete a service account, run vastool service delete <name-of-your-service-account>. For example, to delete the sql service account, run:

vastool -u admin service delete sql/

Both the account in AD and the keytab file for the service are deleted.

To list the service principals associated with a service account, run vastool service list service. For example, to list the principals associated with the sql service account, run:

vastool -u admin service list sql/
Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione