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 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)
mail 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
    • 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.