The University of Melbourne Active Directory

• About the Active Directory
• Getting your department involved
• Joining computers to the Active Directory
• Certification and training
• Terminal Services and licensing

About the Active Directory

Active Directory architecture

The Windows 2000 Active Directory was established as a result of the Windows 2000 Working Group recommendations in February 2000.  The model, rollout plan and architecture described in Windows 2000 architecture (.doc) was adopted as official University policy during 2000.

Windows Server 2003

Windows Server 2003 (formerly .NET Server) was released in April 2003 as the successor to Windows 2000 Server. After installing and testing Windows 2003, LAN Server Group has approved its use use on the University network (.doc).

Windows NT 4 Server

Windows NT 4 Server reaches the end of its "Product Life Cycle" on 31 December, 2004 and Microsoft will not be releasing security hotfixes after this date. The cessation of security updates means that it will be an unacceptable security risk to allow NT 4 servers to remain on the University network after this date.

• Departments still operating NT 4 Servers will need to decommission these servers or upgrade to Windows 2000 or 2003 Server as the Microsoft Hardware Compatibility (HCL) permits.
• Departments using Windows NT Server as a domain controller will need to migrate to the University-wide Windows 2000 forest - if they have not already done so - and demote all domain controllers. Please contact LAN Server Group for further advice.
• Departments requiring continued NT 4 domain functionality will need to reestablish the domain using the Samba 3 PDC function. Please note, only limited support for this option is available from the LAN Server Group.

The document, Windows NT 4.0 Server cessation (.doc), has more details of the University policy and the steps departments should take.

WINS servers

Departments are strongly advised to configure their Windows clients to use the central WINS server rather than running local WINS servers. There are no real benefits to having departmentally based WINS servers - an analogy would be each department maintaining its own internal telephone directory and keeping this information private.

Unlike DNS servers, WINS servers are not hierarchical and do not refer queries outside the boundaries of their areas. Hence, when a machine receives an onslaught of connection attempts from a machine in a part of the University that uses a different WINS server, it is extremely difficult to trace the location of the computer. This has been the source of a great deal of frustration and wasted time for administrators trying to track down machines infected with worms which have effectively launched Denial of Service attacks on Windows workstations and domain controllers by trying to guess account passwords.

The Information Technology Users' Committee (ITUC) has endorsed the policy of using only centralised WINS servers and more information is available in the document, WINS servers (.doc).

Getting your department involved

Migration and central account management

All students enrolling at the University of Melbourne automatically receive an account in the student domain of the unimelb forest. The password for this account is synchronised with the password for their central email account. When the email password is changed, either from an email client or over the web, the Active Directory password is also changed.

Eventually all permanent staff will also automatically receive unimelb domain active directory accounts, however this is being rolled out on a department by department basis. As each department joins the Active Directory structure, the accounts of their staff come under central management. Password synchronicity with the central email system comes into play, new staff automatically receive accounts, and accounts for staff who have departed are removed.

To learn more about the active directory structure and how migration is carried out, see Migrating to the University Windows 2000 Domain - A Guide (.doc).

To understand the organisation of the student domain and to learn about how the active directory structure allows you to control the desktop environment of your students see The Student Domain (.doc).

The interaction between central management of accounts and departmental administrators is explained in Centrally Managed Accounts and Local Administrators (.doc) while a list of how department codes are mapped to Active Directory containers is also available.

Making Use of Group Policies

The ability to control a wide range of computer configurations by means of Group Policies is probably the biggest advantage of working in an active directory structure. There are many excellent sources of information about how group policies are applied available on the web. Listed here, however, are some documents specifically aimed at use of Group Policies within the University of Melbourne Active Directory forest.

Group Policy and Logon Scripts (.doc) explains the benefits and practicalities of using Group Policy based scripts in place of legacy logon scripts specified in individual user account profiles. It also demonstrates how these can be used in the student domain to overcome problems caused by central storage of all student accounts. While there were some earlier problems in setting up Group Polices in the student domain using unimelb domain accounts, these difficulties are now fully resolved. For a clarification of this situation see Setting up Group Policies in the Student Domain (.doc).

Most areas of the University have a mixture of Windows 2000 and XP workstations. Using group Policy in mixed areas has caused some confusion, particularly in terms of apparently "disappearing" XP related settings. How to avoid this problem (and how to fix it if it occurs) is explained in Group Policies and XP Workstations (.doc).

Joining computers to the Active Directory

LAN Server group has published documentation on general Active Directory configuration options as well as specific guides to integrating OS X.3 and Linux computers.

Certification and training

Administrators of Windows servers are required to have appropriate certification and training as listed in Windows Server 2003 at The University of Melbourne - Certification and Training (.doc). LAN Server Group can provide training materials and will reimburse exam fees upon successful completion.

Terminal services and licensing

With the introduction of Windows 2003, Microsoft has made radical changes to its model of Terminal Service licensing. Some of these have negative consequences for us; in particular the abolition of complimentary TS CALs built into current client OSes. On the other hand, some positive changes have been made including the introduction of user based client licensing (as an alternative to device based), and a simplification of the procedures for setting up departmental based client licensing.

These issues are discussed in Terminal Service Licensing and Windows Server 2003 (.doc).