Solution 1 :
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 doit 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 tout juste sorti de presse semble se concentrer sur les nouvelles fonctionnalités de Red Hat Enterprise Linux (RHEL) 7. Il a été publié pour le Summit 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 des pannes de service très rares qui nécessitent qu'une personne disposant d'un compte root ou d'un autre compte local entre et rebondisse winbindd. Cela pourrait probablement être traité par une surveillance appropriée si vous tenez à y mettre l'effort.
Il convient de noter que Centrify dispose de 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 Windows de Red Hat Enterprise Linux 7
Solution 2 :
re :"Les solutions commerciales telles que Centrify et Similar ont toujours fonctionné, mais semblaient inutiles, car cette fonctionnalité est intégrée au 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 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 en quelque sorte pour obtenir cette case à cocher, et cette case à cocher ne fonctionne généralement que sur...
- leur plate-forme de système d'exploitation 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 de 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 manière dont votre AD est déployé, de même que l'intégration AD du fournisseur de système d'exploitation prend en charge les contrôleurs de domaine en lecture seule (RODC), les approbations unidirectionnelles, fournit une prise en charge multi-forêts, etc. espace UID existant (ce que vous ferez), 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 sur un seul AD dans les situations où votre espace UID n'est pas plat. Et qu'en est-il de ... eh bien vous avez l'idée.
Ensuite se pose la question du support...
Le fait est que l'intégration AD peut sembler facile sur le plan conceptuel 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 d'assistance premium avec le fournisseur du système d'exploitation qui fera de son mieux pour résoudre tout problème susceptible de survenir. Sinon, vous voudrez peut-être envisager une solution tierce spécialisée.
Solution 3 :
L'option Serveur pour les outils NIS (Server for Network Information Service) des outils d'administration de serveur distant (RSAT) est obsolète.
Cela ne me surprend pas :NIS est la preuve que Sun nous détestait et voulait que nous soyons misérables.
Utilisez le LDAP natif, le client Samba, Kerberos ou des options non Microsoft.
C'est un bon conseil. Compte tenu des choix, 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 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 dispose simplement d'un grand nombre de systèmes RedHat), il vaudrait certainement la peine de vous pencher sur la « RedHat Way of Doing Things » officiellement prise en charge.
Comme je n'ai moi-même aucune expérience avec RedHat/SSSD, je me contente de consulter la documentation, mais il semble assez robuste et bien conçu.
Solution 4 :
Parmi les méthodes suggérées, laissez-moi vous donner une liste des avantages/inconvénients :
Kerberos/LDAP directement
Avantages :Fonctionne très bien lorsqu'il est configuré correctement. Les ruptures rares, résilientes, survivront aux problèmes de réseau. Aucune modification nécessaire dans AD, aucun changement de schéma, aucun accès administrateur nécessaire à 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é sudo de base. Gratuit.
Inconvénients :Support intensif. Non résilient au réseau. S'il y a un problème de réseau, les machines Linux peuvent être supprimées de l'AD, ce qui nécessite de réenregistrer le serveur, une tâche de support. Accès au compte administrateur d'AD requis. Peut être nécessaire d'apporter des modifications au 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 seul 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éseau résilient. 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.
Résumé
En regardant 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 panne 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 coûter cher. La plupart des bugs sont corrigés dans la nouvelle version, mais il y en a encore 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 de 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.
Solution 5 :
Je dois commenter ceci :
Il convient de noter que Centrify dispose de 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 gestion de configuration comme Puppet. Par exemple, prise en charge du mappage de plusieurs UID sur un seul compte AD (Zones), 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 super que Red Hat publie ça, les options sont bonnes. Notez que cela donne au client 10 options pour effectuer une intégration AD de base. La plupart des options sont des variantes de Winbind, et la page 15 répertorie les avantages et les inconvénients de chacune, et il y a un tas d'étapes manuelles requises pour chacune (avec les inconvénients correspondants / le manque de fonctionnalité ci-dessus). L'avantage de Centrify Express est que, selon les autres commentateurs ci-dessus, c'est :
- il est simple à installer sans toutes les étapes manuelles et...
- est gratuit et...
- n'est pas limité à Red Hat V7, ce qui est important car la question concernait Linux, pas seulement une variante -- Centrify prend en charge plus de 300 variantes de *nix et...
- prend en charge toutes les variantes de Windows AD, pas seulement Windows 2008. Ils ont publié une comparaison entre Centrify et Winbind ici, mais ce n'est pas open source.
À la fin, cela revient à vouloir le rouler vous-même ou à opter pour une solution commerciale. Vraiment une question où vous et comment vous passez votre temps.