1 / 63

Windows User Group

Windows User Group. Active Directory. Objectives. Where did Active Directory come from Why is AD the way it is What is AD fundamentally What does this mean to you Where is AD going. Agenda. Directory Services History What is Active Directory How to implement AD Active Directory Futures

mervin
Download Presentation

Windows User Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Windows User Group Active Directory

  2. Objectives • Where did Active Directory come from • Why is AD the way it is • What is AD fundamentally • What does this mean to you • Where is AD going

  3. Agenda • Directory Services History • What is Active Directory • How to implement AD • Active Directory Futures • Windows 2003 R2 • Active Directory Federation Services

  4. Security • Identity - The catalog of what you have and who you are • Authentication – How do you know that someone is who they claim to be • What you are • What you have • What you know • Authorization – What can they do? • Auditing – Who did what?

  5. Directory Services • External (Public) Directories • X.500 (de jure) • DNS (de facto) • RFC 2247 • PKI (not a DS but here for discussion) • Internal Directories • IBM Mainframe (eg RACF, NetBIOS) • UNIX (e.g. Host file, NIS, YP) • Novell Bindery/NDS • Banyan StreetTalk • LDAP

  6. Active Directory Design Goals • Maintain Download compatibility with NetBIOS domains • Utilize Kerberos Realms as the primary native namespace • Utilize LDAP as the access/query protocol • Support PKI • Dynamically extensible • Performance/cost

  7. RFC 2247 is the Key • X.500 never achieved global operational stability • DNS became the defacto global naming standard • RFC 2247 mapped the X.500 naming standard into the DNS nomenclature • Administrative boundaries moved from the OU (x.500) to the DC (DNS). This is a point of contention with x.500-based directory services to this day. • The Domain Component mapped directly into the kerberos realm and NetBIOS Domain namespace model. • NetBIOS Shortnames became the Relative Distinguished Name (RDN) • PKI Security boundaries mapped into the DC authority level. • PKI cross-signed trusted mapped into the inter-domain trust model.

  8. Active Directory Functional Components • Database • Optimize for queries • Efficient use of space (sparse data) • Replication Engine • Protocol Headers • NetBIOS • LDAP • DAP • Kerberos • PKI • other • Management Interfaces

  9. AD Database Issues • Database structure • Bootstrapping • Attribute granularity • Attribute-level permissioning • Multi-valued attributes • Linked value integrity • Schema Extensibility • Replication • Replication topology • Replication protocols • Collision detection/resolution

  10. AD Namespaces • Forest Common • Schema Context • Small and rarely Changes • Common throughout the forest • Configuration Context • Global Catalog • Contains a subset of attributes • Glues the forest together • Domain • Domain Naming Context • Contains all details of each domains objects • Application Namespaces

  11. Floating Single Master Operations • Forest-Wide Roles • Schema Master • Domain Naming Master • Domain-Wide Roles • Primary Domain Controller Emulator • RID Master • Infrastructure Master • Updates user-group relationships

  12. What’s new with AD Branch Offices this year? • Windows Server 2003 Branch Office guide released to web • 250 pages of proven and supported recommendations. • New Branch Office Monitoring tool (Brofmon) • V1.1 of guide shipped • Upcoming Win2k03 Sp1 changes: • ADLB.EXE and DCDIAG.EXE have fixes (both updates are in the Branch Office Guide) • Ultrasound is a FRS monitoring tool which shipped late 03’

  13. What’s upcoming with AD Branch Offices? • R2 – Branch Office Team building branch office solution for role deployment • V 2.0 of the AD Branch Office Guide should ship March ‘05 • New chapter on Disaster Recovery for branches • New tool and process for converting all manual connections to KCC generating • Longhorn server - branch appliance for authentication\authorization

  14. AD Branch Office Scenario

  15. What Makes a Branch Office Design Interesting? • IP connectivity incl. WAN, link speed, Dial on demand, routers, firewalls, IPSEC • Name resolution incl. DNS server, zone and client configuration • Active Directory replication to a large number of replication partners • FRS replication • Group policy implementation • Considerations • Proper care of DNS name resolution will guarantee replication success • IPSEC preferred firewall solution

  16. New Features in Windows 2003 for Branch Office Deployments • KCC improvements • KCC/ISTG inter-site topology generation • Bridgehead Server load-balancing and connection object load-balancing tool (ADLB.EXE) • KCC redundant connection object mode for branch offices • No more “keep connection objects” mode if replication topology is not 100% closed • Better event logging to find disconnected sites • Replication improvements • Linked-Valued Replication • More replication priorities • Intra-Site before Inter-Site • NC priorities: Schema -> Config -> domain -> GC -> DNS • Notifications clean-up after site move • Lingering Object detection

  17. New Features in Windows 2003 for Branch Office Deployments • No GC full-sync • In Windows 2000, schema changes that changed the PAS triggered GC full sync • Removed in Windows 2003 • Universal Group Caching • DNS Improvements • Install from media • FRS improvements • Plus many more….

  18. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  19. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  20. Forest Design • Follow recommendations in Windows 2003 Deployment Kit (Chapter 2) • http://www.microsoft.com/downloads/details.aspx?familyid=6cde6ee7-5df1-4394-92ed-2147c3a9ebbe&displaylang=en • Reasons for having multiple forests • Political / organizational reasons • Unlikely in branch office scenarios • Too many locations where domain controllers must be deployed • Complexity of deployment • Too many objects in the directory • Should be partitioned on domain level • GCs too big? • Evaluate not deploying GCs to branch offices • Windows 2003: Universal group caching • Recommendation: Deploy single forest for Branch Offices

  21. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  22. Centralized vs. Decentralized Domain Controller Deployment • The number of sites with domain controllers defines the scope of the deployment • Deployment options • Centralized deployment • Domain controllers are located in datacenters / hub sites only • Users in branches logon over WAN link • De-centralized deployment • All branches have domain controllers • Users can logon even if WAN is down • Mixed model • Some branches have DCs, some don’t • Centralized deployment has lower cost of ownership • Easier to operate, monitor, troubleshoot

  23. Design Considerations for Domain Controller Placement • Local DC requires physical security • Domain controller management • Monitoring, auditing, SP deployment etc. must be guaranteed • Required services – business drivers • File & Print, email, database, mainframe • Most of them require Windows logon • Logon requires DC availability • Can the business still run even if WAN is down? • Is the business in the branch focused on a LOB application that requires WAN access (mainframe)? • Logon locally or over the WAN • WAN logon requires acceptable speed and line availability • WAN only an option if WAN is reliable • Cached credentials only work for local workstation logon • Terminal Service clients use local logon • In many cases, network traffic is important • Client logon traffic – directory replication traffic

  24. Design Considerations for Global Catalog Placement • No factor in single domain deployment • Turn on GC flag on all DCs • No extra cost associated • GC not needed for user logon anymore in multi-domain deployments • Universal Group Caching • GC placement driven by application requirements in multi-domain deployments • Exchange 2000\2003 servers • Outlook

  25. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  26. Domain DesignRecommendation for Branch Office Deployment • Use single domain • Typically only single administration area • Central administration (users and policies) • Replication traffic higher, but more flexible model (roaming users, no GC dependencies) • Database size no big concern • If high number of users work in central location • Create different domains for headquarters and branches • If number of users very high ( > 50,000) • Create geographical partitions • High number of domains discouraged • Examples: One domain / branch, one domain / state • Increases complexity of deployment

  27. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  28. DNS Design Recommendations • DNS server placement • Put DNS server on all domain controllers • DNS client (resolver) configuration • Primary DNS server: Local machine • Secondary DNS server: Same site DNS server or hub DNS server • Windows 2000: Different configuration for forest root DCs • DNS zone configurations • Use AD integrated zones (application partitions) • Use DNS forwarding • No NS records for Branch Office DCs • Configure zones

  29. DNS DesignManaging SRV (locator) records and autositecoverage • SRV records are published by netlogon in DNS • On site level and domain/forest level • Clients search for services in the client site first, and fall back to domain/forest level • Branch Office deployments require specific configuration • Large number of domain controllers creates scalability problem for domain level registration • If more than 1200 branch office DCs want to register SRV records on domain level, registration will fail • Registration on domain/forest level is in most cases meaningless • DC cannot be contacted over WAN / DOD link anyways • If local look-up in branch fails, client should always fallback to hub only • Disable autositecoverage • Use group policy for configuration

  30. Using GPOs for DNS Settings • Create new Global Group for Hub DCs • Add all non-Branch Office DCs as group members • Create new GPO (BranchOfficeGPO) • Configure DC locators records not registered by branch DCs • Configure refresh interval • In BranchOfficeGPO properties, deny “Apply Group Policy” to Hub DCs • Negative list is easier to manage than positive list • No damage if DC is not added to group • Smaller number of hub DCs than Branch Office DCs • Edit Default Domain Controllers Policy • Disable automated site coverage • Important that this is configured for ALL DCs, not only Branch Office DCs

  31. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  32. Replication PlanningImprovements in Windows 2003 • Windows 2000 • Topology creation had scalability limits • Required to manage connection objects manually • Windows 2003 has many improvements to fully automate topology management • New KCC / ISTG algorithm • Bridgehead server loadbalancing • KCC redundant connection object mode • Specifically developed for Branch Office deployments

  33. Replication Planning KCC/ISTG • ISTG = Inter-Site Topology Generator • Computes least cost spanning tree Inter-Site replication topology • Does not require ISM Service • Windows 2000: ISTG uses ISM service • Runs every 15 minutes by default

  34. Replication Planning KCC/ISTG • Vastly improved inter-site topology generation (KCC/ISTG) scalability • Complexity: approximately O(d*s) d = number of domains s = number of sites Win2000: approximately O(d*s²) • Scales to more than 5,000 sites • Still single threaded – uses only one CPU on SMP DCs • Performance: 4,000 sites: 10 secs (700 Mhz test system) • Ongoing tests in scalability lab • Can generate different topology than Windows 2000 KCC/ISTG • Requires Windows 2003 forest functional level

  35. Replication Planning Bridgehead Server Selection • Windows 2000 • On a per site basis, for each domain, one DC per NC used as Bridgehead • Windows 2003 • On a per site basis, for each domain, all DCs per NC used as Bridgehead • KCC picks DC randomly amongst bridgehead candidates when connection object is created • For both incoming and outgoing connection objects

  36. Replication Planning Bridgehead Server Load-Balancing • KCC/ISTG randomly chooses Bridgehead Server • Both incoming and outgoing replication • Once connection object is established, it is not rebalanced when changes happen • Adding new servers does not affect existing connection objects • Has to be used with care in Branch Office Deployments • Necessary to control what servers are used as Bridgehead Servers • Recommendation: Use preferred Bridgehead Server List and load balancing tool

  37. Replication Planning Preferred Bridgehead Server List • Some servers should not be used as Bridgeheads • PDC operations master, Exchange facing GCs, Authentication DCs • Weak hardware • Solution: Preferred Bridgehead Server List • Allows administrator to restrict what DCs can be used as Bridgehead Servers • If Preferred Bridgehead Server List is defined for a site, KCC/ISTG will only use members of the list as Bridgeheads • Warning: • If Preferred Bridgehead Server List is defined, make sure that there are at least 2 DCs per NC in the list • If there is no DC for a specific NC in the list, replication will not occur out of site for this NC • Don’t forget application partitions • If branches have GCs, all bridgeheads should be GCs

  38. Replication Planning Active Directory Load Balancing Tool (ADLB) • ADLB complements the KCC/ISTG • Real load balancing of connection objects • Stagers schedules using a 15 minute interval • Hub-outbound replication only • Hub-inbound replication is serialized • Does not interfere with the KCC • KCC is still needed / prerequisite • Tool does not create manual connection objects, but modifies “from-server” attribute on KCC created connection objects • Can create a preview • Allows using the tool as an advisor • Single exe / command line tool • Runs on a single server / workstation • Uses ISTG in hub site to re-balance connection objects • Not needed for fault tolerance, only as optimization • Can be run on any schedule

  39. Replication Planning KCC Redundant Connection Objects Mode • Goal • Create stable, simple and predictable replication topology • Like mkdsx scripts for Windows 2000 • Enabled on a per site level • Implementation • Creates two redundant connection objects • Each branch site replicates from two different Bridge Head Servers • Two different Bridge Head Servers replicate from each site • Replication schedule is staggered between connection objects • Fail-over is disabled • If replication from one Bridge Head fails, the branch can still replicate from the other Bridge Head • Schedule hashing is enabled • Inbound connections start replication at random time inside the replication window • Only DCs in same site are used for redundant connection objects • Demoting DC causes KCC to create new connection object

  40. Replication Planning KCC Redundant Connection Objects Mode • Schedule for redundant connection objects • Use schedule defined on site-link • Like, window open 8pm to 2am, replicate once every 180 minutes (= 2 replications) • Divide by “2” and stagger • Connection object 1 replicates once between 8pm and 11pm • Connection object 2 replicates once between 11pm and 2am • Second replication usually causes little network traffic • Monitoring becomes even more critical • Important to act quickly if hub DC becomes unavailable

  41. Replication Planning KCC Redundant Connection Objects Mode

  42. Replication Planning Recommendations: Sites, Site-Links and Topology • Create single site for hub site • Leverage KCC load-balancing between Bridgehead servers • Create site-links between Branch Office sites and hub site • No redundant site-links or connection objects are needed • Disable transitivity of site-links • Not only for performance, but also to avoid branch-branch fail-over connection objects • Disable auto-site coverage • Use KCC/ISTG services • Use KCC redundant connection objects mode • Use ADLB to load-balance connection objects • Use Universal Group Caching to remove requirement for GC in branch • Unless branch application requires GC

  43. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  44. Capacity Planning Replication Planning • Branch Office DCs • Usually low load only • Use minimum hardware • Datacenter DCs • Depends on usage • See Windows 2003 Deployment Kit for DC capacity planning • Bridgehead servers • Require planning

  45. Capacity PlanningFormulas to compute number of Bridgeheads • Hub outbound replication is multi-threaded • Hub inbound replication is single-threaded • Hub outbound: OC = (H * O) / (K * T) • OC = outbound connections • H = sum of hours available for outbound replication • O = concurrent connection objects • K = Number of replications required / day • T = time necessary for outbound replication (usually one hour) • Hub inbound: IC = R / N • IC = inbound connections • R = Length of replication in minutes

  46. Capacity Planning Bridgehead Server Overload • Cause • Unbalanced site-links • Unbalanced connection objects • Replication schedule too aggressive • Panic trouble-shooting • Symptoms • Bridgehead cannot accomplish replication requests as fast as they come in • Replication queues are growing • Some DCs NEVER replicate from the bridgehead • Once a server has successfully replicated from the bridgehead, its requests are higher prioritized than a request from a server that has never successfully replicated • Monitoring • Repadmin /showreps shows NEVER on last successful replication • Repadmin /queue <DCName>

  47. Capacity Planning Bridgehead Server Overload - Solution • Turn off ISTG • prevents new connections from being generated • Delete all inbound connection objects • Correct site-link balance and schedule • Enable ISTG again • Monitor AD and FRS replication for recovery

  48. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

  49. Monitoring Design • Monitoring is must for any Active Directory Deployment • DCs not replicating will be quarantined • DCs might have stale data • Not finding issues early can lead to more problems later • I.e., DC does not replicate because of name resolution problems, then password expires • Use MOM for datacenter / hub site • Monitor replication, name resolution, performance • Windows Server 2003 Branch Office Guide ships with BrofMon • System to push and run scripts to Branch DCs • Results copied to central server • Web page presents Red/Yellow/Green state per server • Evaluate available monitoring tools • MOM and third parties

  50. Active Directory DeploymentFor Branch Offices • Active Directory Design • Forest design • Decide on centralized or decentralized deployment • Domain design • DNS design • Site topology and replication design • Capacity planning • Monitoring design • Active Directory deployment • Deploying and monitoring non-branch domains • Deploying branches domain in hub site • Deploying and monitoring a staging site • Deploying and monitoring the branch sites

More Related