Best Practices zum Sichern von Active Directory-Verbunddiensten (AD FS)

  • Artikel
  • 12 Minuten Lesedauer

Dieses Dokument bietet bewährte Methoden für die sichere Planung und Bereitstellung von Active Directory-Verbunddienste (AD FS) (AD FS) und Web-Anwendungsproxy. Es enthält Empfehlungen für zusätzliche Sicherheitskonfigurationen, bestimmte Anwendungsfälle und Sicherheitsanforderungen.

Dieses Dokument gilt für AD FS und WAP in Windows Server 2012 R2, 2016 und 2019. Diese Empfehlungen können entweder für ein lokales Netzwerk oder in einer cloud gehosteten Umgebung wie Microsoft Azure verwendet werden.

Standardbereitstellungstopologie

Für die Bereitstellung in lokalen Umgebungen empfehlen wir eine Standardbereitstellungstopologie, die aus:

  • mindestens einen AD FS-Server im internen Unternehmensnetzwerk
  • mindestens ein Web-Anwendungsproxy (WAP)-Server in einem DMZ- oder Extranetnetzwerk.

Auf jeder Ebene, AD FS und WAP wird ein Hardware- oder Softwarelastenausgleich vor der Serverfarm platziert und das Datenverkehrsrouting verarbeitet. Firewalls werden nach Bedarf vor der externen IP-Adresse des Lastenausgleichs platziert.

A diagram depicting a standard A D F S topology.

Hinweis

AD FS erfordert eine vollständige schreibbare Domänencontrollerfunktion im Gegensatz zu einem Read-Only Domänencontroller. Wenn eine geplante Topologie einen Read-Only Domänencontroller enthält, kann der Read-Only Domänencontroller für die Authentifizierung verwendet werden, die LDAP-Anspruchsverarbeitung erfordert jedoch eine Verbindung mit dem schreibbaren Domänencontroller.

Härten Ihrer AD FS-Server

Nachfolgend sehen Sie eine Liste der bewährten Methoden und Empfehlungen für die Härtung und Sicherung Ihrer AD FS-Bereitstellung.

  • Stellen Sie sicher, dass nur Active Directory-Administratoren und AD FS-Administratoren Administratorrechte für das AD FS-System haben.
  • Verringern Sie die Gruppenmitgliedschaft lokaler Administratoren auf allen AD FS-Servern.
  • Erfordern, dass alle Cloudadministratoren mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) verwenden.
  • Minimale Verwaltungsfunktion über Agents.
  • Beschränken Sie den Zugriff auf das Netzwerk über die Hostfirewall.
  • Stellen Sie sicher, dass AD FS-Administratoren Admin Arbeitsstationen verwenden, um ihre Anmeldeinformationen zu schützen.
  • Platzieren Sie AD FS-Servercomputerobjekte in einer ORGANISATIONS auf oberster Ebene, die auch keine anderen Server hosten.
  • Alle GPOs, die für AD FS-Server gelten, sollten nur auf sie und nicht auf anderen Servern angewendet werden. Dadurch wird die potenzielle Eskalation der Berechtigungen durch die Änderung des Gruppenrichtlinienobjekts begrenzt.
  • Stellen Sie sicher, dass die installierten Zertifikate vor Diebstahl geschützt sind (speichern Sie diese nicht in einer Freigabe im Netzwerk) und legen Sie eine Kalendererinnerung fest, um sicherzustellen, dass sie vor ablaufen (abgelaufene Zertifikatumbrüche Verbundauthentifizierung) erneuert werden. Darüber hinaus empfehlen wir den Schutz von Signaturschlüsseln/Zertifikaten in einem Hardwaresicherheitsmodul (HSM), das an AD FS angefügt ist.
  • Legen Sie die Protokollierung auf die höchste Ebene fest, und senden Sie die AD FS-Protokolle (& Sicherheit) an ein SIEM, um mit DER AD-Authentifizierung sowie AzureAD (oder ähnlich) zu korrelieren.
  • Entfernen unnötiger Protokolle & Windows Features
  • Verwenden Sie ein langes (>25 Zeichen), komplexes Kennwort für das AD FS-Dienstkonto. Es wird empfohlen, ein gruppenverwaltetes Dienstkonto (gMSA) als Dienstkonto zu verwenden, da es die Notwendigkeit für die Verwaltung des Dienstkontokennworts im Laufe der Zeit entfernt, indem sie es automatisch verwalten.
  • Aktualisieren Sie die neueste AD FS-Version für Sicherheits- und Protokollierungsverbesserungen (wie immer, testen Sie zuerst).

Ports erforderlich

Das folgende Diagramm zeigt die Firewallports, die zwischen und zwischen den Komponenten der AD FS- und WAP-Bereitstellung aktiviert werden müssen. Wenn die Bereitstellung Azure AD /Office 365 nicht enthält, können die Synchronisierungsanforderungen ignoriert werden.

Beachten Sie, dass Port 49443 nur erforderlich ist, wenn die Benutzerzertifikatauthentifizierung verwendet wird, die optional für Azure AD und Office 365 ist.

a diagram showing the required ports and protocols for an A D F S deployment.

Hinweis

Port 808 (Windows Server 2012R2) oder Port 1501 (Windows Server 2016+) ist der Net.TCP-Port AD FS, der für den lokalen WCF-Endpunkt verwendet wird, um Konfigurationsdaten an den Dienstprozess und PowerShell zu übertragen. Dieser Port kann durch Ausführen von Get-AdfsProperties | angezeigt werden. wählen Sie NetTcpPort aus. Dies ist ein lokaler Port, der nicht in der Firewall geöffnet werden muss, sondern in einem Portscan angezeigt wird.

Kommunikation zwischen Verbundservern

Verbundserver in einer AD FS-Farm kommunizieren mit anderen Servern in der Farm und den Web-Anwendungsproxy(WAP)-Servern über HTTP-Port 80 für die Konfigurationssynchronisierung. Stellen Sie sicher, dass nur diese Server miteinander kommunizieren können und keine andere ein Maß an Verteidigung ist.

Organisationen können diesen Zustand erreichen, indem Sie Firewallregeln auf jedem Server einrichten. Die Regeln sollten nur eingehende Kommunikation von den IP-Adressen der Server in der Farm und WAP-Servern zulassen. Beachten Sie, dass einige Netzwerklastenausgleichsgeräte (NLB) HTTP-Port 80 verwenden, um die Integrität auf einzelnen Verbundservern zu probieren. Stellen Sie sicher, dass Sie die IP-Adressen der NLB in die konfigurierten Firewallregeln einschließen.

Azure AD Verbinden und Verbundserver/WAP

In dieser Tabelle werden die Ports und Protokolle beschrieben, die für die Kommunikation zwischen dem Azure AD Connect-Server und Verbund-/WAP-Servern erforderlich sind.

Protocol Ports BESCHREIBUNG
HTTP 80 (TCP/UDP) Wird zum Herunterladen von Zertifikatsperrlisten zur Überprüfung von SSL-Zertifikaten verwendet
HTTPS 443 (TCP/UDP) Wird zum Synchronisieren mit Azure AD verwendet
WinRM 5985 WinRM-Listener

WAP- und Verbundserver

In dieser Tabelle werden die Ports und Protokolle beschrieben, die für die Kommunikation zwischen den Verbundservern und WAP-Servern erforderlich sind.

Protokoll Ports BESCHREIBUNG
HTTPS 443 (TCP/UDP) Wird für die Authentifizierung verwendet

WAP und Benutzer

In dieser Tabelle werden die Ports und Protokolle beschrieben, die für die Kommunikation zwischen Benutzern und den WAP-Servern erforderlich sind.

Protokoll Ports BESCHREIBUNG
HTTPS 443 (TCP/UDP) Wird für die Geräteauthentifizierung verwendet
TCP 49443 (TCP) Wird für die Zertifikatauthentifizierung verwendet

Informationen zu erforderlichen Ports und Protokollen, die für Hybridbereitstellungen erforderlich sind, finden Sie im folgenden Dokument.

Informationen zu Ports und Protokollen, die für eine Azure AD- und Office 365-Bereitstellung erforderlich sind, finden Sie im folgenden Dokument.

Endpunkte aktiviert

Wenn AD FS und WAP installiert werden, werden eine Standardmenge von AD FS-Endpunkten im Verbunddienst und im Proxy aktiviert. Diese Standardwerte wurden basierend auf den am häufigsten benötigten und verwendeten Szenarien ausgewählt, und es ist nicht erforderlich, sie zu ändern.

[Optional] Min set of endpoints proxy enabled for Azure AD / Office 365

Organisationen, die AD FS und WAP nur für Azure AD bereitstellen, und Office 365 Szenarien können die Anzahl der auf dem Proxy aktivierten AD FS-Endpunkte noch weiter einschränken, um eine minimale Angriffsfläche zu erzielen. Nachfolgend finden Sie die Liste der Endpunkte, die in diesen Szenarien auf dem Proxy aktiviert sein müssen:

Endpunkt Zweck
/adfs/ls Browserbasierte Authentifizierungsflüsse und aktuelle Versionen von Microsoft Office verwenden diesen Endpunkt für Azure AD und Office 365 Authentifizierung
/adfs/services/trust/2005/usernamemixed Wird für Exchange Online mit Office Clients verwendet, die älter als Office 2013-Update vom Mai 2015 sind. Später verwenden Clients den passiven \adfs\ls-Endpunkt.
/adfs/services/trust/13/usernamemixed Wird für Exchange Online mit Office Clients verwendet, die älter als Office 2013-Update vom Mai 2015 sind. Später verwenden Clients den passiven \adfs\ls-Endpunkt.
/adfs/oauth2 Wird für alle modernen Apps (on-prem oder in Cloud) verwendet, die Sie für die direkte Authentifizierung in AD FS (d. h. nicht über Azure AD) konfiguriert haben.
/adfs/services/trust/mex Wird für Exchange Online mit Office Clients verwendet, die älter als Office 2013 Mai 2015 Update sind. Später verwenden Clients den passiven \adfs\ls-Endpunkt.
/adfs/ls/federationmetadata/2007-06/federationmetadata.xml Anforderung für passive Flusse; und wird von Office 365 / Azure AD verwendet, um AD FS-Zertifikate zu überprüfen.

AD FS-Endpunkte können mithilfe des folgenden PowerShell-Cmdlets auf dem Proxy deaktiviert werden:

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Zum Beispiel:

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

Erweiterter Schutz für die Authentifizierung

Der erweiterte Schutz für die Authentifizierung ist ein Feature, das gegen den Mann in der Mitte (MITM) angreift und standardmäßig mit AD FS aktiviert ist.

Um die Einstellungen zu überprüfen, können Sie folgendes ausführen:

Die Einstellung kann mithilfe des folgenden PowerShell-Cmdlets überprüft werden.

Get-ADFSProperties

Die Eigenschaft ist ExtendedProtectionTokenCheck. Die Standardeinstellung ist "Zulassen", sodass die Sicherheitsvorteile ohne kompatibilitätsbezogene Probleme mit Browsern erreicht werden können, die die Funktion nicht unterstützen.

Verlastungssteuerung zum Schutz des Verbunddiensts

Der Verbunddienstproxy (Teil des WAP) bietet Überlastungskontrolle, um den AD FS-Dienst vor einer Flut von Anforderungen zu schützen. Das Web Anwendungsproxy lehnt externe Clientauthentifizierungsanforderungen ab, wenn der Verbundserver überlastet ist, wie die Latenz zwischen dem Web Anwendungsproxy und dem Verbundserver erkannt wird. Dieses Feature ist standardmäßig mit einer empfohlenen Latenzschwellenstufe konfiguriert.

Um die Einstellungen zu überprüfen, können Sie folgendes ausführen:

  1. Öffnen Sie auf dem Webanwendungsproxy-Computer ein Befehlsfenster mit erhöhten Rechten.
  2. Navigieren Sie zum AD FS-Verzeichnis unter %WINDIR%\adfs\config.
  3. Ändern Sie die Einstellungen für die Verlastungssteuerung von den Standardwerten in <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
  4. Speichern und schließen Sie die Datei.
  5. Starten Sie den AD FS-Dienst erneut, indem Sie net stop adfssrv und danach net start adfssrv ausführen. Anleitungen zu dieser Funktion finden Sie hier.

Standard-HTTP-Anforderungsprüfungen am Proxy

Der Proxy führt auch die folgenden Standardüberprüfungen für alle Datenverkehr aus:

  • Das FS-P selbst authentifiziert sich über ein kurzlebiges Zertifikat an AD FS. In einem Szenario mit verdächtigem Kompromittieren von dmz-Servern kann AD FS die Proxyvertrauenswürdigkeit widerrufen, sodass sie keine eingehenden Anforderungen von potenziell kompromittierten Proxies mehr vertrauen kann. Das Aufheben der Proxyvertrauenswürdigstellung bezieht sich auf jedes eigene Zertifikat des Proxys, sodass es für jeden Zweck nicht erfolgreich für den AD FS-Server authentifiziert werden kann.
  • Der FS-P beendet alle Verbindungen und erstellt eine neue HTTP-Verbindung zum AD FS-Dienst im internen Netzwerk. Dadurch wird ein Sitzungspuffer zwischen externen Geräten und dem AD FS-Dienst bereitgestellt. Das externe Gerät verbindet nie direkt mit dem AD FS-Dienst.
  • Die FS-P führt die HTTP-Anforderungsüberprüfung aus, die speziell HTTP-Header ausfiltert, die von AD FS-Dienst nicht erforderlich sind.

Stellen Sie sicher, dass alle AD FS- und WAP-Server die aktuellsten Updates erhalten Die wichtigste Sicherheitsempfehlung für Ihre AD FS-Infrastruktur besteht darin, sicherzustellen, dass Sie Ihre AD FS- und WAP-Server mit allen Sicherheitsupdates aktuell halten, sowie diese optionalen Updates, die für AD FS auf dieser Seite als wichtig angegeben sind.

Die empfohlene Möglichkeit für Azure AD-Kunden, ihre Infrastruktur zu überwachen und zu halten, ist über Azure AD Verbinden Health for AD FS, ein Feature von Azure AD Premium. Azure AD Verbinden Health enthält Monitore und Warnungen, die auslösen, wenn ein AD FS- oder WAP-Computer eine der wichtigen Updates für AD FS und WAP fehlt.

Informationen zum Installieren von Azure AD Verbinden Health für AD FS finden Sie hier.

Bewährte Methode zum Sichern und Überwachen der AD FS-Vertrauensstellung mit Azure AD

Wenn Sie AD FS und Azure AD verbinden, muss die Verbundkonfiguration (die konfigurierte Vertrauensstellung zwischen AD FS und Azure AD) eng überwacht werden, um alle ungewöhnlichen oder verdächtigen Aktivitäten zu erfassen. Dazu wird empfohlen, entsprechende Benachrichtigungen zu einrichten, damit Sie benachrichtigt werden, wenn Änderungen an der Verbundkonfiguration vorgenommen werden. Informationen zum Einrichten von Warnungen finden Sie unter Überwachen von Änderungen an der Verbundkonfiguration.

Zusätzliche Sicherheitskonfigurationen

Die folgenden zusätzlichen Funktionen können so konfiguriert werden, dass mehr Schutz bereitgestellt wird.

Extranet-Sperrschutz für Konten

Mit der Extranetsperrungsfunktion in Windows Server 2012 R2 kann ein AD FS-Administrator eine maximale zulässige Anzahl fehlgeschlagener Authentifizierungsanforderungen (ExtranetLockoutThreshold) und einen observation windowZeitraum (ExtranetObservationWindow) festlegen. Wenn diese maximale Anzahl (ExtranetLockoutThreshold) von Authentifizierungsanforderungen erreicht wird, versucht AD FS nicht mehr, die angegebenen Kontoanmeldeinformationen für den festgelegten Zeitraum (ExtranetObservationWindow) zu authentifizieren. Diese Aktion schützt dieses Konto vor einer AD-Kontosperrung, d. h. es schützt dieses Konto vor dem Verlust des Zugriffs auf Unternehmensressourcen, die auf AD FS für die Authentifizierung des Benutzers angewiesen sind. Diese Einstellungen gelten für alle Domänen, die der AD FS-Dienst authentifizieren kann.

Sie können den folgenden befehl Windows PowerShell verwenden, um das AD FS Extranet lockout (Beispiel):

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

Die öffentliche Dokumentation dieses Features ist hier.

Deaktivieren sie WS-Trust Windows Endpunkte auf dem Proxy, d. h. aus Extranet

WS-Trust Windows Endpunkte (/adfs/services/trust/2005/windowstransport und /adfs/services/trust/13/windowstransport) sind nur intranetseitige Endpunkte gedacht, die WIA-Bindung auf HTTPS verwenden. Durch das Exponenten von Extranet können Anforderungen gegen diese Endpunkte verwendet werden, um Sperrschutze zu umgehen. Diese Endpunkte sollten auf dem Proxy deaktiviert werden (z. B. aus Extranet deaktiviert), um die AD-Kontosperre mithilfe der folgenden PowerShell-Befehle zu schützen. Es gibt keine bekannten Endbenutzerwirkungen, indem diese Endpunkte auf dem Proxy deaktiviert werden.

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false
Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

Hinweis

Wenn Ihre AD FS-Farm auf Windows internen Datenbanken (WID) ausgeführt wird und über einen sekundären AD FS-Server verfügt, warten Sie nach dem Deaktivieren der Endpunkte auf dem primären Server auf die SYNCHRONISIERUNG, bevor Sie den AD FS-Dienst neu starten. Verwenden Sie den PowerShell-Befehl Get-AdfsSyncProperties auf dem sekundären Knoten, um den letzten SYNC-Prozess nachzuverfolgen.

Differenzieren von Zugriffsrichtlinien für Intranet- und Extranetzugriff

AD FS hat die Möglichkeit, Zugriffsrichtlinien für Anforderungen zu unterscheiden, die aus dem lokalen, Unternehmensnetzwerk und Anforderungen stammen, die über den Proxy aus dem Internet stammen. Diese Differenzierung kann pro Anwendung oder global erfolgen. Bei Anwendungen mit hohem Geschäftswert oder Anwendungen mit vertraulichen oder personenbezogenen Informationen sollten Sie die mehrstufige Authentifizierung erfordern. Mehrstufige Authentifizierung kann über das AD FS-Verwaltungs-Snap-In eingerichtet werden.

Erfordern einer mehrstufigen Authentifizierung (MFA)

AD FS kann so konfiguriert werden, dass eine starke Authentifizierung (z. B. mehrstufige Authentifizierung) speziell für Anforderungen über den Proxy, für einzelne Anwendungen und für bedingten Zugriff auf Azure AD/Office 365 und lokale Ressourcen erforderlich ist. Unterstützte Methoden von MFA umfassen sowohl Microsoft Azure MF- als auch Drittanbieter. Der Benutzer wird aufgefordert, die zusätzlichen Informationen (z. B. einen SMS Text mit einem einmaligen Code) bereitzustellen, und AD FS funktioniert mit dem anbieterspezifischen Plug-In, um den Zugriff zu ermöglichen.

Unterstützte externe MFA-Anbieter umfassen diejenigen, die auf dieser Seite aufgeführt sind, sowie HDI Global.

Aktivieren sie den Schutz, um das Übergeben von Cloud Azure AD Multi-Factor Authentication beim Partnerverbund mit Azure AD zu verhindern.

Aktivieren Sie den Schutz, um die Umgehung der Cloud azure AD Multi-Factor Authentication zu verhindern, wenn sie mit Azure AD verbunden sind und Azure AD Multi-Factor Authentication als Ihre mehrstufige Authentifizierung für Ihre Verbundbenutzer verwenden.

Wenn der Schutz für eine Verbunddomäne in Ihrem Azure AD-Mandanten aktiviert wird, wird sichergestellt, dass die Azure AD Multi-Factor Authentication immer ausgeführt wird, wenn ein Verbundbenutzer auf eine Anwendung zugreift, die von einer Bedingten Zugriffsrichtlinie abhängig ist, die MFA erfordert. Dies umfasst die Ausführung der Azure AD Multi-Factor Authentication auch dann, wenn der Partneridentitätsanbieter (über Verbundtokenansprüche) angegeben wurde, dass die vor dem MFA ausgeführt wurde. Das Erzwingen von Azure AD Multi-Factor Authentication jedes Mal stellt sicher, dass ein kompromittiertes Vorkonto azure AD Multi-Factor Authentication nicht umgehen kann, indem er die Multi-Factor-Authentifizierung bereits vom Identitätsanbieter ausführt und es wird dringend empfohlen, es sei denn, Sie führen MFA für Ihre Partnerbenutzer mit einem MFA-Anbieter eines Drittanbieters aus.

Der Schutz kann mithilfe einer neuen Sicherheitseinstellung aktiviert werden, federatedIdpMfaBehavior die als Teil des Cmdlets "Interne Verbund MS Graph-API" oder "MS Graph PowerShell" verfügbar gemacht wird. Die federatedIdpMfaBehavior Einstellung bestimmt, ob Azure AD die MFA akzeptiert, die vom Partneridentitätsanbieter ausgeführt wird, wenn ein Verbundbenutzer auf eine Anwendung zugreift, die von einer bedingten Zugriffsrichtlinie gesteuert wird, die MFA erfordert. Administratoren können einen der folgenden Werte auswählen:

Administratoren können einen der folgenden Werte auswählen:

Eigenschaft BESCHREIBUNG
acceptIfMfaDoneByFederatedIdp Azure AD akzeptiert MFA, wenn er vom Identitätsanbieter ausgeführt wird. Wenn nicht, führt Azure AD Multi-Factor Authentication aus.
enforceMfaByFederatedIdp Azure AD akzeptiert MFA, wenn er vom Identitätsanbieter ausgeführt wird. Wenn nicht, wird die Anforderung an den Identitätsanbieter umgeleitet, um MFA auszuführen.
rejectMfaByFederatedIdp Azure AD führt immer Azure AD Multi-Factor Authentication aus und lehnt MFA ab, wenn der Identitätsanbieter ausgeführt wird.

Sie können den Schutz aktivieren, indem Sie den folgenden Befehl verwenden federatedIdpMfaBehaviorrejectMfaByFederatedIdp .

MS GRAPH-API


 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

}

Beispiel:

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"

PowerShell

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Beispiel:

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Hardwaresicherheitsmodul (HSM)

In der Standardkonfiguration verwendet die Schlüssel AD FS zum Signieren von Token nie die Verbundserver im Intranet. Sie sind nie in der DMZ oder auf den Proxycomputern vorhanden. Optional wird empfohlen, diese Schlüssel in einem Hardwaresicherheitsmodul (HSM) zu schützen, das an AD FS angefügt ist. Microsoft produziert kein HSM-Produkt, es gibt jedoch mehrere auf dem Markt, die AD FS unterstützen. Um diese Empfehlung zu implementieren, folgen Sie den Richtlinien des Anbieters, um die X509-Zertifikate für die Signatur und Verschlüsselung zu erstellen, und verwenden Sie dann die AD FS-Installations-PowerShell-Installationsbefehle, die Ihre benutzerdefinierten Zertifikate wie folgt angeben:

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

Dabei gilt:

  • CertificateThumbprint ist Ihr SSL-Zertifikat
  • SigningCertificateThumbprint ist Ihr Signaturzertifikat (mit HSM geschützter Schlüssel)
  • DecryptionCertificateThumbprint ist Ihr Verschlüsselungszertifikat (mit HSM geschützter Schlüssel)