AD Child Domains - Arizona State University

advertisement
AD Child Domains
By: Joan Carter
05/29/2003
Who can bring up a child domain in
AD.ASU.EDU?


Campus/college/VP level units
Considerations:


Is there a business purpose that requires the
creation of another domain in the forest?
Would there be a better use of resources?
Do we want a child domain?

We:





Need to manage our own accounts
Have particular needs for password or security settings
that are different from ASURITE domain’s settings
Are geographically or network challenged
Want our users to use/access resources anywhere in
AD.ASU.EDU without an additional logon.
Want the ability to utilize the university structure and
processes in place (e.g., ASURITE accounts, Student
accounts, administrative processes used in the ASU AD
forest, etc.).
What would my responsibilities be?





Maintain 2 domain controllers with current hardware service
agreements, in a secure location
Provide 7/24 support (on-call for non-business hours)
Provide a list of DC administrators with contact info to ITMain
Demonstrate ability to backup/restore AD components.
Coordinate scheduled maintenance on DC’s.


Bring one DC down during any maintenance in the event a problem
occurs.
Run DCDIAG prior to and immediately after any maintenance to
verify that communication with the rest of the domain is intact
What would my responsibilities be?


Provide immediate notification to IT-Main of
unscheduled DC outages
Provide appropriate support during AD.ASU.EDU
Active Directory schema updates as follows:




Be on-call.
Bring one DC down during update
Keep DC’s and Servers up-to-date (security and antivirus)
Use secure account management practices
What would my responsibilities be?

Comply with restriction on Generic (lab or multipleusers-per-account) domain accounts.



Generic accounts can be created on member servers or
locally on individual workstations
Test, Administrator, and Guest accounts can be handled
through Computer Accounts "Exception" process.
Service accounts can be created locally or domain-wide.
NOTE: If a unit has a need for generic accounts that
cannot be handled via the above methods, they may
want to create their own forest to accommodate this
need.
What would my responsibilities be?


Perform all local domain administration and
maintenance
Perform authoritative Active Directory restore
for objects in their domain.
What are IT’s responsibilities?

Information Technology is responsible for
maintaining the stability and integrity of the
AD.ASU.EDU, ASURITE.AD.ASU.EDU and
STUDENT.AD.ASU.EDU domains for the
University.
What are IT’s responsibilities?









Hardware/software maintenance and support
Troubleshooting problems
Backup/restore of AD objects
Schema changes
Performance and event monitoring
DNS support
Account administration
Delegation of authority
7/24 on-call support
Which functions are controlled by
Enterprise Admins only?









DCPROMO
DC DNS authority (ad.asu.edu zone)
Schema updates
Enterprise-wide service accounts
DFS root?
Site Creation
IAS/RAS Authorization
RIS Authorization
DHCP authorization
What does this mean to me?
Plan ahead!! Your lack of planning
should not become IT’s emergency!
What about the other child-domain
administrator’s – can they be trusted?


Domain administrators don’t inherently have
rights to other domains.
There are a few security holes that can be
exploited only by domain administrators,
but…
All are university employees that have been given
this authority by their college/campus/VP unit.
What else do I need to plan/decide?
LOTS!!
Decision Points


Do I have the resources available for a childdomain (i.e., the extra hardware and
manpower for managing it)?
Do I have the resources available for a childdomain in the development environment (i.e.,
the extra hardware and manpower for
managing it)?
Decision Points





What level to join the domain? (i.e., child to AD,
child to another domain, peer to AD).
What will I name the domain? (i.e.,
xxx.ad.asu.edu)
Which DC’s will have which FSMO roles?
Which DC’s will be Global Catalog servers
Will we need to change the DNS suffix on any of
our servers/workstations? How will we accomplish
this?
Decision Points




Upgrade DC’s in-place or rebuild and
migrate?
Migrate groups from resource domains, or
re-create?
Create a separate Site or join the Main Site?
What will the OU Structure look like?
Decision Points

Delegation issues:


User account delegation – who has permissions
to manage user account attributes, what can and
can’t they do?
Computer object delegation – who has
permissions to manage computer objects?
Decision Points

OU delegation – what should OU admins be able to
do in their own OU?
Create/delete computer objects?
 Create/delete contact objects?
 Create/delete Group objects (Local Domain, Global,
Universal -- all as a Distribution or Security group)?
 Create/delete sub OU’s ?
Note: OU’s are created with the ability to create user
accounts. A script can be written to create sub-OU’s with
proper delegated permissions

Decision Points






Create/delete printer objects (publishes print shares)?
Create/delete user objects?
Create/delete shared folder objects (publishes existing
shares in their OU)?
Create/delete Group Policy objects?
Assign others the rights/privileges to manage objects in
their OU (i.e., add others to their OUAdmin group)?
Have different levels of permissions for different
OUAdmins?
Decision Points




What default settings will we need on user accounts
and computer objects?
What will our naming convention be for user
accounts, OU’s, groups, computer objects, etc.?
Will I need to use GPO’s for anything? If so, will I
use loopback GPO’s or will all my domain users
reside in the same OU’s as the computers they use?
Do I use NetID for DHCP or Microsoft DHCP? If I
use Microsoft DHCP, will I want integrated
dynamic DNS?
Decision Points

What scripts are needed? Now? Later?







User account management
Computer object management
User ACL’s
User attribute changes (i.e., UPN, W2K login name,
others?)
OU creation (with correct security for OUAdmins,
others)
Sub-OU creation.
Use monitoring tools or manual processes?
Upgrade or build new?

Upgrade benefits 


keep existing accounts/group memberships
no effect on users (i.e., they keep their
accounts/passwords)
Upgrade problems –


SID history information is everywhere (some
associated latency)
Some systems may have misc unexplainable
problems?
Upgrade or build new?

Build new benefits –



No SID histories, unless ADMT is used.
No unexplained system problems due to upgrade
Build new problems –


User impact (i.e., accounts/passwords)
Re-creation of groups & memberships unless
ADMT is used.
What’s the plan? A general overview

Scenario 1 – Authentication and Resource
domain migration






Upgrade Authentication domain BDC
DCPROMO – make new child domain
Build new DC for second DC (replaces old PDC)
Move FSMO roles to re-built DC, and now
rebuild original DC
Select DC’s for FSMO roles and GC placement
Re-create trusts to resource domains
What’s the plan? A general overview



Use ADMT to migrate groups and/or local
resource domain users to new child domain
Upgrade/rebuild member servers and join to new
child domain
If upgrade of resource domain DC’s is necessary
rather than rebuild (in order to keep data,
permissions, attributes, etc), upgrade and place in
a FAKE W2K forest. Then DCPROMO out of
the forest and make the system a member server.
What’s the plan? A general overview

Scenario 2 – Single NT domain
(authentication and resources)






Upgrade BDC to W2K
DCPROMO – make new child domain
Build new DC for second DC
Upgrade/rebuild member servers
Move FSMO roles to re-built DC, and now
rebuild original DC
Select DC’s for FSMO roles and GC placement
Test, test, test


Set up a copy of your domain(s) in the
development environment to test your
migration.
(xxx.tad.asu.edu)
Test all facets of the upgrade/migration before
you work on your production environment!
Prepare, Coordinate, and DCPROMO


Create a task list to make sure you don’t
forget anything!
Be sure to coordinate all functions with ITMain!
Verify and Monitor - Tools


ClonePrincipal - A command-line tool used
for user, group, and computer object
migration.
Active Directory Migration Tool (ADMT) –
A GUI based Active Directory Migration tool
(ADMT) to migrate users, groups, and
computers from one domain to another, and to
analyze the migration impact both before and
after the actual migration process.
Verify and Monitor - Tools




NETDIAG - Tests the state and functionality of
various network connectivity and components on a
network client.
DCDIAG – Tests the state of various Domain
Controller functions and communication.
NETDOM - Enables administrators to remotely add,
delete, and reset computer objects in a domain.
REPLMON - Displays replication topology, status
and performance of Active Directory domain
controllers.
Verify and Monitor - Tools


GPResult - This command-line tool displays
information about the result Group Policy has
had on the current computer and logged-on
user.
GPOTool - This command-line tool allows
you to check the health of the Group Policy
objects on domain controllers.
Management and Maintenance



Replication monitoring
Object maintenance
Delegation of authority http://www.west.asu.edu/it/faculty_staff/wind
ows_ou/
AD Child Domains
Questions?
AD Forests at ASU
Why would I want my own forest?

High security


Total control


No other domains have access to your resources
Enterprise Admin functions (e.g., schema updates)
Little coordination needed with IT



DNS
Kerberos
LDAP
What’s the down side?

No trust with ad.asu.edu




Exchange users would need to have separate credentials
No cross-forest authentication, i.e., resources in
ad.asu.edu forest may not be available to your users.
No automated user/group management provided by
IT
Additional management/resources are needed to
maintain
AD Forests at ASU
Questions?
Download