> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/de/sicherheit/security.md). # Über Konfigurieren Sie Authentifizierung und rollenbasierte Autorisierung in PowerShell Universal, einschließlich Claim-Mapping, Richtlinienskripten und App-Tokens. ## Authentifizierung Standardmäßig bietet PowerShell Universal eine [lokale Benutzerauthentifizierung](/powershell-universal/de/sicherheit/local-accounts.md). Benutzernamen und verschlüsselte Passwörter werden in der PowerShell Universal-Datenbank gespeichert. Für Unternehmensumgebungen sollten Sie in Erwägung ziehen, die von Ihrer Organisation unterstützten Authentifizierungsmethoden zu verwenden. * [Windows SSO](/powershell-universal/de/sicherheit/enterprise-security/windows-sso.md) * [OpenID Connect](/powershell-universal/de/sicherheit/enterprise-security/openid-connect.md) * [SAML2](/powershell-universal/de/sicherheit/enterprise-security/saml2.md) * [WS-Federation](/powershell-universal/de/sicherheit/enterprise-security/ws-federation.md) ## Autorisierung Die Benutzerautorisierung erfolgt über Rollen. Rollen können entweder über Claims-Mapping, ein Richtlinienskript oder durch die direkte Zuweisung der Rolle an die Identität vergeben werden. {% hint style="info" %} Standardmäßig erhalten Benutzer keine Rollen. Mehrere Rollenzuweisungen sind in PowerShell Universal zulässig. {% endhint %} ### 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 Dialog für die Rolleneigenschaften unter Secure > Roles verfügbar. Wenn Sie beispielsweise bei der Windows-Authentifizierung eine Gruppe einer Rolle zuordnen möchten, können Sie es so konfigurieren, dass die Gruppen-SID der Administratorrolle zugeordnet wird. {% code collapsedlinecount="10" %} ```powershell New-PSURole -Name Administrator -ClaimType 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid' -ClaimValue 'S-123-123-123' ``` {% endcode %} Das Zuordnen von Rollen zu Claims auf diese Weise ist schneller als Richtlinienskripte, da PowerShell bei der Anmeldung des Benutzers nicht ausgeführt werden muss. ### Claim-Informationen anzeigen Um die Entwicklung von Richtlinienskripten oder die Zuweisung von Rollen zu Claims zu unterstützen, können Sie Claim-Informationen anzeigen, indem Sie unter Secure > Roles auf View Claim Information klicken. ### 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. Innerhalb der Ironman Software-Domäne haben wir beispielsweise 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 das Claim-Mapping einrichte. Der Claim Type ist `groups` und der Claim Value ist `61849bf2-e44b-4057-b589-6cd1812d7545`. Sobald ich den Claim zugeordnet habe, sind Benutzer der Gruppe Dashboard Administrators Teil der PowerShell Universal Administrators-Gruppe. Die resultierende `roles.ps1` sieht dann so aus. Alle anderen Rollen sind deaktiviert. {% code collapsedlinecount="10" %} ```powershell 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 ``` {% endcode %} ### Richtlinienzuweisung Standardmäßig werden Rollen über Richtlinien zugewiesen. Richtlinien werden ausgeführt, wenn sich der Benutzer anmeldet. Sie können die Richtlinienskripte auf der Seite Secure > Roles ändern. Klicken Sie auf die Schaltfläche Edit Code, um das Richtlinienskript zu konfigurieren. 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 eines Benutzerkontos umfassen. Sie können ein Objekt mit dieser Struktur erwarten. {% code collapsedlinecount="10" %} ```csharp public class ClaimsPrincipal { public List Claims { get; set; } = new List(); 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 Properties { get; set; } = new Dictionary(); } ``` {% endcode %} ### Rollenzuweisung Um einem Benutzer eine Rolle zuzuweisen, können Sie dessen Identität innerhalb von Universal erstellen und dann die Rolle im Dropdown-Menü auf der Seite Identities auswählen. Standardmäßig erhalten Identitäten eine Rolle über Claim-Mapping oder Richtlinien. ### 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 Einstellungen wie Umgebungen, Rollen oder allgemeine Einstellungen nicht ändern. #### Execute Die Rolle Execute gewährt die Möglichkeit, Skripte auszuführen, und 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 bei der Anmeldung sieht, indem Sie die Eigenschaft `Default Route` für die Rolle festlegen. Beispielsweise möchten Sie möglicherweise, dass HR-Benutzer zum Human Resources-Dashboard und IT-Benutzer zum IT-Dashboard gelangen. ### 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. {% code collapsedlinecount="10" %} ``` { "Kestrel": { "Endpoints": { "HTTP": { "Url": "http://*:5000" } }, "Limits": { "MaxRequestHeadersTotalSize": 132768 }, "RedirectToHttps": "false" }, ``` {% endcode %} ### IIS-Autorisierung Die Autorisierung in IIS funktioniert wie bei jeder anderen Methode, Sie müssen jedoch die Größenbeschränkung des Anforderungsheaders beachten. Es können Fehler auftreten, wenn Sie Claims aktivieren, die viele Gruppen enthalten. Diese können die Header-Größenbeschränkung überschreiten, und IIS gibt 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. *Bad Request - Request Too Long* *HTTP Error 400. The size of the request headers is too long.* Wenn Sie HTTPS aktiviert haben, erhalten Sie einen Fehler zu einem HTTP2-Protokollfehler. 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. {% code collapsedlinecount="10" %} ``` HKLM:\System\CurrentControlSet\Services\Http\Parameters MaxFieldLength: DWORD HKLM:\System\CurrentControlSet\Services\Http\Parameters MaxRequestBytes: DWORD ``` {% endcode %} Weitere Informationen finden Sie in [Microsofts Dokumentation](https://docs.microsoft.com/en-us/troubleshoot/iis/http-bad-request-response-kerberos#workaround-2-set-maxfieldlength-and-maxrequestbytes-registry-entries). 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 die Einstellung auf die der Anwendung zugewiesenen Gruppen beschränken, um zu verhindern, dass alle Gruppen gesendet werden. Gehen Sie in Azure zu **App registrations** > (Wählen Sie die App) > **Token Configuration**, und geben Sie die der Anwendung zugewiesenen Gruppen an. Gehen Sie nun zu **Enterprise Application** > (Wählen Sie die App) > **Users and groups**. Weisen Sie die Gruppe(n) zu, die Sie in die Claims einbeziehen möchten. (Hinweis: Dies kann auch als Sicherheitsgrenze verwendet werden, wenn Sie im Abschnitt „Properties“ der App „User Assignment Required“ auf Yes setzen) ## App-Tokens App-Tokens können Diensten zugewiesen werden, die sich nicht interaktiv anmelden können. Administratoren können Tokens für Identitäten unter Secure > Application Tokens erstellen. Um ein Token für Ihr eigenes Konto zu erstellen, öffnen Sie User Settings über das Benutzermenü und wählen Sie Tokens. Das Token hat eine Gültigkeitsdauer 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-Tokens mit den Universal-Cmdlets oder durch direkte Webanforderungen mit Bearer-Autorisierung verwenden. ## Umgebung Standardmäßig werden die Skripte für die Formularauthentifizierung und die Richtlinienzuweisung innerhalb des PowerShell Universal-Prozesses ausgeführt. Optional können Sie eine externe [Umgebung ](/powershell-universal/de/config/environments.md)konfigurieren, um Ihre Authentifizierungs- und Autorisierungsskripte auszuführen. 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`. {% code collapsedlinecount="10" %} ```powershell Set-PSUSetting -SecurityEnvironment '5.1' ``` {% endcode %} ## 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 Standard-Administratorbenutzer ist, muss er seine Anmeldeinformationen über einen einfachen LDAP-Bind erfolgreich mit 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 zu nutzen und rollenbasierten Zugriff auf PowerShell Universal bereitzustellen. {% code collapsedlinecount="10" %} ```powershell 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 ``` {% endcode %} ## Beispiel: Richtlinie basierend auf Active Directory-Gruppenmitgliedschaft (Windows-Authentifizierung) {% hint style="info" %} Dieses Beispiel erfordert eine Authentifizierungsmethode, die während des Authentifizierungsprozesses Gruppeninformationen bereitstellt. Methoden wie Windows-Authentifizierung und WS-Federation können diese Informationen bereitstellen. Die Formularauthentifizierung funktioniert mit diesem Richtlinientyp nicht. {% endhint %} Dieses Beispiel nutzt die Claims, die während der Authentifizierung bereitgestellt werden. Sie können anhand von Claim-Mappings 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. {% code collapsedlinecount="10" %} ```powershell $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 ``` {% endcode %} ## 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. Wir haben hier eine Gruppe namens „PowerShell Universal Admins“ erstellt, deren Mitglieder Administratorzugriff in PowerShell Universal erhalten sollen. Hier führen wir 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 geeigneter. {% code collapsedlinecount="10" %} ```powershell 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 ``` {% endcode %} ## Beispiel: Gruppenmitgliedschaft basierend auf Azure Active Directory Dieses Beispiel nutzt [OpenID Connect und Azure Active Directory](/powershell-universal/de/sicherheit/enterprise-security/openid-connect.md#configuring-azure-entra-id-azure-active-directory). Nachdem Sie PowerShell Universal und Azure Active Directory konfiguriert haben, können Sie Rollenskripte konfigurieren, um zu überprüfen, ob Benutzer Mitglieder von Gruppen in Azure AD sind. Sie können Claims-Mappings nutzen, um von der Azure AD-Gruppen-ID auf eine PowerShell Universal-Rolle zuzuordnen. Stellen Sie zunächst sicher, dass Sie Gruppenmitgliedschafts-Claims im Manifest Ihrer Anwendungsregistrierung aktiviert haben. Dadurch werden alle Gruppenmitgliedschaften einbezogen, sodass sie in PowerShell Universal verfügbar sind. {% code collapsedlinecount="10" %} ``` "groupMembershipClaims": "All", ``` {% endcode %} 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 von Claims-Mapping überprüfen, ob ein Benutzer eine bestimmte Rolle hat. {% code collapsedlinecount="10" %} ```powershell New-PSURole -Name 'Administrators' -ClaimType 'groups' -ClaimValue '4acabc67-56cc-4590-9de6-164f3c4faf10' ``` {% endcode %} Wenn sich Benutzer anmelden, wird ihre Gruppenmitgliedschaft anhand ihrer Claims validiert und eine Rolle zugewiesen. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/powershell-universal/de/sicherheit/security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.