Active Directory

Procedures
 Change Management Process
 Account Management (create, disable, delete actions)
 Creating and Deploying GPOs
 Group Management
 Patch Management

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.  Institutional Systems Department (Identity Management)

 Directory services authentication requirements (passwords, smart cards, biometrics)

 Directory services integration (e.g. with LDAP, eDir)
 Cyber security policy implementation (e.g. account management)

2.  User Support Department (Desktop Services)

 File and Print

 Software deployment
 Desktop inventory and license tracking
 Desktop security

3.  Infrastructure Department (Infrastructure Upgrades)

 Domain Controller hardware upgrades

 Domain Controller software upgrades
 Cyber security implementation (e.g. firewalls)

Stakeholders

 AD advisory committee (ADAC)

 IT Division management
  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.

Change Management Matrix

Scope Example IT division ADAC OU AD-notify End

management admins group User
Planned  single sign-on approval Advise Advise Notify Advise
Projects  directory
integration
(with potential  Domain
wide impact on controller
the lab upgrades
community)  Mandatory use
of new firewall
policy
Routine or  Apply patches       Notify  
planned  to Win2003
maintenance OS on DC
 Update of
(Change with antivirus
limited or no definitions.
expected  Response to
impact) normal event
and security
log data

Incident  Major       Notify (for  

response windows virus other than
outbreak planned
(Emergency  Failure maintenance)
change condition
directed by within AD that
CPP or IT needs
management, immediate
or in response attention
to unplanned  Power outage
events)
Top

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 OUs

2. LBL naming standards are recommended for computer account names. The standard is to
combine the UID of the primary person using the machine, 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 x for Windows XP, w for Windows 2000, and n
for Windows NT 4. e.g. cwnelson-x44 or cwnelson-w39

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 GPOs

 GPO guidelines at Berkeley Lab

Top

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

CCM

More words on when CCM takes effect and when it does not?

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

Windows Patch Management via WSUS

July 18, 2007

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 LBNL 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 LBNL 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 User Support, IT
Infrastructure, and CPP.  This team meets monthly on the second Tuesday of the month (e.g.
Microsoft Patch Tuesday) to release patches.  IT User support management is responsible for
approving patches but delegates this authority to the WSUS team.

The WSUS team first reviews the patches to identify any high priority patches that may require
CPP 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.  The team also runs the Cleanup Wizard to remove outdated patches and
computers that have not contacted WSUS in more than 30 days.  The patch approval process
takes less than 30 minutes per month.

Patch Problems
The WSUS team releases all WSUS patches at the same time as Microsoft.  The WSUS team
will unapprove a patch in the event the patch is creating significant disruption or causing
significant problems in the LBNL environment.  Unapproval is reserved for when a patch causes
problems in the LBNL environment.  We specifically try to avoid unapproval based upon
Internet discussions alone.  IT User support (Charlie Verboom) is responsible for decide when
patches are unapproved. 

Group Policy Objects

The IT division created and manages two Group Policy Objects (GPOs) in Active Directory
(AD).  The consumer of these GPO’s are OU managers.  OU managers are encouraged, but not
required, to link one of these policies to the computers they manage.  Most computer are linked,
but some computers opt to use the built in Automatic Update capabilities or manually update
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 forcible rebooted.  If no one is logged into the
computer, it will reboot.

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