Anpassen von Berechtigungen per PowerShell Script am Beispiel Terminal Service License Server

Hallo, hier ist Andy aus dem Glutofen München Lohof, mit eine Blog Thema zu PowerShell Scripting – bei 29°C im Büro…

In der Regel verfassen wir in unserem Team keine Scripts zum Anpassen von AD Objekten. Wir wollen und dürfen nicht in Konkurrenz zu Organisationen treten, welche Consulting Leistungen anbieten. Zudem hat auch nicht jeder das entsprechende Know-How dazu.

Das Vorliegende Beispiel demonstriert aber deutlich, wie einfach Scripting inzwischen geworden ist, wenn man sich etwas mit der PowerShell beschäftigt. Aus aktuellem Anlass daher hier ein Beispiel, bei dem neue Berechtigungsrechte zu Terminal Service License Server für existieren Benutzer per Script nachgezogen werden. Bis vor Kurzem wurde dies nur umständlich mittels eines VBS Scripts gemacht. Im Vergleich dazu ist die Umsetzung mit PowerShell praktisch ein Klacks.

Zum Hintergrund unseres Beispiels - Bereits mit Windows Server 2003 wurden im Active Directory zwei neue Berechtigungsrechte den Benutzerobjekten hinzugefügt, die aber erst mit dem Windows 2008 Terminal License Manager verwendet werden. Die Rechte sind „Read Terminal Service license server“ und „Write Terminal Servcie license server“. Diese Berechtigungen müssen am Benutzerobjekt für die Eigenschaft „Terminal Server License Server“ zugewiesen werden. In neuen auf der grünen Wiese aufgebaute Windows 2003 oder 2008 Domains stellt dies kein Problem dar, da alle neue Benutzer Objekte automatisch mit den Standardwerten versehen werden.
Aber in upgegradeten Windows 2000 Domains kommt es zu der Situation, dass neue Benutzer zwar mit den neuen Rechten versehen, bestehende Benutzerobjekte jedoch nicht mit der neuen Schema-Default Berechtigung versorgt werden. Somit können Benutzer, die vor dem W2k3 Schema Update bereits existierten, ihre gültige Terminal Server Client Access License nicht korrekt reporten. Es kommt dann zu dem Microsoft-Windows-TerminalServices-Licensing Event 4105 beschrieben in Artikel 2030310 TerminalServices-Licensing 4105 – The Terminal Services license server cannot update the license attributes for user “<UserName>” in Active Directory Domain “<DomainName>”, https://support.microsoft.com/default.aspx?scid=kb;en-US;2030310

Log Name: System
Source: Microsoft-Windows-TerminalServices-Licensing
Event ID : 4105
Level: Warning
User: N/A
Computer: <computer name>
Description:
The Terminal Services license server cannot update the license attributes for user <user name> in the Active Directory Domain <domain name>. Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain <domain name>.
If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs.
Win32 error code: 0x80070005

Um diese zu beheben muss im Active Directory den bestehenden Benutzer die beiden Rechte Manuell hinzugefügt werden. Da dies in großen Umgebungen schnell zu einem riesigen Aufwand führt, habe ich folgendes PowerShell Script geschrieben.
In dem Script ist die Zeile $Dom = "ou=test,dc=contoso,dc=com" anzupassen, also der DN der Domain und des Containers mit den Usern die ausgewählt werden sollen.

import-module activedirectory
$Dom = "ou=test,dc=contoso,dc=com"
foreach ($user in Get-ADUser -Filter * -SearchBase $Dom)
{
$Path = "AD:/" + $user.DistinguishedName
$acl = Get-ACl $Path
$SDDL = $acl.GetSecurityDescriptorSddlForm([System.Security.AccessControl.AccessControlSections]::Access)
$SDDL = $SDDL + "(OA;;RPWP;5805bc62-bdc9-4428-a5e2-856a0f4c185e;;S-1-5-32-561)"
$acl.SetSecurityDescriptorSddlForm($sddl)
Set-Acl -PAth $Path $acl
}

Das Script läuft auf Windows auf Windows 7 oder Windows 2008 mit den installierten Active Directory Services Remote Administration Tools; speziell mit "Active Directory Module for Windows PowerShell":

Weiterhin erwarte das Script einen Windows 2008R2 Domain oder den Active Directrory Gateway Service (https://www.microsoft.com/downloads/details.aspx?FamilyID=008940c6-0296-4597-be3e-1d24c1cf0dda&displaylang=en ). Den kann man im Übrigen auch auf Windows Server 2003 installieren und mit einem Windows 7 Member in der Domäne, dann auch das PowerShell Script für Windows 2003 anwenden. Es reicht dabei aus, obiges Script in die PowerShell zu kopieren.

Besonders interessant ist im obigen Script die eingesetzte SDDL Syntax zur Veränderung von Berechtigungen. Die wollen wir uns im Folgenden etwas genauer ansehen.
SDDL bedeutet Security Descriptor Definition Language und ist beschrieben in “ACE Strings (Windows) ”, https://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx
Vergleichen wir nun das Standard SDDL Format

ace_type;ace_flags;rights;object_guid;inherit_object_guid;account_sid

mit dem aus unserem Script

OA;;RPWP;5805bc62-bdc9-4428-a5e2-856a0f4c185e;;S-1-5-32-561

so bekommen wir für die einzelnen Parameter

 

ace_type: OA = ACCESS_ALLOWED_OBJECT_ACE_TYPE  
(explizites Erlauben)
ace_flags: nicht verwendet
rights: RPWP = "RP" ADS_RIGHT_DS_READ_PROP 
                         + "WP" ADS_RIGHT_DS_WRITE_PROP  
(Read und Write auf die Property)
object_guid: 5805bc62-bdc9-4428-a5e2-856a0f4c185e  
(attributeSecurityGUID der Security Property “Terminal Server License Server”. Diese und andere GUIDs für verschiedene Security Eigenschaften sind beschrieben in “3.1.1.2.3.3 Property Set”, https://msdn.microsoft.com/en-us/library/cc223204(PROT.10).aspx)
inherit_object_guid: nicht verwendet
account_sid: S-1-5-32-561 
(Well Known SID für “BUILTIN\Terminal Server License Servers”, siehe 243330 Well-known security identifiers in Windows operating systems, https://support.microsoft.com/default.aspx?scid=kb;EN-US;243330)

 

 

Das sollte zum Verständnis helfen aber auch, wenn man mal eine ganz andere Berechtigung anpassen muss - und bitte vor dem produktiven Einsatz solche Scripts immer ausgiebig testen!
Wie bei allen Beispiel-Scripts übernehmen wir keine Verantwortung oder Support. Bei Bedarf kann aber gerne eine Advisory Anfrage an Microsoft gestellt werden.

Was das Script leider nicht kann, ist eine Maß im Biergarten bestellen. Daher mach ich das wie früher ….
Cheers, Andy