Tout le monde parle des contrôleurs de domaine et du fait qu’ils devraient avoir un certificat installé, mais au final c’est optionnel. Une fois installé, qu’est-ce qui utilise réellement ce certificat ? D’après ce que je comprends, il est au moins nécessaire pour :
L’authentification par carte à puce
LDAPS
Cependant, je cherche à savoir s’il existe des actions natives spécifiques du DC ou d’Active Directory où le contrôleur de domaine utilise le certificat.
Je suis conscient des implications de sécurité et des bonnes pratiques Je m’intéresse simplement aux mécanismes en jeu.
La réplication entre les contrôleurs de domaine continuera de se faire via RPC, même après l’installation de certificats SSL. La charge utile est chiffrée, mais pas avec SSL.
Si vous utilisez la réplication SMTP, cette réplication peut être chiffrée avec le certificat SSL du contrôleur de domaine… mais j’espère que personne n’utilise la réplication SMTP en 2017.
LDAPS est comme LDAP, mais via SSL/TLS, utilisant le certificat du contrôleur de domaine. Mais les membres normaux du domaine Windows ne vont pas automatiquement commencer à utiliser LDAPS pour des choses comme DC Locator ou la jonction au domaine. Ils continueront simplement d’utiliser le cLDAP et LDAP en clair.
L’une des principales façons dont nous utilisons LDAPS est pour les services tiers ou les systèmes non joints au domaine qui ont besoin d’un moyen sécurisé d’interroger le contrôleur de domaine. Avec LDAPS, ces systèmes peuvent bénéficier de communications chiffrées même s’ils ne sont pas joints au domaine. (Pensez aux concentrateurs VPN, routeurs Wi-Fi, systèmes Linux, etc.)
Mais les clients Windows joints au domaine ont déjà la signature et le scellement SASL et Kerberos, qui sont déjà chiffrés et assez sécurisés. Ils continueront donc simplement à les utiliser.
Les clients à carte à puce utilisent le certificat SSL du contrôleur de domaine lorsque la validation stricte du KDC est activée. C’est simplement une mesure de protection supplémentaire pour que les clients à carte à puce puissent vérifier que le KDC avec lequel ils communiquent est légitime.
Les contrôleurs de domaine pourraient également utiliser leurs certificats pour la communication IPsec, soit entre eux, soit avec les serveurs membres.
C’est tout ce qui me vient à l’esprit pour le moment.
Je m’intéresse simplement aux mécanismes en jeu.