Basic Active Directory Security

A large majority of breaches happen because of compromised credentials (https://blog.centrify.com/cause-of-data-breaches/) and so it stands to reason that a compromise of privileged credentials would be the worst case scenario. If someone gets hold of Domain Admin credentials the game is essentially over.

Because of this when I’m talking to customers about improving their security posture one of the first things I recommend is reducing the number of accounts in AD privileged groups such as Domain Admin, Enterprise Admin and Schema Admins as documented in the Best Practices for Active Directory Security.  What I often see is;

Lots of accounts in Domain Admins

IT administrators are often in Domain Admins.  Sometimes, but not always, this account is separate from their day to day ‘normal’ account.

Service accounts in Domain Admins

I often ask why so many accounts are put in these groups and the answer is usually along the lines of;

‘I need those permissions’ or ‘stuff just works when an account is in that group’.

For me one of the simplest things you can do to help reduce the attack surface of AD is to simply remove accounts from these privileged groups. Ideally the only account in there would be the built in Administrator (RID 500) account.

AD Security resources;

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory

http://adsecurity.org/

I’ll do another post soon on Group Policy settings to help secure and audit your AD and Windows environment.

 

 

 

Domain Controller promotion stops responding

Whilst promoting a Windows 2012R2 server to a domain controller it got as far as ‘Replicating the schema directory partition’ and then nothing else happened.

Now, this server has NetBios over TCPIP disabled which was causing the above problem.  The quick answer to this is to use the long version of the username when entering the credentials for the domain controller promotion i.e. domainname.comadministrator and not domainadministrator

 

More info here https://support.microsoft.com/en-us/kb/2948052

New Child Domain – Server Core and PowerShell

All of my domain controllers are now server core unless someone can give me a very good reason to install Windows with a GUI, so far no one has given me a good enough reason.

When deploying a new child domain this means we can now use some PowerShell goodness to create our new child domain.

Pre-reqs

Windows 2012R2 Server Core installed

IP address set on the box and preferred DNS server set to the IP address of a domain controller in the parent domain

Install-Windowsfeature AD-Domain-Services

Install-ADDSDomain -DomainType child -NewDomainName ‘childdomname’ -ParentDomainName ‘parentdomname.com’ -InstallDns -CreateDnsDelegation -NewDomainNetBiosName ‘childdomname’ -DomainMode win2012r2 -Credential (get-credential)

 

You will be prompted for the admin credentials of your parent domain and then for the safemodepassword that you want to set on this DC.

SYSVOL Not Replicating – The content set is not ready

Had an odd problem in a lab environment.  The lab was only two Windows 2012R2 core domain controllers, fully patched and up to date and a WSUS server.  For some reason SYSVOL was not replicating and I only noticed when I configured a GPO for WSUS and noticed that one of the DCs never registered in the WSUS console.

AD replication was fine – a repadmin /replsum did not show any errors.  Looking in the DFS Replication log did not show any errors on either DC but what was not logged was an event ID 4604.  A 4604 is an indication that SYSVOL replication has been enabled and the initial sync completed.

Looking in the DFSR logs in c:windowsdebug showed;

 

20160112 20:18:23.416 3088 ISYN    68 InitialSyncManager::ReturnToken InitialSync sync step not finished yet. Wake up other session tasks.
20160112 20:18:43.127 1824 SRTR   971 [WARN] SERVER_EstablishSession Failed to establish a replicated folder session. connId:{EC12E981-AFF0-4B07-85F6-B3FA698EDA9E} csId:{33FC6089-F773-4647-A039-0D3EA525329B} Error:
+ [Error:9051(0x235b) UpstreamTransport::EstablishSession upstreamtransport.cpp:803 1824 C The content set is not ready]
+ [Error:9051(0x235b) OutConnection::TransportEstablishSession outconnection.cpp:510 1824 C The content set is not ready]
+ [Error:9051(0x235b) OutConnection::TransportEstablishSession outconnection.cpp:449 1824 C The content set is not ready]

As the DCs run server core the DFS Management tools (including dfsrdiag) are not available.  I installed the DFS Management tools on a server with a GUI – right click the top branch in the left hand side of the MMC console where it says DFS Management and select ‘Add Replication Groups to Display’.  Add the Domain System Volume.

Running a health report showed that DC01 was waiting for initial sync and DC02 also waiting for initial sync but with some backlogged files.

DC01 was the up to date DC as I could see more policy objects in SYSVOL on that server.

To fix this I ran up adsiedit and went to;

Default naming context | Domain Controllers OU | DC01 | DFSR-LocalSettings | Domain System Volume | SysVol Subscription | Properties

and set the below property.  It was set to 0.

  • Set DFSR-Options to 1

Within 5 minutes I then had an event ID 4604 logged on both DCs and SYSVOL replicating problems

This was a shorter version of https://support.microsoft.com/en-us/kb/2218556 (How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL)

Whether not following the full procedure has any impact in the future I’m not sure but as it was a lab environment with only a few servers it didn’t matter too much and it did fix my SYSVOl replication problems.

Restore Computer Object with AD Recycle Bin

Over the Xmas period it would seem that someone deleted a computer account from AD.  This meant that the user of that PC could not log in using that PC.  This is a Windows 2008R2 forest so to restore the computer object;

 

Get-Adobject -filter {samaccountname -eq “pcname$”} -IncludeDeletedObjects | Restore-Adobject

 

The $ on the pcname is important – computer objects in AD always have $ at the end of the name as part of the samaccountname attribute.

AdminSDHolder and admincount=1 attribute

Certain groups within Active Directory are considered protected groups and are protected by AdminSDHolder.  When a user becomes a member of a protected group it will no longer inherit permissions from its parent object in AD (usually an OU).  This can mess up any carefully laid permission delegations you may have configured.  Much more on AdminSDHolder here

As an AD admin you may find that if you have been delegated permissions to , say, reset passwords of all users in OU you could come across a user who’s password you can’t reset.  You’ll basically be told you do not have permissions on that object.  If that user account was once in a protected group they will not be inheriting the permissions from the parent OU.

To identify users that have the attribute admincount set to 1

$count = Get-Aduser -searchbase “OU=ExampleOU,DC=Example,DC-Com” -Properties adminCount -Filter * | where {admincount -gt 0}

To then set that attribute back to 0

$count | Select SamAccountName,distinguishedName,adminCount | ForEach-Object {Set-Aduser -Identity $_.SamAccountName -Replace @{adminCount=0}}

 

Once that is done then inheritance needs to be re-enabled on the object; the below code from here

 

$users = Get-ADUser -ldapfilter “(objectclass=user)” -searchbase “OU=companyusers,dc=enterpriseit,dc=co”
ForEach($user in $users)
{
# Binding the users to DS
$ou = [ADSI](“LDAP://” + $user)
$sec = $ou.psbase.objectSecurity

if ($sec.get_AreAccessRulesProtected())
{
$isProtected = $false ## allows inheritance
$preserveInheritance = $true ## preserver inhreited rules
$sec.SetAccessRuleProtection($isProtected, $preserveInheritance)
$ou.psbase.commitchanges()
Write-Host “$user is now inherting permissions”;
}
else
{
Write-Host “$User Inheritable Permission already set”
}
}

 

Move users to OU based on description

Trying to keep up with job changes and ensuring users accounts are in the correct OU in AD can be problematic.  In the environment I work in each team has their own OU (I’m not sure why it is like this,  I suspect it’s a case of ‘that’s the way we’ve always done it’).

Anyway mine is not to reason why.  So the good thing is that the descriptions for users are fairly well defined, for example someone in the 2nd line team the description is ‘Second Line Support Team’.   Using this description users can be moved to the correct OU using Powershell

First I create variables for the OUs

$secondlineou = “OU=SecondLineOU,DC=Example,DC=Com”

then I can use Get-Aduser and filter on the description

Get-Aduser -Filter “Description -eq ‘Second Line Support Team'”

This gives me all users in AD with a description of ‘Second Line Support Team’

I then pipe that information to the Move-Adobject cmdlet and specify the variable as the target

Move-Adobject -TargetPath $secondlineou

Putting this all together gives

$secondlineOU = “OU=SecondLineOU,DC=Example,DC=Com”

Get-Aduser -Filter “Description -eq ‘Second Line Support Team'”| Move-Adobject -TargetPath $secondlineou

 

I have this running as a scheduled task.  This has made things easier on the service desk team.  All they now need to do is updated a users description and the automation will ensure the account gets placed into the correct OU