Part 2: Windows Server 2008 Active Directory Kerberos and LDAP Integration — Active Directory Server Setup

For my initial Active Directory server, I chose to use 64-bit Windows Server 2008 Enterprise. The decision to use Enterprise was guided by my intention of eventually supporting an internal PKI for Windows clients, rather than for anything related to the core Active Directory functionality used in this project. As an aside, this initial domain controller which will serve as the primary DC, is a virtual machine running under VMware ESXi. After the initial install reboot, I took care of housekeeping tasks including naming the server, setting a static IP address, installing VMware tools, setting the administrator password, and configuring Windows Updates.

Once this was done, I began the process of installing Active Directory using the dcpromo.exe command. Some of the choices I made:

• Don’t use ‘advanced mode’ installation
• create a new forest
• set the forest functional level to 2008
• install DNS
• reboot upon completion

After the reboot, I also configured the server as a DHCP server for its subnet. This particular system in is a subnet that is contained to a single server room, and most of the IPs on the network are statically assigned. In environments such as this with good physical security, I like to have a small (5-10 IP) range of addresses available via DHCP to simplify the process of setting up new systems and appliances; and in this case, test lab clients. To support DNS resolution for the test client systems, I set the DHCP scope options for DNS to always request DNS records, and to request DNS updates even if clients do not ask for it; these two settings will allow me to use DHCP clients during testing. Finally to authorize the DHCP service to make DNS updates, I created a service account, opened an administrative command prompt, and ran the following command:

the ‘*’ indicates that I wanted to provide the password interactively — it can be replaced by the password itself for scripted use.

Once this was done I moved on with configuring the server for integration. Using the Role Services pane of Server Manager, I installed ‘Identity Management for UNIX’, which makes some configuration changes allowing required LDAP attributes (such as uid, home directory, etc) to be set using the standard ADUC tools; some resources I’ve seen on the web indicate that the Active Directory schema is RFC 2307 compliant without the ‘Identity Management for UNIX’ addition, but I’ve never tested it, and don’t think it’s worthwhile to experiment with unless you never plan to use the Active Directory Users and Computers tools. After installation, another reboot is required.

The next step was to set up OUs for accounts and groups. I chose to stick with UNIX conventions and create an OU called People for user accounts, and one called Groups for groups. The purpose for creating separate groups (ie, not using the CN=Users container) was because I’ve found it valuable to allow anonymous binding for account information, and doing this makes it easier to restrict this access to the most restrictive settings possible.

Enabling anonymous binds requires two steps. First, open Active Directory Users and Computers, check the Advanced Features option on the View menu, right-click properties for the forest root, and select the Security tab. Add the ‘ANONYMOUS LOGON’ user and give it read access, then click the Advanced button, select the ‘ANONYMOUS LOGON’ user and choose Edit; the ‘Apply To’ drop-down box needs to be set to ‘This object and all descendant objects’.

Even after the ANONYMOUS LOGON account has been given access, Windows 2003 and 2008 will by policy still deny anonymous binding. Changing this setting requires the use of adsiedit.msc, which is included by default in Windows Server 2008. After launching adsiedit.msc from the Start Menu, right-click the ‘ADSI Edit’ icon and choose ‘Connect To…’ then from the ‘Select a well known Naming Context’ drop-down, choose Configuration.  Drill down to ‘CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration’ and open the properties dialog for that object. Locate the dSHeuristics attribute and note what it’s set to. If it is not set — on a freshly installed machine it shouldn’t be set — it should be the 7-digit string ‘0000002′. If it is already set, the last digit should be set to ‘2′ and all others should be left alone.

Although I intend to run an internal PKI from the Active Directory server, for now I plan to set up a commercial third-party SSL certificate to secure LDAP. So far I’ve identified this as a potential problem down the road — Microsoft does not specify any way to choose which of multiple certificates a server will use for LDAPS, so once I add the PKI I’m not sure that LDAPS will continue to use the third-party certificate — if this turns out to be the case, in production I’ll have to create the internal CA at this point and make it’s root certificate available to clients, rather than downloading the commercial CA root certificate.

But for now, installing the third-party certificate can be done using the Certificates MMC snap-in. Open mmc.exe and add Certificates; choose ‘Computer Account’, then ‘Local Computer’ and click Finish. Expand the ‘Certificates (Local Computer)’ tree, right-click on Personal, and choose ‘All Tasks’->’Import…’. Walk through the wizard to implement your certificate (you’ll need it in a PKCS#12 format). After the certificate has been imported, it will be visible under the Personal certificates pane. Rebooting the server is all that is needed to enable LDAPS.

At this point the domain controller is pretty much all set up for basic authentication. The next step is to populate at least a minimum set of user and group accounts. The user accounts should be normal users created in the OU=People, and the groups should be global security groups created in OU=Groups. Note that due to Active Directory naming restrictions, this won’t allow you to use the RedHat user-group convention, in which each user’s primary group is the same as the user’s name, and any additional memberships are secondary. Since this model isn’t used in my environment it barely has any impact on my setup, but if you’re used to using this group model, you’ll need to plan around this. After creating a new user or group, open the properties dialog for the object, select the UNIX Attributes tab, select the “NIS domain” corresponding to your domain name, and set the required attributes for the object.

That’s pretty much it as far as Active Directory configuration goes. I anticipate adding a section on setting up Kerberos service and host principals once I get NFS working, but next up will be the scoop on configuring Linux clients to allow user authentication.