For the complete documentation index, see llms.txt. This page is also available as Markdown.

Configuration générale

Pour permettre à SCEPman de traiter correctement les requêtes SOAP entrantes, nous devons suivre quelques étapes :

1

domaine personnalisé

Pour une authentification réussie avec SCEPman, assurez-vous qu’un domaine personnalisé utilisant un enregistrement A pointe vers l’App Service. Sinon, le client ne parviendra pas à demander un ticket Kerberos valide au contrôleur de domaine.

Le domaine personnalisé n’a pas besoin de ressembler au FQDN de votre domaine AD. Donc, avoir un domaine ad.contoso.local ne signifie pas que vous devez utiliser un domaine personnalisé identique ou similaire pour SCEPman.

Consultez le problème connu ci-dessous concernant WS_E_ENDPOINT_ACCESS_DENIED pour plus d’informations.

Assurez-vous que SCEPman est configuré pour être accessible via un domaine personnalisé :

Domaine personnalisé
2

BaseUrl

Pour permettre des authentifications réussies, assurez-vous que la AppConfig:BaseUrl variable corresponde à votre domaine personnalisé.

Paramètre
Valeur

AppConfig:BaseUrl

Exemple : scepman.contoso.com

Sinon, si vous préférez accéder au point de terminaison AD à l’aide d’une URL différente de celle de vos autres points de terminaison SCEPman, utilisez le paramètre dédié AppConfig:ActiveDirectory:BaseUrl .

Paramètre
Valeur

AppConfig:ActiveDirectory:BaseUrl

Exemple : adendpoint.contoso.com

3

Créer le Service Principal

Utilisez l' New-SCEPmanADPrincipal Cmdlet du module PowerShell SCEPman pour créer le Service Principal dans votre domaine Active Directory sur site. Il exportera également un keytab à partir de ce compte et le chiffrera avec le certificat d’AC de SCEPman.

Vous pouvez exécuter cette commande sur un Domain Controller ou sur un serveur joint au domaine sur lequel a été installé le RSAT-AD-Tools fonctionnalité. Vous aurez également besoin des autorisations suivantes dans l’OU dans laquelle vous souhaitez créer le principal :

Sur l’OU elle-même :

  • Créer des objets ordinateur

Sur les objets ordinateur descendants :

  • Réinitialiser le mot de passe

  • Écrire msDS-SupportedEncryptionTypes

  • Écrire servicePrincipalName

  • Écrire userPrincipalName

La variante ci-dessous nécessite également un accès réseau HTTPS sortant vers votre instance SCEPman.

Si votre ordinateur ayant accès à un Domain Controller n’a pas d’accès réseau, il existe des variantes de la CMDlet qui fonctionnent sans cela, mais elles nécessitent une préparation supplémentaire, comme le téléchargement du certificat d’AC de SCEPman et la copie de l’AC sur la machine qui exécute la CMDlet.

Install-Module SCEPman -Force
New-SCEPmanADPrincipal -Name "SCEPmanAD" -AppServiceUrl "scepman.contoso.com" -OU
"OU=Example,DC=contoso,DC=local"

L’exécution de cette commande effectuera les opérations suivantes :

  1. Créer un objet ordinateur dans le OU=Example,DC=contoso,DC=local unité d’organisation.

  2. Télécharger le certificat d’AC de SCEPman pour chiffrer le keytab à l’étape 5.

  3. Ajouter un nom de principal de service (SPN) à l’objet ordinateur.

  4. Créer un keytab pour le compte ordinateur contenant la clé de chiffrement basée sur le mot de passe de l’ordinateur.

  5. Chiffrer le keytab avec le certificat d’AC de SCEPman, afin que seul SCEPman puisse le déchiffrer à nouveau à l’aide de la clé privée de l’AC.

  6. Produire le keytab chiffré, afin qu’il puisse être transféré vers la configuration de SCEPman.

La sortie encodée en Base64 doit ensuite être ajoutée à la variable d’environnement AppConfig:ActiveDirectory:Keytab sur votre App Service SCEPman.

4

Ajouter le keytab à SCEPman

L’intégration peut être facilement activée en ajoutant les variables d’environnement suivantes dans le App Service SCEPman. Selon votre cas d’usage, activez un ou plusieurs des modèles de certificat disponibles :

Exemple avec tous les modèles de certificat activés :

Paramètre
Valeur

Keytab encodé en Base64 pour le Service Principal créé à l’ Étape 3

true

true

true

true

Problèmes connus

WS_E_ENDPOINT_ACCESS_DENIED

Erreur : WS_E_ENDPOINT_ACCESS_DENIED 
Hex : 0x803d0005
Dec : -2143485947

Cette erreur est connue pour se produire lors de la validation du serveur CEP lorsque vous utilisez les par défaut URI de l’App Service Azure. Cette erreur est provoquée par le protocole Kerberos qui demande un nom de principal de service enregistrement A du service auquel on doit accéder. Dans le cas des domaines App Service par défaut, par exemple contoso.azurewebsites.net est un CNAME et pointe vers un enregistrement A semblable à :

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

Comme ce enregistrement A d’un hôte d’infrastructure n’est pas garanti de rester cohérent à l’avenir, l’ajout d’un nom de principal de service pour cet hôte est déconseillé.

Veillez à ajouter un domaine personnalisé à votre app service et à utiliser un enregistrement A auprès de votre fournisseur DNS pour le faire pointer vers l’app service au lieu d’un CNAME.

Domaine personnalisé

ERROR_INVALID_PARAMETER

Erreur : ERROR_INVALID_PARAMETER
Hex : 0x80070057
Dec : -2147024809

Cette erreur se produit lors de l’enregistrement du serveur CEP si vous saisissez une URI commençant par http://. Veillez à enregistrer un serveur CEP uniquement avec https:// .

ERROR_ACCESS_DENIED

Lors de l’enregistrement d’un serveur CEP dans le contexte de la machine, l’utilisateur effectif (le compte qui a lancé gpmc.msc) doit être membre du groupe local Administrateurs sur l’ordinateur pendant la modification de l’objet GPO.

Veillez à lancer gpmc.msc avec des privilèges élevés dans ce cas.

Mis à jour

Ce contenu vous a-t-il été utile ?