> 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

{% 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.

<figure><img src="/files/bQVWgWTy1whu0uw9lzWk" alt=""><figcaption><p>Metadaten laden</p></figcaption></figure>

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

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

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

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

### 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 PowerShell Universal-Verwaltungskonsole konfigurieren können. Um SAML2-Unterstützung hinzuzufügen, klicken Sie auf Security \ Authentication. In der oberen rechten Ecke können Sie SAML2 aus dem Dropdown-Menü auswählen.

![](/files/ArV6eN0o9mNzbvk69H7q)

Sobald 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 in Ihrem Identitätsanbieter konfiguriert sind.

<figure><img src="/files/gRsEocMWxgadMtLJX56w" alt=""><figcaption><p>SAML2-Eigenschaften</p></figcaption></figure>

Das Dienstzertifikat wird zum Signieren von Anfragen verwendet. Es ist nicht erforderlich. Dies kann entweder ein für den PSU-Dienst lokaler Pfad oder der Distinguished Name eines im Zertifikatspeicher „Personal Computer“ installierten Zertifikats sein.

### Zusätzliche Einstellungen

Zusätzlich zu den in der Verwaltungskonsole verfügbaren Einstellungen können Sie Folgendes 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.

```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')
```

#### 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/develop/Sustainsys.Saml2.AspNetCore2/Saml2Options.cs). Das Unterobjekt von SPOptions finden Sie [hier](https://github.com/Sustainsys/Saml2/blob/20990905ecdcf15f6f76fef80506d53831f7857b/Sustainsys.Saml2/Configuration/SPOptions.cs).

```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'
}
```

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

Richten Sie eine Entra ID Enterprise Application innerhalb von Azure ein. Eine [Schritt-für-Schritt-Anleitung finden Sie hier](https://docs.powershelluniversal.com/config/security/openid-connect#configuring-azure-entra-id-azure-active-directory). Sie müssen die Anwendungs-ID und das Federation-Metadatendokument sowie den SAML-P-Anmeldeendpunkt abrufen. Klicken Sie in Ihrer Anwendungsregistrierung auf die Schaltfläche Endpoints.

<figure><img src="/files/snWlTy3eU9HghFyBj8UE" alt=""><figcaption></figcaption></figure>

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

**Innerhalb von PowerShell Universal:**

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

Für die 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 die Identity Provider Entity ID müssen Sie die Entity ID aus dem Federation-Metadatendokument abrufen. Öffnen Sie die Dokument-URL in einem Webbrowser.

<figure><img src="/files/dQWs7AsOn9kQ5SKBc8WG" alt=""><figcaption></figcaption></figure>

Fügen Sie für Metadata Address die URL des Federation-Metadatendokuments ein.

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

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

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

<figure><img src="/files/4BWrZUZ1ascsPOMAe9iB" alt=""><figcaption><p>PSU-Konfiguration</p></figcaption></figure>

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

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

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-Zuordnung

Um PowerShell Universal Gruppen-Claims 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.

<figure><img src="/files/xHNpl6vMl8pTyTwzVX5p" alt=""><figcaption><p>Entra ID-Gruppen-Claims</p></figcaption></figure>

Nachdem Sie auf Add groups claim geklickt haben, 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.

<figure><img src="/files/8jd7QGpsZiX3MebvBuql" alt=""><figcaption><p>Einstellung „Emit groups as role claims“</p></figcaption></figure>

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-Zuordnungen 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 den Claim Value für diese Rolle an. Beispielsweise habe ich 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.

<figure><img src="/files/plESMsykbsKBxiKUUMUP" alt=""><figcaption><p>Claim-Zuordnung</p></figcaption></figure>

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 mindern, 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 anschließend auf die Schaltfläche Edit unter Attributes & Claims.

<figure><img src="/files/a9bl2UyGRpihjVqHgTpJ" alt=""><figcaption></figcaption></figure>

Klicken Sie auf den Gruppen-Claim, um die Optionen anzuzeigen. Die erweiterten Optionen ermöglichen es Ihnen, die Gruppen zu filtern, die an den PowerShell Universal-Server bereitgestellt werden. Sie können Gruppen-Claims auch über die Token-Konfiguration in der Application Registration für die Enterprise Application konfigurieren.

<figure><img src="/files/XHCqPG7DwlPkgNYSJXVo" alt=""><figcaption></figcaption></figure>

## Beispiel: Okta

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

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.

![](/files/KZfqRTbkxSdD6RxGvp83)

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

![](/files/qLUsMNQi5P96SMy4e0Ae)

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

![](/files/IomIVHylBD3o8PbTL79j)

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

### authentication.ps1

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

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

| Parameter                | Beschreibung                                                                                             | Typ    |
| ------------------------ | -------------------------------------------------------------------------------------------------------- | ------ |
| EntityId                 | Dieser Wert sollte mit dem übereinstimmen, was Sie in Okta unter Audience Restriction eingetragen 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 angegeben wurde.                | string |

## Beispiel: Shibboleth

Dieses Beispiel zeigt, wie Shibboleth für die Verwendung mit PowerShell Universal konfiguriert wird. Es bietet die grundlegendste Konfiguration und folgt nicht notwendigerweise Best Practices.

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

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

```

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

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

```

### attribute-resolver.xml

Die Datei `attribute-resolver.xml` wurde aktualisiert, um den LDAPDirectory Data Connector 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 der Benutzername des sich anmeldenden Benutzers ist, mithilfe eines Attribut-Encoders dem erforderlichen Claim Type zu.

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

```

### attribute-filter.xml

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

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

```


---

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