2008 AD Drilldown by wgv13363

VIEWS: 0 PAGES: 45

									2008 AD Drilldown
Topics
• RODCs                      • ADSIEDIT in ADUC
• Server Deletion Wizard
• AD snapshots
• 2008 AD backups
• Anti-deletion protection
• Fine-grained password
  policies
• “Next closest site”
• Server Core and AD
Read-Only Domain Controllers
what they do
• A subset of DCs can
  – Accept replicated changes from RWDCs but not
    originate new changes (ie cannot accept password
    changes, new accounts, etc)
  – Accept replicated changes to SYSVOL but not originate
    them
  – Accept a subset of the AD (“RO-PAS”)
  – Still act as global catalog servers
• Works in 2003 domain/forest functional level and
  later
Read-Only Domain Controllers
why bother?
• A compromised RODC can do less damage than
  can a compromised RWDC (it lacks parts of the
  AD and cannot originate bad traffic)
• RODCs reduce replication traffic
• RODCs can be locally administered by folks who
  are not domain admins
• RODCs can potentially be exposed to higher-risk
  locations
  – Insecure branch offices
  – DMZs
  – Direct attachment to the Internet
Read-Only Domain Controllers
how they work

• Only replicate with 2008 RWDCs
• So you need at least one RWDC
• Can act as an AD-integrated DNS server, but,
  again, it does not accept DNS registrations
• Design essentially always assumes that they
  cannot be trusted
• Cannot be FSMOs or bridgehead servers
Read-Only Domain Controllers
setup details

• Created in a two-step process
   – Domain admin creates a “slot” in the DS for a RODC
   – DA then delegates the ability to create/administer the
     RODC to someone in the branch office
• RODCs contain almost all of the DS, except for the
  password hashes of user and machine accounts
• DAs can then decide which, if any, passwords to
  let the RODC keep a copy of
Read-Only Domain Controllers
how logins work (default)

• An RODC has no passwords by default
• All local login attempts (assuming no local
  RWDCs) are relayed to a RWDC
• When the login tickets come back from the
  RWDC, the RODC hands them to the client
• At that time, the RODC also asks for the
  client’s password; if it’s okayed for it, then the
  RWDC gives it to the RODC
Read-Only Domain Controllers
so that’s interesting why?

• Yes, if the WAN link is down, no one logs in
• But if it’s up, then the client can get group
  policies, login scripts, roaming profiles and the
  like from the local RODC
• If a DA approves giving any given password to
  the RODC, then that RODC can do local logins
  without the need of the WAN
Read-Only Domain Controllers
planning considerations

• Where to put them
• Which, if any, passwords to store locally (don’t
  forget machine passwords)
• What to do if the RODC is stolen?
• Answer: remove the RODC’s account in Active
  Directory Users and Computers, and the “Server
  Deletion Wizard” offers to either deactivate the
  accounts whose passwords were on that RODC,
  or force them to change passwords
Read-Only Partial Attribute Set
• (“RO-PAS” to its friends)
• Ever since Windows 2000, some AD attributes
  have been marked as “special” in that they’re the
  only thing replicated to global catalogs
• 2008 includes a sort of “anti-special” attribute:
  one that gets replicated to all DCs except RODCs
• Intended for “secret,” credential-like information,
  such as BitLocker recovery keys
• RODCs know not to ask for these attributes
2008 AD Backups
how we access backups

• You of course know what an AD backup is
• But now think about how you access an AD
  backup – via some restore process
• There are times, however, when we’d like to
  look at a backup without actually dumping it
  onto the hard disk
2008 AD Backups
how we access live data

• Now consider how we interact with a “live”
  AD
• LDP, ADSIEdit, Active Directory Users and
  Computers etc all talk to AD in the same way:
  by connecting to an LDAP service on port 389
  or LDAP over SSL on port 636
• Now get ready for the interesting part…
2008 AD Backups
AD snapshots: a little of both worlds

• An AD snapshot lets you use NTDSUTIL to take
  a backup of AD while AD’s running, as we’ve
  seen before
• But then you can mount that using a program
  called dsmain.exe as if it were a read-only
  copy of a directory service, although on a
  different set of ports than 389/626
• ADUC doesn’t work, but LDP and ADSIEdit do
2008 AD Backups
what good are snapshots?
• Being able to read attributes and objects from a
  previous version of AD offers new ways to restore
  deleted objects
  – Use information from there to reanimate
    “tombstoned,” deleted objects
  – Dump the old copy of the AD to a CSV, dump the new
    one to a CSV and do a simple difference comparison
• Similarly, Sysinternals will soon release
  “ADRestore,” an AD-based differencing and
  restore tool
Try it out
• I will be working from an AD called
  “bigfirm.com;” substitute whatever domain name
  you like
• Log on as a domain admin, open an elevated
  command prompt, and start up:
• ntdsutil
• Then tell ntdsutil that you want to look at the
  actual running AD by typing
• activate instance ntds
• snapshot
Create the Snapshot
• create
• Makes the snapshot; you’ll get something like
• Creating snapshot...
• Snapshot set {d496754f-761a-
  44d8-bc93-93790117fe01}
  generated successfully.
• Take a look at what snapshots you have:
• list all
Mount the snapshot
• First, mount the GUID of the snapshot from
  ntdsutil:
• mount {d496754f-761a-44d8-bc93-
  93790117fe01}
• (Use your GUID, not mine!) Result:
• Snapshot {4f51dbad-4319-41ee-
  96f1-b08894902116} mounted as
  C:\$SNAP_200706200818
• _VOLUMEC$\
• Then exit ntdsutil with quit, then quit
Find the AD file
• Open that
  C:\$SNAP_200706200818_VOLUMEC$\ folder
• You’ll see the entire folder structure from
  whatever disk AD (ntds.dit) live on
• I was lazy, so my ntds.dit is in
  C:\$SNAP_200706200818_VOLUMEC$\windo
  ws\ntds\ntds.dit
• Make sure you know where ntds.dit is before
  going any further
Make Your Snapshot “Live”
• Use a new program dsmain.exe to point to the snapshot and assign
  four ports to use for this “second DS instance”; mine looks like
• dsamain
  -dbpath:C:\$SNAP_200706200818_
  VOLUMEC$\windows\ntds\ntds.dit -ldapport:6000
  -sslport:6001 -gcport:6002 -gcsslport:6003
• Notice I choose four consecutive ports – use any four you like, and
  be sure that –dbpath points to the mounted snapshot. A favorable
  response will look like
• EVENTLOG (Informational): NTDS General /
  Service Control: Microsoft Active Directory
  Domain Services startup complete, version
  6.0.6001.16 510
Now Look At It
• Unfortunately ADUC does not let us specify a
  nonstandard port (389 is the standard LDAP port in
  AD), but LDP and ADSIedit do
• Start ADSIedit.msc
• Right-click ADSIedit, click Connect
• In the resulting “Connection Settings” dialog box, click
  the “Computer” radio button and fill in
  “localhost:6000,” substituting whichever port you
  specified
• Now ADSIedit is letting you browse your snapshot as if
  it were a live copy of AD… you just can’t change it
2008 AD Backups
the old stuff is gone…
•   There is no more system state backup…
•   Now Backup images entire drives into a VHD-like file; no option to just grab a
    folder
•   Needs a “Windows Backup Server” role installed, not by default:
•   servermanagercmd –install backup
•   Command line control from wbadmin
•   Result: you’ll want to isolate the AD on a drive by itself
•   But… you also need “system state,” which 2008 defines as “all of C:, even if it’s
    random stuff that has nothing to do with AD or the OS”
•   Result: you’ll want to dedicate a drive to the OS, so as to minimize the size of
    “system state”
•   Result: you must have an extra drive to back up to – tapes cannot be used,
    although DVDs can
•   USB devices can work if they call themselves “fixed” versus “removable”
•   Can do disaster recovery as well, understands all VSS types
•   Backup is now in Admin Tools, not Accessories
Let’s Review That
• If you put your ntds.dit on c:\ntds, then you
  need “only” back up c:\ for system state
• But you can’t back up onto c:\; you’ll need
  another drive
• Of course, that means that it’d be nice to be
  able to easily relocate Program Files / Program
  Files (x86)
Scheduling Backups
• The GUI tool includes a scheduler
• Or just use Task Scheduler and use the command line:
• wbadmin start backup –backuptarget:m:
  -include:c: -allcritical
• Backs up all of drive C:, including system state stuff, to
  drive m: in VHD format
• Note you cannot specify a folder on backuptarget; it’s
  always in WindowsImageBackup on the target drive
• Like System Restore, though, it remembers multiple
  generations of backups – it’s exploiting the “snapshot”
  capability of VHD files
Restoring
• Bare metal with Windows Recovery Environment
• Find what backups you have with wbadmin get
  versions
• Choose what kind of backup from the GUI,
  “incremental” or “full” backup
• That affects how the backup is created, not what is in
  the backup
• Only full backups for network shares and DVDs
• Start bare metal recovery with disc created in
  Maintenance / Create Recovery Disk, or use the install
  DVD
But maybe you don’t need backups
• Okay, I’m kidding… mostly
• But the main value of AD backups is to restore
  accidentally deleted items
• “Accidental deletion” protection available
• “Protect object from accidental deletion” check
  box
• Creates an ACE on the object with an Everyone
  Deny reference
• On OUs by default
Seeing Deletion Protection
• Create an OU
• Click View / Advanced in ADUC
• Examine the Properties page for the OU
• View the Object tab
• You’ll see a check box “Protect object from
  accidental deletion”
• Look in Security tab, notice the Everyone ACE
  with a “deny” checked
Creating Backups for DC Install
• Called “IFM” (Install From Media)
• First appeared in 2003
• Now, however, you need to do a different kind
  of backup to create the files needed to do an
  IFM install
• Starts in ntdsutil
NTDSUTIL and IFM
•   ntdsutil
•   activate instance ntds
•   ifm
•   create nosysvol full e:\mysnapshot
• Other options: nosysvol vs sysvol, full vs rodc
• Then move e:\mysnapshot to the new DC, run
  DCPROMO with advanced features enabled
Fine-Grained Password Policies
• Why create more than one domain in a forest?
• Well, ever since someone figured out that any
  domain admin of any forest could become an
  enterprise admin, there appear to be just two
  reasons:
  – Allow different parts of the enterprise to see
    different password policies
  – Politics and cosmetic reasons (“I want to use my
    domain name!”)
Fine-Grained Password Policies
well, I guess now only politics is left…
• You can now assign specific password policies
  to users (not machines) and groups
• But the way you do it is not what you
  expected
• First, you create an “password settings object”
  (PSO) in a new AD container called “Password
  Settings Container”
• Then, you modify an attribute in the PSO
  telling what objects (users, groups) to assign it
It’s a Password Policy…
• So you must specify all   • Minimum length
  of the components of a    • Minimum and
  password policy:            maximum password age
• Whether passwords are     • How many failures
  reversible or not           before locking out an
• How many previous           account?
  passwords to remember     • Lockout “memory” time
  (“history”)               • How long to leave an
• Is complexity required?     account locked out?
And Speaking of Times…
• Windows internally sees time in increments of
  100
• One second = 10000000 (seven zeroes)
• One minute = 600000000 (eight zeroes)
• One day = 864000000000 (nine zeroes)
• One week = 6048000000000 (nine zeroes)
• And you specify the times as negative
  numbers
Creating a Password Settings Object
• Open adsiedit.msc
• Right click ADSIEdit, Connect to…, OK
• Open “Default naming context,” domain
  name, CN=System
• In System, right-click CN=Password Settings
  Container, New/Object
• Wizard appears
Creating the PSO
• In “Select a class,” choose msDS-
  PasswordSettings, Next
• In “Attribute: cn, Syntax: DirectoryString,” enter a
  descriptive name like “MyPWDPolicy,” Next
• In Attribute: msDS-PasswordSettingsPrecedence,
  enter a value for the priority of this PSO, range 0
  up to whatever; used in case of conflicts of PSOs,
  the lowest number wins. Enter “10” for this test,
  Next
Creating a PSO
• Attribute: msDS-
  PasswordReversibleEncryptionEnabled refers to
  an old and largely unused Windows option to
  store password hashes in an easily reversible
  fashion. Possible values are true or false – enter
  “false” and Next
• Attribute: msDS-PasswordHistoryLengthValue
  tells Windows how many previous passwords to
  remember; takes an integer, set it to 20 and Next
Creating a PSO
• msDS-PasswordComplexityEnabled asks
  whether or not to enforce Windows’ password
  complexity rule, takes “true” or “false;” enter
  “false” and Next
• msDS-MinimumPasswordLength takes an
  integer to specify the minimum number of
  characters in a password; enter “15” and Next
Creating a PSO
minimum and maximum password age

• Minimum password age (how much time you
  must wait between changing passwords) and
  maximum age (how many days can pass
  before you must pick a new password) are
  msDS-MinimumPasswordAge and msDS-
  MaximumPasswordAge, which both take the
  negative values; insert -864000000000 (that’s
  nine zeroes) and -155520000000000 (ten
  zeroes) to specify one day and six months
Creating a PSO
lockout settings
• # bad logon tries = msDS-LockoutThreshold,
  but “0” means don’t lock out – choose that
  and Next
• msDS-LockoutObservationWindow = how long
  to remember a failed logon; set to 0, as we’re
  not locking out
• msDS-LockoutDuration = how long to lock
  people out; set to 0 as we’re not locking out
• Then click Finish
Now What?
• You’ve created a PSO, which is basically a
  password policy… but it’s not applied to
  anything
• You specify what to apply it to (user account
  or group) by modifying an attribute of the PSO
  itself, msDS-PSOAppliesTo; enter the
  distinguished name for the user or group
Applying the PSO
• In my example, I’ll apply my password policy
  to “mark” in the bigfirm.com domain
• In ADSIEDIT, right-click the “MyPWDPolicy”
  object you just created
• In the Attributes tab, find msDS-PSOAppliesTo
• Click the Edit button
• In “Value to add:,” enter the DN – for me, it’s
  cn=mark,cn=users,dc=bigfirm,dc=com
Try it out
• We’ve mandated that the “mark” user must have
  a 15 character password that needn’t be
  complex, despite the fact that default password
  policies in 2008 require complexity
• Open an elevated command prompt and do not
  do gpupdate /force – this is not affected by
  group policies! – and type
• net user mark thisisalongpwdyes
  /domain and press Enter. Notice that Windows
  will accept Mark’s new password, despite the fact
  that the password is not complex (but it is long)
Handling Conflicts
• What if Mark were a member of a group
  called “managers” and there were a PSO
  applied to the managers group; in that case,
  which PSO wins?
• The integer priority answers that question
• But who wants to figure that out?
• Every time you create a PSO, 2008 takes a
  moment and computes which PSO applies to
  every group and user
Seeing the Resultant PSO
• It’s stored on every object in an attribute
  called msDS-PSOApplied
• To see it, go to the CN=Mark object in
  ADSIedit (it’s in the Users folder), right-click it
  and choose Properties
• In Attribute Editor, click Filter and check
  “Backlinks” and then find msDS-PSOApplied
• It will point to the DN for our PSO
Fine-Grained Password Policies
yes, you heard that right

• This does not use group policies
• There may be many policies pointing to a given
  object
• You assign them whole-number priorities; the
  smallest one wins
• Every time you create a PSO, AD does a resultant
  set of policies analysis for each object
• Stores that on each object in msDS-PSOApplied
Thanks!
• Email: help@minasi.com
• Don’t forget the evals!

								
To top