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 IT- Main  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 anti- virus)  Use secure account management practices

What would my responsibilities be?  Comply with restriction on Generic (lab or multiple- users-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 child- domain (i.e., the extra hardware and manpower for managing it)?  Do I have the resources available for a child- domain 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 IT- Main!

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 - ows_ou/ ows_ou/

AD Child Domains Questions?

AD Forests at ASU

Why would I want my own forest?  High security No other domains have access to your resources  Total control 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?