Active Directory

Procedures

Change Management Process

Change Initiation

Change that can impact Active Directory and its community can be initiated by three different groups and with expected impacts that range from significant to limited (or none).

The three groups that can initiate change are:

1.  Identity Management Team

• Directory services authentication requirements (e.g.passwords, smart cards, bio-metrics, MFA)
• Directory services integration (e.g. with LDAP)
• Cyber security policy implementation (e.g. account management)

2.  Desktop Support Team

• File and Print
• Software deployment
• Desktop inventory and license tracking
• Desktop security

3.  Infrastructure Support Team

• Domain Controller hardware upgrades
• Domain Controller operating system software upgrades and patches
• Cyber security implementation (e.g. firewalls)

Stakeholders

• IT Division management (Cyber Security, Identity Management, Workstation Support)
• OU admins group, IT Division Help Desk, others  (to be referred to as the AD-notify group)
• End user

Events and timelines

• Approval:  provide 2 – 4 weeks in advance, as appropriate
• Advise:  provide minimum 1 week in advance, include in testing and evaluation phases
• Notify:  1 day in advance, in progress status (if problems occur) and after completion of the work

General Guidelines

Change Management requires uniform processes no matter which group initiates a change.  The process will differ based on urgency and expected impact, but not by the group that initiates the change.  CCM will be enforced at the root level of the domain or when an action requires Domain Admin privileges.

When approval or advice is required, the announcement must indicate what changes will be made, why the changes are being made, potential impact to IT staff and end users, and how much time the changes are expected to take. 

Notification requires a very short one or two sentence description (maintenance on domain controllers will take place at X for period of Y hours).  Notification is not needed for planned outages published on the Web site (normal weekend maintenance for example).

In the event that a change takes longer than expected, the AD-Notify mail list must be immediately notified with the new completion time

Change management does not involve the test domain.

These rules apply to all changes to the Domain Controllers (DCs) in the LBL domain, including but not limited to the registry, file system permissions, network settings, security settings, virus definition updates, patching, directory services changes, group policy settings, etc.  However, good judgment must be used in order to identify which CCM category the specific changes apply to.Top

Change Management Matrix

Account Management (create, disable, delete actions)

Workstation Info

1. Workstations in the LBL forest should be configured to turn off DDNS registration. This may be enforced by a domain GPO in the future and should not be blocked at the OU level.
2. LBL naming standards are recommended for computer account names. The standard is to combine the UID of the primary person using the system, followed by a dash, followed by a workstation operating system identifier, and finally the last two digits of the DOE number. The workstation identifiers are S for Windows 7, E for Windows 8/8.1, and T for Windows 10. e.g. BHSouza-S44 or BHSouza-T39. For security reasons no older Microsoft operating system are allowed on LBLNet or in the LBL domain.
3. It is recommended that you wait 30 minutes after creating and deleting a computer account before attempting to create a new computer account with the same name. Top

Creating and Deploying Group Policy Objects (GPOs)

• GPO guidelines at Berkeley LabTop

Group Management

Best Practices

• Try to use global groups to organize the users in your OUs into groups
• Try to use domain local groups to assign permissions to resources

Windows Patch Management

Windows Patches are delivered to domain joined systems by Windows Server Update Service (WSUS)

Overview
The IT division manages an institutional Windows Server Update Service (WSUS).  The purpose of the WSUS server is to facilitate patching of Windows computers in the LBL environment.  Participation in the WSUS server is optional, but widely deployed and the default for computers in AD.

 The overarching philosophy is to replicate the patches Microsoft delivers via the LBL WSUS server (E.g., security patches, office patches, and non-critical patches). The WSUS service adds the ability to monitor and verify the patch status as well as stop the deployment of a problem patch.

Patch Approval
Patch approval is done by a collaborative team (WSUS team) from IT Desktop Support, and Cyber Security. This team communicates monthly on the second Tuesday of the month (e.g. Microsoft Patch Tuesday) to release patches.  IT Collaboration Systems is responsible for approving patches but delegates this authority to the WSUS team.  As a normal practice, one individual takes the lead notifying stakeholders of special situations that might require an exception to the normal practice of releasing patches as they are provided by Microsoft.

The WSUS team (or designated individual) first reviews the patches to identify any high priority patches that may require Cyber Security to scan and isolate.  The team then briefly reviews the function of each patch and releases them to all clients.  The team also performs a brief review of WSUS to ensure patches are applying correctly. 

Patch Problems
The WSUS team releases all WSUS patches at the same time as Microsoft.  The WSUS team will not approve a patch in the event the patch is creating significant disruption or causing significant problems in the LBL environment.   IT Collaboration support is responsible for deciding when patches are unapproved. 

Group Policy Objects
The IT division has created, and manages, two Group Policy Objects (GPOs) in the LBL Active Directory (AD) to facilitate taking advantage of the LBL WSUS service.  These GPO’s are provided as a courtesy to OU managers.  OU managers are encouraged (but not required, unless they support an Operations Division) to link one of these policies to the computers they manage.  Most LBL domain computer are linked, but some OU managers and systems owners opt to use the built in Windows Automatic Update capabilities or manually update their systems to maximize control in certain scenarios, such as servers or instrumentation.  The two policies provided are as follows:

IT-WSUS3
This is the GPO recommended for most systems.  This GPO will configure WSUS to download the patches and install them at 10:00AM.  If anyone is logged into the system, they will be prompted to reboot every hour, but never forcibly rebooted.  If no one is logged into the computer, and a reboot is required to apply a patch, then a reboot will automatically occur.

IT-WSUS3-NotifyOnly
This is the GPO recommended for servers and instrumentation computers.  A server manager must do the patch installation and reboot; this WSUS policy only prompts for download and reboot.  This GPO simply tracks the patch status.