Rutgers EI

Enterprise Infrastructure

Integrating Systems

RAD – Architecture

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 Intergration
  • 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

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.

Person Registry Attribute (NetID) RAD Attribute O365 Attribute Source
EnterpriseADPerson objectClass objectClass NetID
giveName giveName giveName NetID
lastName sn sn NetID
country C C NetID
state st st NetID
jobTitle title title NetID
description description description NetID
displayName displayName displayName NetID
location L L NetID
department department department NetID
company company company NetID
smaAccount sAMAccountName sAMAccountName NetID
userPrincipalName userPrincipalName userPrincipalName NetID
disclosure msExchHideFromAddressLists msExchHideFromAddressLists NetID
netid cn cn NetID
rcpId EmployeeNumber EmployeeNumber NetID
roles businessCategory businessCategory NetID
businessAddress streetAddress streetAddress NetID
phone telephoneNumber telephoneNumber NetID
postalCode postalCode postalCode NetID
externalId EmployeeID EmployeeID NetID
phi ExtensionAttribute1 ExtensionAttribute1 NetID
instanceType instanceType instanceType NetID
preferredName ExtensionAttribute2 ExtensionAttribute2 NetID
  unicodePwd unicodePwd NetID
  pwdLastSet pwdLastSet NetID
  userAccountControl userAccountControl NetID
    proxyAddresses NetID
    mobile NetID
    facsimiletelephonenumber NetID
    mail NetID
    mailNickname NetID
    targetAddress NetID
    *LitigationHold* NetID
    authOrig NetID
    extensionAttribute10 NetID
    EmployeeID NetID
    extensionAttribute3 NetID
    extensionAttribute4 NetID

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
    • o Full Rights over User objects in the People OU (DirSync, AD Connector)
  • Rad Password Administration
    • o 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.