Active Directory
Information Technology
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 management |
ADAC |
OU admins |
AD-notify group |
End User |
Planned Projects (with potential wide impact on the lab community) |
|
approval |
Advise |
Advise |
Notify |
Advise |
Routine or planned maintenance (Change with limited or no expected impact) |
|
|
|
|
Notify |
|
Incident response (Emergency change directed by CPP or IT management, or in response to unplanned events) |
|
|
|
|
Notify (for other than planned maintenance) |
|
Account Management (create, disable, delete actions)
Workstation Info
- 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
- 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
- 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
Creating and Deploying GPOs
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.
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.
