ACTIVE DIRECTORY RULES OF ENGAGEMENT

Transcription

1 ACTIVE DIRECTORY RULES OF ENGAGEMENT Version: 1.14 Date: 03/21/2016 SECURITY WARNING The information contained herein is proprietary to the Commonwealth of Pennsylvania and must not be disclosed to un-authorized personnel. The recipient of this document, by its retention and use, agrees to protect the information contained herein. Readers are advised that this document may be subject to the terms of a non-disclosure agreement. DO NOT DISCLOSE ANY OF THIS INFORMATION WITHOUT OBTAINING PERMISSION FROM THE MANAGEMENT RESPONSIBLE FOR THIS DOCUMENT. Enterprise Data Center Application Management Team EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 1 OF 32

2 Version History Date Version Modified By / Approved By Section(s) Comment 4/03/ K. Will All Initial draft 5/24/2007 S. Sharma Incorporated S. Sharma comments: Replace Windows 2000 references with Windows 2003; move Total Cost of Ownership reference, add Maintenance and Backup sections 10/19/ C. Reber All Updated format to new template design. Updated URLs. 02/25/ S. White C. Reber 1.2 Updates to flow in 1.2 per S. White. 11/14/ C Reber Cover Page Insert new OA logo on cover page 03/17/ / C Reber All Update URLs 07/15/ C Reber 1.1 Update ECSA to reflect new CA2 designation. Update URLs for the deployment process. 03/04/ C Reber 3.6 Remove references to MOM and Getting Started link 03/18/ Matt Wentling / C. Reber 3.2 Change verbiage: managed by ESF to fully managed by ESF Remove examples from SRV=Service account / upd urls 05/25/ Dave Melville / C. Reber 3.3 Add new Appendix B Managing MUSER Passwords/Accounts Added new cover page and edits per OA web team standards. 11/16/ C. Reber All Change ESF to EDC. Change SC to ESR. 11/23/ Shobha Sharma / C. Reber Update USER/MUSER domain information 06/14/ Earl Gable All Update document to reflect Windows Server 2008 domain structure. 04/11/ C. Reber All Remove references to Remedy, replace with general term incident 09/15/ B. Muller All Update to reflect Windows Server 2012 R2 03/21/ Nayan Mitra Section Update to reflect new screen for password change EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 2 OF 32

3 Table of Contents 1 EDC OVERVIEW & EDC INFRASTRUCTURE EDC OVERVIEW EDC Engagement Process EDC Deployment Process Commonwealth Application Certification and Accreditation (CA 2 ) EDC INFRASTRUCTURE External DMZ Security Zone Internal Services Security Zone Internal DMZ Security Zone ACTIVE DIRECTORY IMPLEMENTATION PURPOSE / OVERVIEW Benefits ASSUMPTIONS SCHEMATIC DIAGRAM / DIAGRAM DESCRIPTION DETAILS EDC LAN (Extranet) Internet Access Business Logic Layer (BLL) PREREQUISITES IMPLEMENTATION DETAILS EDC Active Directory Implementation Details & Schematic Diagrams Location and Role of Domain Controllers EDC Active Directory Organization Units (OUs) APPS Domain USER Domain and MUSER Domain ACTIVE DIRECTORY RULES OF ENGAGEMENT RULES OF ENGAGEMENT OVERVIEW NAMING CONVENTIONS Server Names Service Accounts User Accounts SERVICES Applications Residing in Managed Services Applications Residing in EDC Co-Location Applications Residing in Agency Location EDC GROUP POLICY OBJECTS (GPOS) ROLES AND RESPONSIBILITIES MONITORING SECURITY Windows 2008 R2 Authentication Architecture Windows Methods of Authentication Certificate Authentication Forms Authentication Recommended Authentication Methods Application Security BACKUP AND RECOVERY CHANGE MANAGEMENT MAINTENANCE ACTIVE DIRECTORY AND APPLICATION DEVELOPMENT RESOURCES ACTIVE DIRECTORY RESOURCES APPLICATION DEVELOPMENT RESOURCES EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 3 OF 32

4 5 APPENDI A SCHEMA MANAGEMENT PROCESS APPENDI B MANAGING MUSER PASSWORDS/ACCOUNTS CREATING A NEW MUSER ACCOUNT RESETTING A MUSER ACCOUNT PASSWORD MUSER Password Reset Rules MUSER Password Reset Instructions EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 4 OF 32

5 1 EDC Overview & EDC Infrastructure This section contains standard information that is included in all ROE documents. 1.1 EDC OVERVIEW The Commonwealth of Pennsylvania s Enterprise Data Center (EDC) provides hosting services for agency web-based and agency specific applications. Its mission is to maintain a high level of security, availability, reliability, and management of the Commonwealth of Pennsylvania's mission critical web applications. Refer to the Enterprise Data Center website, for a full description of the EDC and all hosting and service offerings EDC Engagement Process If your agency is considering deploying applications in the EDC, first examine the EDC website to understand the EDC Services Portfolio, and then contact your Enterprise Services Representative who acts as a liaison between agencies and the EDC. They answer preliminary questions and coordinate meetings with EDC personnel to ensure consistent communication on simple or complex projects EDC Deployment Process The EDC follows a well-defined deployment process for all application deployments. Application development is performed at the agency or contractor location while the EDC houses both a staging and a production environment, which are mirror images of each other. This structured deployment and testing process ensures a stable application in production. Refer to Deploying in Managed Services to review MS deployment process documents Refer to Deploying in Managed Services Lite to review MSL deployment process documents Commonwealth Application Certification and Accreditation (CA 2 ) Prior to entering the EDC every new application is required to undergo a security assessment. It is the responsibility of each agency to ensure that the security assessment is completed for their application. Refer to Commonwealth Policy ITB-SEC005 regarding "Commonwealth Application Certification and Accreditation" Click to initiate the Commonwealth Application Certification and Accreditation (CA 2 ) Process. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 5 OF 32

6 1.2 EDC INFRASTRUCTURE The EDC architecture is segmented into security zones that are isolated from each other via firewalls. The EDC network contains the External DMZ security zone, the Internal Services security zone, and the Internal DMZ security zone. These three primary networks are either, physically or logically, connected to one another. MAN Internet Agency MAN site Agency Firewall EDC Intranet Firewall Perimeter Firewall Internal DMZ / Services Managed Services Lite Internal DMZ Managed Services Internal Services Managed Services Internal DMZ Co-location Internal Services Co-location External DMZ Managed Services External DMZ Co-location External DMZ Managed Services Lite EDC InterZone Firewall External DMZ Security Zone The External DMZ security zone contains Internet-facing servers that are connected to the Enterprise DMZ. EDC-managed web servers (such as Managed Services) and agency-managed servers (such as Co- Location servers) both exist in the External DMZ Security zone. Managed Services and Co-Location servers are on separate subnets secured by either firewalls or Access Control Lists (ACLs) Internal Services Security Zone The Internal Services security zone contains Managed Services database servers and other application servers from which dynamic content is obtained by web servers Internal DMZ Security Zone The Internal DMZ security zone contains the Managed Web and application servers that need to be accessible only from the Commonwealth Metropolitan Area Network (MAN). This Security Zone also contains internal Co-Location databases and web and application servers that are isolated from the Managed Services servers. When EDC Domain Controllers intercommunicate in a security zone, all communications use standard RPC and do not require IPSEC encryption or authentication. Domain Controller-to-Domain Controller communications between security zones only use IPSEC with Authentication Headers (AH). Other host-to-ad Component communication in the Managed Services portion of the Enterprise Data Center does not require IPSEC. However, IPSEC is required for all communications between entities outside the Managed Services and EDC AD components. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 6 OF 32

7 2 Active Directory Implementation 2.1 PURPOSE / OVERVIEW The Commonwealth of Pennsylvania s EDC uses the Windows Server 2012 R2 Active Directory (AD) and server infrastructure to separate the commonwealth s enterprise AD forest applications from those applications that can be accessed internally and externally. The Applications Management Team (AMT) manages the EDC Active Directory environment Benefits Based on a study conducted by Gartner, the Total Cost of Ownership for the EDC AD is a fraction of an in-agency Active Directory solution that includes hardware, software, operations, and facilities. Your agency gains these benefits when you use EDC AD: OA provides a secure location to host the Active Directory and dependent functions (such as DNS). The application can use existing authentication and authorization data from either the APPS domain (EDC) or the internal PA.LCL domain (CWOPA), which provides the agency s internal users with single sign-on to its application. Windows 2012 R2 Active Directory schema changes to accommodate applications can be made in the EDC AD forest, the PA.LCL forest, or both at the discretion of the Architectural Standards Committee and Schema Management Board. See Appendix A Schema Management Process for details. Internal IT staff is freed up to work on agency strategic initiatives. AMT will provide 24x7 monitoring, management, and support to provide increased reliability, availability, scalability, and security as well as improve application authentication through EDC Active Directory. EDC Active Directory is highly available with built-in redundancy, disaster recovery, and multiple locations for access. EDC has the knowledge and expertise to maintain and manage Active Directory and is fully engaged with Unisys and Microsoft to diagnose, troubleshoot, and resolve any issues or problems 2.2 ASSUMPTIONS This document assumes that the reader has a basic understanding of AD concepts including: Forests Domains Organization Units (OUs) Objects Schema DNS AD Management Principles Note: Appendix B Active Directory and Application Development Resources contains references that discuss each of these assumptions in depth. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 7 OF 32

8 2.3 SCHEMATIC DIAGRAM / DIAGRAM DESCRIPTION DETAILS The network architecture is the key component of the functionality and security of the EDC LAN (extranet). This diagram shows how EDC network deployment relates to Active Directory. Three primary networks within the deployment are either - logically or physically - connected to one another to make up the EDC network: EDC LAN (Extranet) Internet Access Business Logic Layer (BLL) EDC LAN (Extranet) The extranet resides in the CTC Internet Zone (Demilitarized Zone or DMZ) and contains Internet Information Services (IIS), domain controllers, and other AD infrastructure such as DNS and WINS. Through router security permissions or the Access Control Lists (ACLs) on the router/firewall between CWOPA and the extranet, all traffic that originates from CWOPA is allowed into the extranet. If a resource on CWOPA is pushing data to a server on the extranet, all communication is allowed. In reverse, all traffic originating from the extranet is blocked going back to CWOPA. If a batch job attempts to run a process from an extranet machine that initiates communication back into CWOPA, the traffic is blocked by the ACLs on the router between CWOPA and the extranet. Data on CWOPA servers is either pushed to the extranet from the CWOPA resource or the CWOPA resource must reside in the extranet. Within the extranet, all servers are homed to the same network and are allowed to communicate with one another assuming appropriate rights between resources. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 8 OF 32

9 The servers located in the extranet communicate back to CWOPA through Internet Protocol Security (IPSec). This table shows the approved ports and associated functions for Active Directory communication that is allowed to traverse from the extranet to internal Active Directory servers: Ports and Protocols Accessible from DMZ to CWOPA Internal Network Protocol Description 50 Encapsulating Security Protocol (ESP) for IPSEC 51 Authentication Header (AH) for IPSEC Port Type Description 20 and 21 TCP and UDP FTP 25 TCP and UDP SMTP (outbound only) 80 TCP and UDP http 443 UDP SSL Internet Access The external firewall (Internet-facing) manages traffic between the internet and the extranet. Clients accessing web sites in the Extranet are allowed to connect via the Internet once the proper credentials are supplied to the Active Directory. Ports Accessible from Internet to Extranet (DMZ) Network Port Type Description 53 TCP and UDP DNS name resolution and zone transfers 88 TCP and UDP Kerberos 389 TCP and UDP LDAP 500 UDP ISAKMP for IPSEC Business Logic Layer (BLL) The current design of the EDC DMZ allows only Internet services such as http, https, and other basic services like FTP and SMTP through the internet-facing side of the DMZ. All management and database access to co-located servers is via an intranet-only routable back-end address through the Business Logic Layer (BLL). BLL ensures that agency traffic including management traffic such as FTP, web administration, backups, terminal services, or other remote management software and back-end data traffic such as database traffic between the co-located server and the agency have a secure, higher-speed path that is not available from the Internet. To facilitate this design, a network card is added to every co-located server and configured with an intranet routable address. The default gateway is left blank for this interface, and persistent routes are added for each agency server or management station that needs BLL access. BLL security advantages are: Only http, https, FTP, and SMTP access are allowed from the Internet Separate paths exist for public and agency data BLL cannot be reached directly from the Internet EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 9 OF 32

10 BLL performance advantages are: Separate NICs and ingress/egress paths for front and back end access provide more aggregate bandwidth via less congested facilities Fewer hops and higher speed links between the data center Co-Location area and the agencies Because persistent routes need to be added to allow proper routing to agency systems across the BLL, front-end access from these same systems can be problematic. Traffic that is sent to the front-end from such a host may be routed back across the BLL, and the return traffic is sourced from the BLL address rather than the co-located server s front-end address. When this traffic reaches the agency host originating the traffic, it is dropped as invalid. To improve security, EDC operating policy states that front-end access to a co-located server is not supported for any system that accesses that same server via the BLL. However, we understand that in some cases agencies may not be able to discontinue such front-end access from management stations or servers. 2.4 PREREQUISITES Applications must meet these requirements to use EDC AD in the EDC: The application must be integrated to run on the Windows Server family of operating systems and must be able to use integrated security (Active Directory Authentication). AMT has full administrative access over the Active Directory Forest. The EDC forest trusts the CWOPA (PA.LCL) domain. This trust facilitates the single sign-on security model whereby user accounts in CWOPA can be used to grant access to the applications in the EDC. If you have non-windows based applications or another situation not identified in this document that requires Active Directory or any directory service, engage the Architectural Standards Committee at [email protected] to discuss business requirements, architecture, and possible solutions. See Appendix A Schema Management Process for details. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 10 OF 32

11 2.5 IMPLEMENTATION DETAILS EDC Active Directory Implementation Details & Schematic Diagrams EDC implemented a single forest/multiple domain model for Active Directory. An empty root called ROOT.STATE.PA.US resides within the forest. This domain houses the Enterprise Admins role, Schema Admins role, and forest-wide FSMO roles. Applications reside in APPS.STATE.PA.US and user accounts are divided between two domains: USER.APPS.STATE.PA (USER) and MUSER.APPS.STATE.PA.US (MUSER). USER houses non-managed users or self-registered users similar to a typical portal user with customized content like PA PowerPort. USER domain security is commensurate with requirements for Internet applications. MUSER houses managed users, constituents, and vendors that must access line-of-business applications or other applications where authorization and security are critical. The sponsoring agency performs user, group, and authorization management similar to the way CWOPA is managed. This diagram shows a high-level view of the CWOPA and EDC Active Directory namespace as defined in the functional specification Location and Role of Domain Controllers Go to DIRECTORY-DNS/Domain Controller/Domain Controllers.xls to view the most up-to-date information about the domain controllers within this environment EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 11 OF 32

12 2.5.3 EDC Active Directory Organization Units (OUs) This diagram shows the Organization Units (OUs) for the EDC Active Directory namespace as defined in the functional specification. Applications reside in APPS.STATE.PA.US (APPS) and user accounts reside in USER.APPS.STATE.PA (USER) and MUSER.APPS.STATE.PA.US (MUSER) APPS Domain AMT controls and manages the APPS domain and defines and maintains all levels of OU structure. AMT recommendations for OUs in the APPS domain are: OU depth should not exceed four levels The top level OU is the agency OU and consists of the agency s 2-digit code The second level consists of the servers OU and service accounts OU Lower level OU recommendations are: 6 characters maximum length; optional if it applies to the agency s IT administration model Groups may be placed in all OUs starting from the agency OU OUs are locked down by default with changes initiated through the initial deployment process or a service request (incident ticket). Currently, delegated permissions over OUs within the APPS domain are not supported. Machine accounts are ONLY created by AMT through the initial deployment process or a service request. Delegated permission to the APPS domain is restricted to maintain stability and security for all agencies and applications. EDC personnel handle all change requests including, but not limited to, server creation/deletion, service account setup, and group policy placement. (GPO creation and management are discussed in depth in a later section.) USER Domain and MUSER Domain All self-registered users are housed in the PALogin OU for the USER domain. AMT defines and maintains the top three levels of the MUSER OU structure. AMT recommendations for OUs in the MUSER domain are: OU depth should not exceed four levels The top level OU is the agency OU and consists of the agency s 2-digit code The second level consists of the application name and user container AMT gives agencies delegated permissions over their OUs. An agency can administer only that portion of the directory that pertains to them (their own OU). Since the MUSER.APPS.STATE.PA.US domain enforces tighter security policies, EDC Tools is the only supported means of maintaining user accounts in the MUSER domain. Submit a request for EDC personnel to configure EDC Tools access for the agency application. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 12 OF 32

13 Authorized MUSER OUAdmins can use the EDC Tools website: to create, modify, and delete users within the agency s OUs; create commonwealth employee accounts and vendor accounts; reset passwords; and unlock accounts. However, EDC Tools cannot change employee IDs that are entered incorrectly. Please reference Appendix B Managing MUSER Passwords/Accounts for instructions of how to create a new MUSER account and how to reset MUSER passwords using the EDC Password Manager. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 13 OF 32

14 3 Active Directory Rules of Engagement 3.1 RULES OF ENGAGEMENT OVERVIEW This section discusses EDC Standards and aspects of services provided for the Active Directory. 3.2 NAMING CONVENTIONS Naming conventions provide a standard approach to naming different objects and help to troubleshoot and locate objects. All objects also need a detailed description of use. Naming conventions are as follows: Naming conventions provide a standard approach to naming different objects within Active Directory and help to troubleshoot and locate objects. All objects also need a detailed description of use. A description field is available for all User, InetOrgPerson, Computer, Group, OU and Container objects within Active Directory Server Names When a server name is based on location, browsing or searching by the first part of the server name returns all servers from all agencies (for example, searching on HBG returns all HBG servers from all agencies). Since multiple agencies exist in the same location, use the two-digit agency code at the front of the server name to locate an agency s servers, rather than the location name. As all new servers are built, the recommended naming standard is AALLLFFE, where: AA = Agency code LLL = Location code; for example: CTC = Commonwealth Technology Center, WLO = Willow Oaks, CAM = Cameron Street FF = Function code; for example: BT = BizTalk, E = Exchange Server, IS = Web Server, SQ = SQL Server, AP = Application E = Environment; for example: T = Test lab, S = Staging, D = Development, P = Production, R=Disaster Recovery = Unique number that increments based on use The recommended cluster naming standard is Server name\sc(e)(), where: SC = Server Cluster E = Environment; for example: T = Test lab, S = Staging, D = Development, P = Production, R=Disaster Recovery = Unique number; for example: 001 (should be the same as the server s name) If the application is hosted and fully managed by EDC, the predefined two-digit code is EN for Enterprise Service Accounts As an agency has more applications hosted in the Applications AD, more service accounts must be used for applications. The recommended naming standard is AASRVFFE, where: AA = Agency code SRV = Service account FF = Function code; for example: BT = BizTalk, E = Exchange Server, IS = Web Server, SQ = SQL Server, AP = Application E = Environment; for example: T = Test lab, S = Staging, D = Development, P = Production = Unique number that increments based on use If the application is hosted and fully managed by EDC, the predefined two-digit code is EN for Enterprise. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 14 OF 32

15 3.2.3 User Accounts The server operations team performs an initial bulk creation of user accounts based on an Excel spreadsheet that the agency provides. Follow this naming standard for these accounts: A user name has three parts: a first name, a last name, and middle initial. Use these parts to construct a user account name where the variables are FirstName, LastName, and MiddleName and %n represents an integer number of characters of the variable from the left. For example, %5Godzilla is equal to Godzi. If a particular user account name already exists, follow this list until a unique user name is found: 1 - %1FirstName%9LastName 2 - %2FirstName%8LastName 10 -%1FirstName%1MiddleName%8LastName 11 -%2FirstName%1MiddleName%7LastName 18 -%1LastName%9FirstName 19 -%2LastName%8FirstName 27 -%1MiddleName%1FirstName%8LastName 28 -%1MiddleName%2FirstName%7LastName 35 -%1FirstName%8LastName%1MiddleName 36 -%2FirstName%7LastName%1MiddleName 43 -%1MiddleName%8LastName%1FirstName 44 -%1MiddleName%7LastName%2FirstName If you exhaust all these options, use numbers from 01 to 99 as suffixes to these options in order based on availability. User names should not exceed 12 characters (10 characters without numerals). 3.3 SERVICES The EDC AD is a critical part of the Enterprise architecture for single sign-on, security, and identity management. Applications can leverage the EDC Active Directory in three scenarios: as part of Managed Services, as a Co-Location customer, or for Active Directory benefits only. Within this section, front-end represents all servers and services such as the web servers, portal services, and applications, and back-end represents servers and services whose resources the front-end servers use for information or data. The EDC AD forest is optimized for use in an internet data center or hosting environment rather than a distributed corporate-like or CWOPA environment. The EDC AD is optimized to rapidly replicate directory data, handle a high volume of authentication requests per second, and facilitate tightly managed services for high reliability, availability, and security. The directory is deployed in a centralized model to accommodate these requirements optimally Applications Residing in Managed Services Managed Services is where EDC provides complete management for either or both front-end and backend servers and services located in the EDC. Managed Services uses the EDC Active Directory and is the ideal way for an agency to leverage the full enterprise infrastructure of single sign-on, identity management, security, and directory services. All servers, users, groups, and policies are maintained in Active Directory similar to the way that commonwealth employee user accounts and mailboxes are maintained in CWOPA Applications Residing in EDC Co-Location Co-Location hosting is for agencies that want to retain full management responsibility for day-to-day hosting within a secure and conditioned environment. The CTC EDC provides a highly secure and conditioned environment with access to high bandwidth and security-enhanced internet connectivity. Co-Location services also provide the benefits of Active Directory for its customers. Co-Location customers can add their servers into Active Directory to leverage single sign-on, integrated security, added server management through group policy, and complete integration with the enterprise infrastructure. Directory-enabled applications should reside in Co-Location or Managed Services for optimal directory accessibility and performance. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 15 OF 32

16 Certain server or service configurations such as IPSEC are required for all communication with the domain. Contact your AAM for details. Applications Residing in EDC Co-Location Applications Residing in Agency Location Some agencies choose to house all of their servers in a location outside the physical and logical locale of the EDC. Agencies that need to leverage the enterprise architecture and have identified requirements to use the EDC Active Directory can leverage the EDC AD services across the network. This configuration requires careful planning and analysis to avoid unexpected problems. Agencies in this situation should contact their AAM immediately for further assistance. Another Active Directory option for remote use of directory services is to distribute a domain controller to a remote site (decentralized domain controllers). The EDC AD is deployed and optimized for a high volume hosting environment and therefore requires architectural changes to accommodate a distributed architecture. Accommodating this requirement involves multiple design and facility considerations that an agency may or may not be able to fulfill. Some factors that affect the decision for decentralized domain controllers are: EDC AD design considerations for remote placement of domain controllers such as site topology/gc placement, replication latency, and secure network transmissions EDC or agency access to physical remote domain controllers add cost and risk to managing and securing the Forest Post-deployment management and monitoring of EDC changes to domain controllers involves added complexity and cost EDC must actively manage the real available bandwidth or bandwidth guarantees from agency to EDC for Active Directory operations This list demonstrates why decentralized domain controllers are the least preferred method and not a currently supported solution. However, the EDC is committed to addressing the emerging business needs of the commonwealth. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 16 OF 32

17 If your agency requires a distributed domain controller or remote use of the EDC Active Directory, contact your AAM to request a consultation. Please include the nature of your request and all relevant information. Applications Residing in Agency Location EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 17 OF 32

18 3.4 EDC GROUP POLICY OBJECTS (GPOS) EDC implements domain policies that include password, machine account, and user account policies. The agency maintains and applies group policy at the OU level in Co-Location. The current EDC domain policy for MUSER.APPS.STATE.PA.US is: Policy Default Setting Setting Configuration Password Policy Enforce password history is the maximum value Maximum password age Mimimum password age 0 2 Mimimum password length 0 7 Passwords must meet complexity requirements Disabled Enabled Store passwords using reverse encryption Disabled Disabled Account Lockout Policy Account lockout duration Disabled Account is locked out until Administrator unlocks it Not applied to APPS domain Account lockout threshold Disabled 5 Accounts locked out after 5 failed attempts Reset account lockout counter after Disabled 720 Failed attempt reset after 12 hours Audit Policy Audit account logon events No auditing Success, Failure Audit account management No auditing Success, Failure Audit directory service access No auditing No auditing Audit logon events No auditing Success, Failure Audit object access No auditing Failure Audit policy change No auditing Success, Failure Audit privilege use No auditing Failure Audit process tracking No auditing No auditing Audit system events No auditing Failure Security Options Allow system to be shut down without having to log on Disabled Restrict CD-ROM access to locally logged-on user only Enable File servers may need to share CD-ROMs Restrict floppy access to locally logged-on user only Enable Smart card removal behavior No action Force logoff Event Log Policy Maximum application log size 512 kilobytes 5056 kilobytes Maximum security log size 512 kilobytes kilobytes Maximum system log size 512 kilobytes 5056 kilobytes EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 18 OF 32

19 Policy Default Setting Setting Configuration Prevent Local Guest group from accessing application log Disabled Enabled Prevent Local Guest group from accessing security log Disabled Enabled Prevent Local Guest group from accessing system log Disabled Enabled Retain application log Retain security log Retain system log Retention method for application log Retention method for security log Retention method for system log Not defined Not defined Not defined As needed As needed As needed Event Log ACL Not configured Enabled Configure the Registry so that only domain administrators can clear event logs System Services Alerter Computer Browser DHCP Client Distributed File System Distributed Link Tracking Client Distributed Transaction Coordinator DNS Client Event Log IPSEC Services License Logging Local Disk Manager Messenger Net Logon Plug and Play Print Spooler Protected Storage Remote Procedure Call (RPC) Remote Registry Removable Storage Secondary Logon Security Accounts Manager Server Smptsvc EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 19 OF 32

20 Policy Default Setting Setting Configuration System Event Notification Task Scheduler TCP/IP NetBIOS Helper Windows Time Workstation Application Management Manual ClipBook Manual Network DDE Manual Network DDE DSDM Manual Remote Access Connection Manager Manual Rsvp Manual \Winnt and all subfolders File System Policy Administators SYSTEM CREATOR/OWNER Domain Users Full Control Full Control Full Control Read \Winnt\Repair Administators Full Control \Winnt\System32\config \Winnt\System32\spool <log partition> Control Panel Administators SYSTEM CREATOR/OWNER Domain Users Administators SYSTEM CREATOR/OWNER Power Users (w/s only) Domain Users Administators SYSTEM CREATOR/OWNER Everyone Full Control Full Control Full Control List Full Control Full Control Full Control Full Control Read Full Control Full Control Full Control None Hide Screen Saver tab Not configured Not configured Users should not be able to change the screen saver Screen saver executable name Not configured Not configured 32-bit logon screen saver Password protect the screen saver Not configured Not configured Password protection needed Screen saver timeout Not configured Not configured Terminal Services Set time limit for disconnected sessions Not configured Enabled End a disconnected session: 1 day EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 20 OF 32

21 Policy Default Setting Setting Configuration Set time limit for active but idle Terminal Services sessions Not configured Enabled Idle session limit: 1 day Terminate session when time limits are reached Not configured Enabled 3.5 ROLES AND RESPONSIBILITIES This table outlines the administrative and management task responsibilities for EDC, Customer, and combined AMT and Customer. AMT has completed most of its responsibilities in setting up Active Directory. Role/Responsibility EDC Reponsibility Customer Responsibility Domain Management FSMO Replication Domain Policy Password Policy Schema Management Group Policy (Common) Domain Controller Maintain operating system Apply service packs/security rollup packages/patches Apply security templates Disaster recovery Deploy/Install DC OU Management Create top level (Agency OU) Permissions on top level Create Secondary/Tertiary Permissions on second and third level OU Create group policies (OU only for agency in Co-Location) User Management Create users Create groups Modify users Modify groups Delete users Delete groups Create machine accounts EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 21 OF 32

22 Delete machine accounts EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 22 OF 32

23 3.6 MONITORING Since Active Directory is such a critical component of the EDC infrastructure and the applications running in this environment, monitoring and managing Active Directory is essential to ensure the availability and performance of agency business applications. EDC operations deliver an enterprise-class solution for operations management and monitoring of Windows servers, Windows infrastructure including Active Directory, and.net Enterprise servers such as SQL server. EDC manages critical functions to ensure that Active Directory services are operational and performing at a high degree of reliability. The Active Directory health indicators that EDC considers critical are: Ability for users to log on quickly to access to network resources Quick responses to LDAP queries Consistent data on all domain controllers Replication occurs within expected timeframes Quick response to correcting outages All role masters up and running Stable CPU usage on Domain Controllers Reduced WAN traffic To monitor these AD critical functions, SCOM uses these indicators to ensure EDC AD health: No errors or warnings in relevant logs such as AD, DFS, LSASS, and many more Replication latency CPU utilization Free space Disk queue length LDAP ping/query times Cache hit rates Role holder priorities 3.7 SECURITY Windows 2012 R2 Authentication Architecture Windows 2012 R2 is built upon two basic authentication types: local (or interactive) authentication and network (or non-interactive) authentication. Each authentication type has a slightly different architecture. A local authentication occurs when a user logs on through a user interface. (For example, a user initiates a workstation logon sequence such as CTRL-ALT-DEL to authenticate to a Windows 2012 R2 machine or domain.) This type of authentication is not currently implemented or supported in the EDC infrastructure. However, to accommodate an agency s unique needs, this requirement involves decisions regarding: VPN access from the agency to the EDC (Changes to firewall rules) Terminal Server access to applications that reside in the EDC for interactive use (Infrastructure considerations) A network authentication occurs when a client application calls the Security Support Provider Interface (SSPI) to establish a secure network connection. This type of authentication is supported in EDC and is the primary focus for the guidance provided in this document. Windows 2012 R2 authentication architecture updates include: Kerberos; Microsoft's Kerberos version 5 (v5) protocol is an authentication mechanism based upon a publicly available protocol. The SSP uses mutual authentication between a client computer and server or between one server and another, within an Active Directory domain. Negotiate package; a security support provider (SSP) in Windows that provides authentication and encryption. Its role is to negotiate which authentication protocol to use based on the protocols supported on the client computer and server for an authentication request. In versions of Windows earlier than Windows 7 and Windows Server 2012 R2, the Negotiate package supports NTLM and EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 23 OF 32

24 Kerberos. For Windows 7 and Windows Server 2012 R2, the Negotiate package has been updated to support additional SSPs. Authentication credentials stored in the Active Directory that replace the NT4 SAM on domain controllers Windows Methods of Authentication Windows methods of authentication through IIS are: Method Anonymous Basic Digest Integrated Description All users authenticate as the IUSR_machinename account. Use only for unrestricted parts of the site. Basic authentication requests a user name and password for verification, but the user's details are transmitted to the server in clear text. Security is not very good because the packets can be intercepted and credentials stolen. Security can be increased by using the Secure Sockets Layer (SSL), which provides a secure communications channel for the transfer of sensitive information. Digest authentication requests a user name and password before allowing access to the restricted areas of a site. Digest authentication does not send the credentials using clear text as basic authentication does; instead it uses a hashing mechanism to encrypt the data before transmission. In integrated Windows authentication the user s NT domain or Active Directory service account is used for authentication. Since integrated Windows encrypts transmitted data, it is ideal for intranet solutions Certificate Authentication Certificate authentication uses a certificate, or key, stored on the client's computer to verify the user's identification. The certificate is automatically presented for authentication when a restricted resource is requested. If a certificate is not present, access is granted using the guest account. Certificates can be mapped to a single NT domain or Active Directory account (many-to-one mapping) or each certificate can be mapped to a separate account (one-to-one mapping) Forms Authentication Forms authentication uses a custom web page to request a user's logon credentials for restricted areas of a web site. The logon form does not perform user verification; it is solely for collecting authentication details. Custom code validates the user's credentials against a data store for authentication. After the user has been authenticated, a token is returned. The token verifies the user for each subsequent access to a restricted part of a web site. Use cookies or a custom mechanism such as a unique identifier in the URL query string or hidden fields to identify users after they have logged on Recommended Authentication Methods We recommend these authentication methods: Method Intranet site Extranet site Description We recommend Integrated Windows authentication if the web site meets this criteria: All users have an NT domain or Active Directory account. Access is exclusively through Internet Explorer. No unrestricted areas exist. Any one of three forms of authentication are suitable if the web site meets this criteria: Users are from both internal and external sources. Some unrestricted areas exist. Suitable authentications are: Basic authentication Certificate authentication Forms authentication Certificate authentication provides seamless authentication by allowing associated certificates to NT domain or Active Directory accounts. Certificate authentication is a very secure solution for sensitive data stored on the web site. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 24 OF 32

25 Use forms authentication if you do not want to create NT domain or Active Directory accounts for your external users. We also prefer forms authentication if the cost of managing certificates outweighs the added security value. Basic authentication requests a user name and password for verification. SSL provides a secure communications channel for the transfer of sensitive information. After a user is authenticated, verify access rights for the requested resource. If the resource is a file system resource such as a template file, check the ACL. If the user is: Listed in the ACL and has sufficient privileges to perform the requested function, grant access. Not listed in the ACL or does not have sufficient access privileges, deny access to the resource Application Security PALogin Application External constituents must have a PALogin account to have access and single sign-on to all EDC web sites. Accounts that use PALogin to login to the state websites are housed within the USER.APPS.STATE.PA.US domain. This domain does not have any account restrictions such as lockout, minimum password length, or password strength. The constituent manages these accounts (for example, changing a password). These Internet user accounts do not have any access to the internal PA.LCL environment. SQL Authentication Use digest authentication or integrated security for SQL service. Do not use built-in SA account or account database. SQL security can be shared EDC SQL or agency-owned SQL (installed in the agency location or EDC Co-Location). For EDC shared SQL, give owners permissions for SA type rights to their database but not the entire server. For agency-owned SQL, use digest authentication or integrated security with Active Directory. Application Authentication Use digest authentication or integrated security for applications. Do not use built-in authentication / authorization. Terminal Services Authentication Use certificates or integrated security for Terminal Services. Do not use digest or basic model authentication. 3.8 BACKUP AND RECOVERY EDC performs a full backup of Managed Services servers nightly, Monday through Friday, and incremental backups on Sundays. Tapes are sent to an off-site facility weekly. The EDC also maintains a weekly, monthly, and yearly tape archive. Daily and weekly tapes are redeployed in the rotation scheme; yearly backups are retained for seven years. Refer to EDC BACKUP AND RECOVERY OVERVIEW for an overview of EDC Managed Services backup and recovery policies, procedures, and licensing: 3.9 CHANGE MANAGEMENT Refer to EDC CHANGE MANAGEMENT PROCESS AND PROCEDURES to review standard EDC change management processes MAINTENANCE The agency specifies available maintenance windows for the EDC to perform maintenance for each application. The EDC performs Enterprise maintenance that affects a large number of applications during the Enterprise maintenance window. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 25 OF 32

26 4 Active Directory and Application Development Resources This appendix summarizes important references to Active Directory concepts and components. 4.1 ACTIVE DIRECTORY RESOURCES Designing and Deploying Directory and Security Services: Best Practice Guide for Securing Windows Server Active Directory Installations Windows Server 2012 R2 Deployment Guide DNS and Active Directory Windows DNS Guide FSMO Placement and Optimization on Active Directory Domain Controllers For non-microsoft-specific DNS information, see Albitz, Paul, and Cricket Liu. DNS and BIND Sebastopol: O Reilly & Associates, Inc., 2001 EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 26 OF 32

27 4.2 APPLICATION DEVELOPMENT RESOURCES The Active Directory provides rich support for locating and working with AD objects. Review these links to documents, sites, and sample code that helps with the deployment, administration, and development of applications built upon Active Directory, Active Directory Services Interface (ADSI), and Directory Services. Active Directory Schema ADSI Using Active Directory Roles Sample EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 27 OF 32

28 5 Appendix A Schema Management Process The EDC works closely with and participates in the Architectural Standards Committee (ASC). The ASC works with agencies to understand evolving business requirements and help to leverage, protect, and extend the existing Commonwealth infrastructure. This document describes Active Directory, as it exists today in EDC. The AD product and AD in the Commonwealth (CWOPA) is vastly more complex and encompassing. When you think about the schema, remember: Schema changes are global. An entire forest has a single schema that is globally replicated. A copy of the schema exists on every domain controller in the forest. When you extend the schema, you do so for the entire forest. Schema additions are not reversible. When a new class or attribute is added to the schema, it cannot be removed. An existing attribute or class can be disabled but not removed. Refer to Disabling Existing Classes and Attributes at for more information Disabling a class or attribute does not affect existing instances of the class or attribute, but it prevents new instances from being created. You cannot disable an attribute if it is included in any class that is not disabled. Because the schema is a key part of the directory that affects the entire forest, special restrictions apply to schema extensions. To reduce the possibility of schema changes by one application breaking other applications and to maintain schema consistency, the EDC enforces restrictions on the type of schema changes that an application or user is allowed to make. To engage the ASC, an agency works through their AAM: Contact your AAM (see EDC Engagement Process) Create an addressed to your AAM and include as much of this information as possible: Problem statement Business case Business impact Requirements Diagrams and functional specifications Contact information The commonwealth s appointed technical representative (team technical lead), Microsoft premier support, and other appropriate individuals pre-screen the request to ensure that the object/attribute size, numbers, and rate of change do not exceed the recommended AD maximums. In addition, the technical representative identifies any currently unused attributes that might be adapted, or any commonwealthdeveloped, currently used attributes which might fulfill the need. If approved, the requested attributes and object classes are assigned new names and object identifiers (OIDs) - which are documented by a commonwealth appointed technical representative. To ensure that the modifications have been correctly inserted into the Active Directory, application developers load the schema modifications into a test forest and validate them with Microsoft, the operations team, and other members of applicable team(s). EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 28 OF 32

29 6 Appendix B Managing MUSER Passwords/Accounts To manage MUSER end user accounts and passwords for applications leveraging the MUSER domain via EDC Tools, follow the instructions below: 6.1 CREATING A NEW MUSER ACCOUNT To create a new MUSER account, 1. Access EDC Tools: and login using your CWOPA account. 2. Select the OU you have been granted access to manage from the drop-down menu and then select the Create New User link. 3. Enter user information for the new account, then enter and verify a temporary password and select the Update User button. Important: Leave the Must Change password at next logon checked. 4. Send the temporary password to the user along with the instructions in 6.22 step 2. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 29 OF 32

30 6.2 RESETTING A MUSER ACCOUNT PASSWORD MUSER Password Reset Rules Please remember when resetting an end-user MUSER password via EDC Tools that it is only a temporary password. Once this is done, the user is required to change their password before accessing any applications: o Use EDC Password Manager available at MUSER passwords have a minimum age of 15 days. This means that once a user changes their password in EDC Password Manager they cannot change it again for 15 days. If they require it to be changed a new temporary password will need set via EDC Tools. If you create a temporary MUSER password for someone and they log into an application, web site, etc before changing their password they will be unable to change the password themselves for 15 days due to the password age. If they need the password changed, a new temporary password should be set via EDC Tools and the user must go to EDC Password Manager to change it themselves. MUSER passwords must meet the following requirements: Passwords must be at least 8 characters in length and contain characters from 3 of the categories below. o Upper case letters [A, B, C, Z] o Lower case letter [a, b, c, z] o Numerals [0, 1, 2, etc] o Non-alphanumeric characters #, $, etc] Passwords expire every 60 days MUSER Password Reset Instructions The MUSER password reset is a 2 step process where the agency admin first creates a new temporary password and the end user then resets the temporary password to a user defined value. 1. Agency administrator creates a temporary MUSER password a. Access EDC (ESF) Tools, and login using your CWOPA account. b. Select the OU you have been granted access to manage, from the drop-down menu. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 30 OF 32

31 c. Select Modify to the right of the user information. d. Type a temporary password and verify it, then click Reset Password Important: You must leave the Must Change password at next logon checked. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 31 OF 32

32 e. A Password set confirmation message is displayed. f. Send the temporary password to the user along with the instructions in step The end user is required to change the temporary password to a self-defined password a. Go to EDC Password Manager available at to create your own password. b. Enter your MUSER account as username. c. Enter the temporary MUSER password sent to you in the Old Password field d. Create your new MUSER password and confirm. The password must meet the requirements noted below. e. Select OK. NOTE: MUSER passwords must meet the following requirements: o o Passwords must be at least 8 characters in length and contain characters from 3 of the categories below. Upper case letters [A, B, C, Z] Lower case letter [a, b, c, z] Numerals [0, 1, 2, etc] Non-alphanumeric characters #, $, etc] Passwords expire every 60 days. f. A confirmation message is displayed. You will now be able to access your MUSER applications with their own password. NOTE: If an error message is displayed, please return to the previous screen and try again. Make sure to follow the password rules and requirements. If blank fields are shown after Change Password is clicked, please try again. EDC ACTIVE DIRECTORY RULES OF ENGAGEMENT PAGE 32 OF 32