Design Document for Fermi National Accelerator Lab
Design Document for
Fermi National Accelerator Lab
Centrify Corporation
10 April 2008
Final Release 1.0
Abstract
The purpose of this document is to document the detail design and implementation of Centrify DirectControl at Fermi National Accelerator Lab.
Centrify Corporation
TEL(650) 961-1100 FAX(650) 962-0307
444 Castro Street, Suite 1100
Mountain View, CA 94041
URL www.centrify.com
Centrify Professional Services Page 1
Design Document for Fermi National Accelerator Lab
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Centrify Corporation.
Centrify may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Centrify, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
(c) 2008 Centrify Corporation. All rights reserved.
Centrify and DirectControl are trademarks of Centrify Corporation in the United States and/or other countries. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
1 Introduction 6
1.1 Purpose of this document 6
1.2 Success Criteria 6
1.3 Definitions, Abbreviations, Acronyms 6
1.4 Visible Dependencies 7
1.5 References 7
1.6 Platforms 7
1.7 Acknowledgments and thanks 8
2 Architecture 9
2.1 Overview 9
2.2 Logical Network Architecture 10
2.3 Description of network architecture 10
2.4 Active Directory Architecture 10
2.5 DNS 13
2.6 Networking 13
2.7 Perl 13
2.8 Authentication Providers 13
2.9 FTP servers 13
2.10 Kerberos 13
2.11 Database Servers 13
2.12 SSH, Telnet, R-protocols 14
2.13 Active Directory Sites and Services 16
2.14 Recommended Active Directory Security Groups 17
2.15 Existing Standards 18
3 Zone Architecture 20
3.1 Zones Overview 20
3.2 Design Goals 21
3.3 Underlying Design Principles 21
3.4 Application of goals and principles to FERMI data 22
3.5 Model 1 22
3.6 Model 2 23
3.7 Selected Model 24
4 Deployment 28
4.1 Zone creation 28
4.2 Zone delegation 28
4.3 User and Groups ignore 29
4.4 Home Directories and shells 29
4.5 UNIX Deployment of DirectControl 29
4.6 NTP Change Options 29
4.7 Group Policies 30
4.8 Applying Group Policy using Active Directory OUs 30
4.9 Recommended Group Policies 30
4.10 SUDOERS File Design 32
4.11 Applying Group Policies 34
5 Post deployment configuration 35
5.1 Account Fulfillment 35
5.2 Maintenance 36
5.3 Existing Processes 36
5.2 User and Group Provisioning 36
6 Schedule Guidance 37
6.1 Timeline 37
6.2 Potential Future Phases 40
6.3 Zone Integration Plan 40
7 Appendix A 42
8 Common Tasks with DirectControl 43
8.1 Architectural Tasks 43
8.2 Analytical [SME] Tasks 44
8.3 Operational Tasks 45
Version History
0.1 / 04/09/2008 / Ron Allmand / Initial version based on customer interviews.
0.2 / 04/09/2008 / Ron Allmand / Second draft based on feedback.
0.3 / 04/10/2008 / Ron Allmand / Final Draft after team review.
1.0 / 04/10/2008 / Ron Allmand / Final Release Design Document
Prepared for:
Fermi National Accelerator Lab
Prepared by:
Ron Allmand
Centrify Corporation
Fermi National Accelerator Lab
Jack Schmidt
Ben Segbawu
Jason Ormes
Wayne Baisley
Ken Fidler
Kirk Skaar
Jack Schmidt
Greg Brown
1 Introduction
1.1 Purpose of this document
This document describes the design for the deployment of Centrify DirectControl at Fermi National Accelerator Lab. All future references for Fermi National Accelerator Lab will be listed as FERMI. The intended audience of this document is the FERMI design team, Fermi management, and the FERMI CIO. This document marks the end of the design phase.
1.2 Success Criteria
* Centralized Management and Authentication
* Reduce Administrative overhead
* Enforce DOE Security Policies
1.3 Definitions, Abbreviations, Acronyms
AD Active Directory
DIT Directory Information Tree
DNS Domain Name System
DOE Department of Energy
GID Group Identifier
IIS Internet Information Server
LDAP Lightweight Directory Access Protocol
OU Organizational Unit
SMS Systems Management Server
SOX Sarbanes-Oxley
SSH Secure Shell
UID User Identifier
UNIX Operating environment. This term includes Unix, Linux,
and Mac OS
UNIX Profile The credentials a user requires to login to a unix machine. This includes username, UID, GID, home directory, and shell.
Zone Group-based administrative control of computer access.
1.4 Visible Dependencies
During the discussion and data collection portion of the design process there were a few operational dependencies that existed within the environment. However, those dependencies will not impact the first portion of this design which is specifically intended to integrate Mac Workstations and Laptops into Centrify DirectControl.
There are some design dependencies that exist for Phase 2 of the project and they have been listed below. Only brief overviews have been provided to act as a placeholder for the eventual UNIX migration design for Phase 2 of the project. These dependencies apply only to the Unix based systems:
· NIS Domains
· BlueArc Filers
· MIT Kerberos
1.5 References
* Centrify DirectControl Administrator's Guide.
* Centrify DirectControl Administrators Guide for Mac OSX.
* Centrify DirectControl Group Policy Guide.
* Centrify DirectControl Best Practices.
* Centrify DirectControl Planning and Deployment Guide.
* Centrify NIS Whitepaper.
1.6 Platforms
* Phase 1: – Mac OSX 5.8
* Phase 2: - Solaris 7, 8, 9, and 10
* “Scientific Linux”
1.7 Acknowledgments and thanks
This project would not have been possible without the hard work and contributions of many talented individuals. Special thanks to:
Name / Project RoleJack Schmidt / Department Head
Wayne Baisley / DSS Manager
Ray Pasetes / CST Manager
Ken Fidler / AD Admin
Jason Ormes / UNIX Admin
Kirk Skaar / MAC Admin
Greg Brown / BD Representative
Ben Segbawu / MAC Project Lead
2 Architecture
2.1 Overview
FERMI is initially deploying Centrify DirectControl 4.0 to approximately 200 Mac OSX workstations to gain administrative efficiencies, ensure any SOX compliance issues are addressed, and to enhance auditing capabilities. The hosts will be integrated with FERMI Active Directory Services and Kerberos for authentication and authorization purposes.
The FERMI network environment is generally suitable for the MAC specific implementation of Centrify DirectControl, without requiring any substantial changes to the FERMI Active Directory architecture or existing infrastructure.
The DNS environment is based on specific DNS servers throughout the infrastructure which are Unix based.
DirectControl 4.0 and Centrify’s build of OpenSSH is not intended for distribution due to the already implemented Kerberos authentication process and the specific MIT Kerberos platform. The MAC machines already utilize this technology for authentication.
The selected Zone Design was based specifically on the integration of the Mac OSX environment within Fermi. Centrify Professional Services continues to leverage well-documented best practices for this design.
2.2 Logical Network Architecture
UNIX based DNS Core technology for managing users, computers, and other resources.
NTP Server Core technology for managing time.
Mac Workstation/Laptop (workstation or laptop) joined to Active
Directory.
2.3 Description of network architecture
The illustration shows the network post-state deployment of DirectControl.
Active Directory Domain Controller. There are existing Domain Controllers deployed and associated with each primary site at FERMI.
DNS servers. Windows Domain Controllers for fermi.win.fnal.gov are integrated with Active Directory, however initial DNS is handled by UNIX DNS Servers.
UNIX computers. These represent a variety of Unix based machines like RHEL, Mac, and Solaris.
NTP Servers. Time synchronization with strata routers will be the standard time service across the enterprise.
2.4 Active Directory Architecture
There is a single in-scope forest at FERMI, and the in scope child domain is fermi.win.fnal.gov which will be the primary focus of this implementation. This forest is running windows 2003 R2.
Figure 21 Forest Structure
Figure 22 ‘fermi.win.fnal.gov’ OU structure
Figure 23 Sample OU structure
Computers Stored in multiple OUs in Computer and Servers
Users Stored in multiple OUs under the Administration and
Users OUs
Groups Stored in multiple OUs under the Administration and
Users OUs
2.5 DNS
FERMI uses the DNS services that are integrated with Active Directory. All in-scope MAC machines use the DNS Servers for name resolution.
FERMI primarily runs a flat level infrastructure with some unique isolated environments. These unique environments are specifically set up with varying subnets for access restrictions and resource controls.
2.6 Networking
The Fermi infrastructure is utilizing workstation based network OS level firewalls with external border routers having specific port/data filtering in place.
2.7 Perl
DirectControl requires Perl 5.8 for processing of group policies. If Perl 5.8 is not installed on a UNIX host then either the version of Perl must be upgraded or installed in an alternate path. This process is documented in Centrify’s Knowledgebase KB-0771.
2.8 Authentication Providers
The FERMI infrastructure has two known additional authentication or authorization services currently in use on the in-scope Mac machines which are using local authorization and for remote access they are using Kerberos authentication. The UNIX environment is running a Kerberos authentication process for access to UNIX resources including the NIS Domain. There is no visible passwd/group file replication in place.
2.9 FTP servers
All FTP servers are protected through the Certificate/Kerberos authentication method as well.
2.10 Kerberos
The FERMI environment currently utilizes MIT Kerberos for user authentication and access authority.
2.11 Database Servers
FERMI currently employs several database servers and clustered environments, they are out of scope for the migration of Mac machines for this design engagement.
2.12 SSH, Telnet, R-protocols
The FERMI Mac OSX population utilizes the Kerberized version of OpenSSH and employs Perl 5.8 which will allow Group Policy integration for Mac machines.
Active Directory design
Below is the new design to support the integration of UNIX machines. The UNIX OU is placed as high in the domain as possible
The UNIX OU “ou=unix” will be created as a high-level OU. One option has been to place the OU UNIX below a high-level OU [example CENTRIFY OU as the high level OU and UNIX as a sub-level OU]. Then, filtering Group Policy Inheritance so that it only applies the default domain policy. This sort of placement would also protect the Mac environment from getting policies not intended for Mac computers, or after Phase 2 UNIX hosts; thereby protecting them from any unintentional impacts generated by the implementation of a group policy.
Figure 24 Active Directory Design
This is a simple overview of the UNIX OU creation and the migration points for the unix hosts ‘ou=computers,ou=unix’.
Computers OU for Unix computers. Sub-OUs can be created below this OU for application of computer group policy.
Groups OU for all Unix specific groups
SVCACCTS OU for Unix based service accounts.
Zones Organizational unit for storing Centrify application-specific data. See the next illustration for further details.
Figure 25 Zones and AD
Based upon the way FERMI does administration, it is recommended that all zones be below the UNIX Organizational Unit.(In the diagram above an optional high level OU is listed) Administration for the in-scope MAC machines are performed centrally and the majority of the Mac machines are physically located at the Chicago facility.
It is strongly recommended that the UNIX profiles, Zone data, licenses, and other associated application-specific data be stored in the recommended location where the zones are defined (cn=zones,ou=unix). Licenses should be stored in "Program Data - Centrify" path. This will allow for rapid deployment, reduce operational complexity, and ensure full version compatibility for future releases.
2.13 Active Directory Sites and Services
There are multiple sites defined geographically by name but are not actually defined by operational sites. The operational structure remains flat in nature.
2.14 Recommended Active Directory Security Groups
Traditionally, Centrify Professional Services recommends the creation of separate security groups named “Zone Administrators”, “Fullfillment”, and “JoinOperators” including the delegated ability to create UNIX profiles in existing Zones for existing Active Directory User and Group objects. The FERMI Project Integration team will review the recommended security groups with the current Active Directory team to ensure this is the most practical and effective approach for FERMI.
ZoneAdmin. Members of this Active Directory security group can create new Zones, delegate permissions on existing Zones, and delete Zones. Without this Active Directory Group, only Active Directory Administrators and Enterprise Administrators would be able to create new Zones.
This group requires the following permissions on “ou=Zones,ou=UNIX”. These permissions must be set using ADSI Edit.
On the “Object” tab:
Create Container Objects (This object and all child objects)
Delete Container Objects (This object and all child objects)
On the “properties” tab:
Read All Properties (this object only)
Write displayName (This object and all child objects)
Fulfillment. Members of this Active Directory security group can create, modify, and delete UNIX profiles for Active Directory Users and Groups. This group may have nested group membership with existing UNIX fulfillment teams.
It is recommended that during the initial user and group migration from UNIX to Active Directory, the membership of Fulfillment will be temporarily expanded. This will be to allow members of the project team to use the DirectControl Console Import Wizard to migrate large numbers of UNIX profiles for users and groups.