Cet article a été traduit automatiquement. La traduction peut contenir des imprécisions.
Passer à la version originale en anglais.
Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Configuration générale

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

1. Domaine personnalisé et BaseUrl

Pour une authentification réussie avec SCEPman, assurez-vous qu’un domaine personnalisé utilisant un enregistrement A est pointé vers l’App Service. Sinon, le client ne parviendra pas à demander un ticket Kerberos valide auprès du Domain Controller.

Le domaine personnalisé n’a pas besoin de ressembler au FQDN de votre domaine AD. Ainsi, disposer d’un domaine ad.contoso.local ne signifie pas que vous ayez besoin d’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 à l’aide d’un domaine personnalisé :

Domaine personnalisé

La même exigence s’applique également après la demande initiale de stratégie (liste des modèles de certificat) pour l’inscription des certificats. Pour permettre des authentifications réussies, assurez-vous que la AppConfig:BaseUrl variable corresponde à votre domaine personnalisé ou utilisez le paramètre dédié AppConfig:ActiveDirectory:BaseUrl si vous préférez accéder à l’AD Endpoint via une URL différente de celle de vos autres points de terminaison SCEPman.

2. Créer le Service Principal

Utilisez le 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 CA de SCEPman.

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

Dans l’UO 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 l’ordinateur depuis lequel vous avez accès à un Domain Controller n’a pas accès au réseau, il existe des variantes du CMDlet qui fonctionnent sans cela, mais qui nécessitent une préparation supplémentaire, comme le téléchargement du certificat CA de SCEPman et la copie du certificat CA sur la machine qui exécute le CMDlet.

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

  1. Créer un objet ordinateur dans le OU=Example,DC=contoso,DC=com Unité organisationnelle.

  2. Télécharger le certificat CA 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 CA 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é dans la configuration de SCEPman.

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

3. Ajouter le keytab à SCEPman

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

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

Paramètre

Valeur

AppConfig:ActiveDirectory:Keytab

keytab encodé en Base64 pour le Service Principal créé à l’étape 1

AppConfig:ActiveDirectory:Computer:Enabled

true

AppConfig:ActiveDirectory:User:Enabled

true

AppConfig:ActiveDirectory:DC:Enabled

true

Problèmes connus

WS_E_ENDPOINT_ACCESS_DENIED

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

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

Assurez-vous d’ajouter un domaine personnalisé à votre App Service et d’utiliser un enregistrement A auprès de votre fournisseur DNS pour le pointer vers l’App Service plutôt qu’un CNAME.

Domaine personnalisé

ERROR_INVALID_PARAMETER

Cette erreur se produit lors de l’enregistrement du serveur CEP en contexte machine si vous saisissez une URI commençant par http://. Assurez-vous d’enregistrer un serveur CEP uniquement à l’aide de https://

ERROR_ACCESS_DENIED

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

Assurez-vous de lancer gpmc.msc avec des privilèges élevés dans ce cas.

Mis à jour

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