Windows 2000 Active Directory in the University of Oxford

 

Caveat

This document may change as our knowledge and understanding of Active Directory develops.

 

Background

Unlike NT4, which uses NetBIOS names together with WINS for providing NetBIOS to IP address resolution, Windows 2000 uses IP names, together with the DNS for name resolution and for the location of Windows 2000 services by Windows 2000 Professional clients. Additionally, Thus the naming of Windows 2000 domains within Oxford has implications for the configuration of the existing Oxford DNS. For this reason we need to reach an agreement on the way in which Active Directory will be implemented within Oxford, particularly in so far as the naming of domains and DNS configuration are concerned, or clients may not be able to locate the servers that they need to.

Since the renaming of Active Directory domains is impossible, it is currently recommended that no production Active Directory systems be set up until a decision has been reached as to the Active Directory structure within Oxford, together with a naming scheme and associated DNS setup. This recommendation only affects setting up live Active Directory systems; running Windows 2000 server without Active Directory and setting up test Active Directory systems is not a problem.

This document follows on from the Windows 2000 Active Directory meeting held in Corpus Christi on 26 April 2000. In the course of the meeting we considered the options for implementing Active Directory within the University.

The first option considered was a single forest model with each unit running its own domain. The root domain of the forest would be a subdomain of ox.ac.uk, such as ad.ox.ac.uk, and each unit would run their own DNS server to service the servers in the unit.ad.ox.ac.uk zone.

The second option considered was a multiple forest model with each unit setting up their own single-domain forest. The name of the forest would be the same as existing domain names i.e. unit.ox.ac.uk and limited DNS authority for certain subzones of unit.ox.ac.uk would be delegated to Windows 2000 servers in the unit to support dynamic updating of SRV records for that unit.

The consensus reached at the end of the meeting was to adopt the second option. The findings were presented at a subsequent Network Advisory Group meeting on 9 May 2000. At the meeting, concerns were raised over whether this decision would preclude the future use of Kerberos as a mechanism for a single point of authentication. In the light of these concerns any decision was deferred while the implications for Kerberos were considered and we reconsidered the various options available.

This document aims to set out the options available together with their main advantages and disadvantages.

 

Active Directory Models

During our original discussion we considered one model for a single forest within the University, and one model for multiple forests. In fact there are two main models for a single forest.

Single Forest Models

Model 1 Single forest, multiple domain model. This is the original model discussed where we have a single forest with one domain per unit, giving a minimum of one Domain Controller per unit (for all units requiring Windows 2000 server).

Advantages: Disadvantages:

Model 2 Single forest, single domain model. This is the model that we haven't considered. Again this would be a single forest but with only one domain for the whole university. This is actually the scenario that is most in line with what other Universities (e.g. Leicester, York, also US Universities) are doing. It would require the least infrastructure hardware (e.g. Leicester currently have 5,500 users, 1,400 clients and peak concurrent logins of 750 supported on 6 servers, 4 of which run Active Directory and 1 of which runs Exchange).

If we were to implement this within Oxford, only a small number of domain controllers would be required and these would be managed centrally. As a result, the administration of schema updates and replication traffic should not cause problems. Units could keep administrative responsibility for management of local users and workstations through delegated responsibility for Organisational Units. Units could run member servers for local applications. However units would lose flexibility by not running Active Directory in-house. For example, a unit wanting to install a beta copy of software that required a schema update might not be able to. One major consideration would be how to integrate existing Exchange servers into this scenario. In addition, even with a single domain, there still remains the question of whether users have a single username, or multiple usernames, one for each unit that they belong to.

Advantages: Disadvantages:

Multiple Forest Model

Model 3 Multiple forest, single domain model. In this model, each unit that wants W2K would run its own Domain Controller(s) to administer its own domain. Each domain is in its own forest. This is essentially the same as Model 2, but at a unit level. The unit would be limited to one domain.

Advantages: Disadvantages:

Model 4 Combination. We might also want to consider combining Models 2 and 3 by providing a central service for units who want to use it, and allowing units who want to develop their own AD service to do so as described by Model 3.

 

DNS and Active Directory.

Background and Requirements

  1. The Active Directory uses the DNS to register services and servers. Active Directory requires that the DNS support SRV records and prefers that it support dynamic updates.
  2. Within Oxford University DNS services are currently provided using BIND on UNIX systems and they are managed centrally. These central servers will be retained and will continue to provide the main University DNS service. Security concerns mean that dynamic updates will not be allowed on the central servers. Further, dynamic updating of A records (DNS name to IP address mapping) within the current Oxford University namespace as it exists at present will not be allowed. Thus to allow dynamic updates, one or more zones must be delegated to DNS servers running on Windows 2000 servers.
  3. We can make a distinction between the DNS registration of "A" records (DNS name to IP address mapping) and "SRV" records (which are registered by servers and are necessary to allow Windows 2000 clients to find Active Directory servers and services.) It is possible to allow "SRV" records for a domain to be updated dynamically but not "A" records by delegating four new zones from an existing domain to a Windows 2000 DNS server within that zone. These zones are _tcp.domain, _udp.domain, _sites.domain and _msdcs.domain. All "SRV" records are registered in these zones, but no "A" records are registered in them; therefore no A records can be updated dynamically.
  4. Where Universities have been looking at implementing Active Directory then in general they have created a new zone (e.g. Leicester have created cfs.le.ac.uk), delegated authority for this zone to a Windows 2000 DNS server and used the zone name as their Windows 2000 domain name. One US University appears does to be using the existing DNS domain names for their Active Directory implementation. At Oxford we have considered both creating a new zone (e.g. ad.ox.ac.uk) and keeping the Active Directory domain name(s) the same as existing names (e.g. unit.ox.ac.uk).
  5. PCs running Windows 2000 (Server or Workstation) can have more than one identity. They can have an identity that is determined by the name of the Windows 2000 domain that they currently belong to, and an identity that is used for Internet purposes. This is because the Active Directory namespace is not the same as the DNS namespace, even though the DNS is used to register and locate machines in both namespaces. This split identity initially caused us concern. However, it looks as if for workstations and member servers, the Active Directory identity is not required, and both identities can be fixed as the same, namely the Internet identity. Thus the only PCs that may have a dual identity are domain controllers.
  6. Using existing domain names would only require a mechanism for updating "SRV" records we could continue to use existing methods for registering "A" records. Using a new subdomain (e.g. ad.ox.ac.uk) would require a method for registering "A" records within this new domain for servers. For example, server1.unit.ad.ox.ac.uk, which would also have the identity server1.unit.ox.ac.uk, would require an "A" record mapping server1.unit.ad.ox.ac.uk, as well as the normal one for server1.unit.ox.ac.uk. This is because all "SRV" records pointing at this server will point to its Windows 2000 identity, i.e. server1.unit.ad.ox.ac.uk.
  7. Whether or not a new zone is delegated (e.g. ad.ox.ac.uk), it is desirable that existing names be retained. For example we don't want to have externally visible servers such as web servers changing their name.
  8. Regardless of the name of the Windows 2000 domain, alternative User Principal Names (UPN) can be used in order to simplify usernames as far as the user is concerned. For example, by setting up an appropriate UPN, a user with the name test, logging on to a domain called oucs.ad.ox.ac.uk using the full name of test@oucs.ad.ox.ac.uk could also log on as test@oucs.ox.ac.uk. Thus as far as the user is concerned the choice of domain name may not be too important.

DNS Solutions for the above models

Model 1 Single forest, multiple domains. For this model we proposed configuring a new zone e.g. ad.ox.ac.uk and delegating authority to an intermediary DNS server (probably Windows 2000 based). From this server, authority would be delegated for each unit (unit.ad.ox.ac.uk) to that unit's own Windows 2000 based DNS servers. This would allow both SRV and A records for that zone to be updated dynamically. Secure updates should be tailored; for example to only allow updates from certain IP addresses (e.g. known servers).

Model 2 Single forest, single domain. In this scenario we would probably configure a new zone e.g. ad.ox.ac.uk and delegate authority for this zone to Windows 2000 DNS running on servers in the forest. Again secure updates should be tailored; for example to only allow updates from certain IP addresses (e.g. known servers).

Model 3 Multiple forests, single domain. We proposed keeping the Active Directory domain names the same as the existing DNS names for units (i.e. unit.ox.ac.uk). In this case, the "A" records for servers can be registered using the current methods. Within a unit, SRV records can be updated dynamically by delegating the _tcp, _udp, _sites and _msdcs zones beneath unit.ox.ac.uk to a Windows 2000 DNS server in the unit. The Windows 2000 DNS server could be configured only to allow secure dynamic updates from known servers.

Model 4 Multiple forests, single domain. This would use the solutions for Models 2 and 3, since it is a combination of the two.

 

Single Point of Authentication and Kerberos

The main reason for reopening the single versus multiple forest debate was concern over the practicality of developing a mechanism for a single point of authentication using Kerberos for the University if we adopt the multiple forest model. Developing a single sign-on mechanism using Kerberos would (as I understand it) most likely require trusts to be set up between Kerberos realms. It is much more likely that a solution for a University-wide single point of authentication that includes Active Directory can be developed if the University has a single forest than if it has multiple forests, since the trust relationships required to support the later may be too impractical (or impossible) to implement.

However, the University does essentially has two levels of IT provision, one which is administered centrally and the other at a unit level. In the light of this, perhaps our best approach to the single point of authentication issue is to recognise that for units adopting Model 3, it may not be possible to include Active Directory in any University-wise solution, which for units adopting Model 2, a solution will be provided. This would leave the choice to individual units.

 

Summary

Model 1 Single forest, multiple domains. There are a lot of unknown quantities with this model, particularly reservations about the administration of schema updates and replication traffic. We should obtain further information about the practicality of this model before considering it further.

Model 2 Single forest, single domain. This model has already been tried and tested to some extent, with other universities at various stages down this path. It appears to have very few disadvantages, requiring the least hardware, being easier for users and should be easier to incorporate into any future single sign-on solution. However, one of its main disadvantages is likely loss of flexibility at the unit level, and this may mean that it is an unacceptable solution for some units.

Model 3 Multiple forests, single domain. Since this is essentially Model 2. operating at a unit (as opposed to University) level, it should work well while preserving unit-level flexibility. However following this route may mean that it may be difficult or impossible to include Active Directory domains in any future University-wide single sign-on system, and it leaves many users with multiple identities in different units (which is the same as at present).

Model 4 Combination of Models 2 and 3. Combining Models 2 and 3 by providing a central service for units who want to use it, and allowing units who want to develop their own AD service to do as described by Model 3 may be a compromise solution.

Bridget Lewis, OUCS
June 2000