This document may change as our knowledge and understanding of Active Directory develops.
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.
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.
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:
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:
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:
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.
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.
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.
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