Kerberos est le protocole d’authentification par défaut d’Active Directory. Cette seule phrase en dit suffisamment long.
Le constat laisse croire qu’Active Directory devient de plus en plus incontournable pour maintes raisons.
Incompréhension !
Lorsque l’on pense à l’authentification Active Directory, le protocole qui vient en premier à l’esprit est Kerberos. Souvenez-vous-en ou notez le, Kerberos est le graal des linuxiens 🤐
Je peine donc à comprendre les linuxiens qui militent pour une authentification NTLM pour les systèmes d’exploitation Linux. Un linuxien qui prône le NTLM me choque puisque c’est purement du non-sens 😒
Si le linuxien ne trouvait que des défauts à l’annuaire Active Directory, j’aurais été plus compréhensif et rassuré quant au fait que ce dernier ce dernier choisisse OpenLDAP comme annuaire.
La question est : pourquoi choisit-il Active Directory en acceptant des transactions NTLM ?
Quoi qu’il en soit, miser sur du NTLM est de l’inconscience avérée, cela met à risques toute une infrastructure d’entreprise. C’est typiquement l’effet papillon 🫣
Le linuxien est de mauvaise foi quand cela l’arrange, un grand classique lorsqu’il n’a pas la vision globale nécessaire dans une infrastructure Active Directory.
Rappel
Active Directory n’est pas une application. Il s’agit d’un service d’infrastructure devant être stable, sécurisé et résistant à toute épreuve.
De ma fenêtre, la protection des identités et l’authentification doivent se faire à travers le protocole Kerberos dans un environnement Active Directory. Kerberos est une des clés principales d’un annuaire bien protégé. Même l’annuaire NDS de Novell NetWare (paix à son âme) comprenait et fournissait le protocole Kerberos.
Une entreprise désireuse d’un bon niveau de maturité en termes de sécurité ne doit donc pas idéalement bypasser le protocole Kerberos.
Autre point important, Kerberos nécessite un système de résolution irréprochable, c’est à dire : le DNS doit être parfait 👌
Autrement dit, si le DNS est approximatif, c’est mort pour Kerberos 💀
Par conséquent, quand ton DNS est pourri et que la configuration de ton application portée par un système Linux est très approximative, c’est trop facile de tirer sur Active Directory pour ne pas te remettre en cause.
Architecture et sécurité
Dans un environnement hétérogène, veiller à ne pas multiplier les bases de comptes relève du bon sens. Homogénéiser le protocole d’authentification l’est également. Kerberos étant un standard et sécurisé, ai-je besoin réellement d’achever cette phrase ?
Quoi qu’il en soit, l’idée de ne garder qu’un seul référentiel reste la meilleure. Active Directory est un candidat parfait pour faire ce job de centralisation, qui peut le plus peut effectivement le moins. L’approche demeure un annuaire global en évitant d’éparpiller lesdits comptes à hauts privilèges. Autrement, les comptes à privilèges peuvent être coffrés afin d’accroitre davantage le niveau de sécurité au global.
La simplicité, l’efficacité et les efforts constants mènent à la sécurité durable et efficace des infrastructures, dès la phase de build jusqu’à chaque intégration de chacune des applications.
Un raisonnement très orienté production n’apportera que des limites tout compte fait et va jusqu’à l’utilisation des leviers politiques pour tenter de résoudre des soucis techniques évidents. C’est ainsi qu’une infrastructure devient un grand n’importe quoi au fil du temps.
Enfin, quelque que soit le type de clients de votre infrastructure au global, se référer à un annuaire unique en utilisant le protocole fort Kerberos reste la bonne stratégie.
Kerberos en priorité, pourquoi ?
La raison est simple, c’est pour protéger sérieusement nos identités dans le milieu de l’entreprise.
Adopter Kerberos avec les concepts décrits plus haut, avec une bonne dose constante de sensibilisation, permet :
- De ne gérer qu’une unique base de comptes, enfin un nombre limité d’annuaires dans tous les cas,
- D’avoir de la visibilité quant à l’activité de l’ensemble des comptes,
- D’éviter les authentifications point à point basées sur les protocoles faibles, dont le NTLM qui est âgé de plus de 20 ans maintenant (il convient de favoriser un protocole sécurisé comme Kerberos).
Clairement, Kerberos fonctionne et offre ce qui suit :
- Une authentification mutuelle : le client et le serveur s’authentifient l’un l’autre, cela garantit une connexion sûre et fiable,
- Un système basé sur des tickets : au lieu de transmettre des informations d’identification sensibles, Kerberos utilise des tickets/jetons. Une fois l’authentification réussie, un client reçoit un ticket de la part du KDC, il peut le présenter alors pour accéder aux services spécifiques sans avoir à envoyer de nouveau le mot de passe,
- Un SSO : prise en charge de l’authentification unique, cela permet aux utilisateurs de s’authentifier une seule fois et d’accéder à plusieurs services sans avoir à saisir plusieurs fois les informations d’identification,
- Une Authentification par un tiers : Kerberos utilise un tiers de confiance (le KDC en l’occurrence) pour l’authentification, ceci renforce la sécurité dans les systèmes distribués,
- Un chiffrement des communications : Kerberos assure la confidentialité de toutes les transactions, y compris l’échange des tickets cité plus haut, ce qui a pour effet d’empêcher les écoutes et les accès non autorisés.
Intégration Linux dans Active Directory
Dans le LAB qui suit, le cas d’un client Ubuntu intégré à Active Directory, li est démontré que l’effort est simple à condition de ne rien négliger (définition des priorités, importance de la phase de build, politique de sécurité et cætera). La réflexion est de mise avant le choix.
Les autres distributions, e.g. FreeBSD, CentOS, MacOS et cætera, peuvent s’intégrer à Active Directory sans aucune difficulté particulière. C’est à noter. Les systèmes Unix/Linux sont parfaitement compatibles avec Kerberos également.
Bref, la version Ubuntu dont il est question ici est la fameuse 24.04 LTS, assez récente.
Les paquets nécessaires à la jonction au domaine Active Directory sont les suivants : realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
Une fois ces paquets installés, l’ajout au domaine s’effectue avec la commande ci-après : realm join – – user=%admin_sAMAccountName_allowed_admin% %domain_fqdn_name%. Le mot de passe du compte Active Directory vous sera demandé pour finaliser le processus d’intégration au domaine.
Une fois la machine Ubuntu intégrée au domaine, les comptes des utilisateurs Active Directory peuvent être utilisés pour l’authentification basée sur Kerberos.
Cette situation est largement plus confortable par rapport au fallback NTLM entre un client Linux/Unix et l’annuaire Active Directory.
La possibilité d’intégrer le poste Ubuntu à Active Directory est proposée lors de la phase de déploiement du système d’exploitation en mode GUI maintenant. Le processus est ansible aussi 👍 … c’est un signe 😊
👆 + 👇 = c’est juste ce qu’il faut. Kerberos de bout en bout au sein de l’infrastructure 👌
Le message
Ne pas intégrer les clients Linux/Unix dans Active Directory est un choix qui a un impact non-négligeable à la longue. Ce n’est pas compatible avec le concept sérieux de la sécurité globale en tout cas.
Une trajectoire basée sur l’authentification point à point ne permet pas de faciliter la protection des comptes. Cela ne favorise pas a sécurité des comptes stratégiques : comptes de service et comptes à privilèges.
Une machine Linux/Unix hébergeant un applicatif critique et/ou sensible et qui plus est dialogue en NTLM n’est pas du tout sérieux. C’est indéfendable de ma fenêtre, c’est tout sauf une stratégie ! C’est vraiment un manque de vision architecturale et du laxisme vis-à-vis de la sécurité.
Conclusion
Kerberos et NTLM sont tous deux des protocoles d’authentification, mais restent diamétralement différents. Les mécanismes de sécurité les opposent.
L’utilisation par Kerberos de l’authentification mutuelle, de l’authentification unique, le concept de tickets avec le chiffrement le rend largement plus robuste et sécuritaire que NTLM.
NTLM est plus qu’obsolète et reste à éviter si nous voulons nous améliorer.
Ainsi, Kerberos reste plus adapté aux environnements d’entreprise à grande échelle, peu importe le parc client.
Garder toutefois à l’esprit que standardiser Kerberos n’est que le début. Bon début, mais un simple début.
La case gestion des risques est trop souvent utilisée à tort pour occulter ce type de problématique avec NTLM. On a la même similitude avec le protocole SMBv1, la mise en avant du côté vital d’une application importante basée sur un protocole faible.
Enfin, ma vision paraît rigide comme d’habitude, mais tout le monde voit généralement la vie autrement une fois l’infrastructure poutrée. Il faut donc miser sur l’anticipation et l’élimination de toutes les brèches possibles, largement en amont.