Microsoft Access Based Enumeration

Adam Bell — Tue, 16 Sep 2008 03:37:48 +0000

Have you ever had one of those moments in IT, when you discover a tool, and a light bulb goes on inside your head, and you say to yourself “I’ve needed this for ages! This really fixes issue X”?

I’ve had that a few times (maybe I need to get out more?), and one of those times was a few years ago with a tool from Microsoft, named as only MS can: Windows Server 2003 Access Based Enumeration or ABE. I took it for granted that everyone knew about this great tool, and was using it. That was until I suggested to a client that it may help his corporate share restructering project, and he looked at me blankly. In fact the more people I’ve mentioned this to, the more blank looks I’ve got. So, if you’ve not heard of it you’re probably asking what the damned thing does?

ABE, is a very small download from Microsoft, that provides a piece of functionality everyone has been wishing for since, well NT4 in my case. Basically when you have a user connect to a shared folder, and they are browsing within that folder structure, if they don’t have permission to a folder/file then they just don’t see it. Gone are the previous issues of getting access denied messages, followed by helpdesk calls to clarify if they should be allowed in to Folder Y. Great huh?

As part of installing ABEUI.msiyou have the following options:

Configuration choice during installation

Post installation changes can be made through CLI using abecmd.exe or through a tab on the share’s property dialog:

Options for configuration ABE on the Property sheet of the share folder

Acess Based Enumeration requires Windows Server 2003 with Service Pack 1. It’s not required on Windows Server 2008, because the behaviour is already included, but is not configurable. Finally ;)

Windows 2003 DNS Server rights issue

Adam Bell — Wed, 27 Feb 2008 14:45:11 +0000

Apparently there is a permissions issue regarding hosting DNS zones in the ForestDNSZones, or DomainDNSZones partitions in Server 2003. I haven’t looked to see if this has been resolved in 2008. The issue and solution is detailed in Microsoft KB939090.

This issue occurs because of the permissions that are set in the Active Directory directory service….
The members of the DnsAdmins group do not have permissions on the following application partitions:
CN=MicrosoftDNS,DC=ForestDNSZones,DC=Domain…
CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain…

The documented solution is to edit your Active Directory with ADSIEdit and go in to fix the problem:

To resolve this issue, set permissions for the DnsAdmins group on the DomainDNSZones application partition and on the ForestDNSZones application partition.

We have taken a pretty close look at manipulating permissions in AD with PowerShell before, covering:
Standard Rights
Removing Rights in AD
Inheritance and Propagation
Extended Rights
and Controlling Access Rights in AD

We’re going to build a function similar to Add-DsAce.ps1 we used in the Standard Rights post, but this time we’re going to use a slightly different constructor, so that we can apply the correct inheritance. We want this to affect “This object and all Child Objects”, which means we need to use:



[System.DirectoryServices.ActiveDirectorySecurityInheritance]"SelfAndChildren"

So, our modified function looks like this:
Add-DsAce2.ps1



#----------------------------------------------------------------------------------------------------------

function Add-DsAce

#----------------------------------------------------------------------------------------------------------

{

Param (

  $DSobject,

  $Identifier,

  $DSrights,

  $AccessType = "Allow",

  $Inheritance

  )

  # GetAccessRules: Explicit ACE's, Inherited ACE's, TargetType

  $account = New-Object system.security.principal.ntaccount($Identifier)

 

  # Retrieve the SID - as a manual step you can check it's not empty :)

  $sid = $account.translate([system.security.principal.securityidentifier])

 

  $Inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"SelfAndChildren"

  $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($account, $DSrights, $AccessType, $Inheritance)

  $DSobject.psbase.get_objectsecurity().AddAccessRule($ace)

  $DSobject.psbase.CommitChanges()

}

#----------------------------------------------------------------------------------------------------------

Now that we have the ability to modify the AD, and presuming we dot source the newly created function we could do the following:



$root = [adsi]""

$ForestDNSZones = [adsi]("LDAP://DC=ForestDNSZones,"+$root.distinguishedName)

$DomainDNSZones = [adsi]("LDAP://CN=MicrosoftDNS, DC=DomainDNSZones,"+$root.distinguishedName)

 

Add-DSace $ForestDNSZones "DNSAdmins" "GenericAll"

Add-DSAce $DomainDNSZones "DNSAdmins" "GenericAll"

Basically, we’ve bound to AD via ADSI so that we can dynamically provide the domain DN, and the two locations in AD we want to apply the ACE to. Then it’s just a matter of passing the created function the parameters needed.

Lead, Follow, or Move » Windows Server 2003

Microsoft Access Based Enumeration

Windows 2003 DNS Server rights issue