Un nom principal de service est-il requis lors de l'utilisation de Kerberos avec DCOM?

Question

J'utilise DCOM pour fournir divers services d'application sur un réseau Windows, en utilisant Kerberos pour gérer l'authentification. Le système fonctionne normalement correctement, mais je rencontre des problèmes d'accès au service à partir d'un domaine séparé (de confiance). En particulier, le service est incapable d'effectuer des rappels à l'application cliente, en recevant l'erreur "Une erreur spécifique au package de sécurité s'est produite". En outre, si je modifie le service pour exiger spécifiquement l'authentification Kerberos (plutôt que d'utiliser SNEGO/negotiate), le client ne peut même pas appeler le serveur (recevant à nouveau "Une erreur spécifique au package de sécurité s'est produite").

La chose déroutante est que les choses ont fonctionné pendant des années sans problème. Cependant, certaines choses sont différentes ici, par rapport à ce que nous avons fait auparavant. Pour un, les serveurs impliqués exécutent Windows 2008, que je n'ai jamais utilisé auparavant. En outre, comme indiqué ci-dessus, les erreurs se produisent uniquement lorsque le service est accessible à partir d'un compte à partir d'un domaine distinct, et l'utilisation précédente n'a jamais tenté cela.

Maintenant à la question: Je n'utilise pas un nom principal de service (SPN) pour ce service DCOM, mais certaines des erreurs et des journaux d'événements me font penser que cela pourrait être le problème. Cependant, tous les documents que j'ai trouvés ne sont pas clairs sur la question de savoir si c'est correct ou comment je configurerais le SPN si j'en avais besoin. Est-ce que quelqu'un sait avec certitude si un SPN est ce qui me manque ici? Si oui, pouvez-vous me montrer comment cela devrait être fait?

Détails supplémentaires:

Pour le scénario dans lequel le serveur est configuré pour forcer l'authentification Kerberos, l'activation Extended RPC Debugging donne quelques indices supplémentaires. Le client peut se connecter avec succès à l'aide de CoCreateInstanceEx, mais les appels sur l'interface de service échouent comme indiqué ci-dessus. Les enregistrements d'erreur RPC affichent une erreur à l'emplacement 140 et le code d'erreur est 0x80090303 ("La cible spécifiée est inconnue ou inaccessible") et le troisième paramètre pour cet enregistrement est une chaîne vide. Cela indique un SPN manquant en tant que coupable.

Answer 1

Modifier: Il semble que je puisse me tromper à ce sujet. Au moins un site Web que j'ai trouvé indique que DCOM handles SPNs automatically for you (voir le bas de la page), et j'ai confirmé que les clients peuvent se connecter avec succès s'ils exigent l'authentification Kerberos et utilisent "host/[computername]" comme SPN.

---

Il n'a pas l'air comme un SPN est nécessaire pour le service, si vous avez besoin explicitement l'authentification Kerberos lors de l'appel CoInitializeSecurity dans le processus serveur DCOM. Pour moi, l'appel ressemblait à ceci:

Avertissement: Veuillez ne pas copier ce code directement sans vous assurer que les valeurs correspondent à vos besoins de sécurité.

SOLE_AUTHENTICATION_SERVICE sas; 
sas.dwAuthnSvc = RPC_C_AUTHN_GSS_KERBEROS; 
sas.dwAuthzSvc = RPC_C_AUTHZ_NONE; 
sas.pPrincipalName = L"myservice/mymachine"; 
sas.hr = S_OK; 
CoInitializeSecurity(0, 1, &sas, 0, RPC_C_AUTHN_LEVEL_DEFAULT, 
    RPC_C_IMP_LEVEL_DEFAULT, 0, EOAC_NONE, 0); 

Le SPN peut être configuré en utilisant setspn, comme démontré ci-dessous:

setspn -A myservice/mymachine serviceusername 

(voir les documents SetSPN pour les détails).

Malheureusement cela n'a toujours pas résolu mon problème, mais je pense que le problème restant est lié à un problème spécifique avec les machines de test.

Answer 2

Pour ce que cela vaut, Kerberos nécessite par définition des SPN.Vous pourriez être en mesure d'utiliser le SPNS intégré (host /) et les différentes saveurs que l'hôte implique (Cette traduction d'alias est stockée dans l'AD, mais pour la vie de moi, je ne peux pas trouver la liste des articles où ceci est trouvé). Je commencerais par regarder l'authentification inter-domaine - Il peut être difficile avec kerberos. Je voudrais d'abord activer kerberos logging à la fois sur le client et le serveur et voir si cela retourne quelque chose.

Answer 3

J'ai rencontré cette erreur en essayant de créer une instance de l'objet COM distant. Nous pouvons faire face à cette erreur Si le niveau d'emprunt d'identité "Delegate" est utilisé par le client lors de l'appel à CoInitializeSecurity(), le service COM + s'exécute sous un compte d'utilisateur qui n'a pas l'autorisation "délégation" au niveau du domaine.