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.

#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

Powershell overlapping pipeline problem

During the recent Microsoft 2012 scripting games, I encountered an interesting problem which really threw me off for a few hours. When trying to link up WMI results with registry entries in the Advanced 8 event, I ended up with a lot of Get-ItemProperty failures, where the values being read in my registry access where actually results from my WMI lookups. Here is a sample of the code

function get-physicalphysical {
     param(  [parameter(position=0)][string]$nicGUID   )
    $vals = Get-ChildItem hklm:"\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}" |
          get-itemproperty -name $_.name | where {$_.netcfginstanceid -match $nicGuid}
    if ($vals.characteristics -eq 0x84) { return $true } else { return $false }
}

$nics = Get-WmiObject -Class Win32_NetworkAdapter -Filter "PhysicalAdapter = True" |
where {get-physicalphysical $($_.guid)}

So we have GWMI for network adapters piped to a function called get-physicalphysical.  The guid of the WMI network adapter result is searched in the registry for lower level details that are not available via WMI.  The error we get is something like this (repeating many times and for different adapter names)

Get-ItemProperty : Property Intel(R) 82567LM Gigabit Network Connection does not exist at path HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000.
At line:11 char:25
+         get-itemproperty <<<<  -name $_.name | where {$_.netcfginstanceid -ma
tch $nicGuid}
    + CategoryInfo          : InvalidArgument: (Intel(R) 82567L...work Connect
   ion:String) [Get-ItemProperty], PSArgumentException
    + FullyQualifiedErrorId : System.Management.Automation.PSArgumentException
   ,Microsoft.PowerShell.Commands.GetItemPropertyCommand

In this case, the WMI results have a property called Name, and the entries in the registry that we were looking at also have a value for Name.  What we want is the name of the registry key that contains the configurations for the adapter.  But with the use of two pipelines, it appears that the $_ referenced in the pipeline within the function is accessing the pipeline $_ from outside of the function.  I'm not expert in low level powershell details and how the pipeline works, but after playing around a bit with trying to scope the $_ variable, and eventually reading the about_functions help, I found that you can scope a function.  By scoping the function and the $_ variable within it (using the same scope), I was able to separate the two pipelines and accomplish what I was hoping for.  You can see the full code at the entry script.

AD Powershell module and managing multiple domains

One of the things I have noticed every time I try using the Microsoft AD powershell commandlets is that they are not very multi-domain friendly. Most of the commandlets have a -server option where you can point to a server. To do this dynamically, you need to discover a DC with Get-ADDomainController first. However, today I was thinking it would be nice to update permissions cross domain with get-acl/set-acl. Unfortunately, there is no -server option here. From the examples I have seen for managing AD permissions with these two, it uses the AD: PSdrive that gets created when the ActiveDirectory Module is loaded. This default drive points to the domain that your machine is a member of, so this may not be helpful. If you try to use get-acl with this drive and point to a distinguishedName in another domain you will see an error like this:

Get-Acl : A referral was returned from the server

Since AD: is a PSDrive, there is no reason you can't add some more for other domains. Lets say you have two domains, contoso.com and child.contoso.com

New-PSDrive -Name "Child" -Root "" -PsProvider ActiveDirectory -server (Get-ADDomainController -domain child.contoso.com -discover -writable).name

This will create a PSDrive called Child:, which will reference this domain. So to work with get-acl you can reference child:"objectdn" to get the acl. For other commandlets, set-location child: and try using these to access objects in it.

If you wanted to auto-create a drive for every domain in your forest you could do this easily (though a bit slowly). PSDrive names are limited in that they cannot contain '.', so in this example I'm just stripping a domain's first portion of its name out:

(get-adforest).domains|foreach {$temp = $_.substring(0,$_.indexof('.')); New-PSDrive -Name $temp -Root "" -PsProvider ActiveDirectory -server (Get-AD
DomainController -domain $_ -discover -writable).name}

Update:

After trying to work with the Microsoft AD powershell module for this, and having a lot of problems in a mixed 2008/2003 multidomain environment, I ran into the BSonPosh module. This has a much simpler way of reading and writing ACL's in AD which looks like it will run very easily in a multidomain environement, or non-2008 AD domain. I have a extension to the module to Decode AD ACL.

Checking NIC for collisions (speed/duplex mismatch)

This is an old powershell v1 script that I came up with quite a long time ago. I'm sure it can be modified for easier and more robust usage. Since network card settings in the registry can be difficult to decode between vendors, the best way to look for speed/duplex issues is looking at collisions. Microsoft systems are not very details on networking errors, but they do keep track of this type of problem and it is available WMI. The script below pieces together two WMI classes to get the speed setting and looks for collisions.

Results in PSObject array of all NIC's

Computername        NicName                       LinkSpeed          Collisions
------------        -------                       ---------          ----------
MyComputer          Intel(R) PRO/100...                 100                   0

function get-NicError ([string]$server) {
 #This function uses WMI queries against the target machine to get link speed information and
 #check for any recorded network collissions.  It combines the two queries to print out collisions
 #per adapter with link speed.

 if ([string]::IsNullOrEmpty($server)) {
  write-host -foregroundcolor "yellow"  "Usage: get-NicError servername"
  write-host -foregroundcolor "yellow"  "   Get speed and collision details for network adapters"
  return
 }

 $result = @()

 $a = gwmi -namespace root\wmi -class msndis_ethernetmoretransmitcollisions -computername $server |select-object instancename,ndisethernetmoretransmitcollisions
 $b = gwmi -namespace root\wmi -class msndis_linkspeed -computername $server | select-object instancename,ndislinkspeed 

 if (($a -eq $null) -or ($b -eq $null)) {
  write-error "WMI connection error"
  return 
 }

 foreach ($link in $b) {
  $link.ndislinkspeed = $link.ndislinkspeed / 10000
 }

 foreach ($item in $a) {
   foreach ($seconditem in $b) {
    if ($item.instancename -eq $seconditem.instancename) {
      $myres = New-Object psobject
     Add-Member -InputObject $myres NoteProperty Computername $server
     Add-Member -InputObject $myres Noteproperty NicName $item.instancename
     Add-Member -InputObject $myres Noteproperty LinkSpeed $seconditem.ndislinkspeed
     Add-Member -InputObject $myres Noteproperty Collisions $item.ndisethernetmoretransmitcollisions
     $result += $myres
    }
   }
 }

 return $result
   
}

Crazy uptime (windows 2000 domain controller)

C:\>uptime
\\SRVNAMECHANGED has been up for: 2111 day(s), 10 hour(s), 31 minute(s), 52 second(s)

Anyone got a datacenter and server that stable?  This is a Dell PE2650 with windows 2000, which also has 0 hardware problems. 

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.

Is belief enough