Dernièrement un client m’a demandé quel était le meilleur choix en termes de zones Centrify – quel type de zone doit on privilégier ?
La question est intéressante, car la “zone Centrify” est un élément important d’un design d’intégration UNIX/Linux dans Active Directory.
Comme d’habitude, il n’y a pas de réponse absolue, s’il existe plusieurs types de zones, c’est que certaines situations impliquent un type de zone et d’autres un autre type… évidement…
Rappel sur la notion de zone
Une zone Centrify représente ce que j’appelle personnellement un “ilot identitaire” – les zones servent globalement aux situations suivantes:
– Résultat de migration depuis différents ilots identitaires existants (plusieurs serveurs NIS, des serveurs LDAP, voir des fichiers passwd locaux depuis chaque système) – Ceci permettant notamment de gérer la problématique de collision d’UIDs/GIDs qui est LE gros problème rencontré par des entreprises voulant migrer vers un annuaire unique
– Règles de gouvernance: les zones permettent de ségréguer la gouvernance de différents ensembles de serveurs Unix, Linux ou Windows ou des Workstations Linux ou MacOS: si des équipes d’administrateurs IT différentes gèrent différents périmètres, les zones peuvent aider à encadrer tout cela
– Règles d’accès: même si il est possible de gérer les règles d’accès des utilisateurs aux différents systèmes, c’est à dire, « qui a le droit de se connecter sur tel système » de plusieurs manières différentes (GPOs, Rôles, pam.deny, pam.allow, etc.) les zones Centrify permettent rapidement et facilement de définir le « qui a a accès à quoi »
– Le reporting: il est extrêmement facile de générer des reports par zone, indiquant facilement le “qui a accès à quoi” en termes de systèmes – extrêmement efficace pour des audits
Pour une zone donnée, il est très simple de définir des attributs POSIX pour un utilisateur Active Directory, et bien sur il est possible de définir des jeux d’attributs POSIC différents par zone pour un même individu:
Les différents types de zones
Il existe 7 types de zones Centrify:
(0) AutoZone (nous ne le traiterons pas dans cet article, dans la vraie vie, ceci ne concerne que les workstations sous MacOS)
(1) SFU-compatible zones, version 3.5
(2) SFU-compatible zones, version 4.0
(3) Classic Centrify zones, 2.x, 3.x, and 4.x
(4) Classic RFC 2307-compatible zones
(5) Hierarchical Centrify zones, 5.x
(6) Hierarchical RFC 2307-compatible zones
Les zones dites “SFU-compatible” (1)(2) permettaient la compatibilité avec le schéma SFU exploité par Microsoft dans Active Directory à une certaine époque, autant dire que vu le “bazard” que constitue SFU en terme de compatibilité et de standard, peu de clients se sont aventuré dans cette voie…
Les zones “Classic” (3)(4) représentent l’ancienne famille de zone Centrify, à cette époque, les zones étaient “à plat”, c’est à dire non-hiérarchiques – c’était déjà très bien, mais cela obligeait à reproduire toutes les configurations communes aux différentes zones dans chacune des zones, de façon individuel et donc sans gestion centralisée – beaucoup de clients utilisent encore ce modèle car ils n’ont pas migré vers le modèle hiérarchique.
Les zones “Hierarchical” permettent d’avoir une arborescence de zones, avec un héritage descendant au niveau des profils POSIX. Cela permet notamment de définir une zone dite Parent avec l’ensemble des UIDs Corporate voulus et de définir des zones enfants avec uniquement les exceptions/différences par rapport aux profils POSIX définis dans la zone Parent. C’est donc bien évidement le meilleur choix, même dans le cas d’une architecture simpliste (dans ce cas on ne créera qu’une seule zone parent).
La zone “Hierarchical RFC 2307-compatible”
Avec la nouvelle version de Centrify Server Suite, le format de zone par défaut lorsque l’on créé une zone est le format: Hierarchical RFC 2307-compatible – l’avantage de ce format est que les attributs POSIX rattachés au ServiceConnectionPoint représentant le profil Unix de l’utilisateur dans la zone est “proprement” renseigné dans des attributs particuliers, permettant des requêtes LDAP facilitées et surtout une gestion par un outil IAM externe extrêmement simplifié.
On voit ici par exemple que l’attribut POSIX uidNumber est un attribut à part entière dans l’annuaire Active Directory.
Cette approche simplifie la manipulation des profils Unix depuis un browser LDAP:
Merci pour ce client, je n’avais jamais pensé faire un article sur ce sujet ! N’hésitez pas à me contacter pour plus précision.