Scott Brondel Sam Martinez
USGS Active Directory
FAQS
The “Tier 1” Domain
Controllers are placed in Anchorage AK, Denver CO, Menlo Park CA, Reston VA,
Rolla MO, Sioux Falls SD, and Vancouver WA.
We’ve asked for funding for additional “Tier 2” and “Tier 3” Domain
Controllers in the FY02 budget, but we have no idea at this time if they will
be purchased.
If your users are running
Windows NT 4, Windows 2000, or Windows XP, they can still login to their
machine using their domain credentials – these OS’s by default “cache” a
certain number of previous logins.
However, the users wouldn’t be able to access any file or print services
on the network because there wouldn’t be a Domain Controller available to
perform the authentication. Windows 9x
users would be able to cancel out of the login screen and access local computer
resources, but they would be cut off from network resources as well.
This is a hot topic of
discussion between the Lighthouse team and several USGS administrators. While the team knows that there will be
sites that require a local Domain Controller, the team is reluctant to have a
DC at every site for several reasons:
Even though this is a
bureau-level deployment, it was a conscious design goal of everyone on the team
to keep as much administrative control in the hands of the local administrators
as possible. Right now, the bureau’s
many NT domains exist as a bunch of disconnected entities. In the Active Directory structure, each one
of these domains would be a separate OU in one large domain. Inside that OU, the designated “OU
Administrator” would have almost all the rights and privileges that a “Domain
Administrator” would have – creating users and groups, bringing up member
servers, changing passwords, creating sub-OU’s to match their local management
structure, managing backups, etc. Only
activities that Microsoft deemed as changes that can have an enterprise-wide
impact (like password length, creating trusts, etc.) require Domain or
Enterprise-level administrator privileges.
Group Policies can be
created that will automatically place groups of the local administrator’s
choosing into the local Administrator group of Windows 2000 machines. Windows NT 4 machines will still need to
have that done manually, though this can be automated through scripts.
As mentioned above, there
are a few things that could require a local OU Admin to call the central
team. Bringing up a DHCP or RAS server
are two notable cases. For these, a
Domain Admin can connect to your server and “Authorize” it in the Active
Directory. Once that’s done, any
further configuration is left to the local OU Admin. The ability to do the authorization can be delegated to local OU
Admins as well.
Windows 9x and NT 4
Workstations and Servers can participate in the Active Directory just like they
would in an NT4 Domain. In order to
experience more of the benefits of Active Directory, there is an additional
client that should be installed on these operating systems to make them
“site-aware” and enable functions like Domain-based Distributed File System
shares and the ability to search the Directory for users, computers, etc. Unfortunately, even with the additional
client, Windows 9x and NT4 machines still use NTLM-based authentication methods
and cannot use Kerberos for authentication.
Active Directory by default
uses Kerberos for authentication. Unix
workstations can be configured to use the Active Directory as a Kerberos realm
for logins. If a site uses NIS to
manage their Unix workstations, it is also possible to set up an Active
Directory Domain Controller to act as an NIS master, allowing people to use
their Windows username and password to authenticate to their Unix workstations.
Macintosh machines can be
configured to allow users to login to the Active Directory and access Windows-based
file shares and printers through the Services for Macintosh component of
Windows 2000.
Ports:
· 88 – Kerberos (TCP and UDP)
· 137 – NetBIOS Name Service (TCP and UDP)
· 138 – NetBIOS Datagram Service (UDP)
· 139 – NetBIOS Session Service (TCP)
· 389 – LDAP (TCP)
· 445 – Microsoft CIFS (TCP and UDP)
· 500 – Internet Key Exchange (IPSec) (UDP)
· 636 – LDAP SSL
· 3268 – Global Catalog LDAP
· 3269 – Global Catalog LDAP SSL
· 3389 – Terminal Server (UDP)
Protocols:
Admittedly, there are many
Microsoft products that are not known for strong security (IIS in
particular). The Active Directory
services in Windows 2000 are almost two years old as of this writing, and the
Lighthouse team is unaware of any weaknesses, hacks or exploits against the
Active Directory that can result in the equivalent of “root shell” access.
There are two levels of
administrators in the USGS Active Directory design: Domain Admins and local OU Admins. While the Domain Admins do have broad administrative authority,
their responsibilities revolve around the general maintenance of the Directory,
performing migrations from other Domains, maintaining Domain Controllers, and
assisting local OU Admins as needed.
The Domain Admins are not responsible for deploying patches or
applications to all machines in the domain; these are local responsibilities
that would continue to reside with the local OU Admins.
When an OU for a new site
is created, a hierarchy of OU’s for delegating permissions inside the OU is
also created by a Domain Admin. For
example, let’s say an OU is created for a Water Resources site in Pearl,
Mississippi. The OU that would be
created would be “PearlMS-W”. Another
OU would be created called “PearlMS-W Full Admins”, and a group of the same
name would be created in that OU.
Permissions on both of these OU’s are then set so that anyone in the
“PearlMS-W Full Admins” group has full administrative access on all objects
created in both OU’s. Using this
method, an administrator in the “DenverCO-G” OU, for example, could not change anything
in the “PearlMS-W” OU unless an admin in Pearl gave the Denver administrator
the rights necessary to do so.
Send an email to the “GS
Lighthouse” Lotus group. If possible,
please provide the following information:
This depends greatly on
the current configuration of the machines.
If they are already members of an NT4 domain, the process becomes fairly
automatic. Scripts will be provided
that can remotely change the DNS and WINS IP addresses of NT4 / 2000 clients,
and free migration tools are available to remotely migrate the computer
accounts as well as their share and file permissions to the Active Directory
domain.
If the machines are
members of a workgroup, it’s likely that the individual machines will need to
be visited. In either case, Windows 9x
and NT4 machines should be visited to have the Active Directory Client
installed on them.
Why deploy an Active Directory structure and use a Single Domain Active Directory model?
Reasons to deploy Active
Directory and the Single Domain model are for standard security, single sign
on, support integrated science, and design simplicity.
Where will the Domain Controllers be deployed - centrally in a regional Network Operation Center (NOC) model or a decentralized model where Domain Controllers are spread out through the Bureau sub-organizations?
Domain
Controllers will most likely be deployed in locations that are “well connected”
(have good telecommunication connectivity) such as Regional Offices and Sioux
Falls, ND. Additionally, Alaska will
also have Domain Controllers.
Who will be the
Enterprise Administrators?
Personnel from throughout
the USGS will be picked and most likely those personnel who are co-located with
Domain Controllers.
What changes, if any, will be incorporated into the overhead scheme to pay for this project?
The group had not
considered this in previous meetings.
To be decided by the GIOLT.
How does Active Directory deployment affect the District IT personnel’s PD’s?
The Lighthouse group had
not considered this in previous meetings but felt there would be no impact on
the PD’s of District IT personnel.
What is the problem resolution design for problems not associated with the Organizational Unit (OU) operation?
This
is to be determined by the final staffing decision to be determined by the
GIOLT.
Is there a test bed system to test Active Directory policies that would be applied to the domain and are all software applications supported by USGS being tested against these policies?
There is a test bed system
available for testing policies but not all software has been used to test
effects of these policies.
Will Enterprise Administrator personnel be on a 24x7 schedule for problem resolution?
To be determined by the
GIOLT.
Will deployment
of a Single Domain model combined with different telecommunication line speeds
throughout the organization cause response times to decrease in field
offices/subdistrict offices?
Not really, Active
Directory produces minimal replication traffic that can adjust for sites with lower
bandwidth capabilities.
How will User profiles be maintained in Active Directory?
Each local administrator can
determine who will use what type of profile using his or her local member
servers for storage. The administrator
can choose either local or roaming profiles for their users.
What type of
items will need to be procured during FY02 to support moving to AD?
Depending on the level of
Active Directory funding available, additional Tier 2 Domain Controllers may be
purchased either by the bureau or local office.
What personnel
additions/deletions may have to be planned for during the FY02-03
deployment?
A bureau level team
consisting of USGS staff and contractors will need to be planned immediately in
order to adequately manage Active Directory.
What changes to
overhead percentages will occur during establishment of AD?
This will need to be
decided by the GIOLT
What type of training for both Enterprise Administrators and Organizational Unit personnel will there be?
Planning
is underway to schedule regular classes for
Active
Directory Domain Administrators, and Local Active Directory
Administrators
(LADA) beginning in early Spring 2002.
Will the Local Active Directory Administrator be capable of to Remote Access Server (RAS) and other services in AD in the local Organizational Unit without having to have an Enterprise Administrator complete the installation?
Yes,
this can and will be the policy to allow local site administrators the
capability to add network services to their local sites.
Does the Windows 2000 Kerberos integrate with UNIX
Kerberos?
Yes, Here is an
explanation:
Windows KDC (Key
Distribution Center). Non-Windows Kerberos implementations can authenticate to
the KDC in a Windows 2000 domain. Non-Windows Kerberos users and hosts can
authenticate to a domain controller by using kinit and DES-CBC-MD5 or
DES-CBC-CRC encryption.
Non-windows Kerberos KDC.
Systems running Windows 2000 can authenticate to a host serving as the KDC of a
Kerberos realm. In addition, a standalone Windows 2000 system can be configured
so that local computer accounts map to Kerberos principals. This configuration
allows users to log on simultaneously to both the computer and the Kerberos
realm.
Windows Client,
Non-Windows Kerberos Service. Client applications running on Windows 2000 can
authenticate to non-Windows Kerberos services if the services support the
Generic Security Service Application Program Interface (GSS-API) defined in RFC
1964. Windows 2000 does not provide the GSS-API. Applications written for the
Windows 2000 operating system should use the SSPI to get support for Kerberos
version 5 authentication. The two interfaces are compatible and similar.
Non-Windows Kerberos
Client, Windows Service. Client applications running on non-Windows Kerberos
systems can authenticate to services running on Windows 2000 if the client
applications support the GSS-API as defined in RFC 1964.
Summary: This paper
describes the features and components in Microsoft Windows NT that enable broad
interoperability with UNIX-based systems, data, and applications. Using Windows
NT Server and its fully integrated system services, customers can build
interoperable solutions to satisfy their goals for lowering total cost of
ownership and maximizing business value. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnt40/html/ntsunixinterop.asp
Interoperability-
Microsoft's implementation of the Kerberos protocol is based on standards-track
specifications recommended to the Internet Engineering Task Force (IETF). As a
result, the implementation of the protocol in Windows 2000 lays a foundation
for interoperability with other networks where Kerberos version 5 is used for
authentication.
There are interoperability
tools from Microsoft: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2k/html/kerberossamp.asp
For more information on
Kerberos integration: http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000serv/deploy/walkthru/kerbstep.asp
Will I as a
Local Active Directory Administrator be capable of creating new users, adding
computers, and other tasks I currently perform?
Yes, The management of
these tasks will be performed by modifiying those Organizational Units (OUs)
you own and administer.
What System Administrator rights will be taken away from me as Local Active Directory Administrator?
The
Local Active Directory Administrator will continue to perform local site tasks
as normal. The limitation is any task
that could impact the entire Active Directory infrastructure.
Results from NT 4.0
Questionnaire Sent to System Administrators December 2001
Do
you currently administer a Windows NT 4.0 Domain environment?
Yes=50
No=6 Not Sure=1 No response=2
How
many NT 4.0 Domains do you administer?
Number
of Domains (PDCs): 65 total
How
many NT 4.0 Backup Domain Controllers do you currently have installed at these
sites?
Number
of Domains (BDCs): 84 total
If
you have a single Windows NT 4.0 Domain does that include your field offices?
Yes=17
No=13 N/A=24 No Response=5
How
do you manage field office data information at your field office sites?
Local
File Server Storage at each field office site=21
Data
is stored local on each desktop=6
Data
is accessed from the main office via the network=12
No
Response=12
Can
most of your current Windows NT 4.0 Domain Controllers be upgraded to Windows
2000 Server (CPU at least 133 MHz, RAM at least 256 MB, Disk Space at least 2 GB)?
Yes=43
No=5 N/A=7 No Response=4
Are
you willing to purchase Windows 2000 domain controllers for your remote field
offices if necessary?
Yes=25
No=15 N/A=15 No Response=4
Are
you willing to secure these Windows 2000 domain controllers in a locked room at
each of your remote field offices if
necessary?
Yes=19
No=19 N/A=15 No Response=6
Are
you willing to abide by a policy that restricts access and configuration to the
domain controllers to only Active Directory domain administrator and not you or
your staff?
Yes=18
No=29 N/A=6 No Response=6
On
average how reliable is your Wide Area Network (WAN) connectivity ?
Good=32
Fair=20 Poor=2 No Response=5
Coordinated Deployment Independent Deployment Effect
|
End user |
Universal user access to files,
printers, and profile |
Case-by-case user access to files and
printers. No universal access to
profile without extra System Administrator effort |
Pre-defined access vs.
access-as-needed |
|
Corporate Applications |
Faster, staged on-line distribution
of applications, through use of public shares, for deployment by local SAs |
“Burn” and mail CDs to 100+ sites |
Faster vs. slow distribution of
applications |
|
Support Staff |
6 to 10 Bureau-funded FTE |
Unknown |
Bureau support vs. division support |
|
Migration and support processes |
Bureau-based, in coordination with
Discipline IT support and local SAs |
Discipline-based (at best), in
coordination with local SAs |
Coordination among disciplines vs.
duplication in each division |
|
Training |
Vendor training for 6 to 10 core
support staff In-house training for 200 local SAs |
Local decision to send SA to
training. Training will be
inconsistent and expensive |
Widely trained staff in USGS vs. inconsistent
expertise |
|
Equipment |
100 domain controllers (approximately
1 per cost center) |
Estimated 200 to 600 domain
controllers, depending on local implementation choices |
Less capital outlay vs. more capital
outlay |
|
Operating System |
Standard configuration and service
packs on all domain controllers |
Unique configurations and service
pack levels on most domain controllers |
Distributed and consistent vs.
uncontrolled and inconsistent |
|
Security |
Controlled rollouts of anti-virus
software and definitions on domain controllers. Quick rollout of hot fixes. Deployment of Bureau baseline
security policy (password specs, logging) |
Unique configurations of anti-virus
software and definitions. Hot fixes
would be applied at local office discretion and timeline. No baseline security policy. |
Controlled and consistent vs.
uncontrolled and inconsistent |
|
Network |
Increased traffic, but manageable |
No change |
Manageable traffic increases vs. no
change |
|
Domain Name Service |
One dynamic DNS |
Estimated 100 to 300 dynamic DNS
servers, depending on local decisions |
Managed name space (adusgs.usgs.gov)
vs. unmanaged name space, i.e. many different naming conventions |
Training
for the Active Directory management team, site administrators, and end users:
Domain Administrator course (5-day) - This will
be the first class that should be attended by all folks that are going to be
involved with the day to day administration of AD. This will be the Active Directory nuts and bolts course led by
and MCSE instructor that will get us all to the same knowledge level. It's important to note that no one in the AD
team has been officially trained by the USGS yet.
Local Active Directory Administrator (3-day) -
This is going to be equivalent to the current LLMA in Lotus Notes. These are administrators that will need to
know how to add, configure, and manage systems in an Active Directory
environment. This course will be taught
by both an MCSE instructor and USGS personal to give the local site
administrator the knowledge they need to successfully deploy AD at their site.
Introduction to Active Directory
Active Directory logical structure
Active Directory physical structure
Methods for administering a Windows 2000 network
Introduction to the role of DNS in Active Directory
DNS and Active Directory
DNS name resolution in Active Directory
Active Directory integrated zones
Installing and configuring DNS to support Active Directory
Introduction to creating a Windows 2000 domain
Installing Active Directory
The Active Directory installation process
Examining the default structure of Active Directory
Performing post Active Directory installation tasks
Troubleshooting the installation of Active Directory
Removing Active Directory
Introduction to user accounts and groups
User logon names
Creating multiple user accounts
Administering user accounts
Using groups in Active Directory
Strategies for using groups in a domain
Troubleshooting domain user accounts and groups
Introduction to publishing resources
Setting up and administering published printers
Implementing printer locations
Setting up and administering published shared folders
Comparing published objects and shared resources
Troubleshooting published resources
Module 6: Delegating Administrative Control
Object security in Active Directory
Controlling access to Active Directory objects
Delegating administrative control of Active Directory objects
Customizing MMC consoles
Setting up taskpads
Introduction to Group Policy
Group Policy structure
Working with Group Policy objects
How Group Policy settings are applied in Active Directory
Modifying Group Policy inheritance
Delegating administrative control of Group Policy
Monitoring and troubleshooting Group Policy
Introduction to managing user environments
Introduction to Administrative Templates
Using Administrative Templates in Group Policy
Assigning scripts in Group Policy
Using Group Policy to redirect user folders
Using Group Policy to secure the user environment
Troubleshooting user environment management
Introduction to managing software deployment
Windows Installer technology
Deploying software
Configuring software deployment
Maintaining deployed software
Removing deployed software
Troubleshooting software deployment
Introduction to trees and forests
Creating trees and forests
Trust relationships in trees and forests
The global catalog
Strategies for using groups in trees and forests
Troubleshooting creating and managing trees and forests
Introduction to Active Directory replication
Replication components and processes
Replication topology
Using sites to optimize Active Directory replication
Implementing sites to manage Active Directory replication
Monitoring replication traffic
Adjusting replication
Troubleshooting Active Directory replication
Introduction to operations masters
Operations master roles
Managing operations master roles
Managing operations master failures
Introduction to maintaining the Active Directory database
The process of modifying data in Active Directory
The garbage collection process
Backing up Active Directory
Restoring Active Directory
Moving the Active Directory database
Decrementing the Active Directory database
Business scenario
Requirements for the Active Directory infrastructure
Class Discussion: how to implement the Active Directory infrastructure