441 2. Open the Add or Remove Programs applet. 3. Click on Add/Remove Windows Components. 4. Check the box beside Certificate Services and click Yes to verify. 5. Click Next. 6. Select the type of authority you want the domain controller to be (select Enterprise root CA if you are unsure) and click Next. 7. Type the common name for the CA, select a validity period, and click Next. 8. Enter the location for certificate database and logs and click Next. 9. After the installation completes, click Finish. 10. Now open the Domain Controller Security Policy GPO. 11. Navigate to Computer Configuration Windows Settings Security Settings Public Key Policies. 12. Right-click on Automatic Certificate Request Settings and select New Automatic Certificate Request. 13. Click Next. 14. Under Certificate Templates, click on Domain Controller and click Next. 15. Click Finish. 16. Right-click on Automatic Certificate Request Settings select New Automatic Certificate Request. 17. Click Next. 18. Under Certificate Templates, click on Computer and click Next. 19. Click Finish. 14.1.3 Discussion After domain controllers obtain certificates, they open up ports 636 and 3289. Port 636 is for LDAP over SSL/TLS and port 3289 is used for the global catalog over SSL/TLS. See Recipe 14.2 for more information on how to query a domain controller using SSL/TLS. 14.1.4 See Also MS KB 247078 (HOW TO: Enable Secure Socket Layer (SSL) Communication Over LDAP For Windows 2000 Domain Controllers), MS KB 281271 (Windows 2000 Certification Authority Configuration to Publish Certificates in Active Directory of Trusted Domain), and MS KB 321051 (How to Enable LDAP over SSL with a Third-Party Certification Authority) Recipe 14.2 Encrypting LDAP Traffic with SSL, TLS, or Signing 14.2.1 Problem You want to encrypt LDAP traffic using SSL, TLS, or signing. 442 14.2.2 Solution 14.2.2.1 Using a graphical user interface Most of the GUI-based tools on a Windows Server 2003, Windows XP, or Windows 2000 SP 3 machine 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 • ADSI Edit • Group Policy Management Console • Object Picker Also with ADSI Edit, you can 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. The Windows Server 2003 version of LDP supports encryption using the StartTLS and StopTLS operations, which are available from the Options TLS menu. With the Windows 2000 version, you can use SSL by going to Connection Connect and entering 636 or 3269 for the port. 14.2.2.2 Using a command-line interface The DS command-line tools support LDAP signing and encryption when run from Windows Server 2003 or Windows XP against a Windows 2000 SP3 or Windows Server 2003 domain controller. This includes dsadd, dsmod, dsrm, dsmove, dsget, and dsquery. 14.2.2.3 Using VBScript ' This code shows how to enable SSL and secure authentication using ADSI ADS_SECURE_AUTHENTICATION = 1 ADS_USE_SSL = 2 set objLDAP = GetObject("LDAP:") set objOU = objLDAP.OpenDSObject("LDAP://ou=Sales,dc=rallencorp,dc=com", _ "administrator@rallencorp.com", _ "MyAdminPassword", _ ADS_SECURE_AUTHENTICATION + ADS_USE_SSL) WScript.Echo objOU.Get("ou") ' This code shows how to enable SSL and secure authentication using ADO: ' Constants taken from ADS_AUTHENTICATION_ENUM ADS_SECURE_AUTHENTICATION = 1 ADS_USE_SSL = 2 443 set objConn = CreateObject("ADODB.Connection") objConn.Provider = "ADsDSOObject" objConn.Properties("User ID") = "administrator@rallencorp.com" objConn.Properties("Password") = "MyAdminPassword" objConn.Properties("Encrypt Password") = True objConn.Properties("ADSI Flag") = ADS_SECURE_AUTHENTICATION + ADS_USE_SSL objConn.Open "Active Directory Provider" set objRS = objConn.Execute("<LDAP://cn=users,dc=rallencorp,dc=com>;" & _ "(cn=*);" & "cn;" & "onelevel") objRS.MoveFirst while Not objRS.EOF Wscript.Echo objRS.Fields(0).Value objRS.MoveNext wend 14.2.3 Discussion The out-of-the-box install of Windows 2000 Active Directory did not provide any default data encryption over the network between clients and domain controllers with most of the standard tools. 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, so with Windows Server 2003 most of the AD tools sign and encrypt traffic from the clients to the domain controllers by default. To use the more secure Windows Server 2003 tools against Windows 2000 domain controllers, you need to install SP 3 on the Windows 2000 domain controllers. The new versions of the tools cannot be run directly on Windows 2000, so you must use a Windows XP or Windows Server 2003 machine to host them. If you want to take advantage of some of the new features of the tools, but have not installed SP 3 yet, you can disable signing on the Windows XP or Windows Server 2003 machine. It is worth stating the obvious that this is insecure and defeats one of the major benefits of the new tools, but you may have no other choice. To disable signing, set the following registry value to 0x03: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AdminDebug\ADsOpenObjectFlags 14.2.4 See Also Recipe 14.1 for enabling SSL/TLS, MS KB 325465 (Windows 2000 Domain Controllers Require SP3 or Later When Using Windows Server 2003 Administration Tools), MS KB 304718 (Administering Windows Server-Based Computers Using Windows XP Professional-Based Clients), and MSDN: ADS_AUTHENTICATION_ENUM 444 Recipe 14.3 Enabling Anonymous LDAP Access 14.3.1 Problem You want to enable anonymous LDAP access for clients. In Windows 2000 Active Directory, anonymous queries were enabled by default, although restricted. With Windows Server 2003 Active Directory, anonymous queries are disabled except for querying the RootDSE. 14.3.2 Solution 14.3.2.1 Using a graphical user interface 1. Open ADSI Edit. 2. In the Configuration partition, browse to cn=Services cn=Windows NT cn=Directory Service. 3. In the left pane, right-click on the Directory Service object and select Properties. 4. Double-click on the dSHeuristics attribute. 5. If the attribute is empty, set it with the value: 0000002. 6. If the attribute has an existing value, make sure the seventh digit is set to 2. 7. Click OK twice. 14.3.2.2 Using VBScript ' This code enables or disables anonymous query mode for a forest. ' SCRIPT CONFIGURATION boolEnableAnonQuery = 2 ' e.g. 2 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") for i = len(strDSH) to 6 strDSH = strDSH & "0" next strNewDSH = Left(strDSH,6) & boolEnableAnonQuery strNewDSH = strNewDSH & Right(strDSH, len(strDSH) - 7 ) WScript.Echo "Old value: " & strDSH WScript.Echo "New value: " & strNewDSH if strDSH <> strNewDSH then objDS.Put "dSHeuristics", strNewDSH objDS.SetInfo WScript.Echo "Successfully set anon query mode to " & boolEnableAnonQuery else WScript.Echo "Anon query mode already set to " & boolEnableAnonQuery end if 445 14.3.3 Discussion 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 Mode" (see Recipe 14.15) 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 bit 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 the following: 0000002. After enabling anonymous access, the assumption is you'll want to grant access for anonymous users to retrieve some 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 email addresses of user objects. 14.3.4 See Also MS KB 320528 (How to Configure Active Directory to Allow Anonymous Queries), and MS KB 326690 (Anonymous LDAP Operations to Active Directory Are Disabled on Windows Server 2003 Domain Controllers) Recipe 14.4 Restricting Hosts from Performing LDAP Queries 14.4.1 Problem You want domain controllers to reject LDAP queries from certain IP addresses. This can be useful if you want to prohibit domain controllers from responding to LDAP queries for certain applications or hosts. 14.4.2 Solution 14.4.2.1 Using a command-line interface This option is not present in the Windows Server 2003 version of ntdsutil. The following adds network 10.0.0.0 with mask 255.255.255.0 to the IP deny list: > ntdsutil "ipdeny list" conn "co t s <DomainControllerName>" q 446 IP Deny List: Add 10.0.0.0 255.255.255.0 *[1] 10.0.0.0 GROUP MASK 255.255.255.0 NOTE: * | D - uncommitted addition | deletion IP Deny List: Commit [1] 10.10.10.0 GROUP MASK 255.255.255.0 NOTE: * | D - uncommitted addition | deletion 14.4.3 Discussion The IP deny list is stored as an octet string in the lDAPIPDenyList attribute of a query policy. See Recipe 4.23 for more information on the LDAP query policy. When the IP deny list is set, domain controllers that are using the default query policy will not respond to LDAP queries from any IP address specified in the deny list address range. To test whether a certain IP address would be denied, run Test x.x.x.x, where x.x.x.x is an IP address, from the IP Deny List: subcommand in ntdsutil. By setting the IP deny list on the default query policy, you would effectively restrict the IP address range from querying any domain controller in the forest. If you need to only restrict queries for a specific domain controller, you'll need to create a new LDAP query policy and apply it to the domain controller. 14.4.4 See Also Recipe 4.23 for more information on the LDAP query policy, and MS KB 314976 (HOW TO: Use the Ntdsutil Utility to Deny Access to IP Addresses in Windows 2000) Recipe 14.5 Using the Delegation of Control Wizard 14.5.1 Problem You want to delegate control over objects in Active Directory to a user or group. 14.5.2 Solution 14.5.2.1 Using a graphical user interface 1. Open the Active Directory Users and Computers or Active Directory Sites and Services snap-in depending on the type of object you want to delegate. 2. In the left pane, browse to the object you want to delegate control on. 3. 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. 4. Click Next. 5. Click the Add button and use the Object Picker to select the users or groups you want to delegate control to. 447 6. Click Next. 7. If the task you want to delegate is an option under Delegate the following common tasks, check 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 go perform two additional steps: a. Select the object type you want to delegate. b. Click Next. c. Select the permissions you want to delegate. d. Click Next. 8. Click Finish. 14.5.3 Discussion 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 limited. The default tasks that can be delegated are fairly minimal, although you can add more tasks as described in Recipe 14.6. Another limitation is that you can only add new permissions; you cannot undo or remove permissions that you set with the wizard. To do that, you have to use the ACL Editor directly as described in Recipe 14.10. 14.5.4 See Also Recipe 14.6 for customizing the Delegation of Control wizard Recipe 14.6 Customizing the Delegation of Control Wizard 14.6.1 Problem You want to add or remove new delegation options in the Delegation of Control Wizard. 14.6.2 Solution Open the Delegation of Control Wizard INF file (%SystemRoot%\Inf\Delegwiz.inf) on the computer you want to modify the wizard for. Under the [DelegationTemplates] section, you'll see a line like 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 I'll follow the same naming convention and create a template named template14. The line now looks like this: 448 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 = <CommaSeparatedOfObjectClassesInvokedFrom> 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, e.g., template14. In the AppliesToClasses line, replace <CommaSeparatedObjectClassesInvokedFrom> 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: 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 an example 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 that be delegated. In this example, permissions will be modified for user and inetOrgPerson objects: ObjectTypes = user,inetOrgPerson 449 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 grant the ability to create (CC) or delete (DC) 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. Here are the valid codes: 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 grant full control over all existing user and inetOrgPerson objects, I'll use these entries: [template14.user] @=GA [template14.inetOrgPerson] @=GA 450 This is very similar to the previous example except that SCOPE was 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 attribute the permission applies to. For example, this would grant 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 need to specify the LDAP display name of the control access right you want to enable. This next 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 14.6.3 Discussion 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 use group policy to automate the distribution of it. 14.6.4 See Also Recipe 14.5 for more on using the Delegation of Control wizard Recipe 14.7 Viewing the ACL for an Object 14.7.1 Problem You want to view the ACL for an object. 14.7.2 Solution 14.7.2.1 Using a graphical user interface 1. 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. To see the Security tab with ADUC, you must select View Advanced Features from the menu. 2. Click the Advanced button to view a list of the individual ACEs. 14.7.2.2 Using a command-line interface . enable anonymous LDAP access for clients. In Windows 2000 Active Directory, anonymous queries were enabled by default, although restricted. With Windows Server 2003 Active Directory, anonymous queries. tools on a Windows Server 2003, Windows XP, or Windows 2000 SP 3 machine automatically sign and encrypt traffic between the server and client. This includes the following tools: • Active Directory. command-line tools support LDAP signing and encryption when run from Windows Server 2003 or Windows XP against a Windows 2000 SP3 or Windows Server 2003 domain controller. This includes dsadd, dsmod,