In a previous post on decoding AD ACL's, I provided some code which took BSonPosh's get-adacl output and decoded the SID's and GUID's to help provide more readable output. The example of this is below, however you may find some of the other fields to be a bit confusing. So I created a few different types of test permissions on an OU to show how they are reflected in the Powershell output of these two commands.
Permission set in GUI: "Apply to: All Descendant objects, create/delete Conference Site objects"
ActiveDirectoryRights : CreateChild, DeleteChild
InheritanceType : Descendents
ObjectType : msExchConferenceContainer
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : TEST.LOCAL\Nathan
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : InheritOnly
Permission set in GUI: "Apply to: This object and all descendant objects, create/delete Contact objects"
ActiveDirectoryRights : CreateChild, DeleteChild
InheritanceType : All
ObjectType : contact
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : TEST.LOCAL\Nathan
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : None
Permission set in GUI: "Apply to: This object only, create/delete Computer Objects"
ActiveDirectoryRights : CreateChild, DeleteChild
InheritanceType : None
ObjectType : computer
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : TEST.LOCAL\Nathan
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
Permission set in GUI: "Apply to: Descendent Computer objects, Modify Owner"
ActiveDirectoryRights : WriteOwner
InheritanceType : Descendents
ObjectType : 00000000-0000-0000-0000-000000000000
InheritedObjectType : computer
ObjectFlags : InheritedObjectAceTypePresent
AccessControlType : Allow
IdentityReference : BHI-MASTER\adminlinlnat
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : InheritOnly
InheritedObjectType: Notice this will be all zero's when the permission is for creating a child object in a container. When it is permissions being set on a specific type of child objects, then it will be set that that object type, and the ObjectType value will be all zero's. When setting a permission on a specific property of a specific type of child object, you will get both fields filled in with the ObjectType being the specified property, and InheritedObjectType being the AD object's type.
PropagationFlags: InheritOnly exists when applying to something other than the current OU. (https://msdn.microsoft.com/en-us/library/system.security.accesscontrol.propagationflags(v=vs.110).aspx)
InheritenceFlags: ContainerInherit when applying to anything below the current level, ObjectInherit when applying to child objects (https://msdn.microsoft.com/en-us/library/system.security.accesscontrol.inheritanceflags(v=vs.110).aspx)
InheritanceType: All (everything from this level down), Descendents (children and descendants, not the current object), None (current level only) (https://msdn.microsoft.com/en-us/library/system.directoryservices.activedirectorysecurityinheritance(v=vs.110).aspx)
Showing posts with label ACL. Show all posts
Showing posts with label ACL. Show all posts
Tuesday, April 12, 2016
Tuesday, September 3, 2013
What not to do with access control lists on Active Directory objects
Although Active Directory can give a very fine level of control over properties of objects, its best to perform a bit of planning before making changes. Some ACL entry changes can give a lot of access, while adding very little to an Access control list, while other property specific changes can make a huge size difference on your access control list.
For those not familiar with access controls, basically all objects in active directory have an attribute on them which specifies the access to the object. This can be referred to as an Access Control List (ACL), security descriptor (SD, SDDL), or object security. Within the ACL, there are entries which may be referred to as Access Rules, or Access Control Entries (ACE). You will see different terminologies in different tools and .NET classes that manipulate the information. There are also different formats that the rules can be read in. Typically everyone is familiar with the security tab in Active Directory Users and Computers (available in advanced view). In the advanced mode of this, you have a better view of the access control entries. The ACE's themselves contain information such as:
ActiveDirectoryRights : ReadProperty, WriteProperty
InheritanceType : None
ObjectType : e45795b2-9455-11d1-aebd-0000f80367c1
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : S-1-5-10
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
You can find more about decoding these in my previous post which provides a script for this. In the background though, you have uglier formats to deal with like:
SDDL language O:DAG:DAD:AI(A;;LCRPLORC;;;PS)
Binary: hex code
If you look at technet on Security Descriptors, the maximum size of an ACE is 64k or roughly 1820 entries. That's quite a few, but its not too hard to shoot yourself in the foot with this. For example, you want to give someone access to almost every property of an object, but then you decided that there is one or two specific properties you don't want them to have. So you may start with giving "read all properties" and "write all properties" rights to the account. Then you go back into advanced view and uncheck a few properties. This removes the previous few entries for read/write all, and expands it into hundreds of ACE's for each specific property. We can see here how this affects the size. I created a directoryservices.directoryentry object pointing to a computer object
PS> $de.psbase.objectsecurity.getsecuritydescriptorbinaryform()|measure-object
Count : 11112
Here we see how many bytes are in the ACL. Now if I go and do what I just described to the ACL
PS> $de.psbase.objectsecurity.getsecuritydescriptorbinaryform()|measure-object
Count : 45692
The size has quickly exploded to a value that is edging towards the maximum size. When we hit the max size, we may end up with various failures in different places, with perhaps some very vague errors as to what the real problem is. The functions that manage the ACL and do conversions may be limited to a length value of 64K, causing exceptions to be thrown when they are processed.
For those not familiar with access controls, basically all objects in active directory have an attribute on them which specifies the access to the object. This can be referred to as an Access Control List (ACL), security descriptor (SD, SDDL), or object security. Within the ACL, there are entries which may be referred to as Access Rules, or Access Control Entries (ACE). You will see different terminologies in different tools and .NET classes that manipulate the information. There are also different formats that the rules can be read in. Typically everyone is familiar with the security tab in Active Directory Users and Computers (available in advanced view). In the advanced mode of this, you have a better view of the access control entries. The ACE's themselves contain information such as:
ActiveDirectoryRights : ReadProperty, WriteProperty
InheritanceType : None
ObjectType : e45795b2-9455-11d1-aebd-0000f80367c1
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : S-1-5-10
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
You can find more about decoding these in my previous post which provides a script for this. In the background though, you have uglier formats to deal with like:
SDDL language O:DAG:DAD:AI(A;;LCRPLORC;;;PS)
Binary: hex code
If you look at technet on Security Descriptors, the maximum size of an ACE is 64k or roughly 1820 entries. That's quite a few, but its not too hard to shoot yourself in the foot with this. For example, you want to give someone access to almost every property of an object, but then you decided that there is one or two specific properties you don't want them to have. So you may start with giving "read all properties" and "write all properties" rights to the account. Then you go back into advanced view and uncheck a few properties. This removes the previous few entries for read/write all, and expands it into hundreds of ACE's for each specific property. We can see here how this affects the size. I created a directoryservices.directoryentry object pointing to a computer object
PS> $de.psbase.objectsecurity.getsecuritydescriptorbinaryform()|measure-object
Count : 11112
Here we see how many bytes are in the ACL. Now if I go and do what I just described to the ACL
PS> $de.psbase.objectsecurity.getsecuritydescriptorbinaryform()|measure-object
Count : 45692
The size has quickly exploded to a value that is edging towards the maximum size. When we hit the max size, we may end up with various failures in different places, with perhaps some very vague errors as to what the real problem is. The functions that manage the ACL and do conversions may be limited to a length value of 64K, causing exceptions to be thrown when they are processed.
If you really need to do something like this, what you should do is grant the broad level of access and then create a few separate deny permission entries for the few properties that they shouldn't have access to.
Thursday, April 26, 2012
Decoding AD ACL's (Powershell)
Today I was looking at a deep dive video on creating modules and found out about the BSonPosh module. This contains some interesting commandlets, one of which is similar to some of the work I have been doing lately related to managing AD object ACL's. The commandlets for get-adacl in this module are similar to what you can get with the Microsoft AD module using get-acl pointing to the AD PSDrive. The thing that makes BSOnPosh great in comparison is that it works great on a multi-domain environment, and you don't need to go out of your way to point to 2008 servers if you have a mixed environment. In any case, if you look at my previous post related to decoding GUID's in ACL's by converting GUID's into an ldap searchable format, we can use this to extend the work done by BSonPosh. First, lets look again at what the acl entries look like:
ActiveDirectoryRights : CreateChild, DeleteChild
InheritanceType : None
ObjectType : bf967aa8-0de6-11d0-a285-00aa003049e2
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : S-1-5-32-550
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
Here, you can see many of the enumerations are decoded into text, but we have guid's and SID's that may show up without translation. With BSonPosh, there is a function for converting SID's already, though in this case I'm modifying it to handle SID's that do not translate with that code. Combining that with another helper function to decode the GUID's to the ldap display attribute listed in the schema, you can get a result that is more readable like this:
Get-ADACL -distinguishedname "dc=contoso,dc=com" | convert-adacl
ActiveDirectoryRights : ReadProperty, WriteProperty, Delete
InheritanceType : Descendents
ObjectType : msRTCSIP-UserPolicies
InheritedObjectType : user
ObjectFlags : ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType : Allow
IdentityReference : CONTOSO\RTCDomainUserAdmins
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : InheritOnly
Below is the code. One function was changed (ConvertTO-Name). The rest is added to BSActiveDirectory.psm1. It is important to note, that this conversion function creates its own custom PSobject, so it is not longer an ACL that you can play with and try to write back. This was more designed for auditing purposes.
Update: 1/29/2013
Just an additional note. Since you need distinguishednames for the commandlets, this can be a pain at times. If you like to use dsquery for quick and short results you can pipe these in, however you need to deal with the quotations that are put around the dsquery output. Example:
Update: Sept 2020
It looks like all the links to the BSOnPosh module are broken now. Below is the functions that were referenced from there.
ActiveDirectoryRights : CreateChild, DeleteChild
InheritanceType : None
ObjectType : bf967aa8-0de6-11d0-a285-00aa003049e2
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : S-1-5-32-550
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
Here, you can see many of the enumerations are decoded into text, but we have guid's and SID's that may show up without translation. With BSonPosh, there is a function for converting SID's already, though in this case I'm modifying it to handle SID's that do not translate with that code. Combining that with another helper function to decode the GUID's to the ldap display attribute listed in the schema, you can get a result that is more readable like this:
Get-ADACL -distinguishedname "dc=contoso,dc=com" | convert-adacl
ActiveDirectoryRights : ReadProperty, WriteProperty, Delete
InheritanceType : Descendents
ObjectType : msRTCSIP-UserPolicies
InheritedObjectType : user
ObjectFlags : ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType : Allow
IdentityReference : CONTOSO\RTCDomainUserAdmins
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : InheritOnly
Below is the code. One function was changed (ConvertTO-Name). The rest is added to BSActiveDirectory.psm1. It is important to note, that this conversion function creates its own custom PSobject, so it is not longer an ACL that you can play with and try to write back. This was more designed for auditing purposes.
#region Convert-ADACL
function Convert-ADACL
{
<#
.Synopsis
Translates the AD Object ACL to a more readable format by converting SID and GUID values to text
.Description
Translates the AD Object ACL to a more readable format by converting SID and GUID values to tex
.Parameter ACL
ACL Object to Apply
.OUTPUTS
Object
#>
[cmdletbinding()]
Param(
[Parameter(ValueFromPipeline=$true)]
[System.DirectoryServices.ActiveDirectoryAccessRule]$ACL
)
Begin {
$results = @()
}
process {
if ($_.ActiveDirectoryRights -eq "ExtendedRight") {
$myresult = New-Object PSobject -Property @{
ActiveDirectoryRights = $_.ActiveDirectoryRights
InheritanceType = $_.InheritanceType
ObjectType = Convert-GUIDToName -guid $_.objecttype -extended
InheritedObjectType = Convert-GUIDToName -guid $_.inheritedobjecttype
ObjectFlags = $_.ObjectFlags
AccessControlType = $_.accesscontroltype
IdentityReference = ConvertTo-Name -sid $_.identityReference
IsInherited = $_.isinherited
InheritanceFlags = $_.InheritanceFlags
PropagationFlags = $_.PropagationFlags
}
} else {
$myresult = New-Object PSobject -Property @{
ActiveDirectoryRights = $_.ActiveDirectoryRights
InheritanceType = $_.InheritanceType
ObjectType = Convert-GUIDToName -guid $_.objecttype
InheritedObjectType = Convert-GUIDToName -guid $_.inheritedobjecttype
ObjectFlags = $_.ObjectFlags
AccessControlType = $_.accesscontroltype
IdentityReference = ConvertTo-Name -sid $_.identityReference
IsInherited = $_.isinherited
InheritanceFlags = $_.InheritanceFlags
PropagationFlags = $_.PropagationFlags
}
}
$results += $Myresult
}
end {
$results |Select-Object ActiveDirectoryRights,InheritanceType,ObjectType,InheritedObjectType,ObjectFlags,`
AccessControlType,IdentityReference,IsInherited,InheritanceFlags,PropagationFlags
}
}
#endregion
#region ConvertTo-Name
function ConvertTo-Name
{
param($sid)
Write-Verbose $sid
try {
$ID = New-Object System.Security.Principal.SecurityIdentifier($sid)
$User = $ID.Translate( [System.Security.Principal.NTAccount])
$User.Value
} catch {
switch($sid) {
#Reference http://support.microsoft.com/kb/243330
"S-1-0" { "Null Authority" }
"S-1-0-0" { "Nobody" }
"S-1-1" {"World Authority" }
"S-1-1-0" { "Everyone" }
"S-1-2" { "Local Authority" }
"S-1-2-0" { "Local" }
"S-1-2-1" { "Console Logon" }
"S-1-3" { "Creator Authority" }
"S-1-3-0" { "Creator Owner" }
"S-1-3-1" { "Creator Group" }
"S-1-3-4" { "Owner Rights" }
"S-1-5-80-0" {"All Services" }
"S-1-4" { "Non Unique Authority" }
"S-1-5" { "NT Authority" }
"S-1-5-1" { "Dialup" }
"S-1-5-2" { "Network" }
"S-1-5-3" { "Batch" }
"S-1-5-4" { "Interactive" }
"S-1-5-6" { "Service" }
"S-1-5-7" { "Anonymous" }
"S-1-5-9" { "Enterprise Domain Controllers"}
"S-1-5-10" { "Self" }
"S-1-5-11" { "Authenticated Users" }
"S-1-5-12" { "Restricted Code" }
"S-1-5-13" { "Terminal Server Users" }
"S-1-5-14" { "Remote Interactive Logon" }
"S-1-5-15" { "This Organization" }
"S-1-5-17" { "This Organization" }
"S-1-5-18" { "Local System" }
"S-1-5-19" { "NT Authority Local Service" }
"S-1-5-20" { "NT Authority Network Service" }
"S-1-5-32-544" { "Administrators" }
"S-1-5-32-545" { "Users"}
"S-1-5-32-546" { "Guests" }
"S-1-5-32-547" { "Power Users" }
"S-1-5-32-548" { "Account Operators" }
"S-1-5-32-549" { "Server Operators" }
"S-1-5-32-550" { "Print Operators" }
"S-1-5-32-551" { "Backup Operators" }
"S-1-5-32-552" { "Replicators" }
"S-1-5-32-554" { "Pre-Windows 2000 Compatibility Access"}
"S-1-5-32-555" { "Remote Desktop Users"}
"S-1-5-32-556" { "Network Configuration Operators"}
"S-1-5-32-557" { "Incoming forest trust builders"}
"S-1-5-32-558" { "Performance Monitor Users"}
"S-1-5-32-559" { "Performance Log Users" }
"S-1-5-32-560" { "Windows Authorization Access Group"}
"S-1-5-32-561" { "Terminal Server License Servers"}
"S-1-5-32-561" { "Distributed COM Users"}
"S-1-5-32-569" { "Cryptographic Operators" }
"S-1-5-32-573" { "Event Log Readers" }
"S-1-5-32-574" { "Certificate Services DCOM Access" }
"S-1-5-32-575" { "RDS Remote Access Servers" }
"S-1-5-32-576" { "RDS Endpoint Servers" }
"S-1-5-32-577" { "RDS Management Servers" }
"S-1-5-32-575" { "Hyper-V Administrators" }
"S-1-5-32-579" { "Access Control Assistance Operators" }
"S-1-5-32-580" { "Remote Management Users" }
default {$sid}
}
}
}
#endregion
#region Convert-GUIDToName
#helper module to convert schema GUID's to readable names
function Convert-GUIDToName
{
param(
[parameter(mandatory=$true)][string]$guid,
[switch]$extended
)
$guidval = [Guid]$guid
$bytearr = $guidval.tobytearray()
$bytestr = ""
foreach ($byte in $bytearr) {
$str = "\" + "{0:x}" -f $byte
$bytestr += $str
}
if ($extended) {
#for extended rights, we can check in the configuration container
$de = new-object directoryservices.directoryentry("LDAP://" + ([adsi]"LDAP://rootdse").psbase.properties.configurationnamingcontext)
$ds = new-object directoryservices.directorysearcher($de)
$ds.propertiestoload.add("displayname")|Out-Null
$ds.filter = "(rightsguid=$guid)"
$result = $ds.findone()
} else {
#Search schema for possible matches for this GUID
$de = new-object directoryservices.directoryentry("LDAP://" + ([adsi]"LDAP://rootdse").psbase.properties.schemanamingcontext)
$ds = new-object directoryservices.directorysearcher($de)
$ds.filter = "(|(schemaidguid=$bytestr)(attributesecurityguid=$bytestr))"
$ds.propertiestoload.add("ldapdisplayname")|Out-Null
$result = $ds.findone()
}
if ($result -eq $null) {
$guid
} else {
if ($extended) {
$result.properties.displayname
} else {
$result.properties.ldapdisplayname
}
}
}
#endregion
Update: 1/29/2013
Just an additional note. Since you need distinguishednames for the commandlets, this can be a pain at times. If you like to use dsquery for quick and short results you can pipe these in, however you need to deal with the quotations that are put around the dsquery output. Example:
dsquery group -name Mygroup | foreach {$_.replace("`"","")} |
get-adacl | where {$_.isinhertied -eq $false} |convert-adacl
Update: Sept 2020
It looks like all the links to the BSOnPosh module are broken now. Below is the functions that were referenced from there.
function Get-ADACL
{
<#
.Synopsis
Gets ACL object or SDDL for AD Object
.Description
Gets ACL object or SDDL for AD Object
.Parameter DistinguishedName
DistinguishedName of the Object to Get the ACL from
.Parameter SDDL [switch]
If passed it will return the SDDL string
.Example
Get ACL for ‘cn=users,dc=corp,dc=lab’
Get-ADACL ‘cn=users,dc=corp,dc=lab’
Get SDDL for ‘cn=users,dc=corp,dc=lab’
Get-ADACL ‘cn=users,dc=corp,dc=lab’ -sddl
.Outputs
Object
.Link
N/A
.Notes
NAME: Get-ADACL
AUTHOR: YetiCentral\bshell
Website: www.bsonposh.com
#Requires -Version 2.0
#>
[Cmdletbinding()]
Param(
[Alias('dn')]
[ValidatePattern('^((CN|OU)=.*)*(DC=.*)*$')]
[Parameter(ValueFromPipeline=$true,Mandatory=$True)]
[string]$DistinguishedName,
[Parameter()]
[switch]$SDDL
)
Write-Verbose " + Processing Object [$DistinguishedName]"
$DE = [ADSI]"LDAP://$DistinguishedName"
Write-Verbose " - Getting ACL"
$acl = $DE.psbase.ObjectSecurity
if($SDDL)
{
Write-Verbose " - Returning SDDL"
$acl.GetSecurityDescriptorSddlForm([System.Security.AccessControl.AccessControlSections]::All)
}
else
{
Write-Verbose " - Returning ACL Object [System.DirectoryServices.ActiveDirectoryAccessRule]"
$acl.GetAccessRules($true,$true,[System.Security.Principal.SecurityIdentifier])
}
}
Tuesday, February 21, 2012
Converting guid to escaped bytes for LDAP lookups (powershell, AD ACL)
If you have looked at access lists in active directory using get-acl, you may be familiar with this type of entry
ActiveDirectoryRights : CreateChild, DeleteChild
InheritanceType : None
ObjectType : bf967aa8-0de6-11d0-a285-00aa003049e2
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : S-1-5-32-550
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
Given that the ObjectType and occsionally the InheritedObjectType are guid's, it may be difficult to determine what this entry is referring to. You can do an ldap lookup into the schema partition to find what object or attribute this guid is referring to, however the ldap filter for the search needs the guid in binary. .Net comes to the rescue for easy conversion to binary, but this is not sufficient for an ldap search, as it returns a byte array.
You can create a GUID object in powershell by casting $myguid = [guid]"bf967aa8-0de6-11d0-a285-00aa003049e2"
In this object, there is a byte conversion method tobytearray().
For ldap searches, we need the byte array escaped with forward slashes on each byte. To do this you can run the guid through this simple function
function guid-toescapedbyte($guid) {
$bytearr = $guid.tobytearray()
$bytestr = ""
foreach ($byte in $bytearr) {
$str = "\" + "{0:x}" -f $byte
$bytestr += $str
}
return $bytestr
}
In our example we will get this:
guid-toescapedbyte([guid]"bf967aa8-0de6-11d0-a285-00aa003049e2")
\a8\7a\96\bf\e6\d\d0\11\a2\85\0\aa\0\30\49\e2
We can add this to a filter like this:
$de = new-object directoryservices.directoryentry("LDAP://cn=schema,cn=configuration,dc=contoso,dc=com")
$ds = new-object directoryservices.directorysearcher($de)
$bytestr = guid-toescapedbyte [guid]"bf967aa8-0de6-11d0-a285-00aa003049e2"
$ds.filter = "(|(schemaidguid=$bytestr)(attributesecurityguid=$bytestr))"
$ds.findone().properties
Name Value
---- -----
systemmustcontain {versionNumber, uNCName, shortServerName, ser...
admindisplayname {Print-Queue}
name {Print-Queue}
objectguid {184 69 64 30 219 21 163 78 168 107 59 106 18...
systemonly {False}
whencreated {10/21/1630 4:21:11 PM}
defaultobjectcategory {CN=Print-Queue,CN=Schema,CN=Configuration,DC...
systemflags {16}
ldapdisplayname {printQueue}
usnchanged {4748}
objectcategory {CN=Class-Schema,CN=Schema,CN=Configuration,D...
systemposssuperiors {organizationalUnit, domainDNS, container, co...
showinadvancedviewonly {True}
defaultsecuritydescriptor {D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RP...
instancetype {4}
distinguishedname {CN=Print-Queue,CN=Schema,CN=Configuration,DC...
cn {Print-Queue}
dscorepropagationdata {1/1/1601 12:00:00 AM}
objectclass {top, classSchema}
defaulthidingvalue {False}
usncreated {4748}
rdnattid {cn}
objectclasscategory {1}
systemmaycontain {priority, printStatus, printStartTime, print...
schemaidguid {168 122 150 191 230 13 208 17 162 133 0 170 ...
subclassof {connectionPoint}
whenchanged {6/11/2010 5:23:32 PM}
governsid {1.2.840.113556.1.5.23}
admindescription {Print-Queue}
adspath {LDAP://CN=Print-Queue,CN=Schema,CN=Configura...
And we can see from our results that our ACL is related to print queue child objects. If we translate the SID, we will see this is the print operators builtin group.
ActiveDirectoryRights : CreateChild, DeleteChild
InheritanceType : None
ObjectType : bf967aa8-0de6-11d0-a285-00aa003049e2
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : S-1-5-32-550
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
Given that the ObjectType and occsionally the InheritedObjectType are guid's, it may be difficult to determine what this entry is referring to. You can do an ldap lookup into the schema partition to find what object or attribute this guid is referring to, however the ldap filter for the search needs the guid in binary. .Net comes to the rescue for easy conversion to binary, but this is not sufficient for an ldap search, as it returns a byte array.
You can create a GUID object in powershell by casting $myguid = [guid]"bf967aa8-0de6-11d0-a285-00aa003049e2"
In this object, there is a byte conversion method tobytearray().
For ldap searches, we need the byte array escaped with forward slashes on each byte. To do this you can run the guid through this simple function
function guid-toescapedbyte($guid) {
$bytearr = $guid.tobytearray()
$bytestr = ""
foreach ($byte in $bytearr) {
$str = "\" + "{0:x}" -f $byte
$bytestr += $str
}
return $bytestr
}
In our example we will get this:
guid-toescapedbyte([guid]"bf967aa8-0de6-11d0-a285-00aa003049e2")
\a8\7a\96\bf\e6\d\d0\11\a2\85\0\aa\0\30\49\e2
We can add this to a filter like this:
$de = new-object directoryservices.directoryentry("LDAP://cn=schema,cn=configuration,dc=contoso,dc=com")
$ds = new-object directoryservices.directorysearcher($de)
$bytestr = guid-toescapedbyte [guid]"bf967aa8-0de6-11d0-a285-00aa003049e2"
$ds.filter = "(|(schemaidguid=$bytestr)(attributesecurityguid=$bytestr))"
$ds.findone().properties
Name Value
---- -----
systemmustcontain {versionNumber, uNCName, shortServerName, ser...
admindisplayname {Print-Queue}
name {Print-Queue}
objectguid {184 69 64 30 219 21 163 78 168 107 59 106 18...
systemonly {False}
whencreated {10/21/1630 4:21:11 PM}
defaultobjectcategory {CN=Print-Queue,CN=Schema,CN=Configuration,DC...
systemflags {16}
ldapdisplayname {printQueue}
usnchanged {4748}
objectcategory {CN=Class-Schema,CN=Schema,CN=Configuration,D...
systemposssuperiors {organizationalUnit, domainDNS, container, co...
showinadvancedviewonly {True}
defaultsecuritydescriptor {D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RP...
instancetype {4}
distinguishedname {CN=Print-Queue,CN=Schema,CN=Configuration,DC...
cn {Print-Queue}
dscorepropagationdata {1/1/1601 12:00:00 AM}
objectclass {top, classSchema}
defaulthidingvalue {False}
usncreated {4748}
rdnattid {cn}
objectclasscategory {1}
systemmaycontain {priority, printStatus, printStartTime, print...
schemaidguid {168 122 150 191 230 13 208 17 162 133 0 170 ...
subclassof {connectionPoint}
whenchanged {6/11/2010 5:23:32 PM}
governsid {1.2.840.113556.1.5.23}
admindescription {Print-Queue}
adspath {LDAP://CN=Print-Queue,CN=Schema,CN=Configura...
And we can see from our results that our ACL is related to print queue child objects. If we translate the SID, we will see this is the print operators builtin group.
Subscribe to:
Posts (Atom)