Sagesse commune sur l'authentification Active Directory pour les serveurs Linux?
Quelle est la sagesse courante en 2014 à propos de l'authentification/intégration Active Directory pour les serveurs Linux et moderne Systèmes d'exploitation Windows Server (centrés sur CentOS/RHEL)?
Au fil des ans depuis mes premières tentatives d'intégration en 2004, il semble que les meilleures pratiques à ce sujet aient changé. Je ne sais pas exactement quelle méthode a le plus d'élan actuellement.
Sur le terrain, j'ai vu:
Winbind/Samba
Tout droit LDAP
Parfois LDAP + Kerberos
Services Microsoft Windows pour Unix (SFU)
Microsoft Identity Management pour Unix
NSLCD
[~ # ~] sssd [~ # ~]
FreeIPA
Centrifiez
Powerbroker ( née De même)
Winbind semblait toujours terrible et peu fiable. Les solutions commerciales comme Centrify et Liklike ont toujours fonctionné, mais semblaient inutiles, car cette capacité est intégrée dans le système d'exploitation.
Les dernières installations que j'ai faites avaient la fonction de rôle Microsoft Identity Management pour Unix ajoutée à un serveur Windows 2008 R2 et NSLCD côté Linux (pour RHEL5). Cela a fonctionné jusqu'à RHEL6, où le manque de maintenance sur NSLCD et les problèmes de gestion des ressources mémoire ont forcé un changement vers SSSD. Red Hat semblait également soutenir l'approche SSSD, donc cela me convenait parfaitement.
Je travaille avec une nouvelle installation où les contrôleurs de domaine sont des systèmes Windows 2008 R2 Core et n'ont pas la possibilité d'ajouter la fonction de rôle Gestion des identités pour Unix. Et on me dit que cette fonctionnalité est obsolète n'est plus plus présente dans Windows Server 2012 R2 .
L'avantage d'avoir ce rôle installé est la présence de cette interface graphique, tout en permettant une administration facile en une seule étape des attributs utilisateur.
Mais...
L'option Outils Server for Network Information Service (NIS) des Outils d'administration de serveur distant (RSAT) est déconseillée. Utilisez LDAP natif, Samba Client, Kerberos ou des options non Microsoft.
Il est donc très difficile de s'y fier s'il peut rompre la compatibilité ascendante. Le client veut utiliser Winbind, mais tout ce que je vois du côté de Red Hat pointe vers l'utilisation de SSSD.
Quelle est la bonne approche?
Comment gérez-vous cela dans l'environnement votre?
En mars 2014, Red Hat a publié une architecture de référence pour intégrant Red Hat Enterprise Server avec Active Directory . (Ce matériel devrait certainement être à jour et pertinent.) Je déteste publier ceci comme réponse, mais c'est vraiment trop de matériel à transférer dans le champ de réponse.
Ce document (corrigé) est chaud, la presse semble se concentrer sur les nouvelles fonctionnalités de Red Hat Enterprise Linux (RHEL) 7. Il a été publié pour le Sommet la semaine dernière.
Si ce lien devient obsolète, veuillez m'en informer et je mettrai à jour la réponse en conséquence.
J'ai personnellement utilisé WinBind de manière assez fiable pour l'authentification. Il y a une panne de service très rare qui nécessite qu'une personne avec un compte root ou un autre compte local entre et rebondisse sur winbindd. Cela pourrait probablement être résolu par une surveillance appropriée si vous souhaitez y mettre l'effort.
Il convient de noter que Centrify possède des fonctionnalités supplémentaires, bien que cela puisse être fourni par une gestion de configuration distincte. (Marionnette, etc.)
Modifier 16/06/14:
re: "Les solutions commerciales comme Centrify et Liklike ont toujours fonctionné, mais semblaient inutiles, car cette capacité est intégrée dans le système d'exploitation."
Eh bien, je pense que la plupart d'entre nous entendons depuis des années que le système d'exploitation XYZ brise enfin le puzzle de l'intégration AD. À mon humble avis, le problème est que pour le fournisseur de système d'exploitation, l'intégration AD est une fonctionnalité de case à cocher, c'est-à-dire qu'ils doivent fournir quelque chose qui fonctionne un peu pour obtenir cette case à cocher, et cette case à cocher ne fonctionne généralement que sur ...
- leur plate-forme OS et
- la version actuelle de cette plate-forme et
- par rapport à une version plus récente d'Active Directory.
La réalité est que la plupart des environnements ne sont pas monolithiques en termes de fournisseur de système d'exploitation et de version du système d'exploitation, et auront des versions plus anciennes d'AD. C'est pourquoi un fournisseur tel que Centrify doit prendre en charge plus de 450 versions d'UNIX/Linux/Mac/etc. contre Windows 2000 à Windows 2012 R2, pas seulement RHEL 7 à nouveau Windows 2012 R2.
De plus, vous devez prendre en compte la façon dont votre AD est déployée. L'intégration AD du fournisseur de système d'exploitation prend également en charge les contrôleurs de domaine en lecture seule (RODC), les approbations unidirectionnelles, la prise en charge multi-forêts, etc. Et si vous avez pré- espace UID existant (que vous allez utiliser), existe-t-il des outils de migration pour migrer les UID vers AD Et la prise en charge AD du fournisseur de système d'exploitation permet-elle de mapper plusieurs UID à une seule AD dans les situations où votre espace UID n'est pas plat. Et qu'en est-il ... eh bien vous avez l'idée.
Ensuite, il y a la question du soutien ...
Le point est que l'intégration AD peut sembler facile conceptuellement et peut être "gratuite" avec le dernier système d'exploitation d'un fournisseur, et peut probablement fonctionner si vous n'avez qu'une seule version d'un système d'exploitation d'un fournisseur et que vous avez un AD Vanilla qui est la dernière version, et vous avez un contrat de support premium avec le fournisseur du système d'exploitation qui fera de son mieux pour résoudre les problèmes qui pourraient survenir. Sinon, vous voudrez peut-être envisager une solution tierce spécialisée.
L'option Outils Server for Network Information Service (NIS) des Outils d'administration de serveur distant (RSAT) est déconseillée.
Cela ne m'étonne pas - NIS est la preuve que Sun nous détestait et voulait que nous soyons misérables.
Utilisez LDAP natif, Samba Client, Kerberos ou des options non Microsoft.
C'est un bon conseil. Compte tenu des choix que je dirais "Utiliser LDAP natif (sur SSL, s'il vous plaît)" - il existe de nombreuses options disponibles pour cela, les deux que je connais le mieux étant pam_ldap + nss_ldap (de PADL), ou le combiné nss-pam-ldapd (qui est à l'origine un fork et qui a connu un développement et des améliorations continus).
Puisque vous posez des questions sur RedHat en particulier, il convient de noter que RedHat vous offre d'autres alternatives en utilisant SSSD.
Si votre environnement est entièrement RedHat (ou ne dispose que d'un grand nombre de systèmes RedHat), la recherche de la "manière de faire RedHat" officiellement prise en charge en vaut certainement la peine.
Comme je n'ai aucune expérience avec RedHat/SSSD moi-même, je me fie aux documents, mais il semble être assez robuste et bien conçu.
Parmi les méthodes suggérées, permettez-moi de vous donner une liste des avantages/inconvénients:
Kerberos/LDAP
Avantages: Fonctionne très bien lorsqu'il est correctement configuré. Les ruptures, résilientes, survivent rarement aux problèmes de réseau. Aucun changement nécessaire dans AD, aucun changement de schéma, aucun accès administrateur nécessaire à l'AD. Gratuit.
Inconvénients: relativement difficile à configurer. Plusieurs fichiers doivent être modifiés. Ne fonctionnera pas si le serveur d'authentification (Kerberos/LDAP) n'est pas disponible.
Winbind
Avantages: Facile à configurer. Fonctionnalité de base de Sudo. Gratuit.
Inconvénients: Support intensif. Pas résilient au réseau. S'il y a un problème de réseau, les machines Linux pourraient être abandonnées de l'AD nécessitant un réenregistrement du serveur, une tâche de support. Accès au compte administrateur d'AD requis. Pourrait apporter des modifications de schéma dans AD.
Centrifier/De même, etc.
Avantages: relativement facile à configurer.
Inconvénients: Change la fonctionnalité Sudo en propriétaire, plus difficile à prendre en charge. Coût de la licence par serveur. Besoin de compétences supplémentaires pour gérer.
SSSD
Avantages: Un fichier de configuration, facile à configurer. Fonctionne avec toutes les méthodes d'authentification présentes et futures. Évolutif, grandit avec le système. Fonctionnera en mode déconnecté. Résilient au réseau. Pas besoin de modifier le schéma AD. Pas besoin d'informations d'identification d'administrateur AD. Gratuit, pris en charge.
Inconvénients: n'a pas de services gagnants comme les mises à jour automatiques du DNS Besoin de configurer les partages CIFS.
Sommaire
En ce qui concerne les avantages et les inconvénients, SSSD est clairement le gagnant. S'il s'agit d'un nouveau système, il n'y a aucune raison d'utiliser autre chose que SSSD. Il s'agit d'un intégrateur qui fonctionne avec toutes les méthodes d'authentification actuelles et peut évoluer avec le système car de nouvelles méthodes peuvent être ajoutées lorsqu'elles sont disponibles. Il utilise des méthodes Linux natives et est beaucoup plus fiable et rapide. Si la mise en cache est activée, les systèmes fonctionneront même dans des systèmes complètement déconnectés avec une défaillance complète du réseau.
Winbind peut être utilisé pour les systèmes existants s'il y a trop de travail à modifier.
Centrify a eu des problèmes d'intégration qui pourraient devenir coûteux. La plupart des bogues ont été corrigés dans la nouvelle version, mais il y en a toujours qui causent des maux de tête.
J'ai travaillé avec toutes ces méthodes et SSSD est clairement le gagnant. Même pour les systèmes plus anciens, le retour sur investissement pour la conversion de Winbind en SSSD est très élevé. À moins qu'il n'y ait une raison spécifique de ne pas utiliser SSSD, utilisez toujours SSSD.
Je dois commenter ceci:
Il convient de noter que Centrify possède des fonctionnalités supplémentaires, bien que cela puisse être fourni par une gestion de configuration distincte. (Marionnette, etc.)
En tant que personne qui travaille avec Centrify, je ne sais pas d'où vient ce commentaire. Regardez this et vous pouvez voir qu'il y a un tas de fonctionnalités que vous n'obtenez pas avec un outil de configuration mgmt ala Puppet. Par exemple, la prise en charge du mappage de plusieurs UID vers un seul compte AD (zones), la prise en charge des approbations de domaine Active Directory complètes (que la solution Red Hat documente à la page 3 qu'elle ne prend pas en charge), etc.
Mais revenons à ce guide Red Hat. C'est formidable que Red Hat publie cela, les options sont bonnes. Notez qu'il donne au client 10 options pour effectuer l'intégration AD de base. La plupart des options sont des variantes de Winbind, et à la page 15, il répertorie les avantages et les inconvénients de chacun, et il y a un tas d'étapes manuelles requises pour chacune (avec les inconvénients/manque de fonctionnalités correspondants ci-dessus). L'avantage de Centrify Express est que selon les autres commentateurs ci-dessus:
- il est simple à installer sans toutes les étapes manuelles et ...
- est gratuit et ...
- n'est pas limité à Red Hat V7 qui est important car la question concernait Linux, pas seulement une variante - Centrify prend en charge plus de 300 versions de * nix et ...
- prend en charge toutes les variantes de Windows AD, pas seulement Windows 2008. Ils ont publié une comparaison de Centrify vs Winbind ici , mais ce n'est pas open source.
À la fin, cela se résume à ce que vous voulez faire rouler vous-même ou opter pour une solution commerciale. Vraiment une question où vous et comment vous passez votre temps.