|
|
|
Trust with MIT Kerberos 5 Realm
In order to maintain a central user account at Penn State, it was necessary to setup up a one-way Kerberos trust between the forest and the MIT Kerberos 5 (K5) realm that holds Penn State Access Account userids and passwords. The purpose of the Penn State root domain is to provide the trust and allow other organizations to leverage it.
Microsoft® has extended and enhanced Kerberos 5 by adding PAC data into a user's Kerberos ticket. In order for a user to be able to use resources within the Forest, the user's ticket must contain this data. To make Microsoft® Kerberos work with standard Kerberos, Windows® maps accounts in the Forest to the Kerberos ticket from the K5 realm. These accounts are stored in the root domain and are referred to as skeleton or shadow accounts. Skeleton accounts contain only necessary user information and several common LDAP attributes link with the PSU LDAP server. Account passwords are random passwords that no one knows.
Currently, three ways exist to join the forest, all of which utilize trust and skeleton accounts:
A fourth option for utilizing Pass-through authentication is called a direct trust. You can find more information on this here, but this is not considered to be a part of the ACCESS forest.
Then, this ticket is mapped to a skeleton user account. Mapping consists of the skeleton account's PAC data inserted into the MIT K5 ticket. The user now has valid credentials to use throughout the Forest.
DNS in the Microsfot Windows Active Directory® Forest
One key constraint considered when designing the Forest was the Domain Name Service (DNS) Policy set forth by Telecommunications and Networking Services, a unit of ITS. The DNS Policy requires that the suffix of a machine align with the administrative hierarchy of the organization. For example, a domain controller named DC1 in the root domain ACCESS.PSU.EDU would be named dc1.access.psu.edu. In the Windows Active Directory® Forest at Penn State, the name of the domain controller is dc1.aset.psu.edu. The correct SRV records and principles are created; however, there is a limitation. When a machine attempts to locate a machine in the same domain, it assumes that the suffixes are the same. This means that if dc1 attempts to access dc3 then dc3 must have the same suffix as dc1. Therefore, dc1.aset.psu.edu and dc3.aset.psu.edu will work but dc1.aset.psu.edu and dc3.offsite.psu.edu will not.
Active Directory® is tightly integrated with DNS. When a domain is created, five sub-domains are also created. They are:
Within the zones, Active Directory® creates SRV records that point to services within the domain. SRV records dynamically change periodically. In order to integrate this dynamic DNS scheme with Penn State's existing BIND DNS infrastructure, Microsoft® DNS servers would be used for only the five sub-zones; NS records were created on the authoritative servers for the sub-zones. NS records point to the Microsoft® servers that allow dynamic updates.
Naming of client machines follows along with the naming of domain controllers. A client machine or a stand alone server will be a part of a domain, but the DNS suffix will not match. For example, dc-ws1.aset.psu.edu is the FQDN for a workstation that is a member of the ACCESS.PSU.EDU domain. It is important to correctly name a machine before putting it into the domain whether it is a domain controller, stand alone server, or a workstation. If you do not correctly name a machine before adding it to the domain the service principles and dnshostname attribute in LDAP will not get set correctly resulting in loss of functionality
We also require that the FQDN of every machine in the Forest be prefixed by a two or three letter designator given to your organizaiton by an ACCESS enterprise administator to ensure that every machine within the Forest has a unique name preventing issues.
Microsfot Windows Active Directory® Forest Topology
When designing the Forest Topology, we wanted to keep each organization as autonomous as possible. One of the fundament design requirements was seperating organizations and preventing one organization from impacting another organization as much as possible. One way we accomplish this is by limiting replication for your organization with the ACCESS domain only. In some situations, an organization where and organization is geographically disperse the admins of that organizaiton may want to replicate there distant sites with there parent site and have that parent site replicate with the ACCESS domain. This must be co-ordinated with the ACCESS enterprise admins and is encouraged.
Microsfot Windows Active Directory® ACCESS Domain OU Structure
During the design of OU structure within the ACCESS domain, autonomy was taken into consideration. There are seven OU created under access.psu.edu and each has a specific purpose. The OUs are listed below:
This the the OU where a user's ACCESS shadow account is created. Common LDAP attibutes are synced and the account is given a random password that no one knows. The only accounts that have permissions within this OU are Entreprise admins, the account used to create shadow accounts, and exchange admins have permissions the permissions needed to set the user's mailbox.
This OU has been tested for syncing LDAP groups. In the near furture we will be implementing this and you will see this OU being populated. Only enterprise admins have priveleges in this OU.
This OU has been tested for future integration with FPS accounts. Only enterprise admins have priveleges in this OU.
This OU is used to store groups and admin accounts created for different organizations. Will will find all admin accounts created the all organizations utilizing the ACCESS Forest.
This is the container where a computer account is place when a new account is created. Only the enterprise admins and the admins in the DC-OU-Admins group have priveleges with in this OU. This is done to restrict who can add a machine to the ACCESS domain. Once an account is created in the OU only the person how created the account or and enterprise admin can move or delete the account.
This is the OU where most of an organizations administration happens. Under this OU you will find a hierarchy of organizations. Organizations are first broken down into campus locations. From there they are organized using the reporting structure of their organization. Enterprise admins have full control over this OU and an organization's admins are given full control over there designated OUs.
Infrastructure servers are stored in this OU. Only enterprise admins have priveleges in this OU.
The Pennsylvania State University ©2006. All rights reserved.
Alternative Media - Nondiscrimination Statement
This site maintained by Academic Services and Emerging Technologies, a unit of Information Technology Services.
Problem reports and requests for assistance should be directed to ITS Help Desk staff.
Last revised: Tuesday, March 14, 2006.