Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Delegation Of Control’ Category

(2014-09-13) PowerShell And DACLs In AD: Checking For Correct Canonical Order Of DACL

Posted by Jorge on 2014-09-13


PowerShell Code to check if the DACL of each OU in the AD domain is in canonical order or not.

Also see this blog post.

# Clear The Screen Clear-Host # Get The UI Config $uiConfig = (Get-Host).UI.RawUI $uiConfig.ForegroundColor = "Yellow" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Get List Of OUs In AD Domain $listOfOUsToProcess = Get-ADOrganizationalUnit -Filter * | %{$_.DistinguishedName} # Process Each OU $OUsWithDACLInCanonicalOrder = @() $OUsWithDACLNOTInCanonicalOrder = @() $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) $aclOU = Get-Acl $ouDrivePath If ($aclOU.AreAccessRulesCanonical) { $ouObj = "" | Select "List Of OUs That DO Have The DACL In Canonical Order" $ouObj."List Of OUs That DO Have The DACL In Canonical Order" = $ou $OUsWithDACLInCanonicalOrder += $ouObj } If (!$aclOU.AreAccessRulesCanonical) { $ouObj = "" | Select "List Of OUs That DO NOT Have The DACL In Canonical Order" $ouObj."List Of OUs That DO NOT Have The DACL In Canonical Order" = $ou $OUsWithDACLNOTInCanonicalOrder += $ouObj } } $uiConfig.ForegroundColor = "Red" If ($OUsWithDACLNOTInCanonicalOrder.Count -eq 0) { $ouObj = "" | Select "List Of OUs That DO NOT Have The DACL In Canonical Order" $ouObj."List Of OUs That DO NOT Have The DACL In Canonical Order" = "+++ NONE +++" $OUsWithDACLNOTInCanonicalOrder += $ouObj } $OUsWithDACLNOTInCanonicalOrder | FT -Autosize $uiConfig.ForegroundColor = "Green" If ($OUsWithDACLInCanonicalOrder.Count -eq 0) { $ouObj = "" | Select "List Of OUs That DO NOT Have The DACL In Canonical Order" $ouObj."List Of OUs That DO NOT Have The DACL In Canonical Order" = "+++ NONE +++" $OUsWithDACLInCanonicalOrder += $ouObj } $OUsWithDACLInCanonicalOrder | FT -Autosize $uiConfig.ForegroundColor = "Yellow"

SNAGHTML322b396a

Figure 1: Checking The Canonical Order Of The DACL On All OUs In The AD Domain Through PowerShell

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 6 Comments »

(2014-08-28) PowerShell And DACLs In AD: Removing All ACEs On Some Object

Posted by Jorge on 2014-08-28


PowerShell Code to remove all ACEs from one or multiple OUs for some security principal.

Example security principal: ADCORP\MyDelegationAdminGroup

# Clear The Screen Clear-Host # Get Script Location $scriptFolder = (Get-Location).Path # Get File With OUs To Process $fileWithListOfOUsToProcess = "List-Of-OUs-To-Process-For-Delegations.txt" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Get List Of OUs To Process $listOfOUsToProcess = Get-Content $($scriptFolder + "\" + $fileWithListOfOUsToProcess) # Security Principal To Assign Permissions To $securityPrincipalAccount = "ADCORP\MyDelegatedAdminGroup" # Process Each OU $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) Write-Host "" Write-Host "Processing OU: $ou" -Foregroundcolor Cyan Write-Host " REMOVING ACEs..." Write-Host " Security Principal...: $securityPrincipalAccount" Write-Host "" $aclOU = Get-Acl $ouDrivePath $aclOU.Access | ?{$_.IdentityReference -eq $securityPrincipalAccount} | %{ $accessRule = $_ $aclOU.RemoveAccessRule($accessRule) } $aclOU | Set-Acl $ouDrivePath }

image

Figure 1: DACL Before Removal

If the removal action outputs "True", it means it found the ACE and it was removed. If the removal action outputs "False", it means it did not find the ACE and nothing was removed. 

image

Figure 2: Configuring The DACL Through PowerShell

image

Figure 3: DACL After Removal

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 3 Comments »

(2014-08-26) PowerShell And DACLs In AD: Removing ACE For Some Extended Right On Some Object

Posted by Jorge on 2014-08-26


PowerShell Code to remove an ACE from one or multiple OUs for some security principal to some extended right (control access right) on some object.

Example object class: user

Example extended right: Reset Password

Example security principal: ADCORP\MyDelegationAdminGroup

# Clear The Screen Clear-Host # Get Script Location $scriptFolder = (Get-Location).Path # Get File With OUs To Process $fileWithListOfOUsToProcess = "List-Of-OUs-To-Process-For-Delegations.txt" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Create Hash Table With The lDAPDisplayName And schemaIDGUID Of Each Schema Class And Attribute $mappingTable_lDAPDisplayName_schemaIDGUID = @{} Get-ADObject -SearchBase ($rootDSE.schemaNamingContext) ` -LDAPFilter "(schemaIDGUID=*)" ` -Properties lDAPDisplayName,schemaIDGUID | %{ $mappingTable_lDAPDisplayName_schemaIDGUID[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID } # Create Hash Table With The displayName And rightsGUID Of Each Extended Right (a.k.a. Control Access Right) $mappingTable_displayName_rightsGUID = @{} Get-ADObject -SearchBase $("CN=Extended-Rights," + $rootdse.ConfigurationNamingContext) ` -LDAPFilter "(&(objectClass=controlAccessRight)(rightsguid=*))" ` -Properties displayName,rightsGuid | %{ $mappingTable_displayName_rightsGUID[$_.displayName]=[System.GUID]$_.rightsGuid } # Get List Of OUs To Process $listOfOUsToProcess = Get-Content $($scriptFolder + "\" + $fileWithListOfOUsToProcess) # Object Class And Attribute To Assign Permissions For $scopedObject = "user" $schemaIDGUIDScopedObject = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedObject] $scopedCAR = "Reset Password" $schemaIDGUIDScopedCAR = $mappingTable_displayName_rightsGUID[$scopedCAR] $inheritanceScope = "Descendents" # Security Principal To Assign Permissions To $securityPrincipalAccount = "ADCORP\MyDelegatedAdminGroup" $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount) # Define ACE $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"ExtendedRight" $aclType = [System.Security.AccessControl.AccessControlType]::"Allow" $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedCAR,$inheritanceScope,$schemaIDGUIDScopedObject $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition) # Process Each OU $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) Write-Host "" Write-Host "Processing OU: $ou" -Foregroundcolor Cyan Write-Host " REMOVING ACE..." Write-Host " Security Principal...: $securityPrincipalAccount" Write-Host " ACL Type.............: $aclType" Write-Host " Access Type..........: $rightsCollection" Write-Host " Scoped CAR...........: $scopedCAR" Write-Host " Scoped Object Class..: $scopedObject" Write-Host " Scope................: $inheritanceScope" Write-Host "" $aclOU = Get-Acl $ouDrivePath $aclOU.RemoveAccessRule($accessRule) $aclOU | Set-Acl $ouDrivePath }

image

Figure 1: DACL Before Removal

If the removal action outputs "True", it means it found the ACE and it was removed. If the removal action outputs "False", it means it did not find the ACE and nothing was removed. 

image

Figure 2: Configuring The DACL Through PowerShell

image

Figure 3: DACL After Removal

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 4 Comments »

(2014-08-24) PowerShell And DACLs In AD: Removing ACE For Write Property On Some Object

Posted by Jorge on 2014-08-24


PowerShell Code to remove a specific ACE from one or multiple OUs for some security principal on some object.

Example object class: user

Example permission: Write Property

Example attribute: employeeID

Example security principal: ADCORP\MyDelegationAdminGroup

# Clear The Screen Clear-Host # Get Script Location $scriptFolder = (Get-Location).Path # Get File With OUs To Process $fileWithListOfOUsToProcess = "List-Of-OUs-To-Process-For-Delegations.txt" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Create Hash Table With The lDAPDisplayName And schemaIDGUID Of Each Schema Class And Attribute $mappingTable_lDAPDisplayName_schemaIDGUID = @{} Get-ADObject -SearchBase $($rootDSE.schemaNamingContext) ` -LDAPFilter "(schemaIDGUID=*)" ` -Properties lDAPDisplayName,schemaIDGUID | %{ $mappingTable_lDAPDisplayName_schemaIDGUID[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID } # Get List Of OUs To Process $listOfOUsToProcess = Get-Content $($scriptFolder + "\" + $fileWithListOfOUsToProcess) # Object Class And Attribute To Assign Permissions For $scopedObject = "user" $schemaIDGUIDScopedObject = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedObject] $scopedAttribute = "employeeID" $schemaIDGUIDScopedAttribute = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedAttribute] $inheritanceScope = "Descendents" # Security Principal To Assign Permissions To $securityPrincipalAccount = "ADCORP\MyDelegatedAdminGroup" $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount) # Define ACE $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"WriteProperty" $aclType = [System.Security.AccessControl.AccessControlType]::"Allow" $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedAttribute,$inheritanceScope,$schemaIDGUIDScopedObject $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition) # Process Each OU $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) Write-Host "" Write-Host "Processing OU: $ou" -Foregroundcolor Cyan Write-Host " REMOVING ACE..." Write-Host " Security Principal...: $securityPrincipalAccount" Write-Host " ACL Type.............: $aclType" Write-Host " Access Type..........: $rightsCollection" Write-Host " Scoped Attribute.....: $scopedAttribute" Write-Host " Scoped Object Class..: $scopedObject" Write-Host " Scope................: $inheritanceScope" Write-Host "" $aclOU = Get-Acl $ouDrivePath $aclOU.RemoveAccessRule($accessRule) $aclOU | Set-Acl $ouDrivePath }

image

Figure 1: DACL Before Removal

If the removal action outputs "True", it means it found the ACE and it was removed. If the removal action outputs "False", it means it did not find the ACE and nothing was removed. 

image

Figure 2: Configuring The DACL Through PowerShell

image

Figure 3: DACL After Removal

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 5 Comments »

(2014-08-22) PowerShell And DACLs In AD: Removing ACE For Delete Some Object

Posted by Jorge on 2014-08-22


PowerShell Code to remove a specific ACE from one or multiple OUs for some security principal on some object.

Example object class: user

Example permission: Delete Child

Example security principal: ADCORP\MyDelegationAdminGroup

# Clear The Screen Clear-Host # Get Script Location $scriptFolder = (Get-Location).Path # Get File With OUs To Process $fileWithListOfOUsToProcess = "List-Of-OUs-To-Process-For-Delegations.txt" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Create Hash Table With The lDAPDisplayName And schemaIDGUID Of Each Schema Class And Attribute $mappingTable_lDAPDisplayName_schemaIDGUID = @{} Get-ADObject -SearchBase $($rootDSE.schemaNamingContext) ` -LDAPFilter "(schemaIDGUID=*)" ` -Properties lDAPDisplayName,schemaIDGUID | %{ $mappingTable_lDAPDisplayName_schemaIDGUID[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID } # Get List Of OUs To Process $listOfOUsToProcess = Get-Content $($scriptFolder + "\" + $fileWithListOfOUsToProcess) # Object Class And Attribute To Assign Permissions For $scopedObject = "user" $schemaIDGUIDScopedObject = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedObject] $inheritanceScope = "All" # Security Principal To Assign Permissions To $securityPrincipalAccount = "ADCORP\MyDelegatedAdminGroup" $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount) # Define ACE $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"DeleteChild" $aclType = [System.Security.AccessControl.AccessControlType]::"Allow" $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedObject,$inheritanceScope $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition) # Process Each OU $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) Write-Host "" Write-Host "Processing OU: $ou" -Foregroundcolor Cyan Write-Host " REMOVING ACE..." Write-Host " Security Principal...: $securityPrincipalAccount" Write-Host " ACL Type.............: $aclType" Write-Host " Access Type..........: $rightsCollection" Write-Host " Scoped Object Class..: $scopedObject" Write-Host " Scope................: $inheritanceScope" Write-Host "" $aclOU = Get-Acl $ouDrivePath $aclOU.RemoveAccessRule($accessRule) $aclOU | Set-Acl $ouDrivePath }

image

Figure 1: DACL Before Removal

If the removal action outputs "True", it means it found the ACE and it was removed. If the removal action outputs "False", it means it did not find the ACE and nothing was removed. 

image

Figure 2: Configuring The DACL Through PowerShell

image

Figure 3: DACL After Removal

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 3 Comments »

(2014-08-20) PowerShell And DACLs In AD: Adding ACE For Some Extended Right On Some Object

Posted by Jorge on 2014-08-20


PowerShell Code to add an ACE to one or multiple OUs for some security principal to some extended right (control access right) on some object.

Example object class: user

Example extended right: Reset Password

Example security principal: ADCORP\MyDelegationAdminGroup

# Clear The Screen Clear-Host # Get Script Location $scriptFolder = (Get-Location).Path # Get File With OUs To Process $fileWithListOfOUsToProcess = "List-Of-OUs-To-Process-For-Delegations.txt" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Create Hash Table With The lDAPDisplayName And schemaIDGUID Of Each Schema Class And Attribute $mappingTable_lDAPDisplayName_schemaIDGUID = @{} Get-ADObject -SearchBase ($rootDSE.schemaNamingContext) ` -LDAPFilter "(schemaIDGUID=*)" ` -Properties lDAPDisplayName,schemaIDGUID | %{ $mappingTable_lDAPDisplayName_schemaIDGUID[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID } # Create Hash Table With The displayName And rightsGUID Of Each Extended Right (a.k.a. Control Access Right) $mappingTable_displayName_rightsGUID = @{} Get-ADObject -SearchBase $("CN=Extended-Rights," + $rootdse.ConfigurationNamingContext) ` -LDAPFilter "(&(objectClass=controlAccessRight)(rightsguid=*))" ` -Properties displayName,rightsGuid | %{ $mappingTable_displayName_rightsGUID[$_.displayName]=[System.GUID]$_.rightsGuid } # Get List Of OUs To Process $listOfOUsToProcess = Get-Content $($scriptFolder + "\" + $fileWithListOfOUsToProcess) # Object Class And Attribute To Assign Permissions For $scopedObject = "user" $schemaIDGUIDScopedObject = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedObject] $scopedCAR = "Reset Password" $schemaIDGUIDScopedCAR = $mappingTable_displayName_rightsGUID[$scopedCAR] $inheritanceScope = "Descendents" # Security Principal To Assign Permissions To $securityPrincipalAccount = "ADCORP\MyDelegatedAdminGroup" $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount) # Define ACE $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"ExtendedRight" $aclType = [System.Security.AccessControl.AccessControlType]::"Allow" $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedCAR,$inheritanceScope,$schemaIDGUIDScopedObject $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition) # Process Each OU $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) Write-Host "" Write-Host "Processing OU: $ou" -Foregroundcolor Cyan Write-Host " ADDING ACE..." Write-Host " Security Principal...: $securityPrincipalAccount" Write-Host " ACL Type.............: $aclType" Write-Host " Access Type..........: $rightsCollection" Write-Host " Scoped CAR...........: $scopedCAR" Write-Host " Scoped Object Class..: $scopedObject" Write-Host " Scope................: $inheritanceScope" Write-Host "" $aclOU = Get-Acl $ouDrivePath $aclOU.AddAccessRule($accessRule) $aclOU | Set-Acl $ouDrivePath }

image

Figure 1: Configuring The DACL Through PowerShell

image

Figure 2: The ACE That Was Added

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 3 Comments »

(2014-08-18) PowerShell And DACLs In AD: Adding ACE For Read/Write Property On Some Object

Posted by Jorge on 2014-08-18


PowerShell Code to add an ACE to one or multiple OUs for some security principal to have read/write permissions for some attribute on some object.

Example object class: user

Example permission: Read Property and Write Property

Example attribute: employeeID

Example security principal: ADCORP\MyDelegationAdminGroup

# Clear The Screen Clear-Host # Get Script Location $scriptFolder = (Get-Location).Path # Get File With OUs To Process $fileWithListOfOUsToProcess = "List-Of-OUs-To-Process-For-Delegations.txt" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Create Hash Table With The lDAPDisplayName And schemaIDGUID Of Each Schema Class And Attribute $mappingTable_lDAPDisplayName_schemaIDGUID = @{} Get-ADObject -SearchBase $($rootDSE.schemaNamingContext) ` -LDAPFilter "(schemaIDGUID=*)" ` -Properties lDAPDisplayName,schemaIDGUID | %{ $mappingTable_lDAPDisplayName_schemaIDGUID[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID } # Get List Of OUs To Process $listOfOUsToProcess = Get-Content $($scriptFolder + "\" + $fileWithListOfOUsToProcess) # Object Class And Attribute To Assign Permissions For $scopedObject = "user" $schemaIDGUIDScopedObject = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedObject] $scopedAttribute = "employeeID" $schemaIDGUIDScopedAttribute = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedAttribute] $inheritanceScope = "Descendents" # Security Principal To Assign Permissions To $securityPrincipalAccount = "ADCORP\MyDelegatedAdminGroup" $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount) # Define ACE $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"ReadProperty","WriteProperty" $aclType = [System.Security.AccessControl.AccessControlType]::"Allow" $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedAttribute,$inheritanceScope,$schemaIDGUIDScopedObject $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition) # Process Each OU $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) Write-Host "" Write-Host "Processing OU: $ou" -Foregroundcolor Cyan Write-Host " ADDING ACE..." Write-Host " Security Principal...: $securityPrincipalAccount" Write-Host " ACL Type.............: $aclType" Write-Host " Access Type..........: $rightsCollection" Write-Host " Scoped Attribute.....: $scopedAttribute" Write-Host " Scoped Object Class..: $scopedObject" Write-Host " Scope................: $inheritanceScope" Write-Host "" $aclOU = Get-Acl $ouDrivePath $aclOU.AddAccessRule($accessRule) $aclOU | Set-Acl $ouDrivePath }

image

Figure 1: Configuring The DACL Through PowerShell

image

Figure 2: The ACE That Was Added

image

Figure 3: Detailed Info Of The ACE

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 3 Comments »

(2014-08-16) PowerShell And DACLs In AD: Adding ACE For Create/Delete Some Object

Posted by Jorge on 2014-08-16


PowerShell Code to add an ACE to one or multiple OUs for some security principal to have create/delete permissions for some object.

Example object class: user

Example permission: Create Child and Delete Child

Example security principal: ADCORP\MyDelegationAdminGroup

# Clear The Screen Clear-Host # Get Script Location $scriptFolder = (Get-Location).Path # Get File With OUs To Process $fileWithListOfOUsToProcess = "List-Of-OUs-To-Process-For-Delegations.txt" # Import The Required Module Import-Module ActiveDirectory #Get The RootDSE Info $rootDSE = Get-ADRootDSE # Create Hash Table With The lDAPDisplayName And schemaIDGUID Of Each Schema Class And Attribute $mappingTable_lDAPDisplayName_schemaIDGUID = @{} Get-ADObject -SearchBase $($rootDSE.schemaNamingContext) ` -LDAPFilter "(schemaIDGUID=*)" ` -Properties lDAPDisplayName,schemaIDGUID | %{ $mappingTable_lDAPDisplayName_schemaIDGUID[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID } # Get List Of OUs To Process $listOfOUsToProcess = Get-Content $($scriptFolder + "\" + $fileWithListOfOUsToProcess) # Object Class And Attribute To Assign Permissions For $scopedObject = "user" $schemaIDGUIDScopedObject = $mappingTable_lDAPDisplayName_schemaIDGUID[$scopedObject] $inheritanceScope = "All" # Security Principal To Assign Permissions To $securityPrincipalAccount = "ADCORP\MyDelegatedAdminGroup" $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount) # Define ACE $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"CreateChild","DeleteChild" $aclType = [System.Security.AccessControl.AccessControlType]::"Allow" $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedObject,$inheritanceScope $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition) # Process Each OU $listOfOUsToProcess | %{ $ou = $_ $ouDrivePath = $("AD:\" + $ou) Write-Host "" Write-Host "Processing OU: $ou" -Foregroundcolor Cyan Write-Host " ADDING ACE..." Write-Host " Security Principal...: $securityPrincipalAccount" Write-Host " ACL Type.............: $aclType" Write-Host " Access Type..........: $rightsCollection" Write-Host " Scoped Object Class..: $scopedObject" Write-Host " Scope................: $inheritanceScope" Write-Host "" $aclOU = Get-Acl $ouDrivePath $aclOU.AddAccessRule($accessRule) $aclOU | Set-Acl $ouDrivePath }

image

Figure 1: Configuring The DACL Through PowerShell

image

Figure 2: The ACE That Was Added

The PowerShell code for this script is included in a ZIP file. The ZIP file can be download from here.

The ZIP file contains all the scripts for the following blogs posts:

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

 

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, PowerShell, Tooling/Scripting | 3 Comments »

(2014-08-04) Incorrectly Ordered Permissions After Removing ACE With LDP

Posted by Jorge on 2014-08-04


I was testing something in my test environment, based upon W2K12R2, regarding the confidentiality bit and the required permissions. I had created a PowerShell script to apply the required permissions on every OU in scope for the assigned trustee. The PowerShell script works great. As you may know both DSACLS and LDP are other tools that can be used to configure the required CONTROL_ACCESS extended right. After configuring the permissions through the PowerShell, I then used LDP to remove the ACE that was configured. Rerunning the PowerShell script resulted in the error as shown below.

image

Figure 1: Error Thrown By PowerShell Because Of Incorrectly Ordered Permissions

Exception calling "SetAccessRule" with "1" argument(s): "This access control list is not in canonical form and therefore cannot be modified."
At line:8 char:1
+ $aclOU.SetAccessRule($AccessRule)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : InvalidOperationException

That was weird, the script just worked correctly in the previous run. After checking the permissions with ADUC or ADSIEDIT, I got the following message: "The permissions on Users are incorrectly ordered, which may cause some entries to be ineffective"

image

Figure 2: Warning Thrown By Active Directory Users And Computers (ADUC) Because Of Incorrectly Ordered Permissions

If CANCEL is clicked, nothing is changed and you will be able to view the permissions in read-only mode. You will not be able to change anything.

If REORDER is clicked, the permissions are reordered and reapplied correctly. You will now be able to change anything you like.

Funny enough if you use LDP to add an ACE, the issue does not occur. Removing an existing ACE results in this error/warning. After some testing I also found out it does not occur on every OU. Even some more testing proved this to occur when having a large number of explicit ACEs on an OU.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Active Directory Users And Computers, ADSIEDIT, Delegation Of Control, LDP, PowerShell | 3 Comments »

(2013-10-21) Delegating The Configuration Of "Trusted For Delegation" In AD

Posted by Jorge on 2013-10-21


The constrained delegation extension allows a service to obtain service tickets (under the delegated user’s identity) to a restricted list of other services running on specific servers on the network after it has been presented with a service ticket, which may be a service ticket obtained through protocol transition. Constrained delegation provides a way for domain administrators to limit the network resources that a service trusted for delegation can access to a restricted list of network resources. This is accomplished by configuring the account under which the service is running to be trusted for delegation to a specific instance of a service running on a specific computer or to a set of specific instances of services running on specific computers.

When working with Kerberos Constrained Delegation (KCD), you need to configure service principal names, configure the "trusted for delegation" flag, choose authentication protocols used and configure the services on servers for which the account is allowed to perform delegation. If you as an engineer want to delegate this to an operational admin, you need to configure this accordingly in AD. This blog post will help you understand the delegations needed for specific tasks. Depending on the environment it may be possible you need to configure the delegated permissions to different (groups of) administrators that manage a different scope of objects in AD. In the latter case you need to duplicate the delegation configuration for every set of scoped objects. In this blog post the assumption is made that "Active Directory Users And Computers" MMC is used. Permissions are also configured at OU level for the accounts in that OU. Although this applies to both targeted computer or user accounts, in this blog post I’m focusing on user accounts.

To be able to configure Kerberos (Constrained) Delegation, you must first configure at least one Service Principal Name (SPN) on the account for which delegation is being configured. However, to be able to configure a Service Principal Name you need to have at least "Allow:Read" and "Allow:Write" permissions for the "servicePrincipalName" attribute on the account.

To configure those permissions you can use the following command:

DSACLS "<Distinguished Name of OU>" /G "<Group Or User Account>:RPWP;servicePrincipalName;user" /I:S

(e.g. DSACLS "OU=TEST,OU=Org-Users,DC=ADCORP,DC=LAB" /G "ADCORP\ADM_R1_00:RPWP;servicePrincipalName;user" /I:S)

After the permissions have been configured you can configure an SPN through the Attribute Editor in ADUC or through some other tool.

As soon as you have done that, the Delegation TAB will appear as shown below.

image

Figure 1: The Delegation TAB After Configuring A Service Principal Name

As you can see in figure 1, you have 4 options you can configure, being:

  1. Trust This User For Delegation To Any Service (Kerberos Only)
  2. Trust This User For Delegation To Specified Services Only – Use Kerberos Only
  3. Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol
  4. Do Not Trusted This User For Delegation

[1]

To configure the option "Trust This User For Delegation To Any Service (Kerberos Only)", you must enable the bit called "TRUSTED_FOR_DELEGATION" on the "userAccountControl" attribute. That bit is enabled by setting the decimal value "524288" or hexadecimal value "0x80000" in addition to whatever value is already configured for the "userAccountControl" attribute.

So, you need to have at least "Allow:Read" and "Allow:Write" permissions for the "userAccountControl" attribute on the account.

To configure those permissions you can use the following command:

DSACLS "<Distinguished Name of OU>" /G "<Group Or User Account>:RPWP;userAccountControl;user" /I:S

(e.g. DSACLS "OU=TEST,OU=Org-Users,DC=ADCORP,DC=LAB" /G "ADCORP\ADM_R1_00:RPWP;userAccountControl;user" /I:S)

Be aware though, that after the permissions have been configured you can configure (enable/disable) ANY of the bits available on the "userAccountControl" attribute. To be as accurate as possible, there are a few exceptions to this statement. One of those exceptions can be read through the following blog post (2008-05-20) Denying The Change Of Password Related Bits On User Objects. The list of userAccountControl bits can be found in the KB article How to use the UserAccountControl flags to manipulate user account properties.

There is yet another exception to that previous statement. If you just configure the permissions for the "userAccountControl" attribute as mentioned above AND you try to configure the option "Trust This User For Delegation To Any Service (Kerberos Only)", you will see the following error. In other operating systems, you may see a slightly different error message.

image

Figure 2: Access Denied When Configuring The Option "Trust This User For Delegation To Any Service (Kerberos Only)"

The reason for this access denied is that the admin account is lacking an important User Right on DCs to be able to configure this option. The User Right that must be granted to the group of admins of admin account on all writable DCs is called "Enable computer and user accounts to be trusted for delegation".

The explanation of that User Right reads:

This security setting determines which users can set the Trusted for Delegation setting on a user or computer object.

The user or object that is granted this privilege must have write access to the account control flags on the user or computer object. A server process running on a computer (or under a user context) that is trusted for delegation can access resources on another computer using delegated credentials of a client, as long as the client account does not have the Account cannot be delegated account control flag set.

So as soon as you in addition grant that user right, you will be able to configure the option "Trust This User For Delegation To Any Service (Kerberos Only)".

[2] and [3]

To configure the option "Trust This User For Delegation To Specified Services Only – Use Kerberos Only" OR the option "Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol", you must also list the specific services on specific servers for which the account can perform delegation for. That list of services is stored in the "msDS-AllowedToDelegateTo" attribute.

So, you need to have "Allow:Read" and "Allow:Write" permissions for the "msDS-AllowedToDelegateTo" attribute on the account.

To configure those permissions you can use the following command:

DSACLS "<Distinguished Name of OU>" /G "<Group Or User Account>:RPWP;msDS-AllowedToDelegateTo;user" /I:S

(e.g. DSACLS "OU=TEST,OU=Org-Users,DC=ADCORP,DC=LAB" /G "ADCORP\ADM_R1_00:RPWP;msDS-AllowedToDelegateTo;user" /I:S)

To configure the option "Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol", you must enable the bit called "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" on the "userAccountControl" attribute. That bit is enabled by setting the decimal value "16777216" or hexadecimal value "0x1000000" in addition to whatever value is already configured for the "userAccountControl" attribute.

So, you need to have "Allow:Read" and "Allow:Write" permissions for the "userAccountControl" attribute on the account.

To configure those permissions you can use the following command:

DSACLS "<Distinguished Name of OU>" /G "<Group Or User Account>:RPWP;userAccountControl;user" /I:S

(e.g. DSACLS "OU=TEST,OU=Org-Users,DC=ADCORP,DC=LAB" /G "ADCORP\ADM_R1_00:RPWP;userAccountControl;user" /I:S)

To configure the option "Trust This User For Delegation To Specified Services Only – Use Kerberos Only", you do not need to enable any bit on the "userAccountControl" attribute. However, you still require the "Allow:Read" and "Allow:Write" permissions for the "userAccountControl" attribute on the account.

As mentioned earlier, be aware though, that after the permissions have been configured you can configure (enable/disable) ANY of the bits available on the "userAccountControl" attribute. To be as accurate as possible, there are a few exceptions to this statement. One of those exceptions can be read through the following blog post (2008-05-20) Denying The Change Of Password Related Bits On User Objects. The list of userAccountControl bits can be found in the KB article How to use the UserAccountControl flags to manipulate user account properties.

There is yet another exception to that previous statement. If you just configure the permissions for the "userAccountControl" attribute as mentioned above AND you try to configure the option "Trust This User For Delegation To Specified Services Only – Use Kerberos Only" OR the option "Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol", you will see the following error. In other operating systems, you may see a slightly different error message.

image

Figure 3: Access Denied When Configuring The Option "Trust This User For Delegation To Specified Services Only – Use Kerberos Only" OR the option "Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol"

The reason for this access denied is that the admin account is lacking an important User Right on DCs to be able to configure this option. The User Right that must be granted to the group of admins of admin account on all writable DCs is called "Enable computer and user accounts to be trusted for delegation".

The explanation of that User Right reads:

This security setting determines which users can set the Trusted for Delegation setting on a user or computer object.

The user or object that is granted this privilege must have write access to the account control flags on the user or computer object. A server process running on a computer (or under a user context) that is trusted for delegation can access resources on another computer using delegated credentials of a client, as long as the client account does not have the Account cannot be delegated account control flag set.

So as soon as you in addition grant that user right, you will be able to configure the option "Trust This User For Delegation To Specified Services Only – Use Kerberos Only" OR the option "Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol".

[4]

To configure the option "Do Not Trusted This User For Delegation", you need to be able to write to the same attributes as you for option [2] and [3] as you need to remove the configured information

In summary, to be able to delegate the configuration of "Trusted For Delegation" you need at least the following permissions and user rights:

  • "Allow:Read" and "Allow:Write" permissions for the "servicePrincipalName" attribute on the account
  • "Allow:Read" and "Allow:Write" permissions for the "userAccountControl" attribute on the account
  • "Allow:Read" and "Allow:Write" permissions for the "msDS-AllowedToDelegateTo" attribute on the account
  • User Right "Enable computer and user accounts to be trusted for delegation" on writable DCs

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control | Leave a Comment »

 
%d bloggers like this: