The NetID authN Domain allows campus college and departmental Active Directory domains the ability to utilize NetID accounts for authentication to their services.
To set up a trust with the NetID authN Domain, complete the request form:
To set up access for a specific service with the NetID authN Domain, complete the request form:
All information on the form should be typed except the signatures. If you are uncertain about how to answer a question, please email firstname.lastname@example.org for assistance.
The form is printed, signed by the requester and mailed to the Identity Management Office, MS 3374 or faxed to 979.845.6090.
If you have any questions about the authentication domain or the request process, send an email to email@example.com.
- What is the authentication domain?
- What type of trust will this be?
- How are passwords handled in this security model?
- What is your intended audience? Who can sign up for this trust?
- What are the requirements to setup and use a trust to this domain?
- What changes do I have to make with security groups within my Active Directory domain after setting up the trust?
- What changes do I have to make with group policy?
- What other changes must be made within my Active Directory environment?
- What access will I have to the authentication domain as an administrator?
- How will I administer security in my domain once the trust is established?
Q: What is the authentication domain?
A: Texas A&M IT 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. Account holder 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 Texas A&M IT (using the request form) 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 Server 2016 running at the 2012 R2 functional level. Prior to setting up the trust, you will need to create a STUB Zone in your Active Directory domain for auth.tamu.edu DNS zone. Use auth-dc-t1.auth.tamu.edu as the master server. The Division of IT will do the same for your domain in the AUTH.tamu.edu forest as soon as your trust request has been approved.
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.
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
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:
- 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
- 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. Texas A&M IT 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
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.
Supported Authentication Mechanisms
Kerberos was introduced with Windows 2000 and is Microsoft's preferred authentication mechanism. Windows Vista, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016 will use Kerberos when they are communicating with Active Directory Domain Services and the members of Active Directory.
NTLMv2 was first released with Windows NT 4.0 SP4.
Computers with Microsoft Windows 3.11, Windows 95, Windows 98 or Windows NT 4.0, SP3 or earlier do not have the NTLMv2 protocol out of the box. Windows 95, 98 and pre-SP4 NT 4.0 could be enabled to support NTLMv2 by installing the "Active Directory Client Extension".
Authentication Mechanisms that are Not Supported
NTLMv1 relies on DES, a very weak encryption algorithm. The NetID authetication domain will not accept authentication requests sent via the NTLMv1 protocol. Due to reliance on this very old authentication mechanism, some systems cannot utilize the NetID authentication domain. Impacted systems are:
- Inbound authentication from Windows 95 or Windows 98 clients that do not have the Directory Services Client installed.
- RRAS servers running versions of Windows prior to Windows Server 2003 Service Pack 1.
- Any RAS server that needs to process MS-CHAPv1.
- Clustered computers running versions of Windows prior to Windows Server 2003 Service Pack 1. Clusters use RPC over UDP, and RPC over UDP cannot use NTLMv2 by default. This was resolved in Service Pack 1.
- Some third-party hardware devices that have an SMB server built in may not be able to authenticate.