Auth Services and Domain Trusts


Looking for some help and advice.

I have a Active Directory that I administer and can install Auth Services into. Within this AD I have some admin users that need access to Redhat machines, all no problem with Auth Services. However, my question is this.

If the AD at the other end of the Trust has users that I need to "Unix Enable", so they can also access the RedHat machines using their AD accounts, is that possible?

Note - the other AD is managed by another company and I have no possibility of getting anything installed or changed other than a trust established.

Can anyone help/suggest if this is possible?



  • Hi Steve,

    Could you elaborate on the nature of the trust that you will have established between the two domains? If it's a two-way trust that will simplify things for you where a one-way trust requires more steps. The inability to put or install anything in the other domain might be a large hurdle however.

    I will elaborate on a two-way trust first then a one-way trust. This all assumes you are using 4.0.3 as a minimum version as well.

    With a two way trust we still recommend installing our windows tools in the other domain as it simplifies things for you including unix-enabling users and perhaps groups as well. It will also help establish what Schema will be used in the other domain. If the domain level is 2003 R2 and above we should simply be using that schema. Which consists of;


    Even without our tools however populating these values correctly is what is required to Unix Enable a user.

    So at this point, assuming a two-way trust and a properly 'unix-enabled' user you will need some extra configuration on the Unix/Linux machines. This can be done manually or via group policy.

    The settings that will be required are "cross-forest-domains" and "user-search-path". If any groups will be used you should also configure "group-search-path'. Assuming our two domains are called '' where our machines are joined and '' being the other domain your entries should look something like this in the vas.conf.


    cross-forest-domains =

    user-search-path = DC=domainA,dc=com;DC=domainB,dc=com

    group-search-path = DC=domainA,dc=com;DC=domainB,dc=com

    At this point we should be caching users in the other domain and they should be able to authenticate normally. We do recommend installing our Control Center in the other domain somewhere and configuring the Quest Authentication Configuration or Q.A.C. which as you stated sounds difficult or impossible. I am including an article on the next line that details what this Q.A.C. is and what it is for. The Q.A.C. can be created using a vastool command as an alternative.

    That basically covers a two-way trust scenario, if this trust you are setting up is a one-way trust then things are more difficult. In order to search for, cache and enable authentication we need a service account in the other domain with an associated keytab. Without this we will not be able to look up users in the other domain nor authenticate them. I'm not sure either how many machines you are looking at but we typically recommend one service account for each machine involved in this scenario. It simply provides more tolerance, a single shared service account becomes a single point of failure for multiple machines.

    This article has more details one-way trust setups.

    That's a really broad overview of both scenarios which might raise more questions than I've answered.

    Leigh Grant

  • Hi Leigh,

    Thanks so much for the detailed answer. It has certainly helped me understand further. As you suspected, it has generated a few questions:

    * I've queried with the other AD admin if those properties could be set manually and if so, I'm assuming the Quest software will tell us what to populate into those field for each user. Is that correct? The ID fields I'm uncertain of as we'd need to ensure there was no clash.

    * A two way/one way trust is still to be confirmed. I suspect it'll be a one-way so that we trust them, but they don't trust us.

    Out of interest you mention caching of credentials, can that be disabled?



  • Hi Steve,

    * If you are using our tools, which again we strongly recommend when you check that 'Unix Enable' box we will populate a number of defaults within those fields and ensure the UID Number chosen is unique. For example the default for loginShell is usually '/bin/sh' and the home directory is '/home/<username>'.

    * If a one-way trust is setup you will need to configure each machine with a keytab which should be explained in some of the information I sent previously I believe.

    * Concerning caching, we don't actually cache credentials themselves for all users. We cache information about those users, the uidnumber's, gidnumber's, group memberships, stuff like that. This is for efficiency, so that if a user gets asked about we can get that information locally instead of going back to AD in order to minimize traffic.

    When a user log's in however we do establish a disconnected credential cache so that if the server was to become disconnected from the network or the AD servers were unavailable they could still login. This feature however can be turned off on a server using a setting in '/etc/opt/quest/vas/vas.conf'. I will include the man page entry below.

           allow-disconnected-auth = <true | false>
              Default value: true

              To globally disallow disconnected authentication set this option to
              false. This may be useful for high security installations that
              should never allow disconnected authentication. By default,
              disconnected authentication is supported by all the QAS
              authentication modules.

              NOTE: This only applies to regular disconnected authentication.
              Persistent disconnected authentication will continue to work if
              configured. To disable that unconfigure perm-disconnected-users.

              The following is an example of how to globally turn off disconnected

               allow-disconnected-auth = false

    Thank you,
    Leigh Grant