MSU funds a Microsoft Windows Active Directory infrastructure for units on campus. By joining the CampusAD domain, units may collaborate with others and securely share resources with other CampusAD users.
The Active Directory authentication system:
- Supports enterprise systems (e.g., file and print servers)
- Provides contact information and scheduling integration
- Offers mechanisms for centralized desktop management.
The purpose of the central CampusAD is to migrate all these environments into a single AD forest to provide university-wide benefits.
About 1,900 accounts adopt CampusAD a year. Units, colleges, and departments who choose to adopt CampusAD for their Active Directory services have the ability to manage their own organization unit (OU). MSU IT uses the Quest ActiveRoles Server (ARS) software for management of OUs offers this tool as part of the CampusAD service.
MSU Information Technology provides the Active Directory server infrastructure for units, relieving them from having to provide their own support and maintenance of Domain Controllers.
- Reduces overhead costs and resources.
- Provides a foundation for other services like Campus Exchange.
- Improves workstation security.
- Provides business continuity though central backup and restoration services.
CampusAD is a single forest with a single domain that currently supports MSU IT and its clients.
Units who participate in the CampusAD service will have a dedicated OU for their unit. If a unit wishes to keep a resource AD within the unit, trusts may be permitted so unit resources can trust accounts in their CampusAD OU.
Active Directory Domain Naming
One of the primary issues to consider when setting up an Active Directory server for units at MSU is the choice of the subdomain for the Active Directory. Once this choice is made and implemented, it can be difficult to change.
Internal name: Define an internal subdomain name that is not tied to the Internet DNS (i.e., does not end in msu.edu). An example would be dept.internal, where dept is your department name or code. This approach makes the names more private, since there will not be direct Internet exposure of the Active Directory data. This approach is recommended in most cases. This approach also requires that the client computers use your AD as the configured DNS server. Your server will still refer clients to other name servers as needed, including the central campus servers for names ending in msu.edu.
Subdomain under the special domain ad.msu.edu: If your department is coordinating Windows-based services with MSU IT, you may need to establish your domain as dept.ad.msu.edu. This will allow your domain to interact with other domains established by MSU IT which are also under the ad.msu.edu domain. Contact firstname.lastname@example.org for more details on this approach.
Subdomain under existing unit domain: Define a domain name under your existing department domain (e.g., ad.dept.msu.edu). This approach makes the names more accessible. The central campus DNS servers (and others off-campus) would have access to the DNS data as needed. This approach should be used where there is a good justification for connecting the Active Directory domain to the Internet at large.
Unit subdomain: Use your existing departmental domain (dept.msu.edu). This approach requires that your Active Directory DNS server also be configured with all existing DNS names for your department (e.g., static IPs, web and mail servers, printers). Your server would also be required to allow secondary (slave) access to the DNS data for the central campus DNS servers, but you would not have to provide your own secondary server. The MSU Hostmaster would verify the configuration and correctness of the data before linking your server to the campus DNS. This approach allows a unit to maintain more immediate control over all DNS data for the unit. It also increases the need to maintain a reliable and accurate DNS service.
Regardless of the approach chosen, you’ll need to register and request subdomain names under msu.edu.