Autorisierung

Die Benutzerautorisierung erfolgt über Rollen. Rollen können entweder über Claims-Zuordnung, ein Richtlinienskript oder durch direkte Zuweisung der Rolle an die Identität zugewiesen werden.

Standardmäßig werden keine Rollen automatisch zugewiesen. Während der Ersteinrichtung wird ein lokales Administratorkonto erstellt und zur Konfiguration der Rollenzuweisungen verwendet.

Rollen-zu-Claim-Zuordnung

Sie können Rollen einem Claim (z. B. einer Gruppenmitgliedschaft) zuordnen, indem Sie die Parameter -ClaimType und -ClaimValue von New-PSURole verwenden. Entsprechende Einstellungen sind auch im Dialogfeld für die Rolleneigenschaften unter Security \ Roles verfügbar.

Rollen-zu-Claim-Zuordnung

Wenn Sie beispielsweise bei der Windows-Authentifizierung eine Gruppe einer Rolle zuordnen möchten, könnten Sie dies so konfigurieren, dass die Gruppen-SID der Administratorrolle zugeordnet wird.

New-PSURole -Name Administrator -ClaimType 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid' -ClaimValue 'S-123-123-123'

Das Zuordnen von Rollen zu Claims auf diese Weise ist schneller als Richtlinienskripte, da beim Anmelden des Benutzers kein PowerShell ausgeführt werden muss.

Claim-Informationen anzeigen

Um die Entwicklung von Richtlinienskripten zu erleichtern oder Rollen zu Claims zuzuweisen, können Sie Claim-Informationen anzeigen, indem Sie unter Security \ Roles auf View Claim Information klicken.

Claim-Informationen anzeigen

Beispiel: Azure Active Directory

Sie können eine Azure Active Directory-Gruppe einer Rolle zuordnen, indem Sie die Objekt-ID der Gruppe in Azure nachschlagen. Beispielsweise gibt es in der Domäne von Ironman Software eine Gruppe namens Dashboard Administrators. Diese Gruppe hat die Objekt-ID 61849bf2-e44b-4057-b589-6cd1812d7545.

Innerhalb von PowerShell Universal kann ich Benutzer dieser Gruppe der Administrator-Gruppe zuweisen, indem ich die Claim-Zuordnung einrichte. Der Claim Type lautet groups und der Claim Value lautet 61849bf2-e44b-4057-b589-6cd1812d7545. Sobald ich den Claim zugeordnet habe, gehören Benutzer der Gruppe Dashboard Administrators zur PowerShell Universal Administrators-Gruppe. Die resultierende roles.ps1 sieht dann so aus.

Alle anderen Rollen sind deaktiviert.

New-PSURole -Name Administrator -ClaimType 'groups' -ClaimValue '61849bf2-e44b-4057-b589-6cd1812d7545'
New-PSURole -Name "Operator" -Description "Operators have access to manage and execute scripts, create other entities within PowerShell Universal but cannot manage PowerShell Universal itself." -Policy {} -Disabled
New-PSURole -Name "Reader" -Description "Readers have read-only access to PowerShell Universal. They cannot make changes to any entity within the system." -Policy { } -Disabled 
New-PSURole -Name "Execute" -Description "Execute scripts within PowerShell Universal." -Policy { } -Disabled
New-PSURole -Name "User" -Description "Does not have access to the admin console but can be assigned resources like APIs, scripts, dashboards and pages." -Policy { } -Disabled

Richtlinienzuweisung

Standardmäßig werden Rollen über Richtlinien zugewiesen. Richtlinien werden beim Anmelden des Benutzers ausgeführt. Sie können die Richtlinienskripte auf der Seite Security / Roles ändern. Klicken Sie auf die Schaltfläche Edit Code, um das Richtlinienskript zu konfigurieren.

Schaltfläche „Edit Policy Code“

Richtlinienskripte erhalten ein ClaimsPrincipal-Objekt als Parameter und müssen true oder false zurückgeben. Bei Richtlinien, die Fehler auslösen, wird von false ausgegangen. Das ClaimsPrincipal-Objekt enthält die Identität des Benutzers und die Claims, die der Benutzer erhalten hat. Diese können Gruppenzuweisungen oder andere Merkmale des Benutzerkontos umfassen.

Sie können ein Objekt mit dieser Struktur erwarten.

public class ClaimsPrincipal
{
    public List<Claim> Claims { get; set; } = new List<Claim>();
    public Identity Identity { get; set; } = new Identity();
}

public class Identity 
{
    public string Name { get ;set; }
}

public class Claim 
{
    public string Type { get; set; }  
    public string Value { get; set; }
    public string ValueType { get; set; } 
    public string Issuer { get; set; }
    public Dictionary<string, string> Properties { get; set; } = new Dictionary<string, string>();
}

Rollenzuweisung

Um einem Benutzer eine Rolle zuzuweisen, können Sie dessen Identität in Universal erstellen und anschließend die Rolle im Dropdown-Menü auf der Seite Identities auswählen.

Standardmäßig erhalten Identitäten eine Rolle über Claim-Zuordnung oder Richtlinie.

Rollenzuweisung

Rollen importieren

Wenn die Windows-Authentifizierung aktiviert ist, können Sie auf die Schaltfläche Import Windows Groups klicken, um Gruppen auszuwählen, die Sie in PowerShell Universal importieren möchten. Nach der Auswahl dieser Gruppen werden Rollen mit Rollen-zu-Claim-Zuordnung erstellt, ohne dass Sie dies manuell konfigurieren müssen.

Schaltfläche „Import Windows Groups“

Integrierte Rollen

Administrator

Vollzugriff auf die gesamte PowerShell Universal-Plattform und deren Einstellungen.

Operator

Operatoren können Ressourcen wie APIs, Skripte und Dashboards hinzufügen und entfernen. Operatoren können keine Einstellungen wie Umgebungen, Rollen oder allgemeine Einstellungen ändern.

Execute

Die Rolle Execute gewährt die Möglichkeit, Skripte auszuführen, sowie Lesezugriff auf alles Übrige.

Reader

Die Rolle Reader bietet schreibgeschützten Zugriff auf PowerShell Universal.

Standardroute pro Rolle

Sie können ändern, welche Seite der Benutzer beim Anmelden sieht, indem Sie die Eigenschaft Default Route für die Rolle festlegen. Beispielsweise möchten Sie vielleicht, dass HR-Benutzer zum Human Resources-Dashboard gelangen, während IT-Benutzer zum IT-Dashboard gelangen sollen.

Benutzer mit vielen Gruppen

Wenn Ihre Benutzer Mitglieder von mehr als etwa 40 Gruppen sind, können Probleme bei der Anmeldung auftreten. Dies liegt an den Größenbeschränkungen der HTTP-Header in IIS und Kestrel. Je mehr Gruppen ein Benutzer angehört, desto mehr Autorisierungs-Claims hat er und desto größer wird der Header.

Sie können das Header-Limit für Kestrel erhöhen, indem Sie die Limits-Konfiguration in der Datei appsettings.json verwenden. Sie müssen die Header-Größe erhöhen. Es handelt sich um einen Wert in Bytes, der standardmäßig 32 KB beträgt.

{
  "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:5000"
      }
    },
    "Limits": {
      "MaxRequestHeadersTotalSize": 132768
    },
    "RedirectToHttps": "false"
  },

IIS-Autorisierung

Die Autorisierung in IIS funktioniert wie bei jeder anderen Methode, Sie müssen jedoch die Größenbeschränkung des Anforderungsheaders beachten. Sie erhalten möglicherweise Fehler, wenn Sie Claims aktivieren, die viele Gruppen enthalten. Diese können das Header-Größenlimit überschreiten, und IIS gibt dann Fehler zurück. Wir haben festgestellt, dass etwa 40 Azure Active Directory-Gruppen dieses Problem bei einer Standard-IIS-Installation verursachen.

Der Fehler, den Sie erhalten, ist entweder ein 400-Fehler mit dem Hinweis, dass die Anforderung zu lang ist.

Wenn Sie HTTPS aktiviert haben, erhalten Sie einen Fehler bezüglich eines HTTP2-Protokollfehlers.

Sie können die IIS-Anforderungsgröße erhöhen, indem Sie die folgenden Registrierungsschlüssel festlegen. Sie müssen Ihren Computer neu starten, damit sie wirksam werden.

HKLM:\System\CurrentControlSet\Services\Http\Parameters
    MaxFieldLength: DWORD

HKLM:\System\CurrentControlSet\Services\Http\Parameters
    MaxRequestBytes: DWORD

Weitere Informationen finden Sie in Microsofts Dokumentation.

Als Alternative zur Erhöhung der Anforderungsgröße können Sie auch die Anzahl der gesendeten Gruppen reduzieren. In Azure Active Directory können Sie festlegen, dass nur die der Anwendung zugewiesenen Gruppen gesendet werden, um zu verhindern, dass alle Gruppen gesendet werden.

Gehen Sie in Azure zu App registrations > (Wählen Sie die App aus) > Token Configuration, und geben Sie die der Anwendung zugewiesenen Gruppen an.

Gehen Sie nun zu Enterprise Application > (Wählen Sie die App aus) > Users and groups. Weisen Sie die Gruppe(n) zu, die Sie in die Claims aufnehmen möchten. (Hinweis: Dies kann auch als Sicherheitsgrenze verwendet werden, wenn Sie im Abschnitt „Properties“ der App „User Assignment Required“ auf Yes setzen.)

App-Token

App-Token können Diensten zugewiesen werden, die sich nicht interaktiv anmelden können. Sie können Ihrem Konto ein neues App-Token gewähren, indem Sie auf der Registerkarte Security / App Tokens auf die Schaltfläche Grant App Token klicken.

Das Token hat eine Gültigkeit von einem Jahr und verfügt über die gültigen Rollen für Ihr Konto. Um das App-Token in Ihr Konto zu kopieren, klicken Sie auf die Aktion Copy. Um ein App-Token zu widerrufen, klicken Sie auf die Aktion Revoke.

Sie können App-Token mit den Universal-Cmdlets verwenden oder Webanforderungen direkt mit Bearer-Autorisierung nutzen.

App-Token-Seite

Umgebung

Standardmäßig werden die Skripte für die Formularauthentifizierung und die Richtlinienzuweisung innerhalb des PowerShell Universal-Prozesses ausgeführt. Wenn Sie eine Sicherheitsumgebung konfigurieren, wird ein externer PowerShell-Prozess gestartet und so konfiguriert, dass er die Einstellungen Ihrer Umgebung verwendet.

Um die vom Sicherheitsprozess verwendete Umgebung anzupassen, setzen Sie -SecurityEnvironment in settings.ps1.

Set-PSUSetting -SecurityEnvironment '5.1'

Beispiel: Formularauthentifizierung mit Active Directory

Das folgende Beispiel zeigt die Durchführung eines einfachen „LDAP BIND“, um die Active Directory-Anmeldeinformationen eines Benutzers zu validieren. Wenn ein Benutzer, der auf PowerShell Universal zugreifen möchte, nicht der Default Admin User ist, muss er seine Anmeldeinformationen erfolgreich über einen einfachen LDAP-Bind bei Active Directory authentifizieren. Dies kann mit einer AD-Gruppenmitgliedschaftsprüfung in den Richtlinien für die Rollen Admin, Operator und Reader kombiniert werden, um Active Directory-Authentifizierung UND Active Directory-Gruppenmitgliedschaft effektiv für rollenbasierten Zugriff auf PowerShell Universal zu nutzen.

param(
    [PSCredential]$Credential
)

#
#   You can call whatever cmdlets you like to conduct authentication here.
#   Just make sure to return the $Result with the Success property set to $true
#

$Result = [Security.AuthenticationResult]::new()
if ($Credential.UserName -eq 'Admin') 
{
    #Maintain the out of box admin user
    $Result.UserName = 'Default Admin'
    $Result.Success = $true 
}
else
{
    # Get current domain using logged-on user's credentials - this validates their credential
    $CurrentDomain = "LDAP://DC=mydemodomain,DC=com"  # Insert Your Domain Here
    $domain = New-Object System.DirectoryServices.DirectoryEntry($CurrentDomain,($Credential.UserName),$Credential.GetNetworkCredential().password)

    if ($domain.name -eq $null)
    {
        "Authentication failed for $($Credential.UserName)!" | Out-File "C:\test\adlogin.txt"
        write-host "Authentication failed - please verify your username and password."
        $Result.UserName = ($Credential.UserName)
        $Result.Success = $false 
    }
    else
    {
        write-host "Successfully authenticated with domain $($domain.name)"
        "Authentication success for $($Credential.UserName)!" | Out-File "C:\test\adlogin.txt"
        $Result.UserName = ($Credential.UserName)
        $Result.Success = $true 
    }
}

$Result

Beispiel: Richtlinie basierend auf Active Directory-Gruppenmitgliedschaft (Windows-Authentifizierung)

Dieses Beispiel erfordert eine Authentifizierungsmethode, die während des Authentifizierungsvorgangs Gruppeninformationen bereitstellt. Methoden wie Windows-Authentifizierung und WS-Federation können diese Informationen bereitstellen. Die Formularauthentifizierung funktioniert mit dieser Art von Richtlinie nicht.

Dieses Beispiel nutzt die während der Authentifizierung bereitgestellten Claims. Sie können mithilfe von Claim-Zuordnungen prüfen, ob der Benutzer über eine groupsid (Gruppenmitgliedschaft) verfügt. Ordnen Sie den Claim-Typ groupid dem Wert zu, dem Sie die Rolle zuweisen möchten.

$Parameters = @{
    Name = "Administrators"
    ClaimType = 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid'
    ClaimValue = 'S-1-5-21-22222222-111111-3333333-153'
}

New-PSURole @Parameters

Beispiel: Richtlinie basierend auf Active Directory-Gruppenmitgliedschaft

In diesem Beispiel konfigurieren wir unser Administrator-Richtlinienskript so, dass es LDAP verwendet, um die Mitgliedschaft einer Active Directory-Gruppe abzurufen. Hier haben wir eine Gruppe namens „PowerShell Universal Admins“ erstellt, deren Mitgliedern Administratorzugriff in PowerShell Universal gewährt werden soll. Wir führen hier eine einfache samaccountname-Prüfung für den Benutzer durch, um sicherzustellen, dass er Mitglied der Gruppe ist. Für robustere Umgebungen wäre eine SID/DN/ObjectGUID-Prüfung besser geeignet.

param(
$User
)

$UserName = ($User.Identity.Name)
$UserName = $UserName.Substring($UserName.IndexOf('\')+1,($UserName.Length -($UserName.IndexOf('\')+1)))

$IsMember = $false;

# Perform LDAP Group Member Lookup
$Searcher = New-Object DirectoryServices.DirectorySearcher
$Searcher.SearchRoot = 'LDAP://CN=Users,DC=berg,DC=com' # INSERT ROOT LDAP HERE
$Searcher.Filter = "(&(objectCategory=person)(memberOf=CN=PowerShell Universal Admins,OU=Information Technology,DC=berg,DC=com))" #GROUP INSERT DN TO CHECK HERE
$Users = $Searcher.FindAll()
$Users | ForEach-Object{
    If($_.Properties.samaccountname -eq $UserName)
    {
        $IsMember = $true;
        "$UserName is a member of admin group!" | Out-File "C:\test\adgroup.txt"
    }
    else {
        "$UserName is NOT member of admin group!" | Out-File "C:\test\adgroup.txt"
    }
}

return $IsMember

Beispiel: Gruppenmitgliedschaft basierend auf Azure Active Directory

Dieses Beispiel nutzt OpenID Connect und Azure Active Directory.

Sobald Sie PowerShell Universal und Azure Active Directory konfiguriert haben, können Sie Rollenskripte so konfigurieren, dass sie überprüfen, ob Benutzer Mitglieder von Gruppen in Azure AD sind. Sie können Claim-Zuordnungen nutzen, um von der Azure AD-Gruppen-ID auf eine PowerShell Universal-Rolle zu mappen.

Stellen Sie zunächst sicher, dass im Manifest Ihrer Anwendungsregistrierung Gruppenmitgliedschafts-Claims aktiviert sind. Dadurch werden alle Gruppenmitgliedschaften einbezogen, sodass sie in PowerShell Universal zugänglich sind.

"groupMembershipClaims": "All",

Nach der Konfiguration können Sie Ihr Rollenskript aktualisieren, um eine Gruppenmitgliedschaft zu prüfen. Notieren Sie sich zunächst die Objekt-ID der Gruppe, die Sie in Azure AD prüfen möchten.

Anschließend können Sie in Ihrem roles.ps1-Skript mithilfe der Claim-Zuordnung validieren, dass ein Benutzer eine bestimmte Rolle hat.

New-PSURole -Name 'Administrators' -ClaimType 'groups' -ClaimValue '4acabc67-56cc-4590-9de6-164f3c4faf10'

Wenn sich Benutzer anmelden, wird ihre Gruppenmitgliedschaft anhand ihrer Claims validiert und eine Rolle zugewiesen.

Siehe auch

• Devolutions Academy – Authentifizierung