The default Windows 2000 installation of Active Directory was not as secure as it could have been out of the box. It allowed anonymous queries to be executed, which could take up valuable processing resources, and it did not place any requirements on encrypting or signing traffic between clients and domain controllers. As a result, usernames, passwords, and search results could be sent over the network in clear text. Fortunately, beginning with Windows Server 2003, things tightened up significantly. LDAP traffic is signed by default, and anonymous queries are disabled by default. Additionally, Transport Layer Security (TLS), the more flexible cousin of Secure Sockets Layer (SSL), is supported, allowing for end-to-end encryption of traffic between domain controllers and clients.
Active Directory’s ACL model provides ultimate flexibility for securing objects throughout a forest; you can restrict access down to the attribute level if you need to. With this flexibility comes increased complexity. An object’s ACL is initially generated from the default ACL for the object’s class, inherited permissions, and permissions directly applied on the object.
An ACL is a collection of ACEs, which defines the permission and properties that a security principal can use on the object to which the ACL is applied. Defining these entries and populating the ACL is the foundation of Active Directory security and delegation.
In this chapter, we will explore some of the common tasks of managing permissions in Active Directory. If you are looking for a detailed guide to Active Directory permissions, we suggest reading Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly).
In order for ACLs to be of use, a user must first authenticate to Active Directory. Kerberos is the primary network authentication system used by Active Directory. Kerberos is a standards-based system originally developed at MIT that has been widely implemented at universities. We will also be covering some Kerberos-related tasks in this chapter that you will likely encounter in an Active Directory environment. For a complete review of Kerberos, we recommend Kerberos: The Definitive Guide by Jason Garman (O’Reilly).
You want to enable SSL/TLS access to your domain controllers so that clients can encrypt LDAP traffic to the servers.
Open Server Manager.
Click Manage, then click Add Roles and Features, and then click Next.
Click Next, which will select a role-based or featured-based installation.
Click Next to select the local server as the destination server.
Check the box beside Active Directory Certificate Services and then click Next.
The Add Roles and Features Wizard will appear. Maintain the option to include the management tools, and then click the Add Features button to add the required features to the role installation. Click Next.
On the features screen, click Next.
On the AD CS screen, click Next.
On the Role services screen, click Next.
Review the installation options and then click Install to begin the installation.
Go back to Server Manager and click the notifications. In the Post-deployment Configuration notification for AD CS, click the “Configure Active Directory Certificate Services on the destination server” link.
On the Credentials screen, enter administrative credentials if needed and then click Next.
On the Role Services screen, click Certification Authority and then click Next.
Select the setup type that you want and click Next.
Select the CA type that you want the server to be and click Next.
The “Specify the type of the private key” screen appears. Click Next to create a new private key.
The Cryptography for CA screen will appear. Click Next.
On the CA Name screen, click Next.
On the Validity Period screen, click Next.
Enter the location for the certificate database and logs, and then click Next.
Click Configure and then click Close when the installation completes.
The GUI solution example installs AD CS on an existing domain controller. (While this works, it is a good practice to separate AD DS and AD CS to separate servers when possible.) Because the example installs AD CS on a domain controller, the domain controller automatically acquires a certificate after the installation is complete. If you install AD CS on member server(s), you will need to acquire a certificate for each domain controller. One way to do this is to create an auto-enrollment GPO for all domain controllers. After Active Directory domain controllers obtain certificates, they automatically listen on ports 636 and 3269. Port 636 is for LDAP over SSL/TLS and port 3269 is used for global catalog queries performed over SSL/TLS. See Securing LDAP Traffic with SSL, TLS, or Signing for more information on how to query a domain controller using SSL/TLS.
Most of the GUI-based tools running on both client computers and server computers will automatically sign and encrypt traffic between the server and client. This includes the following tools:
Active Directory Domains and Trusts
Active Directory Sites and Services
Active Directory Schema
Active Directory Users and Computers
Active Directory Administrative Center
ADSI Edit
Group Policy Management snap-in
Object Picker
With ADSI Edit, you can also specify the port number to use when
browsing a partition. View the settings for a connection by
right-clicking on the partition and selecting Settings. Click the
Advanced button and enter 636 for
LDAP over SSL or 3269 for the
global catalog over SSL.
It is a good idea to test whether traffic is being encrypted. If you run Network Monitor (netmon.exe) while using tools that perform simple LDAP binds, you’ll see LDAP requests, usernames, and passwords going over the network in plain text. Obviously this is not the most secure configuration. If you use some of the tools listed in the preceding section, you will notice that you aren’t able to see the requests, usernames, or passwords. Don’t take encryption for granted.
Enabling SSL/TLS for enabling SSL/TLS; Disabling LDAP Signing; MSDN: ADS_AUTHENTICATION_ENUM
To temporarily disable LDAP encryption or signing for troubleshooting purposes, use the following steps on a client computer:
Create a new GPO. Edit the GPO and select Computer Configuration→Policies→Windows Settings→Security Settings→Local Policies, and then highlight Security Options.
In the right pane, double-click the policy titled “Network security: LDAP client signing requirements”.
Click the checkbox to define the policy setting and then select None as the setting.
Click OK.
Link the GPO to the container that contains the desired computer object(s).
If the target domain controllers require signing, then disabling the client signing will result in the client administrative tools not being able to communicate with the domain controllers. To disable LDAP signing on domain controllers, follow the preceding steps but modify the policy titled “Domain controller: LDAP server signing requirements” in the Default Domain Controllers policy.
Securing LDAP Traffic with SSL, TLS, or Signing to enable LDAP signing and encryption
You want to enable anonymous LDAP access for clients. Anonymous queries are disabled by default except for querying the RootDSE.
In the Configuration partition, browse to
cn=Services→cn=Windows NT→cn=Directory Service.In the left pane, right-click on the Directory Service object and select Properties.
Double-click on the
dSHeuristicsattribute.If the attribute is empty, set it with the value
0000002.If the attribute has an existing value, make sure the seventh digit is set to
2.
$root = [ADSI]"LDAP://RootDSE"
$obj = [ADSI]("LDAP://cn=Directory Service,cn=Windows NT,cn=Services," +↵
$root.configurationNamingContext)
$dsHeuristics = $obj.dsHeuristics.value
if ($dsHeuristics -eq $null)
{
"dsHeuristics was null (not previously set)"
$dsHeuristics = "0000000" # seven zeroes
}
$len = $dsHeuristics.Length
if ($len -lt 7)
{
$dsHeuristics = $dsHeuristics + ("0000000").SubString(0, (7 - $len))
$len = 7
}
# we've ensured that $dsHeuristics is AT LEAST seven chars long now
# it may be 13 chars or more. we really don't care about that!
$char = $dsHeuristics.SubString(6, 1)
if ($char -eq "2")
{
"Anonymous query mode already set to 2"
}
else
{
$upd = $dsHeuristics.SubString(0, 6) + "2"
if ($dsHeuristics.Length -gt 7)
{
$dsHeuristics.SubString(7, $len)
}
$obj.dsHeuristics = $upd
$obj.SetInfo()
"Anonymous query mode set to 2"
"New value of dsHeuristics equal to $upd"
}To enable anonymous access, you have to modify the dSHeuristics attribute of the cn=Directory Service,cn=Windows
NT,cn=Services,ConfigurationDN object. The dSHeuristics attribute is an interesting
attribute used to control certain behavior in Active Directory. For
example, you can enable List Object Access mode (see Enabling List Object Access Mode) by setting the dSHeuristics flag.
The dSHeuristics attribute
consists of a series of digits that, when set, enable certain
functionality. To enable anonymous access, the seventh digit must be set
to 2. By default, dSHeuristics does not have a value. If you set
it to enable anonymous access, the value would be 0000002.
After enabling anonymous access, the assumption is that you’ll
want to grant access for anonymous users to retrieve certain data from
Active Directory. To do that, grant the ANONYMOUS LOGON user access to the parts of
the directory you want anonymous users to search. You must grant the
access from the root of the directory down to the object of interest.
See MS KB 320528 for an example of how to enable the anonymous user to
query the email addresses of user
objects.
Enabling List Object Access Mode; “How to configure Active Directory to allow anonymous queries”; MSDN: DS-Heuristics attribute
Open the Active Directory Users and Computers snap-in (dsa.msc) or Active Directory Sites and Services snap-in (dssite.msc), depending on the type of object you want to delegate.
In the left pane, browse to the object on which you want to delegate control.
Right-click on the object and select Delegate Control. Only certain objects support the Delegation of Control Wizard, so this option will not show up for every type of object.
Click Next.
Click the Add button and use the object picker to select the users or groups to which you want to delegate control.
Click Next.
If the task you want to delegate is an option under “Delegate the following common tasks,” place a checkmark next to it and click Next. If the task is not present, select “Create a custom task to delegate” and click Next. If you selected the latter option, you will need to perform four additional steps:
Select the object type you want to delegate.
Click Next.
Select the permissions you want to delegate.
Click Next.
Click Finish.
The Delegation of Control Wizard is Microsoft’s attempt to ease the pain of trying to set permissions for common tasks. Because Active Directory permissions are so granular, they can also be cumbersome to configure. The Delegation of Control Wizard helps in this regard, but it is still limited in functionality. The default tasks that can be delegated are fairly minimal, although you can add more tasks as described in Customizing the Delegation of Control Wizard. Another limitation is that you can only add new permissions; you cannot undo or remove permissions that you previously set with the wizard. To do that, you have to use the ACL Editor directly as described in Viewing the ACL for an Object.
Customizing the Delegation of Control Wizard for customizing the Delegation of Control Wizard; Revoking Delegated Permissions for more on using dsrevoke
Open the Delegation of Control Wizard INF file (%SystemRoot%System32Delegwiz.inf in Windows Server 2008 and later) on the computer for which you want to modify the wizard.
Under the [DelegationTemplates]
section, you’ll see a line similar to the following:
Templates = template1, template2, template3, template4, template5, template6, template7, template8, template9,template10, template11, template12, template13
You need to append a new template name. In this case, we’ll follow
the same naming convention and create a template named template14. The line should now look like
this:
Templates = template1, template2, template3, template4, template5, template6, template7, template8, template9,template10, template11, template12, template13, template14
Scroll to the end of the file and append a new template section. You can use the other template sections as examples. Here is the generic format:
[<TemplateName>] AppliesToClasses =<CommaSeparatedListOfObjectClassesInvokedFrom>Description = "<DescriptionShownInWizard>" ObjectTypes =<CommaSeparatedListOfObjectClassesThatAreSet>[<TemplateName>.SCOPE]<Permission entries for Scope>[<TemplateName>.<ObjectClass1>]<Permission entries for ObjectClass1>[<TemplateName>.<ObjectClass2>]<Permission entries for ObjectClass2>...
<TemplateName> is the same as
what we used in the [DelegationTemplates] section—that is,
template14.
In the AppliesToClasses line,
replace
<CommaSeparatedListOfObjectClassesInvokedFrom>
with a comma-separated list of LDAP display names of the classes that
can be delegated. This delegation action will show up on the classes
listed here only when you select Delegate Control from a snap-in. To
make our new template entry apply to domain objects, OUs, and
containers, we would use this line:
AppliesToClasses = domainDNS,organizationalUnit,container
In the Description line,
replace <DescriptionShownInWizard> with
the text you want shown in the wizard that describes the permissions
being delegated. Here is a sample description for delegating full
control over inetOrgPerson
objects:
Description = "Create, delete, and manage user and inetOrgPerson accounts"
In the ObjectTypes line,
replace
<CommaSeparatedListOfObjectClassesThatAreSet>
with a comma-separated list of object classes to be delegated. In this
example, permissions will be modified for user and inetOrgPerson objects:
ObjectTypes = user,inetOrgPerson
Next, define the actual permissions to set when this action is
selected. You can define two different types of permissions. You can use
a [<TemplateName>.SCOPE] section to define permissions that are
set on the object that is used to start the wizard. This will be one of
the object classes defined in the AppliesToClass line. This is commonly used in
the context of containers and organizational units to specify, create,
modify, or delete child objects of a particular type. For example, to
allow the granting of create (CC) or delete (DC) permissions for
user and inetOrgPerson objects, you would use the
following:
[template14.SCOPE] user=CC,DC inetOrgPerson=CC,DC
As you can see, each permission (e.g., create child) is abbreviated to a two-letter code (e.g., CC). Table 14-1 lists the valid codes.
Table 14-1. Permissions and abbreviated codes
Abbreviated code | Permission |
|---|---|
RP | Read Property |
WP | Write Property |
CC | Create Child |
DC | Delete Child |
GA | Full Control |
It is perfectly valid to leave out a SCOPE section if it is not needed. The rest of
the lines are used to specify permissions that should be set on the
object classes defined by the ObjectTypes line.
To allow the granting of full control over all existing user and inetOrgPerson objects, we’ll use these
entries:
[template14.user] @=GA [template14.inetOrgPerson] @=GA
This is very similar to the previous example, except that here
SCOPE is replaced with the names of
the object classes the permissions apply to. The @ symbol is used to indicate that the
permission applies to all attributes on the object. You can get more
granular by replacing @ with the name
of the attribute the permission applies to. For example, this would
allow the granting of read and write permissions on the department attribute for inetOrgPerson objects:
[template14.inetOrgPerson] department=RP,WP
You can also enable control access rights using the CONTROLRIGHT designator instead of @ or an attribute name; you just need to
specify the LDAP display name of the control access right you want to
enable. The following section enables the Reset
Password right on inetOrgPerson objects and enables read and
write access to the pwdLastSet
attribute:
[template14.inetOrgPerson] CONTROLRIGHT="Reset Password" pwdLastSet=RP,WP
You can completely customize the tasks that can be delegated with the Delegation of Control Wizard, but you still have the problem of getting the Delegwiz.inf file, on all the clients that need to use the new settings. You can manually copy it to the computers that need it, or you can use Group Policy to automate the distribution of it.
Microsoft offers a prebuilt delegation file that allows you to delegate more than 70 administrative tasks. The file can be used to replace the existing Delegwiz.inf file or it can be used as a starting point if you only wanted to use a subset of the file. See the file at TechNet for more information.
Using the Delegation of Control Wizard for more on using the Delegation of Control Wizard
While the Delegation of Control Wizard makes it trivial to grant permissions to objects within Active Directory, one thing that it lacks is an Undo button. To help address this, Microsoft has made the dsrevoke command-line utility a free download from its website. Note that the tool is dated as it was created originally for Windows 2000. It has been a bit spotty on Windows Server 2008 and Windows Server 2008 R2, but we’ve used it successfully with Windows Server 2012. The dsrevoke utility will remove any permissions that have been delegated to a security principal on a domain or an OU, with the following limitations:
You can use dsrevoke only on a domain or an OU; if you’ve delegated permissions over individual objects, you’ll need to remove them manually.
dsrevoke removes only object permissions; if you’ve assigned any user rights through Group Policy, they’ll need to be removed separately.
You can’t use dsrevoke to remove any permissions that have been delegated to the Schema or Configuration NCs.
Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool such as ADUC or ADSI Edit. Select the Security tab. To see the Security tab with ADUC, you must select View→Advanced Features from the menu.
Click the Advanced button to view a list of the individual ACEs.
Viewing an object’s ACL is a common task and should already be familiar to most administrators. The ACL Editor is useful for checking the permissions that have been set on objects, especially after running the Delegation of Control Wizard. In addition to viewing permissions, the options available in the GUI include viewing auditing settings and the owner of the object. Knowing the owner of an object is important because ownership confers certain inherent rights.
Because the ACL Editor is the same for NTFS permissions and properties as it is for Active Directory objects, you should feel comfortable with the look and feel of the interface; it is exactly the same as file and folder permissions. We also highly recommend getting familiar with the Advanced view of the ACL Editor, as this is truly the view in which you can determine what is going on with permissions. The Basic view presents a list of security principals that have permissions configured, but it will not always show every configured ACE entry. The Advanced view will show the complete picture, including the scope of permissions for ACEs down to the object and even the attribute level.
Changing the ACL of an Object for changing an ACL; Enabling Auditing of Directory Access for auditing of object access
You want to set permissions on attributes that do not show up in the default Active Directory Users and Computers ACL Editor.
The ACL Editor in ADUC and in the Active Directory Administrative Center shows only a subset of the object’s attributes on which permissions can be set. Most attributes can be seen in the ACL Editor by clicking the Advanced button, adding or editing a permission entry, and selecting the Properties tab.
An attribute can have a read permission, a write permission, or both, either of which can be set to Allow or Deny. If the attribute you want to secure is not in the list, you will need to modify the dssec.dat file on the computer that you’re running the ACL Editor from. On Windows Server 2012, the dssec.dat file is located in the %SYSTEMROOT%System32 folder.
There are sections for each object class represented in square
brackets—for example, [user].
Underneath that heading is a list of attributes that you can configure
to display or not display in the ACL Editor.
These are the first few lines for the [user] section:
[user] aCSPolicyName=7 adminCount=7 allowedAttributes=7
The value to the right of the attribute determines whether it is shown in the ACL Editor. The valid values include the following:
- 0
Both the Read property and the Write property are displayed for the attribute.
- 1
The Write property is displayed for the attribute.
- 2
The Read property is displayed for the attribute.
- 7
No entries are displayed for the attribute.
If the attribute is not defined, then the default value (specified by
@, if present) is used.
Much like the Delegation of Control Wizard, you can customize the attributes that are shown in the ACL Editor, but you still need to distribute the dssec.dat file to all computers that need to see the change.
After making the changes to dssec.dat, close ADUC and/or the Active Directory Administrative Center and then reopen them.
Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool such as ADUC or ADSI Edit. Select the Security tab. To see the Security tab with ADUC, you must select View→Advanced Features from the menu.
Click the Advanced button.
Select the Effective Access tab.
Click the “Select a user” button to bring up the Object Editor.
Find the user or group for which you want to see the effective permissions.
Click the “View effective access” button.
The results will be shown in the bottom of the window.
Note
The Effective Access tab is the new name for the Effective Permissions tab since Windows Server 2008.
Viewing the permissions on an object does not tell the whole story as to what the actual translated permissions are for a user or group on that object. The effective permissions of an object take into account all group membership and any inherited permissions that might have been applied farther up the tree. While this is a useful tool to analyze permissions, it is unfortunately only a best guess; there are still some situations in which certain permissions will not be reflected.
The AclDiag tool is from the Windows Server 2003 Service Pack 2 32-bit Support Tools. It is a free download, and it installs and works successfully up to Windows Server 2012.
You want to configure permission inheritance on an Active Directory container to configure whether a child object should automatically receive any permissions that you’ve granted to its parent object.
Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool such as Active Directory Users and Computers (ADUC) or ADSI Edit. Select the Security tab. If the Security tab is not visible within ADUC, you must select View→Advanced Features from the menu.
Click the Advanced button to view a list of the individual ACEs.
To turn off inheritance, click the “Disable inheritance” button.
You will be given the option to “Convert inherited permissions into explicit permissions on this object”, to “Remove all inherited permissions from this object”, or to cancel. Click the desired option.
To reenable permission inheritance from objects farther up the directory structure, click the “Enable inheritance” button in the Advanced Permissions window.
To disable permission inheritance (i.e., to configure an object such that only explicitly assigned permissions apply), use the following syntax:
> dsacls <ObjectDN> /P:YTo enable permission inheritance, do the following:
> dsacls <ObjectDN> /P:NThe following syntax will prevent an object from receiving inherited permissions that have been applied at a higher level in the tree:
$acl = Get-Acl -Path "AD:<ObjectDN>" $acl.SetAccessRuleProtection($true,$true);Set-Acl -AclObject $acl "AD:<ObjectDN>"
The following syntax will configure an AD object so that it will receive inherited permissions that have been applied at a higher level in the directory tree:
$acl = Get-Acl -Path "AD:<ObjectDN>" $acl.SetAccessRuleProtection($false,$false);Set-Acl -AclObject $acl↵ "AD:<ObjectDN>"
Similar to NTFS permissions on the filesystem, Active Directory permissions on container objects can be set to inherit or trickle down to objects farther down the directory structure. This process can greatly simplify assigning permissions, as you can assign a common set of permissions high up in the directory structure and have those permissions filter down to all of the OUs and objects below. In some cases, though, you might want to turn off permission inheritance to configure an entirely different set of permissions for a child object or container.
One thing to keep in mind when enabling or disabling inheritance
is that there are a number of AD security principals protected by the
AdminSDHolder process that will
receive a specific set of permissions regardless of the inheritance
settings you configure. These groups include Enterprise
Admins, Schema Admins, Domain
Admins, Administrators,
Account Operators, Server
Operators, Print Operators,
Backup Operators, and Cert
Publishers. In addition, some Active Directory−aware
applications depend on inheritance being in place in order to function
efficiently.
Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool such as ADUC, Active Directory Administrative Center, or ADSI Edit. Select the Security tab. To see the Security tab with ADUC, you must select Views→Advanced Features from the menu.
Click the Advanced button to view a list of the individual ACEs.
Click Add to specify a new user or group, and then place checkmarks next to the permissions that you want to assign and click OK.
To remove an ACE, highlight the entry and click Remove. If the Permissions entry is inherited from farther up the directory tree, the option to remove the permission will not be available unless you disable inheritance. With inheritance enabled, you will only have the option to remove any permissions that have not been inherited.
To grant permissions from the command line, use the following syntax:
> dsacls<ObjectDN>/g<Permissions>
To deny permissions, replace /g with /d.
To add an entry for Full Control to the ACL of an object, use the following syntax:
$Path = [ADSI]"LDAP://<ObjectDN>" $Group = New-Object System.Security.Principal.NTAccount("<GroupName>") $IdentityReference = $Group.Translate([System.Security.Principal.SecurityIdentifier]) $Perms = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($IdentityReference,"GenericAll","Allow") $Path.psbase.ObjectSecurity.AddAccessRule($Perms) $Path.psbase.commitchanges()
Changing the ACL of an object is a common task for administrators in any but the most basic AD implementations because, as shown in Using the Delegation of Control Wizard and Customizing the Delegation of Control Wizard, the Delegation of Control Wizard is limited and cumbersome to extend and deploy. The GUI and command-line methods are useful for one-off changes to permissions, but for making global changes to a number of objects, you should consider using a script to automate the process.
Delegating Control for Managing Membership of a Group; Creating a Computer for a Specific User or Group; Delegating Control of an Active Directory Integrated Zone; Using the Delegation of Control Wizard; Customizing the Delegation of Control Wizard; Delegating Control of Managing an Application Partition
Each instantiated object in Active Directory has an associated
structural class that defines a default security descriptor (the
defaultSecurityDescriptor attribute).
When an object is created and a security descriptor isn’t specified, the
default security descriptor is applied to it. This, along with
inheritable permissions from the parent container, determines how an
object’s security descriptor is initially defined. If you find that you
are modifying the default security descriptor on a particular type of
object every time it is created, you may want to modify its default
security descriptor. Another option would be to use a script that would
modify the individual object’s ACL at the same time that the object was
created.
Registering the Active Directory Schema MMC Snap-in for more on registering the Active Directory Schema snap-in; Comparing the ACL of an Object to the Default Defined in the Schema for comparing the ACL of an object to the default defined in the schema; Resetting an Object’s ACL to the Default Defined in the Schema for resetting the ACL of an object to the default defined in the schema
You want to determine whether an object has the permissions defined in the schema for its object class as part of its ACL.
For more on the default security descriptor (SD), see Changing the Default ACL for an Object Class in the Schema. AclDiag will determine whether the object possesses the security descriptor that’s defined in the schema—if you’ve modified the security descriptor, AclDiag will compare the object’s SD against the currently defined SD, not the Active Directory default.
Resetting an Object’s ACL to the Default Defined in the Schema for resetting an object’s ACL to the default defined in the schema
Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool such as ADUC, Active Directory Administrative Center, or ADSI Edit. Select the Security tab. To see the Security tab with ADUC, you must select View→Advanced Features from the menu.
Click the Advanced button.
Click the “Restore defaults” button.
For more on the default security descriptor, see Changing the Default ACL for an Object Class in the Schema.
You want to ensure that users can only authenticate to Active Directory using strong authentication protocols.
In the left pane, expand the
Forestcontainer, expand theDomainscontainer, browse to the domain you want to administer, and expand theGroup Policy Objectscontainer.Right-click on the GPO that controls the configuration of your domain controllers and select Edit. (By default, this is the Default Domain Controller Policy, but it may be a different GPO in your environment.) This will bring up the Group Policy Object Editor.
Browse to Computer Configuration→Policies→Windows Settings→Security Settings→Local Policies→Security Options.
Double-click on “Network security: LAN Manager Authentication Level”. Place a checkmark next to “Define this policy setting”.
Select “Send NTLMv2 response only. Refuse LM & NTLM.” Click OK.
Wait for Group Policy to refresh, or run the
gpupdate /forcecommand from the command prompt.
Microsoft operating systems have supported different flavors of LM and NT LAN Manager (NTLM) authentication since the earliest days of Windows. LM authentication is an extremely old and weak authentication protocol that should no longer be used in production environments unless absolutely necessary. By default, Windows 2000 Active Directory supported client authentication attempts using LM, NTLM, or NTLMv2; Windows Server 2003 and later support only NTLM and NTLMv2 out of the box.
The strongest NTLM authentication scheme you can select is to refuse LM and NTLM authentication from any client, and to respond only to clients using NTLMv2. Depending on your client configuration, though, enabling this option may require changes on the client side as well. You can apply the same setting to a GPO linked to your Active Directory domain to ensure that all of your clients will use NTLMv2 instead of older, weaker protocols.
Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 Active Directory have a default value of “Send NTLMv2 response only” for this GPO setting. This is more secure than previous versions of the operating system but still allows domain controllers to accept weaker authentication methods.
You want to prevent any authenticated user from being able to browse the contents of Active Directory by default. Enabling List Object Access mode means that users will need explicit permissions to see directory listings of containers.
In the Configuration partition, browse to
cn=Services→cn=Windows NT→cn=Directory Service.In the left pane, right-click on the Directory Service object and select Properties.
Double-click on the
dSHeuristicsattribute.If the attribute is empty, set it with the value
001. If the attribute has an existing value, make sure the third digit (from the left) is set to1.
On Error Resume Next ' necessary if dsHeuristics is not
' already set
' This code enables or disables list object mode for a forest.
' ------ SCRIPT CONFIGURATION -----
boolEnableListObject = 1 ' e.g. 1 to enable, 0 to disable
' ------ END CONFIGURATION --------
set objRootDSE = GetObject("LDAP://RootDSE")
set objDS = GetObject( _
"LDAP://cn=Directory Service,cn=Windows NT,cn=Services," ↵
& objRootDSE.Get("configurationNamingContext") )
strDSH = objDS.Get("dSHeuristics")
if len(strDSH) = 1 then
strDSH = strDSH & "0"
end if
strNewDSH = Left(strDSH,2) & boolEnableListObject
if len(strDSH) > 3 then
strNewDSH = strNewDSH & Right(strDSH, len(strDSH) - 3)
end if
WScript.Echo "Old value: " & strDSH
WScript.Echo "New value: " & strNewDSH
if strDSH <> strNewDSH then
objDS.Put "dSHeuristics", strNewDSH
objDS.SetInfo
WScript.Echo "Successfully set list object mode to " & ↵
boolEnableListObject
else
WScript.Echo "List object mode already set to " & boolEnableListObject
end ifList Object Access mode is useful if you want your users to view only a subset of objects when doing a directory listing of a particular container, or you do not want them to be able to list the objects in a container at all. This mode was originally intended for multitenant environments and should undergo thorough testing in an environment before deploying to production. By default, the Authenticated Users group is granted the List Contents access control right over objects in a domain. If you remove or deny this right on a container by modifying the ACL, users will not be able to get a listing of the objects in that container using tools such as ADUC or ADSI Edit.
To limit the objects that users can see when they pull up an object listing, you first need to enable List Object Access mode as described in the solution. You should then remove the List Contents access control right on the target container. Lastly, you’ll need to grant the List Object right to the objects that the users or groups should be able to list.
Enabling List Object Access mode can significantly increase the administration overhead for configuring ACLs in Active Directory. It can also impact performance on a domain controller since it will take considerably more time to verify ACLs before returning information to a client.
Using one of the methods described in Changing the ACL of an Object, modify the ACL on the
cn=AdminSDHolder,cn=Systems,<DomainDN>
object in the domain that the administrator accounts reside in. The ACL
on this object gets applied every hour to all user accounts that are
members of the administrative groups.
If you’ve ever tried to directly modify the ACL on a user account that was a member of one of the administrative groups in Active Directory, or you modified the ACL on the OU containing an administrative account, and then wondered why the account’s ACL was overwritten later, you’ve come to the right place. The Admin SD Holder feature of Active Directory is one that many administrators stumble upon after much grinding of teeth. However, after you realize the purpose for it, you’ll understand it is a necessary feature.
Once an hour, a process on the PDC Emulator that we’ll refer to as
the Admin SD Holder process compares the ACL on the AdminSDHolder object to the ACL on the
accounts that are in administrative groups in the domain as well as the
groups themselves. If it detects a difference, it will overwrite the
account or Group ACL and disable inheritance.
Note
If you later remove a user from an administrative group, you will need to reapply any inherited permissions and enable inheritance if necessary. The Admin SD Holder process will not take care of this for you.
The Admin SD Holder process is intended to subvert any malicious
activity by a user that has been delegated rights over an OU or
container that contains an account that is in one of the administrative
groups. An OU administrator could, for example, modify permissions
inheritance on an OU to attempt to lock out the Domain
Admins group; this permission change would be reverted the
next time the AdminSDHolder thread
runs.
These groups are included as part of Admin SD Holder processing:
Administrators
Account Operators
Cert Publishers
Backup Operators
Domain Admins
Enterprise Admins
Print Operators
Schema Admins
Server Operators
The administrator and krbtgt user accounts are also specifically checked during the Admin SD Holder process.
The kerbtray utility can be found in the Windows Server 2003 Resource Kit. The kerbtray utility works through Windows Server 2012. Klist is built into the Active Directory Domain Services role.
Run kerbtray.exe from the command line or from Start→Run.
A new icon (green) should show up in the system tray. Double-click on that icon. This will allow you to view your current tickets.
To purge your tickets, right-click on the kerbtray icon in the system tray and select Purge Tickets.
Close the kerbtray window and reopen it by right-clicking on the kerbtray icon and selecting List Tickets.
Active Directory uses Kerberos as its preferred network authentication system. When you authenticate to a Kerberos Key Distribution Center (KDC), which in Active Directory terms is a domain controller, you are issued one or more tickets. These tickets identify you as a certain principal in Active Directory and can be used to authenticate you to other Kerberized services. This type of ticket is known as a ticket-granting ticket, or TGT. Once you’ve obtained a TGT, the client can use the TGT to gain access to a Kerberized service by querying the Ticket Granting Service on the KDC; if the KDC verifies that the user is authorized to access the service in question, it will issue a service ticket that allows the client to use the particular service.
Kerberos is a fairly complicated system, and we can’t do it justice in a single paragraph. If you want more information on tickets and how the Kerberos authentication system works, see Kerberos: The Definitive Guide by Jason Garman (O’Reilly).
RFC 1510 (The Kerberos Network Authentication Service V5); “Kerberos Authentication Overview”
Clients are experiencing authentication problems, and you’ve determined it is due to UDP fragmentation of Kerberos traffic. You want to force Kerberos traffic to use TCP instead. Perform the solution on all computers that are experiencing the issue (client computers, server, domain controllers).
In the left pane, expand HKEY_LOCAL_MACHINE→System→Current-ControlSet→Control→Lsa→Kerberos→Parameters.
Right-click on Parameters and select New→DWORD value. Enter
MaxPacketSizefor the value name.In the right pane, double-click on MaxPacketSize and enter
1.
> reg add "HKLMSYSTEMCurrentControlSetControlLsaKerberosParameters" /v↵ "MaxPacketSize" /t REG_DWORD /d 1
' This code forces Kerberos to use TCP.
' ------ SCRIPT CONFIGURATION -----
strComputer = "<ComputerName>" ' e.g. rallen-w2k3
' ------ END CONFIGURATION --------
const HKLM = &H80000002
strRegKey = "SYSTEMCurrentControlSetControlLsaKerberosParameters"
set objReg = GetObject("winmgmts:\" & strComputer & ↵
"
ootdefault:StdRegProv")
objReg.SetDwordValue HKLM, strRegKey, "MaxPacketSize", 1
WScript.Echo "Kerberos forced to use TCP for " & strComputerIf you have users that are experiencing extremely slow logon times (especially over VPN) or they are seeing the infamous “There are currently no logon servers available to service the logon request” message, then they may be experiencing UDP fragmentation of Kerberos traffic. This occurs because UDP is a connectionless protocol, so UDP packets that arrive out of order will be dropped by the destination router.
A source of information is the System event log on the clients. Various Kerberos-related events are logged there if problems with authentication occur.
Open the Default Domain Group Policy Object, or another domain-linked GPO, in the Group Policy Management Console.
Navigate to Computer Configuration→Policies→Windows Settings→Security Settings→Account Policies→Kerberos Policy.
In the right pane, double-click on the setting you want to modify.
Enter the new value and click OK.
There are several Kerberos-related settings you can customize, most of which revolve around either increasing or decreasing the maximum lifetime for Kerberos user and service tickets. In most environments, the default settings are sufficient, but the ones you can modify are listed in Table 14-2.
Warning
Change the default Kerberos policy settings with caution, as doing so can cause operational problems and compromise security if done incorrectly.
You want to view the access tokens that are created for a user account that has authenticated to Active Directory.
When an Active Directory security principal receives a TGT from the Kerberos Key Distribution Center, the TGT contains a Privilege Attribute Certificate (PAC). This PAC contains several pieces of authentication data, such as the groups that a user belongs to (including all nested group memberships). In the majority of AD environments, this PAC is created without issue, but some larger environments can run into instances of token bloat. This occurs when a user belongs to a large number of groups (estimates start at around 70 to 120), and the size of the PAC becomes too large for the TGT to handle. This issue can manifest itself through authentication issues or through Group Policy Objects not applying properly. You can download and use the tokensz.exe utility to compute the token size for a user relative to the maximum allowable size, as well as to list the groups that a user belongs to.
You can resolve this issue by streamlining the number of groups
that the user or users belong to, which has the added benefit of
simplifying the process of assigning permissions and applying Group
Policy Objects. If this isn’t possible, you can apply the hotfix
referenced in MS KB 327825 or modify the HKLMSystemCurrentControlSetControlLsaKerberosParametersMaxTokenSize
DWORD value on your domain computers. This issue is most relevant on
legacy domain controllers, since modern versions of Windows have made a
number of improvements to alleviate the need to modify this value.
Additional details about the recent improvements are in the following
“See Also” section.
If you determine that you need to modify the MaxTokenSize value, use the following formula
as an approximate guideline:
1200 + 40d + 80s
In this equation, 1200 denotes a suggested amount of overhead
that’s used by the PAC; you can use the tokensz
utility to determine the size for the domain in question. d refers to the number of domain local
security groups that a representative user is a member of, plus any
universal security groups in other domains that the user belongs to,
plus any groups represented in the user’s sIDHistory attribute. s refers to the number of global security
groups a representative user belongs to, plus any universal security
groups within the user’s own domain.
“MaxTokenSize and Windows 8 and
Windows Server 2012”; “Whoami” (note that a new /CLAIMS parameter exists but is not documented
on the Whoami site at the time of this writing)
Select Dynamic Access Control and then click Claim Types.
From the Tasks menu, click New→Claim Type.
Select an Active Directory attribute to use as a source and modify the name and description, if desired.
Select whether to use the claim type for Users, Computers, or both class types.
Click OK to create the claim type.
Claim types are associated with an Active Directory attribute and are then associated with the object class. Claim types can be associated with the following Active Directory classes:
UserComputerInetOrgPersonmsDS-ManagedServiceAccountmsDS-GroupManagedServiceAccount
“Dynamic Access Control:
Scenario Overview”; New-ADClaimType cmdlet reference;
Active
Directory, Fifth Edition, by Brian Desmond et al.
(O’Reilly)
Select Dynamic Access Control and then click Resource Properties.
From the Tasks menu click New→Resource Property.
Enter a display name for the resource property.
Select a value type from the drop-down list to use for the resource property.
If required by the value type, click Add in suggested values.
Add a value and display name, and then click OK twice.
Resource properties are used to authorize access to data. They can be used to describe and classify files through a manual or automatic classification process. Here is a list of built-in resource property value types:
MS-DS-SingleValuedChoiceMS-DS-YesNoMS-DS-NumberMS-DS-DateTimeMS-DS-OrderedListMS-DS-TextMS-DS-MultiValuedTextMS-DS-MultiValuedChoice
“Deploy a Central Access Policy
(Demonstration Steps)”; New-ADResourceProperty cmdlet
reference; and Active
Directory, Fifth Edition, by Brian Desmond et al.
(O’Reilly)
Select Dynamic Access Control and then click Central Access Rules.
From the Tasks menu, click New→Central Access Rule.
Enter a name for the rule.
If necessary, edit the target resources to customize the scope.
If necessary, modify the permissions that will apply to the central access rule.
A central access rule assigns permissions to resources under the conditions set on the target resource. Central access rules are used in central access policies, which are then applied on a resource, such as a shared folder.
“Deploy a Central Access Policy
(Demonstration Steps)”; New-ADCentralAccessRule cmdlet
reference; Active
Directory, Fifth Edition, by Brian Desmond et al.
(O’Reilly)
Select Dynamic Access Control and then click Central Access Policies.
From the Tasks menu, click New→Central Access Policy.
Enter a name for the central access policy.
Click Add and select the central access rules to add to the policy by selecting the rule and clicking the double-arrow icon.
A central access policy is a collection of central access rules. The policy can be applied to the resource that will be protected. In the PowerShell solution, first we create the access policy and then we add in the central access rules as necessary.
“Deploy a Central Access Policy (Demonstration Steps)”; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)
Create and link a GPO, or select an existing GPO to apply the central access policy.
Right-click the GPO and click Edit.
Navigate to Computer Configuration→Policies→Windows Settings→Security Settings→File System.
Right-click Central Access Policy and select Manage Central Access Policies.
Select the central access policy you wish to apply and then click Add. Click OK to close the configuration dialog box.
Central access policies complement existing discretionary access control lists (DACLs) by providing another layer of permissions for resource access. You can use Group Policy to effectively and efficiently deploy a central access policy to the specific servers that need the central access policy settings.
Applying a Central Access Policy; “Deploy a Central Access Policy (Demonstration Steps)”; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)
Select the Default Domain Controllers Policy or another GPO that applies to all domain controllers. Right-click the GPO and click Edit.
Navigate to Computer Configuration→Policies→Administrative Templates→System→KDC.
Right-click KDS Support for claims, compound authentication, and Kerberos armoring and select Edit.
Click Enabled to enable the configuration and then select Supported from the “options” drop-down list.
Click OK to close the properties dialog box.
For domain controllers to provide claims or device authorization, they must be configured to support Dynamic Access Control. Changing this setting through the Default Domain Controllers Policy allows you to modify this setting for all domain controllers efficiently and effectively.
Creating a Central Access Policy; Applying a Central Access Policy; “Deploy a Central Access Policy (Demonstration Steps)”; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)
Select the Default Domain Policy or another GPO that applies to all domain devices. Right-click the GPO and click Edit.
Navigate to Computer Configuration→Policies→Administrative Templates→System→Kerberos.
Right-click Kerberos Support for claims, compound authentication, and Kerberos armoring and select Edit.
Click Enabled to enable the configuration and then select Supported from the “options” drop-down list.
Click OK to close the properties dialog box, and then close the Group Policy Management console.
Launch the Active Directory Administrative Center.
Select Dynamic Access Control and then double-click Claim Types.
Right-click the claim that you want to modify and then select Properties.
Place a checkmark next to Computer and then click OK.
Note
Kerberos support for claims, compound authentication, and Kerberos armoring requires that there be at least one domain controller running Windows Server 2012 to support devices running Windows 8.
For devices to provide claims, they must be configured to support Dynamic Access Control. The two-step process described in this recipe allows you to configure claims for devices within a domain.
Enabling Domain Controller Support for Claims and Compound Authentication; “Deploy a Central Access Policy (Demonstration Steps)”; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)