Administrators’ Idol Windows and Active Directory Best Practices

1. Required Slide SESSION CODE: WSV301 Administrators’ IdolWindows and Active Directory Best Practices Dan Holme Director of Training & Consulting Intelliem

2. Dan Holme • Consultant & Trainer at Intelliem • www.intelliem.com • Fortune-caliber business, academic & government clients • Microsoft Technologies Consultant, NBC Olympics • Contributing Editor, Windows IT Pro magazine,SharePoint Pro Connections magazine • www.SharePointProConnections.com • Author: Microsoft Press • MVP: Directory Services (2007)SharePoint Server (2008-2010) • danh@intelliem.com • http://www.intelliem.com/resourcekit

3. Fire Hose “On" • Goals of session • Cover tips, tricks & traps, best practices • Show you things you may never have been told and might never find out about anywhere else • Demonstrate (and give you) valuable scripts & tools • Very important resources • http://www.intelliem.com/resourcekit • Enhanced slides with details & step-by-steps • Scripts and tools! • Windows Administration Resource Kit

4. Groups Managing roles, rules, and resources

5. Role-Based Management Questions: “What can Joe get to?” and “Who has access to the budget?” Answers: “Umm….” demo & best practices

6. Access Management Without Groups Identity Resource Access Management

7. Groups Add Manageability Identity Group Resource Access Management

8. Groups Add Scalability Identity Group Resource Access Management

9. One Type of Group Is Not Enough Identity Group Resource Access Management

10. Role-Based Management: Role Groups and Rule Groups Identity Role Group Rule Group Resource Access Management

11. Role-Based Management: Windows Group Scopes Access Management Identity Role Group Rule Group Resource Identity Global Domain Local Access

12. Role-Based Management • Users  Role  Rule  Resource • MaxTokenSize long story short • >200-300 groups and you’re in trouble • You can work around it: deploy a larger MaxTokenSize throughout forest • 1024 is the hard limit (Kerberos) • Double-rule your resources • Migration to RBM • Design your managed framework • Draw a line in the sand: From now on, managed • Back-fill the management over time

13. Group Management best practices

14. Define Group Naming Conventions • Naming conventions • Role groups. Simple, unique name, such as Sales or Consultants • Management groups. For example, ACL_Sales Folders_Read • Prefix. Management purpose of group, such as ACL • Resource identifier. What is managed, such as Sales Folders • Suffix. Access level, such as Read • Delimiter. Separates name components, such as underscore (_)

15. Best Practices for Group Documentation • Why document groups? • Easier to find them when you need them • Easier to understand how and when to use a group • Establish and adhere to a strict naming convention • Prefix, for example, helps distinguishAPP_Budget from ACL_Budget_Edit • Prefix helps you find the group in the Select dialog box • Summarize a group's purpose with its description • Appears in Active Directory Users and Computers details pane • Detail a group's purpose in its Notes field

16. Copy Group Membership • Copy members from one group to another • Copy memberships of one user to another dsget group "CN=Sales,OU=Role,OU=Groups,DC=contoso,DC=com" –members | dsmod group "CN=Marketing,OU=Role,OU=Groups,DC=contoso,DC=com" –addmbr dsget user "SourceUserDN" –memberof | dsmod group –addmbr "TargetUserDN"

17. Delegate Membership Management with Managed By • The Managed By tab serves two purposes: • Provide contact information for who manages the group • Allow specified user (or group) to modify group membership if Manager Can Update Membership List is selected • Tips • Must click OK (not just Apply)to change the ACL on the group • To set a group in the Name box,click Change, then clickObject Types, and then click Groups

18. Shadow groups Membership based on an LDAP query Group_Shadow.vbs demo

19. Delegating System Administration best practices

20. System Administration • Implementation: local Administrators group • Process • Define scopes of computers • Create (global or domain local) role groups defining scopes of administration • e.g. SYS_NYC_Clients_Admins, SYS_FileServer_Admins • Create rules defining the computers in each scope • OUs: OU=NYC,OU=Clients,DC=contoso…, OU=File,OU=Servers,DC=contoso… • or (global) rule groups: COMP_NYC_Clients, COMP_Servers_File • Group Policy Restricted Groups (MemberOf version—cumulative) • Filter GPO by rule groups

21. User-as-Administrator • Make it manageable • Process • Create a (domain local) rule group for each computer • SERVER05_Admin, LAPTOP12_Admin • Add the computer admin group to the local Administrators group • One-time, e.g. image • Startup Script • Note • Do not nest support staff using this method in large environments • MaxTokenSize • Double-Rule: Use the process on the previous slide

22. System Administration • Get Domain Admins out of clients’ Administrators group • Consider the Administrator account • No more generic passwords! • Why do you need local Administrator logon? • Admin credentials when domain is not accessible • Physical, interactive logon only • In the enterprise: never • Remove disk and mount to a functioning system • On the road: possibly • If users are not administrators of their own laptops

23. System Administration • Solutions • Disabled account • Log on in Safe Mode to enable • Random password • If system cannot connect to domain • Yank out disk • Or reimage (non-destructive)

24. System Administration • Solutions • Disabled account • Log on in Safe Mode to enable • Password check out • Password stored securely, retrieved by IT support, then automatically changed • Steve Riley’s book or tools like Liebermann • Unique password • Password based on a system characteristic • Something on your “label” on the computer • Something in BIOS: serial number, asset tag • Plus a unique or random piece that can be retrieved by IT • Changed after use

25. Computers

26. Computer object management • Windows’ default computer management is highly over delegated and not least privilege • Redirect default computer container to an OU with appropriate delegation & configuration • redircmp "DN of OU for new computer objects“ • Remove default “any user can join 10 computers” • Computers_SetQuota.vbs • Delegate creation of computer objects • computerou_delegate_create.bat "DN of OU" "Domain\group" • Delegate joining computers to the domain • computerou_delegate_join.bat "DN of OU" "Domain\group"

27. Provision a computer Computer_JoinDomain demo

28. Computer object management • Prestage computer accounts • No more joining a workgroup computer to the domain with no prestaged account • Use djoin.exe to perform an offline domain join for Windows 7 clients • Reset computer accounts • No more “remove from domain and rejoin domain” • Deletes computer object • Wipes out group memberships of computer • Rename computer accounts • When you give a user a new computer and retire the old one • Maintains group memberships of computer • Alternately, copy group memberships from old to new computer

29. Extending The Schema Schema_Create_AssignedComputers.vbs * Do not try at home without reading the Resource Kit and testing! Parental supervision required! demo

30. User Accounts

31. Last Name, First Name best practices

32. Scenario: User management

33. Problem: Finding users easily

34. Solution: The wrong solution • Do not use <Last>, <First> as the common name • LDAP distinguishedName is delimited by commas, so commas are 'escaped' • Throws off many scripts and apps • displayName can be <Last>, <First>

35. Solution: Customize MMC view • View  Add / Remove Columns • Last Name or Display Name • Sort by Last Name or Display Name

36. New problem: View affects all OUs

37. User Accounts best practices

38. User Logon Names: A Modest Proposal • Pre-Windows 2000 Logon Name (sAMAccountName) • %username% - used in numerous places - unlikely to untangle • Unique in the enterprise (Employee ID or alias) • User Principal Name (UPN) • Make it the same as the user’s email address • Cultural change: Log on with email address – users never forget it! • Rename Administrator • Not for security – to reduce confusion and potential for lockout • Use Group Policy to scope name differently to different classes of computers

39. Generic User Accounts • Security death wish • Typical scenarios • Internet access • Kiosk • Consider local account • Unique password on each system where needed • So account cannot authenticate to other systems with the generic account • Create account with same name in the domain • Better yet: unique accounts for each user, managed the same way • User name: Intern01, Intern02, Intern03 – Unique passwords • In a group, “INTERN” that defines user experience

40. Be informedBe in control

41. Self-reporting Computer_SelfReport demo

42. Self staging change control Software_Deploy.vbs demo

43. Active Directory

44. Active Directory Service Administration best practices

45. Domain Security & Forest Models • Domains • Multi-domain forests out – single-domain forests in • Trusts out – federated identity and claims-based authentication in • OU models • Design first for security (delegation/administration/ACLs) • Object-based models are most typical • Users: ACLed the same • Administrative identities: separated from standard users • Client computers: typically by site – who can add computers to domain? • Servers: typically by role • Groups: highly varied

46. Active Directory Administration & Delegation • Domain’s Administrator account • Super-secured, never used, in-case-of-emergency-break-glass • Domain Admins, Enterprise Admins, domain’s Administrators groups • E-M-P-T-Y (more or less): Custom accounts for use only as needed • Protected accounts: adminSDHolder • Schema Admins: Empty. Add members when schema change needed. • Builtin groups (Account/Server/Print/Backup Operators) empty • Over-delegated • Protected accounts (adminSDHolder) • Delegation • Carefully managed – easy to get out-of-control and to lose documentability • Excellent candidate for role-based management

47. Site topology • What’s changed • Networks are good, need for sites to partition replication has decreased • Fewer sites • Increased use of replicated resources for performance, DR • What’s needed • More sites • Sites without domain controllers (domain controller-less sites) • Partition replicated resources (DFSN/DFSR)

48. Subnets • What’s changed • Multiple components, tools, technologies rely on AD sites • Domain controller location • Increased mobility: Where’s ComputerX? • What’s needed • You must have a process by which IP subnets are synch’ed with AD DS • Ensure all IP addresses are associated with an AD subnet (therefore, site) • IP address provisioning • Use the LOCATION attribute of the AD subnet • US\LA\MSY\ConventionCenter\AudA

49. Replication • What’s changed • Networks are good • Increased need for convergence • People trust AD • Notification-based replication • Change intersite replication to use notification-based replication • Same as intrasite • Reduce convergence of replication • Reduce issues related to password change, group change, lockout, etc.

50. Extreme MMC Consoles