> 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/enterprise-security/saml2.md).

# SAML2

Konfigurieren Sie die SAML2-Authentifizierung in PowerShell Universal mit Identitätsanbietern wie Entra ID, Okta und Shibboleth, einschließlich Metadaten und Claim-Mapping.

{% hint style="info" %}
SAML2 erfordert eine [Lizenz](https://store.devolutions.net/package#psu).
{% endhint %}

PowerShell Universal kann für die Integration mit einem SAML2-Identitätsanbieter konfiguriert werden. Diese Dokumentation enthält die Details zur Konfiguration von PSU mit einem solchen System.

## Metadaten automatisch laden

PowerShell Universal bietet einen Mechanismus, um das Metadatendokument direkt vom SAML2-Identitätsanbieter zu laden, anstatt Konfigurationsoptionen manuell anzugeben. Dabei werden so viele Informationen wie möglich erfasst. Die Entity ID muss dennoch angegeben werden.

Der Callback-Pfad wird oben im Modal der Eigenschaft angezeigt.

## Werte manuell angeben

### Einstellungen des Identitätsanbieters

Sie müssen Ihren Identitätsanbieter für die PowerShell Universal-Anwendung konfigurieren. Sie müssen eine akzeptable Entity ID einrichten und Attribute zuordnen. PowerShell Universal erfordert, dass das Attribut name zugeordnet ist. Der Attributname muss der folgende sein.

{% code collapsedlinecount="10" %}

```
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
```

{% endcode %}

Sie sollten dies der Benutzeridentität zuordnen, die innerhalb von PowerShell Universal verwendet werden soll.

Zusätzliche Attribute können zugeordnet werden und stehen während der [Rollenauswertung](/powershell-universal/de/sicherheit/security.md#authorization) zur Verfügung. Unten finden Sie ein Beispiel für die Konfiguration von Shibboleth.

### Entity ID-Einstellungen

{% hint style="info" %}
[HTTPS ](/powershell-universal/de/config/hosting.md#configuring-https)ist für die SAML2-Authentifizierung erforderlich.
{% endhint %}

Es gibt mehrere grundlegende Einstellungen, die Sie in der Administrationskonsole von PowerShell Universal konfigurieren können. Um SAML2-Unterstützung hinzuzufügen, klicken Sie auf Secure > Authentication. In der oberen rechten Ecke können Sie SAML2 aus der Dropdown-Liste auswählen.

Nachdem die SAML2-Integration hinzugefügt wurde, können Sie die grundlegenden Einstellungen für die Kommunikation mit Ihrem Identitätsanbieter konfigurieren. Sie müssen mindestens die Entity ID und die Identity Provider Entity ID konfigurieren.

Typischerweise sind diese Entity IDs URLs, die innerhalb Ihres Identitätsanbieters konfiguriert sind.

Das Dienstzertifikat wird zum Signieren von Anfragen verwendet. Es ist nicht erforderlich. Dies kann entweder ein lokaler Pfad zum PSU-Dienst oder der Distinguished Name eines im persönlichen Zertifikatspeicher des Computers installierten Zertifikats sein.

### Zusätzliche Einstellungen

Zusätzlich zu den in der Administrationskonsole verfügbaren Einstellungen können Sie die folgenden auch in der Konfigurationsdatei `authentication.ps1` festlegen.

#### ServiceCertificatePassword

Wenn Sie einen Dateipfad für Ihr Zertifikat verwenden und dieses ein Passwort erfordert, können Sie es über `-ServiceCertificatePassword` von `Set-PSUAuthenticationMethod` angeben. Der Wert dieses Parameters ist ein `SecureString`. Sie können das SecretManagement-Modul nutzen, um Geheimnisse zu laden.

{% code collapsedlinecount="10" %}

```powershell
Set-PSUAuthenticationMethod `
-Type "Saml2" `
-EntityId "http://psu.ironman.local/sp" `
-IdentityProviderEntityId 'https://ironman.local/idp' `
-MetadataAddress 'https://idp.ironman.local/idp/shibboleth' `
-CallbackPath "https://localhost:5000/" `
-ServiceCertificate cert.pfx `
-ServiceCertificatePassword (Get-Secret -Name 'certPassword')
```

{% endcode %}

#### Configure

Der Parameter `-Configure` ist ein Skriptblock, mit dem zusätzliche Einstellungen festgelegt werden können, die von `Set-PSUAuthenticationMethod` nicht bereitgestellt werden. Der Skriptblock wird aufgerufen, wenn der Anbieter konfiguriert wird, und erhält einen einzelnen Parameter, der ein Objekt mit den Optionen für die SAML2-Authentifizierung enthält.

Das Objekt ist vom Typ [Saml2Options](https://github.com/Sustainsys/Saml2/blob/v2.11.0/Sustainsys.Saml2.AspNetCore2/Saml2Options.cs). Das Unterobjekt von SPOptions finden Sie [hier](https://github.com/Sustainsys/Saml2/blob/v2.11.0/Sustainsys.Saml2/Configuration/SPOptions.cs).

{% code collapsedlinecount="10" %}

```powershell
Set-PSUAuthenticationMethod `
-Type "Saml2" `
-EntityId "http://psu.ironman.local/sp" `
-IdentityProviderEntityId 'https://ironman.local/idp' `
-MetadataAddress 'https://idp.ironman.local/idp/shibboleth' `
-Configure {
  $options = $args[0]
  $options.SPOptions.DiscoveryServiceUrl = 'https://idp.ironman.local/discovery'
}
```

{% endcode %}

## Beispiel: Entra ID <a href="#example-entra-id" id="example-entra-id"></a>

Richten Sie eine Entra ID Enterprise Application in Azure ein. Eine [Schritt-für-Schritt-Anleitung finden Sie hier](/powershell-universal/de/sicherheit/enterprise-security/openid-connect.md#configuring-azure-entra-id-azure-active-directory). Sie müssen die Anwendungs-ID und das Dokument mit den Verbundmetadaten sowie den SAML-P-Anmeldeendpunkt abrufen. Klicken Sie in Ihrer Anwendungsregistrierung auf die Schaltfläche Endpoints.

### Schritt für Schritt <a href="#step-by-step" id="step-by-step"></a>

**Innerhalb von PowerShell Universal:**

1. Klicken Sie auf Secure > Authentication.
2. Fügen Sie den SAML2-Authentifizierungsanbieter hinzu.
3. Klicken Sie auf die Schaltfläche Edit Properties.

Für Entity ID müssen Sie die Entra ID-Anwendungs-ID mit dem Präfix `spn:` angeben

Zum Beispiel: `spn:2cf33625-e312-4659-a7bd-66ade51a0ea2`

Für Identity Provider Entity ID müssen Sie die Entity ID aus dem Dokument mit den Verbundmetadaten abrufen. Öffnen Sie die Dokument-URL in einem Webbrowser.

Fügen Sie für Metadata Address die URL des Dokuments mit den Verbundmetadaten ein.

Fügen Sie für die Return URL die URL Ihres PowerShell Universal-Servers mit dem Pfad `/Saml/Acs` ein.

{% code collapsedlinecount="10" %}

```
https://localhost/Saml2/Acs
```

{% endcode %}

Fügen Sie für Single Sign-On Service URL den SAML-P-Anmeldeendpunkt aus Azure ein.

Speichern Sie nach Abschluss die Einstellungen und aktivieren Sie den SAML-Anbieter. Klicken Sie auf Abmelden und navigieren Sie zur URL Ihrer Administrationskonsole.

{% code collapsedlinecount="10" %}

```
https://localhost/admin
```

{% endcode %}

Sie werden zur Anmeldung an Azure weitergeleitet und nach der Authentifizierung zurück zu PowerShell Universal umgeleitet.

Alle auftretenden Fehler werden im PowerShell Universal-Protokoll aufgeführt. Wenn die Anmeldung fehlschlägt, können Sie zu `/login` navigieren, um sich mit einem lokalen Konto anzumelden.

### Claim-Mapping

Um Gruppen-Claims an PowerShell Universal bereitzustellen, müssen Sie die Gruppen-Claims aus Ihrer App-Registrierung verfügbar machen. Klicken Sie auf Token Configuration und dann auf Add groups claim.

Nach dem Klick auf Add groups claim haben Sie die Möglichkeit auszuwählen, welche Gruppen bereitgestellt werden. Wenn Sie All Groups auswählen, werden die Gruppen-Claims an PowerShell Universal bereitgestellt

Wenn Sie Groups assigned to the application auswählen, stellen Sie sicher, dass Sie den Wert Emit groups as role claims aktivieren. Diese Einstellung erfordert einen kostenpflichtigen Entra ID-Plan.

Um Ihrer App-Registrierung eine Gruppe zuzuweisen, suchen Sie Ihre App in Enterprise Applications und klicken Sie auf User and Groups. Klicken Sie anschließend auf Add User\Group und wählen Sie die Gruppen aus, die Sie Ihrer Anwendung zuweisen möchten.

Sobald Sie den Gruppen-Claim in Entra ID konfiguriert haben, können Sie die Claim-Mappings von PowerShell Universal auf die bereitgestellten Gruppen aktualisieren.

Geben Sie für jede Rolle, die Sie einer Entra ID-Gruppe zuweisen möchten, den Claim Type und Claim Value für diese Rolle an. Ich habe zum Beispiel in meiner Umgebung eine Gruppe mit der ID 446832da-d4ad-4972-b0a2-eda736129928. Der Claim Type für dieses Objekt ist <http://schemas.microsoft.com/ws/2008/06/identity/claims/role>.

Um dies der Administratorgruppe zuzuweisen, würde ich Folgendes tun.

Benutzer dieser Gruppe wären nun Teil der Administrator-Rolle in PowerShell Universal. Wenn Sie eine andere SAML-Gruppeneigenschaft ausgewählt haben, kann der Wert abweichen (z. B. sAMAccountName).

### Gruppenüberschreitungen <a href="#group-overages" id="group-overages"></a>

Für Organisationen mit vielen Gruppen sollten Sie die Anzahl der an PowerShell Universal bereitgestellten Gruppen begrenzen. Dies kann Autorisierungsprobleme beheben, die entstehen, wenn zu viele Gruppen bereitgestellt werden und dadurch Grenzwerte innerhalb der Anwendung überschritten werden. Klicken Sie in den Einstellungen der Enterprise Application auf Single sign-on und dann auf die Schaltfläche Edit unter Attributes & Claims.

Klicken Sie auf den groups-Claim, um die Optionen anzuzeigen. Mit den erweiterten Optionen können Sie die Gruppen filtern, die an den PowerShell Universal-Server bereitgestellt werden. Sie können Gruppen-Claims auch über die Tokenkonfiguration in der Anwendungsregistrierung für die Enterprise Application konfigurieren.

## Beispiel: Okta

Dieses Beispiel zeigt, wie Sie die Okta SAML2-Authentifizierung für die Verwendung mit PowerShell Universal konfigurieren.

In Okta müssen Sie Ihre Anwendung ähnlich wie folgt konfigurieren. HTTPS ist für SAML2 erforderlich, und Sie müssen die URL Ihrer PSU-Instanz in der Single Sign On URL angeben, gefolgt von `/Saml2/Acs`. Beim Pfad wird zwischen Groß- und Kleinschreibung unterschieden.

Die Audience Restriction sollte die URL Ihres PowerShell Universal-Servers sein.

Damit Ihre Benutzer auf PowerShell Universal zugreifen können, müssen Sie sicherstellen, dass sie der Okta-Anwendung zugewiesen wurden.

Klicken Sie auf der Registerkarte Sign On Ihrer Anwendung auf die Schaltfläche View SAML setup instructions.

Sie müssen die beiden URLs erfassen und das Zertifikat herunterladen, um PowerShell Universal zu konfigurieren. Im nächsten Schritt erfahren Sie, wie diese URLs in der Datei `authentication.ps1` verwendet werden.

### authentication.ps1

Die Datei authentication.ps1 wird zur Konfiguration von PowerShell Universal verwendet.

{% code collapsedlinecount="10" %}

```powershell
Set-PSUAuthenticationMethod -Type "Saml2" `
-EntityId "https://localhost:5001" `
-IdentityProviderEntityId "http://www.okta.com/exk5dvbyzgASPiOFp5d7" `
-CallbackPath "https://localhost:5001" `
-SigningKey "C:\Users\adamr\Downloads\okta.cert" `
-SingleSignOnServiceUrl "https://dev-36706648.okta.com/app/dev-36706648_psusaml_1/exk5dvbyzgASPiOFp5d7/sso/saml"
```

{% endcode %}

| Parameter                | Beschreibung                                                                                            | Typ    |
| ------------------------ | ------------------------------------------------------------------------------------------------------- | ------ |
| EntityId                 | Dieser Wert sollte mit dem übereinstimmen, was Sie in Okta unter Audience Restriction eingegeben haben. | string |
| IdentityProviderEntityId | Dies ist der Wert, der auf der Seite View SAML setup instructions angezeigt wurde.                      | string |
| CallbackPath             | Dies ist der Pfad, zu dem der Benutzer umgeleitet wird, wenn kein Umleitungspfad angegeben wurde        | string |
| SigningKey               | Dies ist die Zertifikatsdatei, die auf der Seite View SAML setup instructions heruntergeladen wurde.    | string |
| SingleSignOnServiceUrl   | Dies ist die Anmelde-URL, die auf der Seite View SAML setup instructions bereitgestellt wurde.          | string |

## Beispiel: Shibboleth

Dieses Beispiel zeigt, wie Sie Shibboleth für die Verwendung mit PowerShell Universal konfigurieren. Es bietet die sehr grundlegende Konfiguration und folgt nicht notwendigerweise Best Practices.

Hierbei wird davon ausgegangen, dass Sie Shibboleth Identity Provider v4 mit Active Directory-Integration installiert haben.

### ldap.properties

Die LDAP-Eigenschaften wurden so konfiguriert, dass die Authentifizierung gegen die lokale Domäne mit einem Domänenadministratorkonto erfolgt. Die LDAP-URL wurde konfiguriert und TLS wurde deaktiviert.

Unten finden Sie das vollständige Beispiel der Datei `ldap.properties`.

{% code collapsedlinecount="10" %}

```
# LDAP authentication (and possibly attribute resolver) configuration
# Note, this doesn't apply to the use of JAAS authentication via LDAP

## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthenticator
idp.authn.LDAP.authenticator=adAuthenticator

## Connection properties ##
idp.authn.LDAP.ldapURL=ldap://ironman.local:389
idp.authn.LDAP.useStartTLS                     = false
# Time in milliseconds that connects will block
#idp.authn.LDAP.connectTimeout                  = PT3S
# Time in milliseconds to wait for responses
#idp.authn.LDAP.responseTimeout                 = PT3S
# Connection strategy to use when multiple URLs are supplied, either ACTIVE_PASSIVE, ROUND_ROBIN, RANDOM
#idp.authn.LDAP.connectionStrategy               = ACTIVE_PASSIVE

## SSL configuration, either jvmTrust, certificateTrust, or keyStoreTrust
idp.authn.LDAP.sslConfig                       = jvmTrust
## If using certificateTrust above, set to the trusted certificate's path
idp.authn.LDAP.trustCertificates=%{idp.home}/credentials/ldap-server.crt
## If using keyStoreTrust above, set to the truststore path
idp.authn.LDAP.trustStore=%{idp.home}/credentials/ldap-server.truststore

## Return attributes during authentication
idp.authn.LDAP.returnAttributes=passwordExpirationTime,loginGraceRemaining,sn,mail

## DN resolution properties ##

# Search DN resolution, used by anonSearchAuthenticator, bindSearchAuthenticator
# for AD: CN=Users,DC=example,DC=org
idp.authn.LDAP.baseDN=CN=Users,DC=ironman, DC=local
idp.authn.LDAP.subtreeSearch                   = true
idp.authn.LDAP.userFilter=(sAMAccountName={user})
# bind search configuration
# for AD: idp.authn.LDAP.bindDN=adminuser@domain.com
idp.authn.LDAP.bindDN=administrator@ironman.local

# Format DN resolution, used by directAuthenticator, adAuthenticator
# for AD use idp.authn.LDAP.dnFormat=%s@domain.com
idp.authn.LDAP.dnFormat=%s@ironman.local

# pool passivator, either none, bind or anonymousBind
#idp.authn.LDAP.bindPoolPassivator                  = none

# LDAP attribute configuration, see attribute-resolver.xml
# Note, this likely won't apply to the use of legacy V2 resolver configurations
idp.attribute.resolver.LDAP.ldapURL=%{idp.authn.LDAP.ldapURL}
idp.attribute.resolver.LDAP.connectTimeout=%{idp.authn.LDAP.connectTimeout:PT3S}
idp.attribute.resolver.LDAP.responseTimeout=%{idp.authn.LDAP.responseTimeout:PT3S}
idp.attribute.resolver.LDAP.connectionStrategy=%{idp.authn.LDAP.connectionStrategy:ACTIVE_PASSIVE}
idp.attribute.resolver.LDAP.baseDN=%{idp.authn.LDAP.baseDN:undefined}
idp.attribute.resolver.LDAP.bindDN=%{idp.authn.LDAP.bindDN:undefined}
idp.attribute.resolver.LDAP.useStartTLS=%{idp.authn.LDAP.useStartTLS:true}
idp.attribute.resolver.LDAP.trustCertificates=%{idp.authn.LDAP.trustCertificates:undefined}
idp.attribute.resolver.LDAP.searchFilter=(sAMAccountName=$resolutionContext.principal)

# LDAP pool configuration, used for both authn and DN resolution
#idp.pool.LDAP.minSize                          = 3
#idp.pool.LDAP.maxSize                          = 10
#idp.pool.LDAP.validateOnCheckout               = false
#idp.pool.LDAP.validatePeriodically             = true
#idp.pool.LDAP.validatePeriod                   = PT5M
#idp.pool.LDAP.validateDN                       =
#idp.pool.LDAP.validateFilter                   = (objectClass=*)
#idp.pool.LDAP.prunePeriod                      = PT5M
#idp.pool.LDAP.idleTime                         = PT10M
#idp.pool.LDAP.blockWaitTime                    = PT3S

```

{% endcode %}

### relying-party.xml

Die Datei `relying-party.xml` wurde aktualisiert, um einen offenen IdP zu aktivieren. Das bedeutet, dass jede Entity ID mit dem Identitätsanbieter kommunizieren kann. Sie können dies auch so konfigurieren, dass bestimmte Entity IDs erzwungen werden. Die Standardkonfiguration wurde ebenfalls angepasst, um das Bean `SAML2.AttributeQuery` zu verwenden.

{% code collapsedlinecount="10" %}

```
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:c="http://www.springframework.org/schema/c"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                           http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"
                           
       default-init-method="initialize"
       default-destroy-method="destroy">

    <!--
    Unverified RP configuration, defaults to no support for any profiles. Add <ref> elements to the list
    to enable specific default profile settings (as below), or create new beans inline to override defaults.
    
    "Unverified" typically means the IdP has no metadata, or equivalent way of assuring the identity and
    legitimacy of a requesting system. To run an "open" IdP, you can enable profiles here.
    -->
    <bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
			<bean parent="SAML2.SSO" p:encryptAssertions="false" />
            </list>
        </property>
    </bean>

    <!-- Default configuration, with default settings applied for all profiles. -->
    <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
                <!-- SAML 1.1 and SAML 2.0 AttributeQuery are disabled by default. -->
                <!--
                <bean parent="Shibboleth.SSO" />
                <ref bean="SAML1.AttributeQuery" />
                <ref bean="SAML1.ArtifactResolution" />
                -->
                <bean parent="SAML2.SSO" />
                <ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <ref bean="SAML2.AttributeQuery" />
                <ref bean="SAML2.ArtifactResolution" />
                <ref bean="Liberty.SSOS" />
            </list>
        </property>
    </bean>
</beans>

```

{% endcode %}

### attribute-resolver.xml

Die Datei `attribute-resolver.xml` wurde aktualisiert, um den LDAPDirectory-Datenkonnektor zu verwenden. Sie lädt die E-Mail-Adresse, den Vornamen, SN und den Anzeigenamen aus Active Directory. Anschließend ordnet sie den Principal Name, der dem Benutzernamen des sich anmeldenden Benutzers entspricht, mithilfe eines Attribut-Encoders dem erforderlichen Claim-Typ zu.

{% code collapsedlinecount="10" %}

```
<?xml version="1.0" encoding="UTF-8"?>
<!--
    This file is an EXAMPLE configuration file containing some example attributes
    based on some commonly used approaches when LDAP is the principal data source.
     
    Not all attribute definitions or data connectors are demonstrated, but some
    LDAP attributes common to Shibboleth deployments (and some not so common) are
    included.

    This example is in no way usable as a substitute for reading the documentation.    
-->
<AttributeResolver
        xmlns="urn:mace:shibboleth:2.0:resolver"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd">

    <!-- ========================================== -->
    <!--      Attribute Definitions                 -->
    <!-- ========================================== -->

    <!-- Simple attributes are exported directly from the LDAP connector. -->

    <AttributeDefinition id="uid" xsi:type="PrincipalName" />
    <AttributeDefinition id="username" xsi:type="PrincipalName">
         <AttributeEncoder xsi:type="SAML2String" name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" friendlyName="displayName" encodeType="false" />
    </AttributeDefinition>

    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->

    <!-- Example LDAP Connector -->

    <DataConnector id="myLDAP" xsi:type="LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="%{idp.attribute.resolver.LDAP.baseDN}" 
        principal="%{idp.attribute.resolver.LDAP.bindDN}"
        principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
        useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}"
        connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}"
        responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}"
        connectionStrategy="%{idp.attribute.resolver.LDAP.connectionStrategy}"
        noResultIsError="true"
        multipleResultsIsError="true"
        excludeResolutionPhases="c14n/attribute"
        exportAttributes="mail displayName sn givenName">
        <FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </FilterTemplate>
        <ConnectionPool
            minPoolSize="%{idp.pool.LDAP.minSize:3}"
            maxPoolSize="%{idp.pool.LDAP.maxSize:10}"
            blockWaitTime="%{idp.pool.LDAP.blockWaitTime:PT3S}"
            validatePeriodically="%{idp.pool.LDAP.validatePeriodically:true}"
            validateTimerPeriod="%{idp.pool.LDAP.validatePeriod:PT5M}"
            validateDN="%{idp.pool.LDAP.validateDN:}"
            validateFilter="%{idp.pool.LDAP.validateFilter:(objectClass=*)}"
            expirationTime="%{idp.pool.LDAP.idleTime:PT10M}"/>
    </DataConnector>

</AttributeResolver>

```

{% endcode %}

### attribute-filter.xml

Die Datei `attribute-filter.xml` wurde aktualisiert, um mehrere der vom LDAPDirectory-Datenkonnektor zugeordneten Attribute sowie den Benutzernamen freizugeben, der als Identität innerhalb von PowerShell Universal verwendet wird.

{% code collapsedlinecount="10" %}

```
<?xml version="1.0" encoding="UTF-8"?>
<!-- 
    This file is an EXAMPLE policy file.  While the policy presented in this 
    example file is illustrative of some simple cases, it relies on the names of
    non-existent example services and the example attributes demonstrated in the
    default attribute-resolver.xml file.

    This example does contain some usable "general purpose" policies that may be
    useful in conjunction with specific deployment choices, but those policies may
    not be applicable to your specific needs or constraints.    
-->
<AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
        xmlns="urn:mace:shibboleth:2.0:afp"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd">

<AttributeFilterPolicy id="example1">
        <PolicyRequirementRule xsi:type="ANY" />
        <AttributeRule attributeID="username">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="displayName">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="uid">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="mail">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="sn">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
    </AttributeFilterPolicy>
 


</AttributeFilterPolicyGroup>

```

{% endcode %}


---

# 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/enterprise-security/saml2.md?ask=<question>&goal=<endgoal>
```

`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.