skip to main content

Authentication & Authorization Services

AD DS NetID authN Domain

Frequently Asked Questions


  1. What is the authentication domain?
  2. What type of trust will this be?
  3. How are passwords handled in this security model?
  4. What is your intended audience? Who can sign up for this trust?
  5. What are the requirements to setup and use a trust to this domain?
  6. What changes do I have to make with security groups within my Active Directory domain after setting up the trust?
  7. What changes do I have to make with group policy?
  8. What other changes must be made within my Active Directory environment?
  9. What access will I have to the authentication domain as an administrator?
  10. How will I administer security in my domain once the trust is established?

Q: What is the authentication domain?
A: Infrastructure Services has designed an Active Directory-driven authentication domain that will contain a mirror of the NetID credentials found in the campus Kerberos database. Active Directory customers across campus can then request a secure trust to this domain and enjoy the benefits of using the NetID credential in their own domains.


Q: What type of trust will this be?
A: From the perspective of the authentication domain, the trust will be a one-way, incoming forest (transitive) trust. From the perspective of your forest or domain, the trust will be one-way outgoing.


Q: How are passwords handled in this security model?
A: NetID password changes are securely synchronized between Kerberos and Active Directory via an encrypted channel. Password management is performed through the standard NetID password management application at http://gateway.tamu.edu.


Q: What is your intended audience? Who can sign up for this trust?
A: Any Texas A&M University business unit (department, college, division, etc.) with an Active Directory domain can request a trust to the authentication domain. The trust must be registered with CIS Infrastructure, and a point of contact identified and kept up to date.


Q: What are the requirements to setup and use a trust to this domain?
A: The authentication domain was built on a Windows 2008 R2 Active Directory domain running at the 2008 R2 domain and forest functional levels. It has not been tested with Windows 2003 or Windows 2003 R2. Prior to setting up the trust, you will need to register the following SRV and A records in campus DNS for each domain controller you want to participate in the trust:

Type: SRV
Record: _ldap._tcp.dc._msdcs.yourDomain
Host: dcDomain
Port: 389

Type: SRV
Record: _ldaps._tcp.dc._msdcs.yourDomain
Host: dcDomain
Port: 636

Type: A
Record: yourDomain
IP Address: dcIPaddress

Example for the AD DS domain 'auth.tamu.edu':

Type: SRV
Record: _ldap._tcp.dc._msdcs.auth.tamu.edu
Host: auth01.auth.tamu.edu
Port: 389

Type: SRV
Record: _ldaps._tcp.dc._msdcs.auth.tamu.edu
Host: auth01.auth.tamu.edu
Port: 636

Type: A
Record: auth.tamu.edu
IP Address: 128.194.147.6


Q: What changes do I have to make with security groups within my Active Directory domain after setting up the trust?
A: In order to use security principles from the authentication domain, you must use Domain Local groups within your own Active Directory forest or domain. Universal and Global groups cannot contain security principles from an external forest or domain. If you are using Exchange 2007 or above, this necessarily means splitting off Active Directory permissions from Exchange permissions, as Exchange permissions are based on the mailbox, which resides in your forest or domain.


Q: What changes do I have to make with group policy?
A: Most Active Directory administrators apply group policies at the Organizational Unit (OU) level. Computer-based group policies should be mostly unaffected, as they will apply to machines that still reside in your AD forest or domain within OUs that have group policies linked to them. However, user-based group policies will have to be changed, because the user object resides in a separate domain. A combination of loop-back processing and security filtering based on Domain Local groups will usually allow you to achieve the same result.


Q: What other changes must be made within my Active Directory environment?
A: By default, only users in the Domain Users built-in group can login to workstations within your Active Directory domain. External principles from the authentication domain are not included in the Domain Users group. Furthermore, Domain Users is a special security group that cannot be changed from a Global to a Domain Local group. As such, you cannot simply add a Domain Local group as a member of it. Instead, you will need to do one of the following:

  1. Modify your domain group policy Local Security settings so that a Domain Local security group containing your users from the authentication domain can log on locally, or
  2. Add the Domain Local security group containing your users from the authentication domain to the local Users group for each workstation and server where you want them to be able to login to.

Note: it is very important to thoroughly test these configurations in advance, particularly when applying group policies at the domain level. CIS is not responsible for damage to your Active Directory environment caused by inadequate testing on your part.


Q: What access will I have to the authentication domain as an administrator?
A: The authentication domain is designed to be as secure as possible in order to prevent the inadvertent or deliberate release of sensitive and/or confidential information to unauthorized individuals. As such, your access will be limited to choosing NetID users from the domain to include in your own Domain Local security groups. You will not be able to login to computers within the authentication domain, link Group Policy Objects, or interact in any other way beyond that which has been mentioned.


Q: How will I administer security in my domain once the trust is established?
A: The most convenient way to perform security as it relates to security principles in the authentication domain is to login to your own domain using your NetID from the authentication domain. By doing this, you will not have to authenticate through the trust every time you want to search for and add a NetID account. Your NetID account should have the ability to modify group membership for the Domain Local security groups used by the trust, but we do not recommend that you make your NetID account a full domain or enterprise administrator within your own forest or domain. We recommend that you use a separate administrator account that exists only within your own forest or domain for high-level administrative functions.