Allgemeine Konfiguration

Um SCEPman zu ermöglichen, eingehende SOAP-Anfragen erfolgreich zu verarbeiten, müssen wir einige Schritte durchführen:

1

Benutzerdefinierte Domäne und BaseUrl

Für eine erfolgreiche Authentifizierung mit SCEPman stellen Sie sicher, dass eine benutzerdefinierte Domäne mit einem A-Record auf den App Service verweist. Andernfalls kann der Client kein gültiges Kerberos-Ticket vom Domänencontroller anfordern.

circle-info

Die benutzerdefinierte Domäne muss dem FQDN Ihrer AD-Domäne nicht ähneln. Wenn Sie also eine Domäne ad.contoso.local haben, bedeutet das nicht, dass Sie für SCEPman eine identische oder ähnliche benutzerdefinierte Domäne benötigen.

Siehe den unten beschriebenen bekannten Fehler zu WS_E_ENDPOINT_ACCESS_DENIED für weitere Informationen dazu.

Stellen Sie sicher, dass SCEPman so konfiguriert ist, dass es über eine benutzerdefinierte Domäne erreichbar ist:

benutzerdefinierte Domänechevron-right

Die gleiche Anforderung gilt auch nach der ersten Richtlinienanfrage (Auflisten der Zertifikatvorlagen) zum Registrieren von Zertifikaten. Damit die Authentifizierung erfolgreich ist, stellen Sie sicher, dass die AppConfig:BaseUrl Variable mit Ihrer benutzerdefinierten Domäne übereinstimmt, oder verwenden Sie die dedizierte AppConfig:ActiveDirectory:BaseUrl Einstellung, wenn Sie den AD-Endpunkt lieber über eine andere URL als Ihre anderen SCEPman-Endpunkte aufrufen möchten.

2

Service Principal erstellen

Verwenden Sie den New-SCEPmanADPrincipal Cmdlet des SCEPman PowerShell-Moduls, um den Service Principal in Ihrer lokalen Active-Directory-Domäne zu erstellen. Außerdem wird ein Keytab aus diesem Konto exportiert und mit dem CA-Zertifikat von SCEPman verschlüsselt.

Sie können diesen Befehl auf einem Domänencontroller oder einem domänenverbundenen Server ausführen, auf dem das RSAT-AD-Tools Feature installiert ist. Sie benötigen außerdem die folgenden Berechtigungen in der OU, in der Sie den Principal erstellen möchten:

Auf der OU selbst:

  • Computerobjekte erstellen

Für untergeordnete Computerobjekte:

  • Kennwort zurücksetzen

  • Schreiben msDS-SupportedEncryptionTypes

  • Schreiben servicePrincipalName

  • Schreiben userPrincipalName

Die untenstehende Variante erfordert außerdem ausgehenden HTTPS-Netzwerkzugriff auf Ihre SCEPman-Instanz.

circle-info

Wenn Ihr Computer mit Zugriff auf einen Domänencontroller keinen Netzwerkzugriff hat, gibt es Varianten des CMDlets, die ohne diesen funktionieren, jedoch zusätzliche Vorbereitungen erfordern, z. B. das Herunterladen des SCEPman-CA-Zertifikats und das Kopieren der CA auf den Computer, auf dem das CMDlet ausgeführt wird.

Die Ausführung dieses Befehls bewirkt Folgendes:

  1. Ein Computerobjekt in der OU=Example,DC=contoso,DC=com Organisationseinheit erstellen.

  2. Das CA-Zertifikat von SCEPman herunterladen, um den Keytab in Schritt 5 zu verschlüsseln.

  3. Einen Dienstprinzipalnamen (SPN) zum Computerobjekt hinzufügen.

  4. Einen Keytab für das Computerkonto erstellen, der den auf dem Kennwort des Computers basierenden Verschlüsselungsschlüssel enthält.

  5. Den Keytab mit dem CA-Zertifikat von SCEPman verschlüsseln, sodass nur SCEPman ihn mithilfe des privaten CA-Schlüssels wieder entschlüsseln kann.

  6. Den verschlüsselten Keytab ausgeben, damit er in die Konfiguration von SCEPman übertragen werden kann.

Die Base64-kodierte Ausgabe muss dann zur Umgebungsvariable AppConfig:ActiveDirectory:Keytab Ihres SCEPman App Service hinzugefügt werden.

3

Keytab zu SCEPman hinzufügen

Die Integration kann einfach aktiviert werden, indem die folgenden Umgebungsvariablen im SCEPman App Service hinzugefügt werden. Je nach Anwendungsfall aktivieren Sie eine oder mehrere der verfügbaren Zertifikatvorlagen:

Beispiel mit allen aktivierten Zertifikatvorlagen:

Einstellung
Wert

AppConfig:ActiveDirectory:Keytab

Base64-kodierter Keytab für den in Schritt 1 erstellten Service Principal

AppConfig:ActiveDirectory:Computer:Enabled

true

AppConfig:ActiveDirectory:User:Enabled

true

AppConfig:ActiveDirectory:DC:Enabled

true

Bekannte Probleme

WS_E_ENDPOINT_ACCESS_DENIED

Fehler: WS_E_ENDPOINT_ACCESS_DENIED 
Hex: 0x803d0005
Dez: -2143485947

Dieser Fehler tritt bekanntermaßen während der Validierung des CEP-Servers auf, wenn Sie die Standard -URIs des Azure App Service verwenden. Dieser Fehler wird dadurch verursacht, dass das Kerberos-Protokoll nach einem Dienstprinzipalnamen des A-Records des Dienstes fragt, auf den zugegriffen werden soll. Im Fall der standardmäßigen App-Service-Domänen, zum Beispiel contoso.azurewebsites.net ist dies nur ein CNAME und verweist auf einen A-Record ähnlich wie:

waws-prod-ab1-234-c56d.westeurope.cloudapp.azure.com

Da dieser A-Record eines Infrastrukturhosts in Zukunft nicht konsistent garantiert ist, wird das Hinzufügen eines Dienstprinzipalnamens für diesen Host nicht empfohlen.

Stellen Sie sicher, dass Sie Ihrem App Service eine benutzerdefinierte Domäne hinzufügen und stattdessen bei Ihrem DNS-Anbieter einen A-Record verwenden, der auf den App Service verweist, anstatt eines CNAME.

benutzerdefinierte Domänechevron-right

ERROR_INVALID_PARAMETER

Fehler: ERROR_INVALID_PARAMETER
Hex: 0x80070057
Dez: -2147024809

Dieser Fehler tritt während der Registrierung des CEP-Servers auf, wenn Sie eine URI eingeben, die mit http://beginnt. Stellen Sie sicher, dass Sie einen CEP-Server nur mit https://

ERROR_ACCESS_DENIED

Wenn Sie einen CEP-Server im Maschinenkontext registrieren, muss der handelnde Benutzer (das Konto, das gpmc.mscgestartet hat) während der Bearbeitung der GPO Mitglied der lokalen Gruppe der Administratoren auf dem Computer sein.

Stellen Sie sicher, dass Sie in diesem Fall gpmc.msc mit erhöhten Berechtigungen starten.

Zuletzt aktualisiert

War das hilfreich?