Search | Directories | Reference Tools
UW Home > UWIN > Computing and Networking > Support > UW Domains 

Windows Domains at the University of Washington

UW Windows Domains Menu

UW Windows Infrastructure

UWNetIDs and Windows

UW Forest

Nebula

Community Resources

How to Setup a Domain

Diagnosing domain controller issues

Windows Domains Site Map

 

Oct. 4, 2002 3-5 p.m.

Ryan Campbell of C&C Client Services described some background on the current UW forest, and how it came to be. C&C decided on a multidomain model primarily because the administrative and support structures in place throughout the university made a single domain a poor fit. Departmental support arrangements, funding arrangements and administrative independence require a great deal of flexibility. So the forest was set up to do the minimum amount possible while still allowing Win2k domains to participate in the UW network infrastructure.

Q. Who does what?
A. C&C handles DNS services and administration of the global catalog, and acts as a central administration and contact point. Within C&C, Ryan handles support issues and maintains web documentation for the forest, while Brad Greer and James Morris of Networks and Distributed Computing handle engineering issues.

Brad Greer then discussed a range of issues ( slides available):

Dynamic DNS

DDNS is presumed by default in Win2k domain and server installations, but we don't support it on our network. This results in the need for timely administrative work that needs to happen before domains/servers can properly participate in the forest, or make changes to domain configuration.

For DDNS to be implemented, BIND 9 has to be implemented. This will take time. The current goal is to permit DDNS for servers within 6-12 months. For desktops, the outlook is still unclear. If domains need DDNS for particular applications, C&C recommends that domains do it themselves. Brad noted that WINS is an available alternative for some purposes.

Q. How do DNS updates happen? (context is 3 recent zone file changes were done inaccurately)
A. Network Operations staff do manual edits of zone files via a web interface.

Q. Why might domains not want to run DDNS themselves?
A. Need for significant expertise, additional cost of duplicating a C&C-provided service. Some administrative approval required.

Security

The forest is vulnerable to a particular exploit, described in Microsoft bulletin MS02-001. Domain admins can elevate privileges to be Enterprise Admin. as described in this Microsoft white paper.

A summary:

  • The attacker must have Domain Admin privileges and physical access to a domain controller.
  • The risk is low. No known attacks yet where attacker had/used physical access to DC.
  • To improve the 'trust' between domains, we need to address this item.

The implications of this vulnerability yield four areas of discussion:

1. Domain controller security

New requirements:

  • Restrict physical access to DC hardware.
  • DCs should not be used as workstations.
  • DCs should not run any extra software (IIS, Exchange, SQL Server, etc.).
  • If there are external trusts, use SID filtering.
  • Minimize the number of DCs. Two is a minimum, three should be a maximum.

New procedures:

  • DCs should stay up 24/7/365.
  • Admins should apply security patches and OS revisions (service pack level). This requires C&C to make periodic connections to DCs, which hasn't been done without explicit request by domain admins in the past.
  • Admins should monitor audit logs, event logs, and uptime.
  • C&C will document GPO settings for baseline compliance with forest requirements. These will be made available by late October. Notification will be sent to win2k@u and settings will be placed on C&C's Windows 2000 support site.

2. Domain administrator rights

  • Domain admin account privileges should go only to UW staff, who are accountable to federal and state laws, as well as UW administrative policy.
  • C&C will require "managed by" contact information on domain and DC objects in Active Directory.

Q. Are there secureID options for DC access?
A. None that are easily implemented in Windows 2000. There is some limited experience with smartcards for Unix root accounts, but they haven't resulted in any implementation that could work as a centrally provided answer for Win2k.

These new forest requirements and policy changes will be required to be implemented by each domain in order to provide more security within the forest. C&C will be examining the forest and contacting existing domain admins to verify these requirements are met. Domain admins should contact Brad, James or Ryan about concerns or implementation issues.

3. Forest rearchitecture

These changes leave current participants with at least 3 options:

  • Stay.
  • Leave the forest. This can be done as before, but please do so in the same way as when the domain was joined, via DCPROMO and with a C&C site visit for the final removal step from the GC.
  • Merge with another domain that can handle the requirements.

Point from audience: Leaving is not simple and creates lots of work. Migration tools are not well developed.

4. Better communication

  • Please report security incidents to security@cac.
  • Join discussions and raise issues. C&C hopes to help cultivate a forest community that can share ideas and help solve common problems.

Q. What benefits come from being in the forest?
A. Resource sharing across domains. Libraries gave examples of using ADSI scripting to improve inventory management and consolidate accounts. Others now can share files and printers across domains.

Q. Could UW offer a single domain like MIT?
A. There are problems. Account management and rights become inflexible. It could be done if domain admin rights aren't needed...admins might try setting up an account to see if they can accomplish necessary work without domain admin privilege. C&C remains open to exploring more options. Point was made that the labs.washington.edu domain allows authentication via KDC but no other rights; this might work for some.

.NET futures

C&C wants to allow for early adoption, so the plan is to make required schema updates approximately 30 days after .NET server ships. Currently this is estimated at Q2 2003.

This change will require that all DCs are at Windows 2000 SP3 and that all domains are in native mode.

Ryan then discussed:

UW NetID authentication

C&C Security Infrastructure Team has decided to allow one-way trusts to domains outside forest. This means NetID authentication can be done without joining the forest. A mechanism for implementing this has not been decided upon at this time.

C&C can help with ADSI tools to make the account management process easier. What do people want? One consensus was a way to do bulk add/remove operations using class lists. C&C will also provide templates for more common ADSI operations.

Brian Arkills (barkills@cac), new C&C software engineer in Networks and
Distributed Computing, then discussed:

Exchange 2000 issues

Brian will coordinate a meeting of current Exchange administrators to learn more about what departmental requirements are for running it, and to help clean up current administrative problems. There are currently 5 Exchange admin groups in the global catalog.

Ryan then concluded the meeting by asking about a possible schedule for future meetings. The consensus was to meet on a quarterly basis. Ryan will coordinate and announce these meetings using the forest administrator's mailing list.

"Minutes of Windows 2000 UW forest administrator meetings"