Zoho Banner September 2011

Archive for May, 2008

One of the improvements to Active Directory Users and Computers (DSA.MSC) in Windows Server 2008 is the "protection from accidental deletion" feature.  This blog article explains what the feature is and how it works under the hood.

Probably the most common cause of restore operations in AD is accidental deletion of objects.  Administrators with fat fingers can fairly easily delete a single object, an OU or an entire OU tree.  Windows Server 2008 provides a handy checkbox that protects an object from accidental deletion.  The screenshot below shows the checkbox selected by default during the creation of a new OU.

 

AccidentalDeleteProtection1

 

The checkbox is subsequently available on the Object tab of the object’s properties, as shown below.  Note that the protection is not just for OUs, it can be set on the Object tab for all object types, including users.

 

AccidentalDeleteProtection6

 

When you attempt to delete an object in Active Directory Users and Computers, you will see the following standard warning.

 

AccidentalDeleteProtection2

 

If you then select Yes, and the object is protected from accidental deletion you will see the error message, "You do not have sufficient privileges to delete <object_name>, or this object is protected from accidental deletion", as shown below.

 

AccidentalDeleteProtection3

 

To go ahead and delete the object you have to go back to the object’s properties, deselect the checkbox on the Object tab and then try the deletion again.

 

So how is this feature implemented behind the scenes?  Well, it’s simply really.  When the checkbox is selected, two new "Deny" access control entries (ACEs) are added to the discretionary access control list (DACL) in the object’s security descriptor.  These explicitly deny everyone permission to delete the object and/or delete the subtree.   The screenshot below shows the entries in the Security -> Advanced view of the object’s properties.   An explicit Deny entry beats an Allow entry, which effectively means the object cannot be deleted by anyone without first removing the ACEs, either by editing the security directly or toggling the accidental deletion checkbox on the Object tab.

 

AccidentalDeleteProtection4

 

It may not represent a radical change to AD like the RODC or Fine-Grained Password Policies, but Microsoft has done a good job in providing a simple-yet-effective method of protecting objects from accidental deletion in Windows Server 2008. 

Those of you already familiar with Windows Server 2008 will know that one of the key Active Directory-related improvements is the introduction of the Read-Only Domain Controller (RODC).  With the RODC comes the ability to separate administrative roles.  This removes the restriction of having to use a Domain Administrators account when carrying out administrative tasks on a DC.   For example, changing the Network Card on a Domain Controller on a Windows Server 2003 DC requires a Domain Admin account, which is clearly overkill.  On a Windows Server 2008 RODC you can now delegate machine-specific administrative tasks to a local administrator.  The delegated account requires no elevated privileges within AD. 

You can specify an account or group to be the the local administrator for a RODC when pre-staging the creation of the RODC on a writeable DC (or at a later time if you prefer).  This pre-staging activity (also new in Windows Sever 2008) delivers the ability to complete the promotion of the RODC using the account (or members of the group) you specified to be the local administrator.  In the example below, I have specified a group named RODC1 Local Admins to be the local administrator for the RODC1 Domain Controller.  Note that the group name I use specifies the the machine name (i.e. RODC1).  This is because the group will typically be used for only one RODC, rather than for all RODCs.

WS2008 Admin Del1

The group or account that you specify will be assigned to the managedBy attribute value of the RODC’s computer object in AD.

WS2008 Admin Del2

You can then use the account (or member of the group you created if you used a group) to complete the promotion of the RODC by running DCPROMO on the server that is to become the RODC (see below).   Again, bear in mind that the account used does not need to be a member of Domain Admins.  You will however receive a warning during the DCPROMO process (see below), which you can safely ignore when completing the promotion of a pre-staged RODC.

WS2008 Admin Del3

WS2008 Admin Del4

The local administrator account can then subsequently be used to log on locally to the RODC and to perform administrative tasks.  Remember that the account will only have local administrator rights to the local RODC. 

We know that the managedBy attribute for the RODC is used to store the account or group that is allowed local administrator rights on the RODC.  But the authentication mechanism needs to provide for scenarios where AD is not available, so how is this information actually used by the RODC?   The information is actually stored in the registry on the RODC in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RODCROLES

As you can see from the screenshot below, the Security Identifier (SID) shown in the “Repair Admins” REG_SZ value corresponds to the account or group specified in the managedBy attribute value on the RODC’s AD object.

WS2008 Admin Del5

Hint: You can use the SID Lookup feature of LDP.EXE to match a  SID to a friendly name.

If you need to include additional local roles, you can use the “Local Roles” feature within NTDSUTIL.   You can define the following local roles

Administrators
Users
Guests
Remote Desktop Users
Network Configuration Operators
Performance Monitor Users
Performance Log Users
Distributed COM Users
IIS_IUSRS
Cryptographic Operators
Event Log Readers
Certificate Service DCOM Access
Incoming Forest Trust Builders
Terminal Server License Servers
Pre-Windows 2000 Compatible Access
Windows Authorization Access Group
Print Operators
Server Operators
Account Operators
Backup Operators
Replicator

When a new local role has been defined, it will appear within the same RODCROLES registry key with a relative identifier that corresponds to the role.  In the example below, an account named “morgaaa” has been assigned the Print Operators local role. 

C:\Windows\system32\ntdsutil.exe: lo ro
local roles: add morgaaa “print operators”
Successfully updated local role.
local roles: show role “print operators”
        TMAD\morgaaa
local roles:

WS2008 Admin Del6

Given that the registry values show the relative identifer (e.g. 550), rather than the the friendly name (e.g. Print Operators) you can use the Microsoft KB article Well-known security identifiers in Windows operating systems to match the registry value to the role.

Remember to ensure that the passwords for the domain accounts used for local roles are cached on the RODC.   Unless you do this, you will not be able to log on to the RODC in situations where other DCs are not available (e.g. when the network link from the Branch office to the hub site is down).

The way in which the local roles are assigned and used is currently not well documented.  Hopefully this blog entry provides you with some useful additional information on how this new Windows Server 2008 feature.

Today I installed Outlook 2007 on a test machine and enabled the RSS defaults.  An hour or so later I noticed that the Junk Mail folder contained 60 items.  Curious as to what might be in there so quickly, I found it was RSS items from MSNBC.com. 

 

JunkMailMSNBC

 

Interesting that one Microsoft product considers another to be Junk.  :-)