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, refer to the Safeguard 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
- 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.
- 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
- 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 Safeguard 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.
