Auth Services and Domain Trusts

Hi,

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?

Thanks,

Steve

Parents
  • 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;

    uidNumber
    gidNumber
    gecos
    unixHomeDirectory
    LoginShell

    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 'domainA.com' where our machines are joined and 'domainB.com' being the other domain your entries should look something like this in the vas.conf.

    [vasd]

    cross-forest-domains = domainB.com

    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.

    https://support.quest.com/SolutionDetail.aspx?id=SOL71908

    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.
    https://support.quest.com/SolutionDetail.aspx?id=SOL65747

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

    Leigh Grant

Reply
  • 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;

    uidNumber
    gidNumber
    gecos
    unixHomeDirectory
    LoginShell

    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 'domainA.com' where our machines are joined and 'domainB.com' being the other domain your entries should look something like this in the vas.conf.

    [vasd]

    cross-forest-domains = domainB.com

    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.

    https://support.quest.com/SolutionDetail.aspx?id=SOL71908

    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.
    https://support.quest.com/SolutionDetail.aspx?id=SOL65747

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

    Leigh Grant

Children
No Data