Table of Contents
The purpose of this site is to outline the proposed architecture for the Microsoft Enterprise Active Directory. The Office of Information Technology is committed to providing leadership and support for the effective use of technology, offering an extensive range of resources that support education, research and clinical environments. These enterprise-wide services provide technology solutions and secured standards to the Rutgers community.
- Active Directory Configuration
- DC Placement
- DNS
- Active Directory Schema
- Provisioning and Sync Integration
- Directory Structure
- Desktop Management
Active Directory Configuration
The Rutgers Active Directory (RAD) is built across multiple domain controllers. The operating system of the domain controllers is currently Windows Server 2012 R2 and will be kept within one major rev of the latest released operating system. LDAP configuration settings are generally set to the Active Directory defaults.
DC Placement
The RAD domain controllers are geographically dispersed so that each main geographic location has at least one or more domain controller. The domain controllers reside in physically secure datacenters that also co-locate with Rutgers’ core network infrastructure to insure redundant high bandwidth links to RUNet.
The domain controllers for RAD reside on Rutgers private address space and cannot be accessed from outside Rutgers without the aid of VPN. The DNS information for the domain controllers is also only advertised on Rutgers private address space. This space includes Rutgers Newark, Piscataway, New Brunswick, and Camden campuses and the Rutgers Biomedical and Health Science campuses.
There is a NAT boundary that exists on the Rutgers network as a result of the merger between Rutgers and UMDNJ. The domain controllers reside on specific NAT exempted networks so that the IP addresses can be accessed freely across the NAT boundary between the legacy Rutgers space the RBHS space. We are also using multiple DNS views so DNS resolution is handled correctly depending upon which side of the NAT boundary the query is coming from. Other key enterprise RAD components also reside on these networks. Although all clients and resources can get to central RAD resources no matter which side of the NAT they reside, clients may not necessarily be able to communicate directly to each other across the NAT boundary. For example a PC on the legacy Rutgers space may not be able to reach another PC on the other side of the NAT boundary on the legacy UMDNJ space even though both machines are members of RAD.
Although the domain controllers are available on all Rutgers space, departments or units running their own firewalls may need to allow incoming access from the domain resources to insure proper communication. Detailed information can be obtained by inquiring to rad-support@oit.rutgers.edu.
DNS
DNS for RAD has been off-loaded from the domain controllers and is completely handled by the University Infoblox DNS grid. The Infoblox grid supports secure Dynamic DNS for both forward and reverse lookups and fully supports the DNS service records required for Active Directory. The Infoblox grid also supports multiple DNS views so that DNS queries are handled correctly on both sides of the NAT boundary within the university. There is a separate DNS view for the legacy Rutgers space and for the legacy UMDNJ space.
Active Directory Schema
The Rutgers Active Directory schema is open to changes, and includes both vendor and Rutgers custom schema elements. The RAD admin team will entertain any schema modification requests. All schema modifications must follow schema best practices. Vendors tend to follow these best practices. Custom schema modifications are also possible.
Users
Most users in RAD will be provisioned and de-provisioned through synchronization to the People Registry using an in-house designed Active Directory connector. RAD in turn provisions the accounts to Azure active directory as the basis for Rutgers Office365 accounts. The attribute mappings for provisioned accounts are listed below.
| RAD Attribute | Description | Used By | Source |
| objectclass | classes necessary for people objects | RAD | Static value, NetId Mgmt |
| SN | Surname | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| C | Country | RAD | Registry, NetId Mgmt(adm accounts only) |
| ST | State | RAD | Registry, NetId Mgmt(adm accounts only) |
| title | Title of user | RAD, MaCS | HR (RIAS and Banner),NetId Mgmt(adm accounts only) |
| description | Descriptive Info | RAD | NetId Mgmt(adm accounts only) |
| displayName | Formatted name for directory listing | RAD, MaCS | Registry,NetId Mgmt(adm accounts only), Also sourced from Preferred name process set by Cliff |
| l | Location | RAD | Registry, NetId Mgmt(adm accounts only) |
| department | School or Department of user at RBHS | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| company | Operational Unit | RAD | Registry, NetId Mgmt(adm accounts only) |
| sAMAccountname | same value as NedID | RAD, IdM, MaCS | Registry, NetId Mgmt(adm accounts only) |
| userPrincipalName | Internet-Style Login name for a user | RAD, MaCS | Registry,NetId Mgmt only copies from RAD to RAD-adm account,RATS |
| pwdLastSet | Password last change | RAD, MaCS | NetID Mgmt |
| msExchHideFromAddressLists | Field to hide users from GAL | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| cn | Common Name | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| givenName | Name strings that are the part of a person’s (user or contact) name that is not their surname | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| initials | middle initial | RAD | NetId Mgmt(adm accounts only) |
| employeeNumber | RCPID, Uniq IdM identifier to recognize a person who come from multiple sources (i.e Banner, PSFT, SRDB,Guest) | RAD, IdM | Registry, NetId Mgmt(adm accounts only) |
| businessCategory | User’s active roles | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| proxyAddresses | A proxy address is the address by which a Microsoft Exchange Server recipient object is recognized in a foreign mail system. Proxy addresses are required for all recipient objects, such as custom recipients and distribution lists. | RAD, MaCS | RATS |
| streetAddress | User’s Address | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| telephoneNumber | User’s Telephone # | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| l | user’s city/locale | RAD, MaCS | Registry |
| st | state or province | RAD, MaCS | Registry |
| postalCode | postal code | RAD, MaCS | Registry, NetId Mgmt(adm accounts only) |
| user’s mail address | RAD, MaCS | RATS | |
| employeeID | External Id, Uniq IdM identifier to recognize a person who come from multiple sources (i.e Banner, PSFT, SRDB,Guest) | RAD, Any Third Party including cloud | Registry, NetId Mgmt(adm accounts only) |
| manager | object link to manager | RAD, MaCS | RATS |
| extensionAttribute1 | PHI Flag | RAD, MaCS | Registry for Now (TBD future),NetId Mgmt(adm accounts only) |
| extensionAttribute2 | Display Name | RAD, MaCS | RATS,NetId Mgmt(adm accounts only) |
| extensionAttribute3 | Connect Locking | RAD, MaCS | RATS |
| extensionAttribute4 | Msexchange hide from GAL | RAD, MaCS | RATS |
| userAccountControl | a control flag in AD that indicate the active status of an account | RAD, MaCS | Registry/netID Managment |
| extensionAttribute5 | Duo Enrollment | RAD, MaCS | NetID Mgmt |
| extensionattribute6 | Primary SMTP address for user | RAD, OIT | MACS |
Group
Initially groups will be provisioned and managed using Microsoft’s Active Directory Users and Computers (ADUC) management interface. This will be used through a transition period for some of the early adopters of RAD. The intention is to eventually put in place a RU Groups Service powered by grouper to handle all group creation and management. When ready, creation of groups will go through the RU Groups Service web interface and propagate to RAD.
Administrative Accounts
The following Delegated rights will be granted to an OU admin underneath the Delegated Sub OU’s.
- Create\Delete PC objects
- Create\Delete Printer Objects
- Create\Delete OU’s
- Create\Modify Group Policies
- Create\Modify Groups
Service Accounts (Non-People)
Service accounts will reside in a protected Sub OU, underneath the Other People OU. These accounts will be configured with the following settings enabled.
- Password does not expire
- User cannot change password
Elevated accounts can be added to one or 2 groups elevated depending on what rights are needed.
- RAD User Administration
- Full Rights over User objects in the People OU (DirSync, AD Connector)
- Rad Password Administration
- Rights to modify Passwords for all user objects in the People OU (Portal password Sync)
Directory Structure
The Rutgers Enterprise Active Directory is a single forest/single domain.
All NetID Based user accounts are under the top-level People OU. We have almost 300,000 accounts residing in this OU.
All other Non NetID accounts (Service, Admin, Resource, and Application) are under the top-level OtherPeople OU. The OtherPeople OU are separated into sub OUs by Org Type requesting the account.
Rutgers OIT does not make any promises about where a given user account will be located and reserves the right to move objects to meet changing service requirements.
Most computers and other directory objects specific to Rutgers clients are under the top-level Delegated OU. This is where departments, schools, and other Rutgers organizations that request a delegated OU are created. This is the only part of the RAD where campus Windows administrators are granted a non-default level of permissions. (creation/deletion of groups, sub-OUs, computer objects.