2 votes

Modèles de certificats Windows : comment inclure les revendications de groupe (ou OU) dans les certificats clients SSL/TLS

J'utilise des certificats client X.509 pour authentifier un ensemble de clients Windows via TLS mutuel. Quels clients font partie de cet ensemble devrait d'une manière ou d'une autre être administré dans AD, par exemple via l'appartenance à un groupe ou l'OU parent.

Remarque : la question s'applique aux certificats d'ordinateur, et non aux certificats d'utilisateur. C'est-à-dire que tout utilisateur doit pouvoir utiliser ce certificat lorsqu'il lance une requête HTTPS à partir d'un tel ordinateur. (Ceci s'ajoute à toute méthode de connexion de l'utilisateur, qui ne fait pas partie du schéma d'authentification mTLS).

Les serveurs doivent être capables de dire que l'ordinateur client qui s'authentifie est un membre de cet ensemble. Les serveurs sont des conteneurs basés sur Linux et ne font pas partie de l'AD/domaine, donc tout ce que nous avons est l'information dans le certificat X.509.

Les modèles de certificat Windows fournissent-ils une méthode pour transmettre une telle déclaration dans le cadre du certificat X.509 ? Il semble que je puisse limiter l'ensemble des ordinateurs qui peuvent obtenir un tel certificat, mais je ne trouve pas de moyen de marquer ces certificats d'une manière qui permette au serveur de les identifier.

  • Le certificat X.509 ne contient pas le nom ou l'ID du modèle administratif, je ne peux donc pas non plus configurer le serveur pour le vérifier.
  • Il semble que la flexibilité de la configuration des sujets soit limitée, et notamment qu'il n'existe pas de méthode permettant de faire correspondre des informations AD au champ sujet. Ce serait l'idéal - est-ce que je manque quelque chose ?
  • Je pensais utiliser un CA intermédiaire spécifique pour ces modèles, mais cela semble bien trop compliqué pour des exigences aussi basiques.

Peut-être y a-t-il un autre aspect du certificat X.509 qui peut être défini par le biais du modèle ? Ou puis-je utiliser une demande différente de celle de groupe/OU ?

1voto

Crypt32 Points 6184

La réponse est non. L'appartenance à un groupe est une propriété plutôt dynamique, non statique et qui ne fait pas partie de l'identité du titulaire du certificat. Par conséquent, vous ne pouvez pas inclure l'appartenance à un groupe dans un certificat, car cette information ne fait pas partie de l'identité. Et chaque fois que l'appartenance à un groupe est modifiée, vous devez réémettre un certificat. Les certificats sont valables pendant une période assez longue. C'est une solution très imparfaite.

C'est-à-dire que n'importe quel utilisateur devrait être en mesure d'utiliser ce certificat lorsqu'il lance une requête HTTPS à partir d'un tel ordinateur.

cela ne fonctionnera que lorsque la demande TLS est envoyée par une application qui fonctionne sous le compte du système local ou du service réseau. Si vous souhaitez utiliser de tels certificats, vous devez configurer explicitement le client TLS pour qu'il utilise un certificat client autre que celui par défaut via le code source, par exemple.

Les serveurs sont des conteneurs basés sur Linux et ne font pas partie de l'AD/domaine.

intéressant, comment les serveurs basés sur Linux sont censés valider l'appartenance réelle à un groupe ?

Le certificat du client dans le TLS mutuel est la méthode d'authentification. Les champs du certificat sont mappés aux informations du compte auquel les serveurs doivent être connectés.

Puisque vos serveurs Linux ne font pas partie d'un AD, ils ne peuvent pas lier le certificat client à un compte utilisateur AD et valider l'appartenance à un groupe. Les serveurs ne peuvent même pas dire si un tel groupe existe vraiment. Il doit y avoir une base de données d'identité séparée disponible pour les serveurs Linux et les serveurs Linux doivent d'une manière ou d'une autre lier le certificat client à l'identité dans cette base de données d'identité séparée. Et seules les informations disponibles dans cette base de données d'identité séparée doivent être utilisées pour l'autorisation du client.

Cela signifie que vos exigences :

L'appartenance à un groupe pour les ordinateurs doit être gérée dans AD.

y

Les serveurs sont des conteneurs basés sur Linux et ne font pas partie de l'AD/domaine.

s'excluent mutuellement et ne peuvent être utilisés ensemble. Il faut soit rendre les serveurs Linux compatibles avec AD, soit inclure dans les certificats des informations sur l'identité qui sont disponibles pour les serveurs Linux. Et j'éviterais fortement d'inclure l'appartenance à un groupe dans les certificats. L'appartenance à un groupe doit être utilisée dans les jetons à courte durée de vie, pas dans les certificats à longue durée de vie.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X