Corelan Cybersecurity Research

Designing a distributed/international Active Directory is certainly the most important piece of a successful AD implementation. One of the issues that should be dealt with is whether you want to allow other people to be Enterprise/Domain Admin or not. If you ask me : it’s not a good idea. You should restrict those rights to just a handful well-trained people and set up logging and auditing on those accounts and groups. Those admins can create the forest and domains, set up the top level OU structure and then delegate access on those OU’s. This will preserve the confidentiality, integrity and availability of your AD. You basically limit the number of people who can blow up AD; and if someone else screws up, the worst they can do is screw up their own OU tree. Very nice – but a good security policy should not limit people in any way or prevent them from doing their job. So the real challenge is to allow local admins to do their job properly, without having to provide them with too much privileges.

This post describes a couple of common tasks that can be delegated to local people, without having to grant those admins access to the "keys to the kingdom".

First of all, let’s make a couple of assumptions :

1. DC’s should be dedicated. Interactive (local) logon to DC’s must be avoided
2. Making people local admin on a DC or member of "Server Operators" must be avoided at all times. While this would solve most of the issues, it will grant them too much rights at the same time
3. Local admins are part of a group. We’ll use the group name to grant necessary permissions.
4. I’ll assume that we are not talking about basic delegation : stuff that can be granted using a delegation wizard on OU level, or by using basic NTFS permissions. You should be able to set up those permissions yourself.

So, in addition to the basic stuff, here are a couple of tasks that could trigger a request to get access to.

• Access to the event log on a DC
• Authorize a DHCP server
• Manage DHCP
• Manage DNS
• Manage WINS
• Create and link GPO’s (including creating/linking GPO’s to sites)

Access to the event log on a DC

By default, access to the event log on a DC is protected. This means that nobody except admins can get access to the log. Even read only access is not allowed. However, there may be very valid reasons to allow certain members of the IT staff to access the event log on a DC. Furthermore, we should set this up in such a way that logging on locally to the DC should not be necessary. Unfortunately, Microsoft has somewhat hidden the options to allow the administrators to delegate access to the eventlog. In fact, these permissions must be set in the registry. The security of each log is stored as a (rather cryptic) SDDL (Security Descriptor Definition Language) string under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog. The Security Descriptors for each event log are stored under :

If you open the registry on a DC and look at the default entry for f.i. the Application event log, you’ll see a SDDL string, which looks like this :

 O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)

Before showing you how to change this string to allow access to a specific group, I need to explain some basics about the SDDL.

Entries are separated by round brackets, the fields within an entry are separated by semi-colons. The first field can be "D" or "A". D means "deny", A means "Allow". "Deny" overrules "Allow". The last fields indicates whom the permission applies to. The most important values are :

(Look at http://technet2.microsoft.com/windowsserver/en/library/86cf2457-4f17-43f8-a2ab-7f4e2e5659091033.mspx?mfr=true to see the well-known SID’s, or http://support.microsoft.com/kb/914392/en-us for a full list of abbreviations that can be used in the SDDL)

The middle field describes the permissions. Some common (hexadecimal) values that apply to event logs are :
0x1 : Read, 0x2 : Write, 0x4 : Clear.
If you want to combine rights, just add the values. So If you want to grant read, write and clear rights, you should use 0x7 as permission.

Quick example : if you want to allow read access to the event log, for all authenticated users, you should add the following string to the already existing SDDL string : (A;;0x1;;;AU)

If you want to grant permissions to a certain group, you will need to find the group’s sid first. I’m sure you can find the sid (adsiedit.msc, hyena, …). Let’s say the sid of the group you want to grant read access to is S-1-5-21-4146450766-854793612-507905764-1120, all you need to do is use that SID in the SDDL string. In this example, the string you need to add to the already existing SDDL is (A;;0x1;;;S-1-5-21-4146450766-854793612-507905764-1120)

The same rules apply to all event log CustomSD entries. Basically, you need to create the correct strings for each event log, and add them to the registry on each domain controller.

If you want to add these permissions using a GPO, you’ll need to make the options available first. By default, there is no way to set this using a GPO because the "ability" to set the option is simply hidden.

You can use the following procedure to unhide the options and edit the Domain Controller GPO in order to centrally deploy the permissions :

1. Use a text editor such as Notepad to open the Sceregvl.inf in the %Windir%\Inf folder.

2. Add the following lines to the [Register Registry Values] section:

MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD,1,%AppCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\Security\CustomSD,1,%SecCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD,1,%SysCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\Directory Service\CustomSD,1,%DSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\DNS Server\CustomSD,1,%DNSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\File Replication Service\CustomSD,1,%FRSCustomSD%,2

3. Add the following lines to the [Strings] section:

AppCustomSD="Eventlog: Security descriptor for Application event log"
SecCustomSD="Eventlog: Security descriptor for Security event log"
SysCustomSD="Eventlog: Security descriptor for System event log"
DSCustomSD="Eventlog: Security descriptor for Directory Service event log"
DNSCustomSD="Eventlog: Security descriptor for DNS Server event log"
FRSCustomSD="Eventlog: Security descriptor for File Replication Service event log"

4. Save the changes you made to the Sceregvl.inf file, and then run the regsvr32 scecli.dll command.

5. Edit the GPO (Domain Controller GPO if that is target you want to apply the settings to)

Double-click the following branches to expand them: Computer Configuration – Windows Settings – Security Settings – Local Policies – Security Options

View the right panel to find the new "Eventlog" settings.

Enable the CustomSD strings and paste the new SDDL. Don’t forget to get the original strings from the registry, append your custom permissions, and paste the entire string into the field.

As soon as the GPO is applied, the changes will be applied. A reboot is not required.

For completeness, the default values under Windows 2003 server SP1 are :

Application :
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)

Directory Service :
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)

DNS Server :
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)

File Replication Service :
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)

Security :
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0005;;;SY)(A;;0x5;;;BA)

System :
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x1;;;SU)(A;;0x1;;;S-1-5-3)(A;;0x2;;;LS)(A;;0x2;;;NS)

Authorize a DHCP server

By default, only a limited set of admins (Enterprise Admins) have permissions to authorize a DHCP server. In order to delegate this permission to non-admins, log on to the first DC in the forest (with Enterprise Admin rights) and open Active Directory Sites & Services. Make sure the Services node is visible. (Select "Active Directory Sites and Services, click view – enable "Show Service Node"). Double-click "Services", and then right click "NetServices". Open the properties of "NetServices" and go to the ‘Security’ tabsheet. Add the group of admins you want to all to authorize DHCP servers, and give the group full control (or at least read, write, create all child objects). Make sure the security applies to "this object and all child objects". By the way : do not delegate permissions using Domain Local groups. Always use Domain Global groups ! If you have multiple domains and you’ve used Local groups, then users may get a "Access Denied" because their DC doesn’t know how to handle the local groups of another domain.

Wait for replication to occur and you’re all set.

From that point forward the group with IT staff members will be able to authorize a DHCP server. In the event something went wrong during an authorize, or after the IP address of a DHCP server was changed or something, and another authorize fails with the following message : "the specified servers are already present in the directory service", you’ll need to clean up AD first.

Go back to the Sites&Services – Netservices, and remove the entry that corresponds with the DHCP server that has an authorization issue. Next, open adsiedit.msc, go to "Configuration", "CN=Configuration, ….", "CN=Services", "CN=NetServices". Right click Netservices and go to properties.

Edit the dchpServers attribute and make sure the server is removed from this list as well. Now wait until the replication cycle has completed and try again.

Manage DHCP

Add the group of admins to the builtin Security Group "DHCP Administrators". You can find this group in AD Users & Computers, under the default "Users" OU.

Manage DNS

Add the group of admins to the builtin Security Group "DNSAdmins". You can find this group in AD Users & Computers, under the default "Users" OU. Note : this will grant members of that group admin access to the entire DNS service. If you want to restrict access to just a specific domain, you can use the security tabsheet on that specific zone (or on server level).

Manage WINS

The only way to grant access to a WINS server is by either putting granting "Server Operators" or local administrator rights. Both scenario’s are not a good idea when applied to DC’s. Furthermore, "Server Operators" is a protected group, which means that the security on every member object will be reset every day. Result : loss of access to your own user account. (http://support.microsoft.com/?kbid=232199). So what are the options ? The only thing I can think of is avoiding using WINS on a DC, but running WINS on a member server; and then grant admin access to that member server. Or – even better – convince the IT staff that the WINS setup is pretty static and that you’ll do all management if required. My recommendation : don’t delegate permissions to WINS. That’s the safest solution.

Create and link GPO’s

Log on to the first DC in the forest, with Enterprise Admin rights. Open AD Users & Computers, go to the "Users" folder, open the "Group Policy Creator Owners" group and add the IT staff group.
Additionally, make sure the AD Administrators group has RW access to the SYSVOL//Policies folder on the DC’s (which should be the case, because of the "Group Policy Creator Owners" membership)
Next, open the GPMC (Group Policy Management Console – http://www.microsoft.com/windowsserver2003/gpmc/default.mspx), go to Forest: , Domains, . Select and in the right pane, go to the Delegation tab sheet.
Add rights to the IT staff group to link GPO’s, do GPO modelling and analyse results :
– select each of the permissions in the drop-down at the top

– add the IT staff group to the list by clicking the "Add button" at the bottom..

If you want to allow Resultant Set Of Policy permissions (logging and/or planning mode), click the "Advanced" button in the lower right corner, select the group, click "Edit", and assign the required Resultant Set Of Policy permissions.

Next, select "Sites", "show sites", and add "Link GPO’s" Access to the sites that will be managed by this IT staff group. (Go to the delegation tab sheet and add the group)

Links :

http://support.microsoft.com/default.aspx?kbid=323076
http://www.microsoft.com/technet/security/guidance/serversecurity/tcg/tcgch06n.mspx
http://mkeadle.org/?p=88