Rutgers, The State University of New Jersey
OFFICE OF INFORMATION TECHNOLOGY | TECHNICAL DIRECTOR'S WEB PAGE
 

Setting up Active Directory at Rutgers

Rutgers does not currently have a University-wide Active Directory infrastructure. Discussions with departmental staff does not indicate sufficient interest in a single University-wide tree to make it worth implementing. That means that most departments will end up setting up their own Active Directory forest.

When designing a departmental AD implementation at Rutgers, there are several things you should think about:

Hostnames (i.e. DNS) are by far the most complex topic. Thus I'll be dealing with them last.

Authentication

Active Directory uses a modified version of Kerberos for authentication. Rutgers has a University Kerberos infrastructure, with passwords for most people in the University. Unfortunately it is not currently practical for departments to access these passwords. OIT is in the process of modifying the way Kerberos is implemented. By the summer of 2003, we hope to make it possible for departments to access Rutgers passwords. This will be done by setting up a trust relationship with the University Kerberos server.

For the moment we believe that most departments will be better off maintaining a separate database of users and passwords. However departments that need large numbers of students to use their system often want a way to authenticate with the official list of registered students. Currently the only way we have to do this is by replacing the login program with a special program that talks to servers maintained by OIT. If you need to do this, please contact hedrick@nbcs.rutgers.edu.

Time Synchronization

Active Directory uses Kerberos for security. Kerberos normally requires time to be synchronized. Active Directory apparently handles time in such a way that it can deal with clients that are out of sync in most cases. However MS still recommends synchronizing all time to a common clock.

The default approach is that all clients synchronize to their Active Directory servers. That's enough in most cases. However you should consider synchronizing your domain controller to an external time source. The best way is to use the following command on the primary domain controller:

net time /setsntp:HOSTNAME

That will set your machine to synchronize time from HOSTNAME, which should be an NTP server. I currently recommend using the OIT Network Service Systems.

This command only needs to be done once, unless you need to change the NTP servers. I believe the clients will synchronize with the servers, so it is probably not necessary on clients. It appears that it does not take effect until you reboot.

DNS/Host name setups

This section assumes you understand the basics of the Domain Name System (DNS). If you do not, Microsoft has an excellent online talk on integrating Active Directory DNS into an existing (University-wide) DNS system, Integrating Active Directory with an Existing DNS Infrastructure. This includes a review of DNS technology, and details of the Microsoft implementations and tools.

For other Microsoft recommendations on setting up AD, take a look at Best Practice Active Directory Design for Managing Windows Networks from Microsoft, and Active Directory in Windows 2000.

While AD can be implemented in a variety of configurations, Microsoft documentation tends to assume that Windows is being used for your entire infrastructure. You will be best positioned to use the features of Windows 2000 and later if you allow it to handle address and name allocation. However doing so raises issues in coordinating your department's services with general University services.

The simplest model (and the one Microsoft recommends) is to delegate all name service to Active Directory. However, as we will see below, there are reasons why you will probably want to use the University DNS system for some parts of your name service.

The basic approach is fairly simple: You choose a subdomain name, and ask the Rutgers Hostmaster to "delegate" that subdomain to you. E.g. suppose you are running services for the Web Science department. You might set up your Active Directory system to use a domain name websci.rutgers.edu. In order for people elsewhere to be able to look up names ending in websci.rutgers.edu, you must ask the Rutgers Hostmaster to delegate websci.rutgers.edu to you.

When you make this request you will need to give the hostmaster the names of two systems (primary and backup) that will act as DNS servers for your subdomain, websci.rutgers.edu. While you can use separate servers for this, most departments will probably use their primary and backup domain controllers. Ideally the backup should be on a different network, so that no failure will take down both the primary and backup. Thus it might be a good idea to arrange with another department to act as your DNS backup.

Here is an example of how to request delegation of a subdomain:

mail hostmaster@tdmx.rutgers.edu
Subject: request for domain

Please create a domain called websci.rutgers.edu. Delegate DNS service for it to my DNS name servers: dc1.websci.rutgers.edu, 128.6.1.2, and dc2.websci.rutgers.edu, 128.6.1.3.

Suppose the Web Science Department has two servers, its web and mail servers, and then a bunch of desktop systems for faculty and students. Suppose it has been given a 32-host subnet, with addresses from 128.6.1.2 to 128.6.1.30. (128.6.1.1 is the router, and 128.6.1.31 is the broadcost address, so you can't use these addresses.) Thus a typical host table would look like

In main Rutgers DNS system:

websci.rutgers.edu: delegated to department.
    name server dc1.websci.rutgers.edu
    name server dc2.websci.rutgers.edu

In Active Directory:

dc1.websci.rutgers.edu [domain controller] address 128.6.1.2
dc2.websci.rutgers.edu [second domain controller] address 128.6.1.3
www.websci.rutgers.edu [web server] address 128.6.1.4
email.websci.rutgers.edu [mail server] address 128.6.1.5
smith.websci.rutgers.edu [a faculty desktop] address 128.6.1.6
...
patel.websci.rutgers.edu [the last faculty desktop] address 128.6.1.30
As long as websci.rutgers.edu has been delegated to your server, and you set up these hosts using Active Directory, these names will work.

Unfortunately we're not quite finished. There are two problems to deal with:

  1. Reliability of forward lookups
  2. Reverse lookups
Both of these problems will tend to lead you to put some information about your hosts into the central University's DNS server.

Reliability of forward lookups

According to RFC 2182, backup DNS servers should be placed in a location where no single failure will affect both the primary and backup. This includes power failures, network failures, etc. Having both primary and backup at Rutgers does not meet the requirements of this RFC. For this reason, the University has an arrangement with another institution to maintain a backup for us. All information in the main University server is backed up there. Information in departmental servers is not backed up.

Many sites currently do not follow RFC 2182. That is, both their primary and backup DNS servers are local. It is open to debate how serious a problem this is. However our inclination is to suggest that you register any server you expect to be used significantly from outside Rutgers in a DNS server with offsite backup. In practice this probably means your web and mail servers.

The easiest way to get offsite backup for DNS service is to use the main Rutgers DNS system. Thus for the Web Science department, you might do the following:

In main Rutgers DNS system:

websci.rutgers.edu: delegated to department.
    name server dc1.websci.rutgers.edu
    name server dc2.websci.rutgers.edu
websci-www.rutgers.edu address 128.6.1.4
websci-email.rutgers.edu address 128.6.1.5

In Active Directory:

dc1.websci.rutgers.edu [domain controller] address 128.6.1.2
dc2.websci.rutgers.edu [second domain controller] address 128.6.1.3
www.websci.rutgers.edu [web server] address 128.6.1.4
email.websci.rutgers.edu [mail server] address 128.6.1.5
smith.websci.rutgers.edu [a faculty desktop] address 128.6.1.6
...
patel.websci.rutgers.edu [the last faculty desktop] address 128.6.1.30

Note that the web and mail server are registered twice, once in Active Directory and once in the University DNS system. This is perfectly legitimate, as long as the names are different. You can't register the name www.websci.rutgers.edu in the main University server because the subdomain websci.rutgers.edu has been delegated to your DNS servers.

In this example, you would be able to use either name, www.websci.rutgers.edu or websci-www.rutgers.edu, to access the web server. However we would recommend that you publicize the name registered in the University DNS server, websci-www.rutgers.edu in this case. (Otherwise there's no point to having two names.)

Other patterns of name are possible. E.g. you could use the names www.webscience.rutgers.edu and email.webscience.rutgers.edu in the main University DNS server. Or if you knew you were going to register all your "visible" servers in the University server, you might use another name for Active Directory, such as websci-ad.rutgers.edu:

In main Rutgers DNS system:

websci-ad.rutgers.edu: delegated to department.
    name server dc1.websci-ad.rutgers.edu
    name server dc2.websci-ad.rutgers.edu
www.websci.rutgers.edu address 128.6.1.4
email.websci.rutgers.edu address 128.6.1.5

In Active Directory:

dc1.websci-ad.rutgers.edu [domain controller] address 128.6.1.2
dc2.websci-ad.rutgers.edu [second domain controller] address 128.6.1.3
www.websci-ad.rutgers.edu [web server] address 128.6.1.4
email.websci-ad.rutgers.edu [mail server] address 128.6.1.5
smith.websci-ad.rutgers.edu [a faculty desktop] address 128.6.1.6
...
patel.websci-ad.rutgers.edu [the last faculty desktop] address 128.6.1.30
or possibly ad.websci.rutgers.edu.

Reverse lookups

DNS can be used to go from name to IP address and also from IP address to name. Microsoft Windows/Active Directory doesn't need "reverse lookups" (going from IP address to name). However if reverse lookups don't work, some systems at Rutgers and elsewhere will refuse to accept email from you, etc. Thus we recommend that you make sure all IP addresses that you use can be can be looked up.

When evaluating your alternatives, it is useful to know that according to Microsoft documentation, Active Directory does not depend upon or use reverse DNS entries. Thus no confusion will occur if the reverse lookup gives a different name than the one used to access Active Directory services.

To go from IP address to name, there are a set of entries that look like this:

30.1.6.128.in-addr.arpa PTR patel.websci.rutgers.edu

These use pseudo-hostnames ending in in-addr.arpa, with the IP address in reverse. This scheme works well with subnets that contain 256 hosts, because you can delegate reverse lookup for a whole subnet to the department. If you delegate 1.6.128.in-addr.arpa, then the department's DNS server has entries for 1.1.6.128.in-addr.arpa through 255.1.6.128.in-addr.arpa.

Unfortunately at Rutgers most subnets are smaller than this. There is actually a convention that allows for the delegation of fewer than 256 hosts, but this convention is not universally implemented. Thus we are not recommending that you use it.

Because it is difficult to delegate reverse lookups, we recommend that you put the reverse information into the main University DNS server.

There are two ways to do this.

1. One approach is to put just the reverse entries into the University's DNS server:

In main Rutgers DNS system:

websci.rutgers.edu: delegated to department.
    name server dc1.websci.rutgers.edu
    name server dc2.websci.rutgers.edu
2.1.6.128.in-addr.arpa PTR dc1.websci.rutgers.edu
3.1.6.128.in-addr.arpa PTR dc2.websci.rutgers.edu
websci-www.rutgers.edu address 128.6.1.4
4.1.6.128.in-addr.arpa PTR websci-www.rutgers.edu
websci-email.rutgers.edu address 128.6.1.5
5.1.6.128.in-addr.arpa PTR websci-email.rutgers.edu
6.1.6.128.in-addr.arpa PTR smith.websci.rutgers.edu
...
30.1.6.128.in-addr.arpa PTR patel.websci.rutgers.edu

In Active Directory:

dc1.websci.rutgers.edu [domain controller] address 128.6.1.2
dc2.websci.rutgers.edu [second domain controller] address 128.6.1.3
www.websci.rutgers.edu [web server] address 128.6.1.4
email.websci.rutgers.edu [mail server] address 128.6.1.5
smith.websci.rutgers.edu [a faculty desktop] address 128.6.1.6
...
patel.websci.rutgers.edu [the last faculty desktop] address 128.6.1.30

This approach works fine if you maintain your hostnames statically, that is if you manually allocate names and IP addresses. Then whenever you add or change a host, you would add an entry in Active Directory, and put the corresponding reverse entry into the University's DNS system.

2. The second approach is to put "dummy" entries in the University's DNS server. These would be entries with "anonymous" names such as websci-desktop-6 through websci-desktop-30. In this case you could dynamically add and move desktops within your department, without having to keep them up to date in the University's DNS server. You probably do want to have correct names for your servers in the University's DNS system:

In main Rutgers DNS system:

websci.rutgers.edu: delegated to department.
    name server dc1.websci.rutgers.edu
    name server dc2.websci.rutgers.edu
websci-dc1.rutgers.edu address 128.6.1.2
2.1.6.128.in-addr.arpa PTR dc1.websci.rutgers.edu
websci-dc2.rutgers.edu address 128.6.1.3
3.1.6.128.in-addr.arpa PTR dc2.websci.rutgers.edu
websci-www.rutgers.edu address 128.6.1.4
4.1.6.128.in-addr.arpa PTR websci-www.rutgers.edu
websci-email.rutgers.edu address 128.6.1.5
5.1.6.128.in-addr.arpa PTR websci-email.rutgers.edu
websci-desktop-6.rutgers.edu address 128.6.1.6
6.1.6.128.in-addr.arpa PTR smith.websci.rutgers.edu
...
websci-desktop-30.rutgers.edu address 128.6.1.30
30.1.6.128.in-addr.arpa PTR patel.websci.rutgers.edu

In Active Directory:

dc1.websci.rutgers.edu [domain controller] address 128.6.1.2
dc2.websci.rutgers.edu [second domain controller] address 128.6.1.3
www.websci.rutgers.edu [web server] address 128.6.1.4
email.websci.rutgers.edu [mail server] address 128.6.1.5
smith.websci.rutgers.edu [a faculty desktop] address 128.6.1.6
...
patel.websci.rutgers.edu [the last faculty desktop] address 128.6.1.30

In this approach, every system has two names, one in Active Directory and one in the University's system. This shouldn't cause any problems.

While these examples only show address and PTR records, you would of course want to have other basic information, such as MX and RP (responsible person) records.

I believe the first approach is in some sense more elegant, because most hosts only have one name. However the second is likely to be easier to manage. It is, of course, possible to use different approaches for different hosts or ranges or hosts.

The second approach is likely to be more practical if you use Active Directory's ability to add and move hosts automatically.

WARNING: If you allocate IP addresses dynamically, make sure that all hosts in the group are under the same management. One major issue these days is abuse: It is quite common for systems to be compromised by a hacker and then used to attack other systems. It is important for University security staff to be able to track down who is responsible for every computer on campus, so that the responsible person can take appropriate action to deal with abuse.

If you use dynamic IP address assignment, you'll want to have different ranges of IP address for different purposes. E.g. you might use addresses 6 - 20 for faculty and 21 - 30 for grad students. Then if there is abuse, it will be clear which type of system is involved, and what staff member to contact. If you have a scheme like this, I would use names that reflect it, e.g. websci-faculty-6 through websci-faculty-20 and websci-grad-21 through websci-grad-30. Make sure that the responsible person entry is correct for each range.

One final (unsupported) option

The major difficulties with the approaches just described come from coordinating names in your AD server with names registered with the University. There is another approach which ends up with only one name. However Microsoft doesn't consider it a best practice, and one department that used this approach was told by Microsoft that it was causing their servers to crash. I'm sceptical, but you need to realize that Microsoft doesn't like this approach. The rest of this section describes how to implement this option. This section is present primarily for historical reasons. Until recently this was the only approach described in this document. I don't believe I would use it in new installations.

In this approach, all names are registered in the University's DNS server. Your AD server will probably act as a DNS server, but the names in it won't be used. Because Windows 2000 automatically assumes that its hostnames are maintained by Active Directory, this requires doing some non-standard setups to give them the names from the University DNS system.

1) Decide on names for your Win2000 server, and your active directory domain (which I'm going to call the AD domain). I strongly recommend choosing a name for your AD domain that is NOT the name you would use for a subdomain for your department.

Example: the computer science department wants to set up an AD server. Computer science is using now, or thinks it might use in the future, cs.rutgers.edu as a regular subdomain, with names like www.cs.rutgers.edu, ftp.cs.rutgers.edu, etc.

I recommend calling their AD domain something else. Two possibilities are a second-level subdomain, e.g. ad.cs.rutgers.edu, or a completely different name, e.g. compsci.rutgers.edu or cs-ad.rutgers.edu.

For this example, I assume that they want to call the Windows 2000 server myserv.rutgers.edu. Another reasonable name would be myserv.cs.rutgers.edu.

2) If your W2K server is already registered with hostmaster (i.e. if you already have a hostname and IP address for it), skip this step.

For your W2K server, make a normal hostmaster request for your server. Get an IP address assigned as usual.

3) Once you have an IP address for your server, make a request to hostmaster for a domain with the same name as your AD domain. E.g. ask hostmaster for a domain ad.cs.rutgers.edu. When you ask for a domain, you need to give them the name of the DNS server for that domain. Give them the name of the your W2K server. E.g.

mail hostmaster@tdmx.rutgers.edu
Subject: request for domain

Please create a domain called ad.cs.rutgers.edu. The name server will be myserv.rutgers.edu. This domain will only be used for Active Directory support data. There will be no hosts registered in it.

I recommend that you not set up AD until you have verified that your subdomain is accessible in DNS. One way to do this is

host -t ns ad.cs.rutgers.edu
or
nslookup -type=ns ad.cs.rutgers.edu

The response should be something like

ad.cs.rutgers.edu name server myserv.rutgers.edu

4) Set your system so that AD won't change its hostname. You must do this before setting up Active Directory.

5) Set up Active Directory on Windows 2000. Once the OS is installed, at some point you'll set up Active Directory. (This is a separate step, which you do after the regular install.) Have your install CD ready before doing this, because it will have to install some additional software. Be aware that you will have to reboot at the end, so pick a time when this is possible. Here's the dialog:

6) Once you've rebooted, verify that the SRV records are actually present. On a Unix system that has the host command, do

host -l -t any ad.cs.rutgers.edu
or
nslookup
server myserv.rutgers.edu
ls -d ad.cs.rutgers.edu

You should see a bunch of SRV records with names that start with _, e.g. _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs. If you see just a couple of records, e.g. just the address of the server, there is probably some problem in the way the subdomain was registered in DNS.

6) AD uses Kerberos for security. Kerberos normally requires time to be synchronized. Active Directory apparently handles time in such a way that it can deal with clients that are out of sync in most cases. However MS still recommends synchronizing all time to a common clock. The best way is to use the following command on the PDC:

net time /setsntp:HOSTNAME

That will set your machine to synchronize time from HOSTNAME, which should be an NTP server. I currently recommend using the new TD NTP servers, but I don't yet know their names.

This command only needs to be done once, unless you need to change the NTP servers. I believe the clients will synchronize with the servers, so it is probably not necessary on clients. It appears that it does not take effect until you reboot.

7) Unless your clients are all going to have host names that are within your AD domain (which would be inconsistent with this option), you need to do the following. These changes allow your clients to choose their own hostnames.

8) You'll want to do step (4) on any client before you configure it to join the AD domain. Otherwise it will change its name when it joins the domain.

BACK TO TOP

For more information, contact hedrick@rutgers.edu.
Last updated: Tuesday, 31-May-2005 12:21:11 EDT
© 2005 Rutgers, The State University of New Jersey. All rights reserved.