Sagesse commune sur l'authentification Active Directory pour les serveurs Linux?

Quelle est la sagesse courante en 2014 concernant l'authentification / intégration Active Directory pour les serveurs Linux et les systèmes d'exploitation Windows Server modernes (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
straight-up LDAP
Parfois LDAP + Kerberos
Microsoft Windows Services for Unix (SFU) de
gestion des identités Microsoft pour Unix
nslcd
SSSD
FreeIPA
Centrify
PowerBroker ( née 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 ont ajouté la fonctionnalité de rôle Microsoft Identity Management pour Unix à 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 fonctionnalité de rôle Identity Management pour Unix. Et on me dit que cette fonctionnalité est obsolète n'est 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 é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 votre environnement?

En mars 2014, Red Hat a publié une architecture de référence pour intégrer Red Hat Enterprise Server à 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 sorti de presse et 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 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 celles-ci puissent être fournies par une gestion de configuration distincte. (Marionnette, etc.)

Modifier le 16/06/14:

Guide d'intégration de Red Hat Enterprise Linux 7 pour Windows

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 résout enfin le puzzle de l'intégration AD. À mon humble avis, le problème est que pour le fournisseur du 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 ...

1. leur plate-forme OS et
2. la version actuelle de cette plate-forme et
3. 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 du 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 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 conceptuellement facile 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 vanille 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 nss-pam- combiné ldapd (qui est à l'origine un fork et 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 propose d'autres alternatives utilisant SSSD.
Si votre environnement est entièrement RedHat (ou possède simplement 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 ne fais que suivre la documentation, 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 pépins du réseau. Aucun changement nécessaire dans AD, aucun changement de schéma, aucun accès administrateur nécessaire à l'AD. Libre.

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é sudo de base. Libre.

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: modifie 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 bugs sont 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 celles-ci puissent être fournies 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 ceci 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:

1. il est simple à installer sans toutes les étapes manuelles et ...
2. est gratuit et ...
3. 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 ...
4. 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.