EXECUTIVE SUMMARY
Project Overview
The University of Florida's computing environment is highly fragmented, with limited centralization of services like Mainframe and GatorLink Currently, Microsoft Windows directory services exemplify this lack of interoperability, as the university hosts over 50 domains with minimal trust relationships Approximately fifteen of these are Windows 2000 domains, each existing within its own Active Directory forest While this structure allows departments to operate independently, it incurs significant maintenance costs and restricts resource sharing, ultimately hindering the university's objectives for a unified identity system.
The University of Florida partnered with Dimension Data to streamline resource sharing by consolidating multiple directories into a single enterprise Active Directory This initiative aims to maintain departmental autonomy while enhancing identity management Dimension Data will assess key business requirements and deliver a high-level design, including implementation options and tailored recommendations.
Dimension Data conducted a comprehensive two-week assessment, interviewing LAN administrators and managers across multiple colleges and departments within the university Additionally, an open-door session was organized to encourage feedback and input from all interested parties.
Document Overview
This document aims to offer strategic guidance and recommendations for implementing Active Directory at the University of Florida, covering key areas such as authentication and forest design Individual colleges and departments are encouraged to develop detailed migration plans for transitioning their systems into the enterprise Active Directory Dimension Data is available to provide expertise and support throughout the planning and execution of these migrations.
The University of Florida's current computing environment is characterized by its robust infrastructure, although it faces challenges related to network performance and reliability Notably, issues have arisen during the implementation of the Enterprise Active Directory Design project, impacting user access and system integration Addressing these network concerns is essential for enhancing overall operational efficiency and ensuring seamless connectivity across the university's digital resources.
Design Goals / Requirements: Defines they key project goals and business requirements.
Active Directory Design Options: Compares various design options providing benefits and disadvantages for each.
Recommendations: Outlines professional recommendations based on interviews, industry trends, vendor information, and research.
Appendices: Provides additional information about topics covered in the document.
Assumptions and Limitations
The following assumptions were made during the design phase:
This directory is being developed as an enterprise service, allowing individual colleges and departments the option to participate The choice to join the enterprise Active Directory will be made by each college or department.
In addition, the following limitations in the design should be noted:
• This design will be created based on key business requirements,
Dimension Data brings extensive experience in implementing Active Directory, supported by case study research and collaboration with universities that have similar needs The current macro design phase lacks hands-on testing, but specific components are tailored to fit the University of Florida's existing infrastructure These customized areas will undergo testing to ensure the design's effectiveness, with validation scheduled for the next phase, which involves proof-of-concept prototyping.
References
During the preparation of this macro design, the following documents were referenced:
• Windows 2000 Deployment Planning Guide http://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp
• University of Florida LAN Administrator Interview Notes
• Inside Active Directory by Sakari Kouti & Mika Seitsonen, pub Addison Wesley
• Managing Enterprise Active Directory Services by Robbie Allen and Richard Puckett, pub Addison Wesley
• http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/deploy/kerberos.asp
• Mission-Critical Active Directory by Micki Balladelli and Jan De Clercq, pub. Digital Press
• http://www.microsoft.com/WINDOWS2000/techinfo/howitworks/security/kerberos.asp
CURRENT COMPUTING ENVIRONMENT
Organizational Summary
The University of Florida comprises five major colleges, each serving over 2,000 students, along with numerous smaller colleges and departments Additionally, it is affiliated with Shands Hospital, where physicians also hold faculty positions within the university's Health Sciences Center.
Physical Network
The University of Florida's main campus is located in Gainesville, Florida, where the Network Services group oversees the management of the majority of networking equipment Cisco is the preferred vendor for routers and switches, ensuring reliable performance A redundant fiber backbone links the campus's local area networks (LANs) to form a robust metropolitan area network (MAN) Most university departments are situated on or close to the campus, benefiting from high-speed connectivity to the network.
The diagrams below depict the physical connectivity of the university’s core network and connectivity to the Internet More diagrams of the campus MAN can be found at http://net-services.ufl.edu.
Figure 1 – Main Campus Core Network
Network Limitations
While the majority of colleges and business units are situated on the main campus, two significant colleges operate remote locations The Institute for Agricultural Sciences (IFAS) features approximately 20 Research Education Centers (REC), each serving 150-200 users and linked to the main campus through the Florida Information Resource Network (FIRN) Additionally, every one of Florida's 67 counties hosts at least one IFAS county extension office (CEO), accommodating 1-50 users and also connected to the main campus via FIRN or VPN The Health Sciences Center (HSC) has a remote facility in Jacksonville, Florida, which is connected to the main campus through a fractional T3 circuit.
The current IFAS network suffers from the following constraints:
• Many REC’s and CEO’s are connected to the main campus via 56Kb frame relay circuits with a 33.6Kb CIR.
Due to the location of many CEOs in county office buildings, IFAS lacks authority over these facilities and networks, which are governed by the controls and restrictions set by county office staff.
Systems Overview
Below is a list of various systems statistics at the University of Florida The following rough estimates were consolidated from information provided by LAN administrators that were interviewed:
• 60% Other (POP3, IMAP, Sendmail, Elm, etc)
4 Primary Databases: DB2, SQL Server, Oracle
5 Primary Web Services: Apache, Internet Information Server
Enterprise Directories
The University of Florida, like many large institutions, utilizes multiple directory services tailored to various operating systems, as there is no universal directory solution This results in multi-platform organizations managing several directory services, which can be challenging and costly to maintain without automation Currently, the University of Florida has several existing directories.
1 Campus Registry – an in-house developed directory service that runs on a
The University of Florida invested over $1 million in developing a comprehensive DB2 database directory that includes records for all individuals connected to the institution, such as students, faculty, administration, and alumni This extensive directory plays a crucial role in establishing and maintaining a unique identity for each person associated with the university through the University of Florida Identifier (UFID), ensuring that every individual has a distinct identification within the university community.
2 Peoplesoft – currently under development This will ultimately become the enterprise resource planning (ERP) solution for the University of Florida Much of the Campus Registry’s functionality will be moved into PeopleSoft and theCampus Registry may be phased out in a few years.
3 Netware Directory Services – there is a significant implementation of Novell
Netware at the university Continued support and integration of these Netware servers is important to many departments within the university.
4 OpenLDAP – A popular open source based LDAP directory Implemented on enterprise AIX servers in the NERDC The university uses this directory as I read only source of data for other directories.
5 Kerberos V5 – developed by MIT, this is the university’s credentials repository that provides an authentication services for many web-based applications.
6 Active Directory – Currently, at least 15 Active Directory forests exist at the
University of Florida Although Active Directory is currently very distributed, it is the purpose of this project to consolidate these disparate Active Directory forests into an enterprise Active Directory.
While the integration of directories is not the focus of this project, recognizing the potential for interoperability between enterprise Active Directory and other directory services can highlight the ROI benefits of consolidating Active Directory Additionally, comprehending the flow of directory information will offer valuable insights into key integration points that can enhance the effectiveness of a centralized Active Directory.
The diagram illustrates how Active Directory can streamline account creation and maintenance by leveraging existing data from other directories to automatically populate accounts within the Active Directory system.
Creating an account through the Campus Registry allows for the input of optional additional information, which automatically generates an Active Directory Account Essential details like password, address, and phone number can be pre-filled in the new account, significantly minimizing account management efforts This streamlined process enhances user experience by requiring the end-user to remember only one password.
Implementing a directory broker enhances flexibility by allowing each directory service to communicate solely with the broker, rather than with each other The broker serves as the central component that manages communication, data mapping, and replication rules, streamlining the process This modular approach enables the easy addition of new directory services through the creation of connectors and configuration of rules within the broker Furthermore, this model allows for different directories to maintain authoritative control over distinct sets of information.
As the University of Florida transitions to Peoplesoft, it is set to become the primary source for information management A broker will determine the ownership of data between Peoplesoft and the Campus Registry, allowing for seamless adjustments in data ownership through rule changes in the broker system.
Where do we get this “directory broker”?
There are couple different ways to implement this:
1 Purchase and configure an enterprise directory synchronization tool, such as Microsoft MetaDirectory Services (MMS) Most metadirectory tools require configuration and scripting to work effectively However, they dramatically reduce the effort required to manage directory synchronization because they already have connectors built for most of the popular directory services. Maintaining data between different directories only requires that rules be configured to manage the synchronization schedules, data mapping, conflict resolution, etc.
Additional information about Microsoft MetaDirectory Services can be found at:
• http://www.microsoft.com/mms
2 Develop a custom directory broker For synchronization of authentication credentials or small amounts of data, a custom application could be written using LDAP and ADSI calls For example, when an account is input into the Campus Registry, a trigger could be launched that sends data to the broker process The broker component could use ADSI commands to automatically create a new account in the Active Directory It is costly to create and maintain directory connectors and interfaces for large amounts of data; therefore, this approach is not recommended for more complex directory synchronization. More information about using ADSI can be found at:
• http://www.microsoft.com/adsi
• Book: Managing Enterprise Active Directory Services by Robbie Allen and Richard Puckett, pub Addison Wesley
DESIGN GOALS / REQUIREMENTS
Through interviews with staff from various colleges and departments, we identified key design goals, which are prioritized by their significance These priorities informed critical design decisions throughout the process.
Single Sign-on (SSO) with a Coordinated Namespace allows users to log in with the same username and password across multiple systems, ensuring a seamless authentication experience For instance, Joe Smith consistently uses the username "JSmith" for access to GatorLink, Peoplesoft, and Active Directory, regardless of the device he uses Conversely, if Jane Smith needs an account, she would receive a unique username like "JaSmith" or "JSmith2," which would be recognized across all enterprise directories This system simplifies user management by requiring individuals to remember only one synchronized password for all platforms.
• Allow interoperability between University of Florida departments –
Facilitate the ability to share resources and information between departments.
• Simplify directory management – Take advantage of opportunities to automate directory management
• Provide better inter-department scheduling – Provide a way that departments with Microsoft Exchange can take advantage of integrated scheduling.
• Create a more comprehensive Exchange global address list – Have all public e-mail addresses listed in the Exchange global address list that all departments can access.
Centralizing commodity services enables colleges to reduce operating costs while enhancing functionality through economies of scale and resource sharing By providing essential services at a lower cost than individual management, institutions can allocate more of their budgets toward mission-specific technology goals For instance, a chemistry department could leverage a centralized university email system, allowing them to invest more funds into vital chemical analysis equipment rather than maintaining email servers.
To ensure effective service delivery, it is crucial to maintain appropriate administrative autonomy within organizations While centralization can lower operating costs, it must not compromise service quality Certain functions should be managed locally to allow for prompt responses to end users' needs Delegating responsibilities to qualified local administrators enables quicker decision-making and enhances service efficiency The extent of this administrative delegation will vary by department, depending on the specific needs and capabilities of the administrative staff Key management tasks suitable for local LAN administrators include group membership management, resource access control, member server oversight, and policy enforcement.
ACTIVE DIRECTORY DESIGN OPTIONS
Active Directory Domain Hierarchy
The debate on whether each college should maintain its own forest or if the university should operate a single forest raises important considerations If a single forest is chosen, the question arises about whether individual colleges should have their own domains or if a unified domain is preferable Furthermore, if a single domain is adopted, the structure of accounts becomes crucial: should they be organized into delegated Organizational Units (OUs) or consolidated into one OU? To address these complexities, we will examine various models.
The single OU model at the University of Florida consolidates all accounts into one organizational unit, akin to the Windows NT 4.0 single domain model This approach allows for account replication across all domain controllers, managed by a single entity However, while suitable for small businesses, it poses challenges for larger institutions, as it lacks the capability to delegate account control Consequently, local LAN administrators at colleges may oppose this model, as it restricts their ability to manage only their specific accounts.
1 Provides strong centralized security and control.
2 Easy to integrate single sign-on.
1 Offers no delegation of control Management tasks cannot be delegated to colleges for only their users.
2 Requires more bandwidth for Active Directory replication because the directory is not partitioned (All 60,000+ accounts are in one domain)
3 Requires a large, centralized staff to provide adequate service to end users.
4 Only one domain security policy (i.e password lifetime/lockout, ticket lifetime, etc.) can be configured for the entire university Colleges cannot implement their own domain policies.
Implementing a single domain with multiple Organizational Units (OUs) ensures robust centralized security while allowing colleges to exercise delegated control Each college can manage directory objects, permissions, and policies within their OU, fostering autonomy Furthermore, colleges can extend this delegated control to sub-colleges or departments, enabling them to manage their own administrative tasks effectively.
To limit replication traffic, Active Directory is broken up into partitions (also known as
Active Directory is structured with domains rather than organizational units, which means that all university accounts are stored on every domain controller This design increases network traffic for domain replication but significantly streamlines single sign-on integration and minimizes the required number of domain controllers across the university An example of the configuration for college and department organizational units is illustrated in Figure 4 below.
Figure 4 – Single Domain / Multiple OUs
1 Provides strong centralized security and control.
2 Easy to integrate single sign-on.
3 Easier than multi-domain model to implement automated account maintenance.
5 Provides delegation of control Management tasks can be delegated, allowing colleges to manage only their users and computers.
1 Requires more bandwidth for Active Directory replication than a multi-domain model because the directory is not partitioned (All account are in one domain)
2 Only one domain security policy (i.e password lifetime/lockout, ticket lifetime, etc.) can be configured for the entire university Colleges cannot implement their own domain policies.
Partitioning Active Directory into multiple domains within a single forest enhances decentralization of security and control Each Domain Admin possesses the authority to manage all directory objects, permissions, and policies specific to their domain When college administrators are included in the Domain Admins group, they gain full administrative privileges over their respective domains, and these privileges cannot be limited in the future.
NOTE: Domain Admins have ultimate authority over all objects in their domain and they cannot be restricted within their own domain.
In turn, colleges with their own domain can delegate control to sub-colleges or departments that have their own administrative staff using OUs
Due to the partitioning of objects across domains, the need for replication within each domain naming context is minimized However, the global catalog, which serves as a partial replica of all objects in the forest, is still replicated to all domain controllers functioning as global catalog servers Windows 2000/XP clients require access to a global catalog server during the login process, making it essential for each site to have at least one local global catalog server for optimal performance Consequently, a domain containing only 20% of the forest's objects will not achieve an 80% reduction in replication traffic; instead, global catalog replication is likely to decrease the bandwidth required for replication by approximately 40-50%.
Each domain can have its own domain security policy with different password and Kerberos ticket lifetimes, account lockout, and password uniqueness settings.
To achieve optimal performance, it is essential for each site to have a dedicated domain controller for every domain that users will access Since domain controllers are limited to hosting only one domain, this setup may lead to an increased need for server hardware, particularly when facilitating resource sharing across different colleges and off-campus locations.
This model is particularly advantageous for legacy applications that do not support the Active Directory Organizational Unit (OU) structure, as these applications typically display account lists in a flat domain namespace In a single domain model, these applications would need to process over 60,000 accounts, while a multi-domain model reduces this number to fewer than 10,000 accounts, streamlining the enumeration process Figure 5 illustrates a potential configuration of domains within this model.
Figure 5 – Single Forest / Multiple Domains
Though not shown, each of the domains in figure 5 above will likely contain OUs for sub-colleges and departments.
1 Provides decentralized management without having to explicitly delegate control to college administrators
(Assuming that college administrators are added to the
Domain Admins group in their respective domain.)
2 Reduced directory replication bandwidth required.
3 Each domain can have different domain security policies; therefore, colleges can tighten the security policy as appropriate to meet their security needs.
4 Provides some isolation against directory corruption or disaster.
1 Security is decentralized, which makes it more difficult to maintain university-wide consistency.
2 Additional configuration is required to achieve single sign-on.
3 Directory automation and management is more complex.
4 Typically requires more domain controllers than a single domain model for comparable performance
5 More administrative resources are required than a single domain model (i.e Additional backups, third- party software, manpower, etc.)
Many LAN administrators at various colleges within a university prefer to operate separate forests for enhanced control and complete network isolation This autonomy allows them to swiftly implement software that alters the directory schema without needing external approval However, since schema changes impact the entire forest, a single forest model necessitates more extensive testing and review before deploying changes to the production environment.
Nonetheless, this autonomy comes at a very heavy cost to interoperability In Windows
In 2000, trusts between domains in separate forests required explicit creation, resulting in non-transitive external trusts that complicate resource sharing among colleges, reminiscent of the Windows NT 4.0 SAM model This situation is particularly challenging for Exchange 2000, which, unlike Exchange 5.5, lacks its own directory service and instead relies on Active Directory and the global catalog for its Global Address List (GAL) Since the global catalog is not replicated across forests, each forest necessitates its own Exchange organization, leading to cumbersome processes of exporting and importing contacts between forests Maintaining synchronized directories across different forests is a complex task without tools like Microsoft Metadirectory Services 2003 and the anticipated GAL Synchronization Solution set to release in the latter half of 2003.
Figure 6 below is an example of what a multi-forest solution might look.
Figure 6 – Single Forest / Multiple Domains
Implementing multiple forests in Windows 2000 is generally discouraged unless necessitated by legal or operational requirements The forthcoming Windows Server 2003 Native-mode Active Directory is anticipated to facilitate transitive trusts between domains across different forests, simplifying resource sharing However, as of the writing of this article, Windows Server 2003 is still in beta testing, and it may take at least two more years for users to fully transition to this new system.
2003 native directory More information about multi-forest design can be found in the
“Multiple Forest Considerations” whitepaper on Microsoft’s website.
The following table compares the single forest and multi-forest attributes.
Feature Single Forest Multi-Forest
Identity Management Easier/Less costly to implement
Requires only a single trust to the Kerberos realm.
More complex / expensive to implement and manage Requires multiple trusts to the Kerberos Realm Requires multiple LDAP directory synchronization connectors.
Enforced by the Forest – User Principle Names can all be in the same namespace.
Not enforced – Users cannot authenticate using a UPN from a trusted domain in a different forest (Not applicable to Non-Windows Kerberos cross-realm authentication.)
Simple Free/Busy schedules within the organization are automatically in the organizations public folders.
Complex Requires using the PFSync tool from the Exchange resource to synchronize public folders between organizations.
Automatic No additional configuration required.
Requires a directory synchronization tool, such as the Microsoft Metadirectory 2003 (Not yet released) and GAL Sync tool.
Applications Much easier to implement because schema and security is maintained within the context of the forest.
More difficult and expensive to implement because of each forest may have a different schema, security, and object model Also, each forest requires is own directory connector and synchronization
Data Isolation Data isolated with discretionary access Data in one domain cannot be accessed by someone in another domain without a domain admin explicitly granting permission.
Complete Isolation – Sharing requires manual trusts and/or 3 rd party synchronization tools.
Service Isolation Services are isolated with discretionary access Services in one domain cannot be accessed by someone in another domain without a domain admin explicitly granting permission.
Complete Isolation – Sharing requires manual trusts and/or 3 rd party synchronization tools.
Schema isolation involves shared schema, which presents a slightly higher risk due to schema changes being applied at the forest level instead of the domain level This necessitates careful planning and thorough testing when deploying applications that extend the schema.
Isolated Directory Schema – Changes to the Active Directory Schema do not affect objects in other forests No risk of application conflicts.
Table 1- Single Forest vs Multi-Forest Comparison
Authentication
The University of Florida has made significant investments in web-based applications utilizing MIT Kerberos for authentication, while also striving to implement a unified identity system This section will concentrate on the mechanisms that enable users to log in using a single username and password.
Active Directory authentication in a mixed MIT Kerberos and Microsoft environment can be achieved through either cross-realm authentication or inter-directory credentials synchronization Each method has its own set of advantages and disadvantages, making it essential for university management to assess these factors Ultimately, the University of Florida must determine which authentication model aligns best with its business priorities to ensure an effective solution.
Cross-realm authentication entails creating a trust between the Active Directory root domain and the existing ufl.edu Kerberos realm, as shown below.
Figure 7 – Cross-Realm Authentication Process
This model is compatible solely with Windows 2000/XP clients that have modified their registries to include the Kerberos realm in the domain list at logon, and it does not support Windows 9x, Mac, or Windows NT 4.0 Additionally, Windows 2000 Servers cannot utilize tickets from the GatorLink Kerberos realm for resource authorization, as these tickets lack Windows security identifiers (SIDs) To address this limitation, proxy accounts, also known as "shadow" accounts, must be established in Active Directory for each GatorLink account These proxy accounts allow Active Directory to accept referrals from the GatorLink Kerberos realm and link the authenticated credentials to the appropriate user and group SIDs.
In this model, there is no established trust between the Active Directory and the GatorLink Kerberos realm, necessitating password synchronization between the two This synchronization can be seamlessly integrated into the existing directory synchronization process that generates Active Directory accounts The accompanying diagram illustrates this model.
Figure 8 – Inter-Directory Synchronization Authentication Process
This authentication model enhances functionality and flexibility by integrating two previous strategies It enables single sign-on for all Windows 2000/XP clients and applications at the University of Florida, while also supporting legacy Windows clients Users can log in with their username@ufl.edu for Windows 2000 and XP clients, whereas legacy clients will use the shadow account username@ad.ufl.edu As legacy clients are upgraded, the ad.ufl.edu namespace will be gradually phased out for authentication, remaining solely for system administrators to assign permissions.
The following table compares the three approaches to authentication.
Feature Cross-Realm Auth MS Domain Auth Mixed
Password Maintenance Passwords are only maintained in the GatorLink Kerberos Realm Active Directory proxy account passwords may or may not be known by the end-user.
Passwords must be synchronized between GatorLink Kerberos realm and the Active Directory
This could be implemented in the same code procedure that changes the GatorLink password.
Passwords must be synchronized between GatorLink Kerberos realm and the Active Directory This could be implemented in the same code procedure that changes the GatorLink password.
No Only supports Windows 2000/XP Does not support Windows 9x, Windows NT 4.0, Windows CE or Mac.
Yes Supports all Windows clients and Mac.
The system is compatible with all Windows clients and Mac operating systems; however, legacy clients such as Win9x, Win NT 4.0, and older Mac versions cannot directly log into the Kerberos realm Instead, these legacy clients must first authenticate using an Active Directory account.
No Supports Kerberos applications only Does not support single sign-on for any current version of Outlook, Exchange, IIS, or other NTLM-based applications
Single Identity Yes Yes Yes For Windows 2000 and
XP only Legacy clients will have the same username, but a different UPN suffix.
Native Windows 2000 support for PC-based
Kerberized Unix applications (such as kerberized telnet)
To use Windows 2000/XP logon, users must first execute MS2MIT, which transfers the MIT ticket from the Microsoft ticket cache to the MIT ticket cache Currently, there are no applications available for this process at the University of Florida (UF).
No Only with 3 rd -party Kerberos client, not native Windows 2000/XP logon
To use the application on Windows 2000/XP, users must first execute MS2MIT, which transfers the MIT ticket from the Microsoft ticket cache to the MIT ticket cache Currently, these applications are not available at the University of Florida (UF).
No Additional PC configuration required
No Every client machine must run Ksetup or have the registry modified to point to the Unix Kerberos realm for authentication.
Yes Works with Windows with no reconfiguration.
No Every Windows 2000/XP client machine must run Ksetup or have the registry modified to point to the Unix Kerberos realm for authentication.
User can change their password from the
Yes Works most of the time.
Fails on multi-homed systems May return a confusing message for user if the password does not meet the validation criteria of the Kerberos realm.
No Password must be changed through the GatorLink password change utility.
No Password must be changed through the GatorLink password change utility.
Multi-domain support Yes Requires a Kerberos patch that is not an official MIT distribution This patch was developed to allow child domains to authenticate thru a transitive trust between the
AD root domain and the Kerberos realm.
Yes No issues Yes Requires a Kerberos patch that is not part of the official MIT distribution for cross-realm authentication of Windows 2000 and XP clients in child domains.
The authentication processes described earlier are based on a multi-domain model that includes one accounts domain and a resource domain To accommodate multiple account domains or a single domain model, slight modifications to the process may be necessary For additional details on authentication, please refer to the provided references.
• http://calnetad.berkeley.edu/documentation/test_environment/kerb_interop_trip-ups-
• http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/deploy/kerberos.asp
• http://www.usenix.org/events/lisa-nt2000/hill/hill_html/
• http://www.microsoft.com/WINDOWS2000/techinfo/howitworks/security/kerberos.asp
• http://www.umich.edu/~lannos/win2000/w2k-kerberos.html
• http://www.membrain.com/pres/ad_integration_20021112/
• http://support.microsoft.com/servicedesks/ webcasts/so_projects/so7/so7.ppt
• http://windows.stanford.edu/docs/HowWork.htm
• http://web.mit.edu/pismere/MSR-Summer-
2000/DAY1_Finished/KerberosWorkshop_Interoperability/CSGKerberosInterop.ppt
Organizational Units
Active Directory allows for the organization of objects into logical groupings known as organizational units (OUs), which are essential for structuring the directory and simplifying the application of group policies It is important to note that an organizational unit differs from a group, as an object can belong to only one organizational unit at a time.
For large organizations like the University of Florida, it is advisable to restrict Organizational Unit (OU) nesting to seven layers or fewer Typically, this structure includes one level for the college, one to three levels for sub-colleges or departments, one level for geographic locations, and one to two levels for object types such as users, servers, laptops, desktops, and printers The specific arrangement of these levels is determined by each college or department according to their unique business and LAN management requirements.
Figure 10 below gives an example of what the IFAS OU structure might look like Note that this structure is only 6 layers deep.
Group Policies
Group Policies offer essential controls for the Windows 2000/XP computing environment, including account lockout policies and application settings Despite the name, Group Policies are not applied to groups; rather, they are assigned to individual computers, sites, domains, and Organizational Units (OUs) It is important to note that Group Policy Objects (GPOs) are applicable only to Windows 2000 and later versions, with domain security policies being an exception GPOs can be implemented at various levels within Active Directory, typically following a specific order where each new GPO overrides the previous one.
Therefore, when a setting on the local computer GPO and the OU GPO conflict, the
Organizational Unit (OU) Group Policy Objects (GPOs) typically take precedence over local computer GPO settings; however, domain-level security settings, like account lockout policies, are exceptions and remain unaffected by OU GPOs Multiple GPOs can be assigned to a single structure, such as an OU or domain, but the GPO that ultimately applies to a user or computer is determined by security permissions When multiple domain GPOs exist, they are processed in a top-to-bottom order, with the first GPO that the user has permission to access being the one that is applied, while all subsequent domain GPOs are disregarded.
User Group Policy Objects (GPOs) can be applied on a per-machine basis through the activation of loopback policy processing, allowing machine account policies to take precedence over user account policies This approach is beneficial for LAN administrators who aim to prevent users from different colleges from logging into computers and executing their specific user account policies.
Due to the potential complexity of troubleshooting policies, there are a few guidelines that should be followed.
1 Keep it simple There are literally hundreds of policies available It is easy to overuse policies and end up with a computing environment that is difficult to troubleshoot and maintain Often, there are other ways to control the computer operations without using policies Look for these other options first, and use policies as a last resort when there is no other way to implement specific control Also try to keep the number of Group Policy objects in the domain to a minimum A single GPO can be used for multiple OUs.
2 Policies are not a replacement for good security Policies should be used to enhance security, not replace it While policies provide many capabilities, sometimes just using Windows 2000 security delegation is a better option For example, a policy could be implemented to disable the ability to start the AD Users and Computers MMC console However, this may be unnecessary if the user does not have administrative privileges on accounts.
Group Strategy
As the University of Florida transitions to a centralized Active Directory, implementing a cohesive group strategy is essential for simplifying group management across the organization To enhance this group strategy, several key guidelines should be adhered to for optimal efficiency.
1 Use global groups to categorize logical organizational groups that have common functions and need similar capabilities/privileges (such as Accounting,
Native-mode Active Directory enables the nesting of global groups within the same domain, allowing for the aggregation of smaller functional groups into larger ones For instance, Purchasing, Payroll, Accounts Payable, and Accounts Receivable can be consolidated into a single Financial Services global group when it aligns with organizational needs This structure benefits Human Resources, Business Unit Managers, Executives, Administrative Assistants, Solutions Center, Oracle Financials Users, and SMS Admins by enhancing group management and collaboration.
2 Use local groups to assign permissions to resources (such as Apopka Printer
Using local groups for assigning permissions to resources is considered best practice, as they can contain both global and universal groups from any domain within the forest In contrast, global groups are limited to containing only other global groups and user accounts from the same domain By structuring permissions around local groups, the Access Control Lists (ACL) for resources remain stable, eliminating the need for frequent updates whenever a user or group is granted access; instead, users can simply be added to a global or universal group to gain the necessary permissions.
3 Consider using Universal Groups for aggregating cross-domain users into a single group – An example of a Universal Security Group (USG) might be a College
The College Deans group has access to university-wide information across various domains, and its composition may vary based on the selected hierarchy model Each domain may include a global Security group, and to streamline permission management for the College Deans, a Unified Security Group (USG) can be established, encompassing all individual Deans' global groups from each domain When granting resource access, the College Deans USG can be integrated into the local group responsible for that resource.
NOTE: Universal Groups are contained in the global catalog so use them appropriately Be careful not to over-use them or global catalog replication traffic may increase noticeably.
Domain Naming Services (DNS)
Microsoft is transitioning all future Windows computer name resolution from WINS to DNS to enhance scalability and reliability Unlike WINS, which depends on the NetBIOS protocol, DNS is a scalable industry standard for host name resolution Active Directory is fundamentally tied to DNS, requiring a DNS server for installation Workstations query DNS whenever they need to locate Active Directory servers that provide essential services, including domain controllers, global catalog, LDAP, and Kerberos Additionally, Active Directory domain names are derived from DNS domain names.
Microsoft prioritized the reliability and scalability of Windows 2000 DNS, recognizing its crucial role in Active Directory, making it suitable for large enterprises Alongside significant improvements in overall system stability, Windows 2000 introduced new features in DNS that enhance redundancy, security, and scalability.
Dynamic DNS enables Windows clients to automatically register their host names and IP addresses within the DNS zone This feature is crucial as it replaces the dynamic registration of workstations and servers that was previously handled by WINS, ensuring seamless network management and improved connectivity.
• Secure Updates – To prevent hackers from updating a DNS zone with bogus records, Windows 2000 DNS can require a machine to authenticate using Kerberos prior to updating the zone with a dynamic record.
Active Directory-integrated replication offers a multi-master replication model for DNS, akin to domain controllers, ensuring that dynamic DNS registration remains functional even if a primary DNS server fails This is achieved through multiple "primary" DNS zones that utilize Active Directory replication to synchronize updates Additionally, AD-integrated zones are capable of performing zone transfers to secondary servers, enhancing reliability and continuity in DNS operations.
Incremental Zone Transfers (IXFR) enable Windows 2000 to transfer only the changes made to DNS records between primary and secondary servers, rather than the entire zone file This approach significantly decreases bandwidth usage and facilitates more frequent updates to secondary DNS servers.
• Simplified Management – Although Windows 2000 DNS can be updated using scripts, it also provides an easy-to-use graphical interface.
While Windows 2000 DNS offers numerous improvements, large organizations such as the University of Florida have long relied on BIND and possess established expertise in managing BIND servers Consequently, these organizations are generally resistant to transitioning their DNS zones to Windows 2000 DNS, and this reluctance is justified Instead, many organizations opt for a hybrid approach that incorporates both Windows 2000 DNS and BIND.
DNS and BIND to achieve the best DNS support for their end-users Let’s explore these integration options in more detail.
To ensure optimal security, DNS is typically divided into two services: external and internal The external DNS service, accessible from the public Internet, facilitates name resolution for various online services such as web, mail, and FTP servers Conversely, the internal DNS service operates behind a firewall, providing resolution exclusively for internal systems, and serves as Microsoft's replacement for WINS.
Active Directory can utilize BIND for name resolution if the servers run BIND version 8.2.1 or later; however, many companies avoid this due to security concerns related to enabling dynamic DNS on BIND servers Additionally, BIND lacks support for secure dynamic updates from Windows clients Therefore, it is recommended to use Windows 2000 DNS for zones hosting Active Directory to ensure optimal support Integration between Windows 2000 DNS and BIND can enhance DNS services for clients.
With this approach the BIND DNS servers will still run manage non-Active Directory zones and Windows 2000 systems can securely register into Windows 2000 dynamic DNS zones.
For optimal performance in remote locations, it is essential to establish a local domain controller for authentication Implementing Active Directory-integrated zones on these local domain controllers significantly enhances DNS registration and query resolution speed, leading to improved client performance.
Because Windows 2000 supports incremental zone transfers and scheduled attribute- level replication within Active Directory, the impact to WAN connections is minimized. 4.6.4 Domain Considerations
The number of zones in an internal DNS namespace correlates directly with the number of domains, as each domain necessitates its own namespace While not mandatory, it is advisable to configure each domain controller as a DNS server that hosts an Active Directory-Integrated zone for its respective domain In a multi-domain forest, each workstation registers within its specific domain's namespace.
Figure 12 – Multi-Domain DNS Implementation
AD-Integrated zone replication is limited to domain controller servers within the same domain For zone replication across different domains, it is necessary to create a secondary zone in the external domain and configure zone transfers accordingly.
For more information about Active Directory DNS Design and BIND Integration, read the following reference materials:
• Mission-Critical Active Directory by Micki Balladelli and Jan De Clercq, pub Digital Press
• http://www.microsoft.com/technet/prodtechnol/ad/windows2000/deploy/prodspecs/dnsreq.asp
• http://www.microsoft.com/windows2000/techinfo/reskit/en-us/cnet/cncf_imp_vsin.asp
Sites
Active Directory sites are distinct from domains, as a single domain can encompass multiple sites, and conversely, multiple domains can reside within a single site Site objects are stored in the Configuration Naming Context and are replicated across all domain controllers within the forest The primary function of sites is to manage replication traffic between domain controllers efficiently.
An Active Directory site is a collection of IP subnets characterized by reliable, high-speed network connectivity, often defined by the boundaries of a WAN link While domains align with an organization’s logical structure, sites are structured according to physical network topology The primary function of a site is to establish locality and manage Active Directory replication, allowing client computers to authenticate with the nearest domain controller for improved efficiency Additionally, sites enhance WAN bandwidth utilization by compressing inter-site traffic and enable better control of replication schedules, allowing for adjustments during non-peak hours if necessary.
To ensure effective domain authentication on the local area network (LAN), it is essential to have at least one domain controller functioning as a global catalog server at each site Additionally, these domain controllers can offer file and print services, making them valuable for smaller remote offices.
The University of Florida's main campus can be structured as a single site, but as the number of workstations increases, the UF Network Services group must closely monitor network traffic Should authentication or replication traffic escalate or user performance decline, it may be necessary to establish additional sites on the main campus to help manage and isolate traffic effectively.
IFAS remote locations will operate as independent sites linked to the main campus, with replication traffic potentially scheduled over slow connections In cases of extremely slow or unreliable connectivity, SMTP replication connectors can be utilized, though this necessitates the setup of a Certificate Server and should only be considered when no other options for enhancing the connection are available.
The HSC Jacksonville location should operate as an independent site to optimize performance By segmenting the replication traffic between the main campus and Jacksonville, bandwidth utilization can be minimized, leading to enhanced overall efficiency.
Active Directory features intelligent components like the Knowledge Consistency Check (KCC) and Intersite Topology Generator (ISTG) that automate the management of replication topology using complex algorithms, significantly easing administrative tasks However, as the number of domains and sites increases, the effectiveness of these components diminishes, necessitating manual management of the replication topology It's advisable to minimize the number of domains, as each added domain lowers the performance threshold; for instance, while these components can efficiently support two domains with over 200 sites, the performance declines with 10 domains at just 95 sites.
(Number of Domains + 1) * Number of Sites 2 > 100,000
Performance is degraded if this formula is true To avoid this limitation, keep the number of domains to a minimum.
Flexible Single Master Operations (FSMO)
Active Directory features several functions that can be managed by multiple domain controllers; however, there are five unique roles known as Flexible Single Master Operations (FSMO) roles, often referred to as “Fizmo” by experienced users These roles can only be assigned to one domain controller at any given time, and the servers that manage these specific roles are called Operation Masters.
In an Active Directory forest, two essential roles—the Schema Master and the Domain Naming Master—are assigned to a single domain controller Meanwhile, each domain within the forest designates one domain controller to manage the remaining three roles: the RID Master, PDC Emulator, and Infrastructure Master.
The Schema Master is responsible for adding classes and attributes to the forest schema Whenever an application “extends” the Active Directory it communicates directly with this server
The Domain Naming Master plays a crucial role in managing the addition and removal of domains within the forest To prevent naming conflicts, it is essential that domains are not altered when the Domain Naming Master is unavailable.
When a new user or group is created within a domain, it receives a unique security identifier (SID) and relative identifier (RID) that are specific to that domain The server guarantees that every domain controller is allocated its own distinct pool of RIDs, ensuring uniqueness across the domain.
The Primary Domain Controller (PDC) Emulator plays a crucial role in both mixed and native mode Active Directory environments In mixed mode, it facilitates directory replication to NT 4.0 backup domain controllers (BDCs) and updates passwords for older Windows NT and Windows 9x clients Additionally, it serves as the domain master browser when the Windows NT 4.0 browser service is enabled Windows 2000 domain controllers first synchronize password changes with the PDC Emulator, which also assists in authentication by checking for any password updates since the last replication Furthermore, in the root domain of the forest, the PDC Emulator is responsible for synchronizing time with an authoritative network time server (NTP or SNTP) and ensuring that all other domain PDC Emulators are aligned with this time.
This server plays a crucial role in updating cross-domain object references within a domain, specifically by managing the updates for Security Identifiers (SIDs) and Distinguished Names (DNs) of users and groups from other domains that are part of universal and local groups in the current domain.
The follow table summarizes the purpose of each operation master and offers guidance for optimal placement.
Schema Master Responsible for performing updates to the directory schema
For optimal management, it is recommended to assign this role to a global catalog server located in the forest root domain Ideally, it should be hosted on the same domain controller as the Domain Naming Master, as both roles are infrequently utilized and require stringent control.
Master This DC is the only one that can add or remove a domain from the directory.
For optimal management, it is recommended to position this role on a global catalog server located in the forest root domain Ideally, it should be hosted on the same domain controller as the Schema Master, as both roles are infrequently utilized and require stringent control.
RID Master Responsible for processing Relative
Identifier Pool requests from all DCs within a given domain
Best practice is to place the RID master and PDC emulator roles on the same DC.
PDC Emulator Responsible for providing key domain authoritative services such as time synchronization, down-level BDC synchronization, domain master browser, and account lockout.
Best practice is to place the PDC emulator and RID master roles on the same DC.
Infrastructure Master Responsible for updating an object's
SID and distinguished name in a cross-domain object reference
The Infrastructure Master (IM) role should be held by a domain controller that is not a global catalog server (GC).
Table 3- FSMO Placement Best Practices
To effectively implement an enterprise Active Directory with a root domain and a child domain, it is essential to adhere to the minimum recommended hardware specifications outlined in Figure 12 This setup should include at least two global catalog servers in each domain, ideally one in every site, while excluding off-campus domain controllers It is crucial to avoid placing the Infrastructure Master role on a server designated as a global catalog server to ensure proper functionality In scenarios involving multiple domains, the Infrastructure Master role is necessary unless all domain controllers are global catalog servers Conversely, a single domain significantly reduces the number of required domain controllers.
Windows Internet Naming Service (WINS)
Microsoft aims to transition away from NetBIOS, but Windows 2000 marked the first version to rely solely on DNS resolution for its operating system functions Since most Windows operating systems and applications from the 1990s primarily utilized NetBIOS for name resolution, it may take years to phase out these legacy systems and update applications to use DNS Therefore, implementing WINS remains essential for maintaining backward compatibility during this transition.
To mitigate the risk of WINS database corruption during replication, the University of Florida should implement two WINS servers located at different facilities on the main campus, ensuring strong network connectivity between them Although it may appear that remote locations would significantly increase WAN traffic for NetBIOS name resolution, the actual increase is minimal due to the small size of WINS data In fact, the traffic generated from replicating the WINS database to remote servers is likely to surpass that created by WINS registrations and queries.
In rare situations, an additional WINS server may be necessary; however, to minimize the risk of corruption, it is crucial to designate one server as the central hub All other WINS servers should function solely as push/pull replication partners to this hub server.
Figure 14 – WINS Push/Pull Replication Model
RECOMMENDATIONS
Domain Hierarchy / Authentication
1 Shands should create its own forest Although Shands Hospital is closely affiliated with the University of Florida, it is technically a separate legal entity To avoid potential conflicts with FERPA and HIPAA Regulations, Shands should have its own forest and create trusts with domains in the University of Florida forest as appropriate.
The Shands forest can use the GatorLink Kerberos server for cross-realm authentication if necessary This multi-forest support will require that the GatorLink Kerberos server be patched with an unofficial MIT Kerberos patch that was modified by the University of Michigan More information about this patch can be found at http://www.citi.umich.edu/u/kwc/krb5stuff/referral.html.
Account creation and maintenance automation for Shands accounts can be achieved using data from GatorLink and the Campus Registry To implement this, developers need to create a field that indicates whether the account belongs to the UF or Shands forest This flag will enable the broker logic to establish LDAP connections to the appropriate forests based on its value.
2 Try to implement a single domain in the forest root for the entire university.
Organizations like the University of Florida often manage multiple domains, but there are strong advantages to consolidating to a single, large domain This approach can maintain satisfactory performance as long as the directory remains under 1 million objects The following section addresses key questions regarding the design of forest hierarchy options.
Q: Why shouldn’t we implement multiple account domains (one for each college) and let each college manage their own accounts?
A: This is a valid option that provides some benefit to distributed organizations like IFAS, but there are limitations to single sign-on using this approach One benefit to a multiple account domain approach is that it partitions the forest Colleges with remote sites can implement a single remote domain controller at each site that has only the college’s accounts and machine objects in the domain naming context In the event that a WAN link goes down, remote users can still authenticate and get their local file and print services Also, account management and security is distributed to the college.
Multiple account domains make single sign-on more complex to implement and manage An unofficial MIT distribution patch is required to implement child domains.This patch can be found at http://www.citi.umich.edu/u/kwc/krb5stuff/referral.html.For child domains to work with cross-realm authentication, the Window 2000 proxy account must reside in the Kerberos trust path from the location of the machine being logged into The diagram in Figure 15 provides an example If the user Joe,whose proxy account resides in the college.ad.ufl.edu domain, tries to log on to PC2 that is a member of the college2.ad.ufl.edu domain, he will not be authenticated.
Figure 15 – Cross-realm Authentication from Child Domains
Single sign-on integration with the GatorLink Kerberos system is a top priority, although additional account domains may be implemented on an exception basis However, this approach is not advisable for the university as a whole The optimal solution is to consolidate all accounts into a single accounts domain at the root, ensuring that every account is within the trust path between all domains and the GatorLink Kerberos realm.
Q: In that case, why don’t we implement a single account domain with resource child domains for each college and let each college manage the computer and resources in this domain?
A: This is also a valid option, but it has some drawbacks in regards to hardware requirements and remote site authentication Implementing resource domains partitions the computer objects and some application objects into a separate domain naming context, while keeping all user accounts in the root domain There may be certain applications that will be perform better with this approach
Organizations with remote sites face specific requirements for authentication and local services during WAN outages To ensure functionality, each remote location should have multiple domain controllers, one from the resource domain and another from the account domain However, acquiring these additional servers can be costly Conversely, if all resource and user objects are centralized within a single domain, only one domain controller is necessary to facilitate local authentication for remote sites.
Q: Are the limitations or benefits to implementing a single domain?
A: First, let’s discuss the limitations A single domain requires more bandwidth for replication It is probable that remote sites with 56Kb WAN links or slower will need to be upgraded to at least 256Kb to handle the additional Active Directory replication traffic In addition, each college will need to be explicitly delegated control over their OUs Each college will have to conform to a single university security policy, instead of having their own domain security policy Applications that enumerate large portions of the domain objects with queries may not perform as well under this model.
The single domain model streamlines implementation and offers numerous advantages, allowing colleges full control over their user accounts, OU Policies, servers, and workstations Windows 2000 users can easily log into Active Directory using GatorLink credentials from any authorized computer Deploying just one domain controller at each remote location enables local authentication for remote users, while simplified DNS management reduces the risk of DNS islands Additionally, the model supports significant site growth without harming KCC performance or requiring manual site link bridge administration Lastly, automating account creation and management is more efficient with a single domain naming context.
Each college has unique business requirements and priorities, making it essential to choose a model that best fits its needs While the single domain model is generally effective for most colleges, exceptions should be made for those that demonstrate a specific need for their own domain.
3 If additional domains are required, create them only when technical or business needs require it Don’t create separate domains for “political” reasons.
Creating a separate domain solely based on the belief that "if College X has its own domain, my college should too" is misguided A distinct domain is not a status symbol; rather, it serves as a practical solution to specific technical issues that cannot be effectively addressed through Organizational Units (OUs).
The University of Florida's use of multiple account domains is primarily justified for IFAS, which faces challenges due to numerous remote sites and slow connections Replicating the entire university domain may overwhelm current WAN capabilities, necessitating verification through proof-of-concept testing By partitioning IFAS directory objects into a separate domain, replication traffic could potentially decrease by 40-50% However, establishing a distinct account domain for IFAS should only be considered after exploring all other alternatives, as enhancing WAN connectivity to IFAS remote locations may prove to be a more cost-effective solution.
4 Create an OU for all colleges with AD-knowledgeable staff and allow them to manage their own OUs Delegate control of to create and manage all objects within the OU, including accounts, groups, policies, machines, etc It is important for college admins realize that they do not need to be a Domain Admin to have complete control over their users, servers, clients, printers and other objects.
Hardware
6 If more than one domain is necessary, at least 3 dedicated core domain controllers should be purchased per domain to accommodate the FSMO roles Refer to section 4.8 of this document for more information These domain controllers should be from a tier-1 vendor, such as HP, IBM, or Dell All core domain controllers should include hardware RAID, redundant fans, redundant power supplies, and failover networking for maximum uptime.
7 For performance reasons, each remote site with less than 50Kb of consistent, available bandwidth per user should have a local domain controller for authentication, browser services, policy distribution, and directory queries A 10-user remote office with 128Kb circuit would require a local domain controller Yet, a 25-user remote office with a full T1 circuit may not need a local domain controller for adequate performance However, telecom circuits are more prone to outage than campus fiber connections It is also important to evaluate the impact of downtime produced by such an outage before making the decision not to deploy domain controller to the remote site.
8 Try to consolidate server vendors and models This will make server recovery faster and easier because there are fewer drivers to maintain.
Directory Integration
9 Begin developing and testing ADSI routines that will be used for managing Active Directory accounts through the Campus Registry and GatorLink Additional information for programmatically manipulating the Active
Directory can be found at: a http://www.microsoft.com/adsi b http://www.microsoft.com/scripting c Book: Managing Enterprise Active Directory Services by Robbie Allen and Richard Puckett, pub Addison Wesley
10 Start defining the level of directory automation and data synchronization that is needed between the enterprise directories and begin evaluating Microsoft Metadirectory Services 2003 as soon as possible to determine if it meets these needs More information about Microsoft Metadirectory Services
2003 can be found at http://www.microsoft.com/mms.
Disaster Prevention / Recovery
11 Implement a permanent “Test” forest that is on an isolated network where testing can be performed This forest should resemble the production forest and it should be used to test new applications (especially those with schema changes), policy changes, and proof-of-concepts This forest will often identify potential problems that may occur prior to implementation in the production forest Also, this forest provides a place for administrators to learn about new products prior to deploying them into production To reduce the hardware necessary to implement this type of test environment, consider using a product like VMWare that creates multiple virtual machines on a single server.
12 Implement a backup & recovery strategy and test it routinely on the Test network Regardless of the redundancy measures put in place, in most organizations it is inevitable that a problem is going to occur with the Active Directory at some point This might be caused by a faulty 3 rd -party application or operator-error Nonetheless, the more prepared the university is for these disasters, the faster service will be restored It is not good enough to do tape backups alone. You should also periodically test restoring from these backups to ensure that you are prepared and can set expectations accurately in the event of a disaster This is why it is a good idea to use the same model hardware in the test lab as is used in the production environment.
13 Whether using NTBackup or 3 rd -party software, ensure that the Windows
Backing up the System State on domain controllers is essential for recovering Active Directory, as it contains the registry and Active Directory data Most backup solutions necessitate the installation of an agent on the domain controller for remote backups from a tape backup server Additionally, it is crucial to create scripts for backing up the WINS and DHCP databases.
Redundancy
14 Always implement at least 2 global catalog servers in each domain.
15 Maintain an out-of-state domain controller for each domain that can be relied upon in case of a large natural disaster, such as a hurricane.
Name Resolution
16 Implement 2-3 core WINS servers in the NERDC and have all clients use these servers.
17 Implement 2 or more centralized internal DNS servers with AD-Integrated zones for the forest root domain Delegate the ad.ufl.edu namespace to these servers Configure these servers to forwarders to the BIND external DNS servers.
Microsoft recommends that domain controllers operate DNS and maintain an Active Directory-Integrated zone for their domain For optimal performance, clients should configure their settings to use the two nearest DNS servers.
DNS-proficient administrators may choose to host their own AD-Integrated DNS zone They should consider hosting a secondary zone on the forest root DNS servers.
18 If multiple domains are implemented, take configure the DNS servers properly to avoid the risk of “DNS islands” Specifically, on child domain controllers implement DNS forwarders to the root domain DNS servers Create a secondary zones on the root DNS servers for the _msdcs. zones. Ensure that the primary and alternate DNS for a forest root domain controllers is not pointed to itself Instead, it should be pointed to another forest root domain controller For additional information about DNS islands and best practices, refer to
Microsoft Knowledgebase article 275278 and http://www.microsoft.com/technet/prodtechnol/ad/windows2000/plan/bpaddsgn.asp.
Personnel Requirements
19 A minimum of 4 Active Directory trained and certified FTEs should be dedicated to managing the enterprise forest root Initially, this will probably start as a single FTE that works with the college LAN administrators during the standard workday to begin prototyping and piloting the Active Directory As more colleges join the forest, additional support will be required to provide 7x24 support. Responsibilities that these individuals should have are: a Active Directory Service Availability and Performance Monitoring b Server hardware and software maintenance for the root domain controllers. c Maintain Operations Masters for the forest and root domain d Troubleshoot all reported Active Directory problems e Documenting and communicating forest policies created by various Active Directory working groups f Perform backup and recovery services on root domain controllers g Validate root domain tape backups with periodic restores to the test domain. h Manage AD root-level internal DNS (i.e ad.ufl.edu) i Maintain a non-production test forest for prototyping and backup validation. j Work with LAN administrators to test new enterprise applications that will impact the Active Directory (i.e schema changes) k Maintain forest root domain security. l Maintain enterprise Certificate Services. m Maintain root Exchange 2000 Servers that may be implemented. (NOTE: Individual colleges may host their user’s mailboxes own servers if necessary, but they should be part of the same Exchange organization) n Create OUs or domains for colleges or business units as necessary. o Provide technical assistance to the enterprise directory development staff in automating Active Directory functions as necessary. p Provide primary support to LAN administrators whose users are members of the enterprise Active Directory. q Create service level agreement (SLA) document outlining enterprise Active Directory service expectations.
The rapid evolution of Active Directory technologies is closely tied to Microsoft's NET strategy, highlighting the necessity for professionals in this field to remain enthusiastic and updated on the latest advancements in both Microsoft and third-party technologies This is particularly crucial for tools that integrate with Active Directory, such as Exchange 2000 and Titanium Obtaining a Microsoft Certified Systems Engineer (MCSE) certification can further enhance expertise in this dynamic landscape.
A minimum of 2000 certification or equivalent experience is recommended for these positions, along with strong interpersonal skills or training experience These qualities are essential as the roles involve significant interaction with LAN administrators.
20 In addition to FTE’s, additional temporary Active Directory migration expertise will be helpful during the initial migrations to Active Directory.
21 An executive-level memorandum should be published to all university staff and faculty defining the university’s Active Directory support team, including responsibilities and service level agreements (SLAs) Doing this serves a three-fold purpose First, it assigns responsibilities to the appropriate group This proved to work well when the Net Services group took over all networking services behind the wall-plate College management understands that the LAN managers no longer have control over WAN traffic and they cannot fix these types of issues Active Directory Services should be handled in a similar fashion Second, this memo provides general direction about the type of service that colleges should expect from the Active Directory Support team Finally, the memo encourages departments that might not be aware of the enterprise ActiveDirectory implementation to participate.
Migration Projects
22 Implement a migration Active Directory project website where colleges can post their project plans, status, ideas, and challenges they’ve encountered during the migration It is important that project teams learn from each other’s experiences.
23 Implement website that shows the enterprise Active Directory’s status, planned outages, statistics, etc.
24 Implement a Native mode root domain and use migration tools to migrate and restructure the existing directories
25 Evaluate the Aelita, NetIQ, and Quest (Fastlane) directory migration tools.
With each new release, migration tools continuously advance, creating a competitive landscape Dimension Data has successfully utilized various migration tools and reassesses their effectiveness with every update Currently, our preferred tool for migrations is Aelita's Controlled Migration Suite (CMS).
AD Active Directory: Microsoft’s Directory Service for Windows 2000
ADSI, or Active Directory Service Interfaces, consists of a collection of objects that can be accessed through various programming languages such as Visual Basic, JavaScript, and ActivePERL These objects enable developers to effectively manipulate and manage the entities stored within Active Directory, utilizing COM-enabled scripting languages for enhanced functionality.
BIND Berkeley Internet Name Domain: The most widely-used DNS program on non-Windows platforms.
CIR Committed Information Rate: The amount of bandwidth is
“guaranteed” on a burstable frame-relay circuit This is the number that should be used when planning constant WAN activity.
The Dynamic Host Configuration Protocol (DHCP) is essential for dynamically assigning IP addresses to devices within a network When a workstation connects, it sends a request to a central DHCP server to obtain an IP address, facilitating seamless network communication.
The Domain Name System (DNS) is essential software that enables users to find computers on the Internet using domain names within a TCP/IP network A DNS server stores a database of domain names, also known as host names, along with their associated IP addresses For instance, when a user queries the DNS server with the domain name www.mycompany.com, it responds with the corresponding IP address, such as 204.0.8.51.
FERPA Family Educational Right to Privacy Act: A federal regulation that describes an educational institutions’ responsibility for maintaining and securing information about its students.
FIRN Florida Information Resource Network: A state funded and operated frame-relay WAN.
FTE Full-time Employee: A university employee that works at least 40 hours per week.
FTP File Transfer Protocol: a protocol used for sending files across a network.
HSC Health Sciences Center: A large group of colleges focused on health professions at the University of Florida.
HSRP, or Hot Standby Routing Protocol, enhances network resilience by enabling two routers to share a virtual IP address In the event of an active router failure, the standby router seamlessly takes over the virtual IP address, ensuring uninterrupted network connectivity.
IFAS Institute For Agricultural Sciences
IP, or Internet Protocol, defines the structure of data packets, known as datagrams, and outlines the addressing system used within a network Typically, IP is used in conjunction with the Transport Control Protocol (TCP), which creates a virtual connection between the source and destination, ensuring reliable data transmission.
IPX Internetwork Packet Exchange: a networking protocol used by the
Layer 2, also known as the data link layer of the OSI model, plays a crucial role in the transmission of data between nodes It is primarily responsible for the physical transfer of data, and most network switching activities occur at this layer.
L3 Layer 3: the network layer of the OSI model This layer is responsible for routing data from nodes on one network to nodes on another.
LAN Local Area Network: a communications network that serves users within a confined geographical area It is made up of servers, workstations, a network operating system, and a communications link.
LDAP Lightweight Directory Access Protocol: an industry standard protocol used to implement interfaces into and between directories
The Media Access Control (MAC) sub-layer is a crucial component of the data link layer (L2) defined by IEEE standards It is responsible for managing access to shared media, determining whether token passing or contention methods will be utilized for communication.
MAN Metropolitan Area Network: a communications network that covers a city-wide area, usually within a 15-mile diameter These networks typically connect many LANs together with a high-speed fiber backbone.
The Management Information Base (MIB) is a crucial database for network management information, utilized and maintained by protocols like SNMP It allows for the retrieval and modification of MIB object values through SNMP commands, typically via a graphical user interface (GUI) in network management systems MIB objects are systematically arranged in a tree structure, encompassing both public (standard) and private (proprietary) branches.
NIC Network Interface Card: a board which provides network communication capabilities to and from a computer system.
NTP, or Network Time Protocol, is a TCP-based protocol designed to ensure precise local timekeeping by referencing radio and atomic clocks available on the Internet It effectively synchronizes distributed clocks within milliseconds, maintaining accuracy over extended periods.
POC Proof of Concept: initial testing intended to prove the viability of a design concept.
QoS Quality of Service: a measure of performance for a transmission system that reflects its transmission quality and service availability
Return on Investment (ROI) measures the business benefits gained against the resources spent on a project Every project necessitates a specific level of investment, and ROI helps to assess the time required to recover that investment through savings or increased revenue generated by the project's completion.
SAM Security Account Manager: The Windows NT 4.0 directory service and account database.
SNMP, or Simple Network Management Protocol, is a popular protocol for network monitoring and control It facilitates the transmission of data from SNMP agents—software or hardware processes that report on the activity of various network devices like hubs, routers, and bridges—to a workstation console that manages and oversees the network.
TCP (Transmission Control Protocol) ensures reliable transport functions by confirming that all bytes sent are accurately received at the destination It operates alongside IP (Internet Protocol), which provides essential routing mechanisms As a routable protocol, TCP/IP messages include both the destination station's address and the network address, enabling communication across multiple networks globally This capability is a key reason for its widespread use on the Internet Each client and server within a TCP/IP network must have an IP address, which can be either permanently or dynamically assigned during startup.
A VLAN, or Virtual LAN, is a software-defined logical subgroup within a local area network that enables the grouping of user stations and network devices, regardless of their physical location This technology enhances traffic efficiency by allowing communication among devices with shared interests, without the need for physical reconfiguration of cables in the wiring closet.
VPN Virtual Private Network: a communications network that uses encryption technology to transmit data over a public network, such as the Internet The encryption technology creates a protected