Does QAS support oneway trusts? How do I setup a oneway trust using QAS?
In a two-way trust situation, the host/ principal from the one domain is trusted in the other and can perform the search for Unix information. In a one-way trust situation, the host from the trusting domain is not trusted by the trusted domain and additional setup is required for QAS to be able to access the Unix attributes.
Yes, oneway and noway trusts are supported. With these setups more configuration needs to be done.
The simplest way to setup a one way trust is to use the vas_oneway_setup.sh script located in /sample_scripts directory or in QAS 4.x in /opt/quest/libexec/vas/scripts directory
This can script prompt you for all of the necessary information and creates the one-way trust configuration for you or you can use options and supply data on the command line.
To see options run the command:
The script requires the following information:
• The principal name with rights to create a service principal in the trusted domain (-u option)
• LDAP DN of the container where the service principal object will be created (-c option)
• Path of the keytab (-k option) - please specify keytab filename
• The name of the service principal in the form of /@(-s option)
• (Optional) Whether this principal should be used to authenticate users from the trusted domain. The default is the host/ principal from the trusting (joined) domain.
This script can be invoked with or without arguments which will specify this information. If this information was not provided, the script will prompt for the information.
The script is a wrapper around the following operations:
• Create the service in the trusted domain (and the keytab)
• Modify the vas.conf [vas_host_services] section
• Restart vasd
Here is the syntax of the command with options specified:
# sh vas_oneway_setup.sh -u -c “” -k /etc/opt/quest/vas/oneway.keytab –s email@example.com
Replace < > with relevant data
Here is an example of the command:
# sh vas_oneway_setup.sh -u administrator -c “OU=OUNAME,DC=example, DC=COM” -k /etc/opt/quest/vas/oneway.keytab –s firstname.lastname@example.org.
This setup can also be done without using the script. Refer to Quest Solution 97961
After configuring the oneway trust, users/groups will not automatically be cached at vastool flush time. For more information on setting the search-paths refer to Quest Solution 74895
Does each machine need a service account in the trusted domain or can the same one be used on all machines?
Either, you can use one keytab for all machines or every machine has their own specific one. It is easier to manage, if using one keytab, but also a single point of failure. Ensure the password on the account is never reset.
What ports are required to be opened from QAS to the trusted domain?
QAS requires the standard ports to be opened to the trusted domain. For more information on port usage refer to Quest solution 13608
For more information please download the "AuthenticationServices_4.1_TrustGuide" below.
You can view the Trust type in Active Directory:
1. Start the Active Directory Domains and Trusts tool. The tool automatically locates a domain controller to read trust relationship data from.
2. An icon is displayed for each domain that represents the root of each item in the hierarchy. Expanding any of these nodes displays the hierarchy of child domains, if any exist. To view the trust relationships for a specific domain, right-click the domain, and then click Properties.
3. Click the Trusts tab. For each of the domains that the selected domain trusts (trusted), or is trusted by (trusting), the type of trust relationship and whether or not the trust relationship is transitive is displayed. Trusts can also be added or removed through the same interface. To view detail information or reset a transitive trust relationship, click the trust you want, and then click View/Edit.In short, The command creates a service account ( user object with servicePrincipalName set ) in the trusted forest. Then vasd uses that service principal (service account) to do ldap queries against the trusted domain so it can obtain unix information. The actual authentication works as kerberos cross realm normally works. Since it is trusted the user is able to get a cross realm Ticket Granting Ticket for the joined domain, then a Ticket Granting Service for the host/ account.