Chat now with support
Chat with Support

Authentication Services 4.2 - 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
Display specifiers Troubleshooting

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.

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.

Supporting legacy LDAP applications

The Authentication Services daemon, vasproxyd, provides a way for applications that use LDAP bind to authenticate users to Active Directory without using secure LDAP (LDAPS). Instead of sending LDAP traffic directly to Active Directory domain controllers, you can configure applications to send plain text LDAP traffic to vasproxyd by means of the loopback interface. vasproxyd proxies these requests to Active Directory using Kerberos as the security mechanism.

vasproxyd provides the following features:

  • Secure LDAP authentication without SSL

    LDAP is designed as a data access protocol. The use of LDAP as an authentication mechanism introduces important security considerations—especially since most applications are only able to produce simple bind credentials. vasproxyd allows applications to use LDAP simple bind securely by generating the appropriate Kerberos authentication traffic. The use of Kerberos eliminates the need for public key cryptography while providing a high level of security.

  • Authenticated anonymous searches

    Many applications require the use of anonymous LDAP searches. vasproxyd allows you to specify a service account that can authenticate and proxy anonymous queries so that applications that expect to be able to use anonymous LDAP can operate with Active Directory without requiring modification of Active Directory to allow anonymous queries.

  • allow/deny authorization

    vasproxyd allows you to add an additional layer of application authorization based on Active Directory user name, Active Directory group membership, or Active Directory Organizational Unit (OU) containership. In other words, vasproxyd returns an LDAP BindResponse error on an (otherwise valid) LDAP bind attempt if the authenticating user is not authorized by means of settings in the users.allow/ users.deny files.

Related Documents