J'ai besoin de mettre en place un AD. La grande organisation dans laquelle je travaille possède son propre service LDAP qui gère l'authentification et d'autres détails. Je voudrais qu'AD utilise ces informations LDAP uniquement à des fins d'authentification. Est-ce possible ?
Réponses
Trop de publicités?
Cela dépend honnêtement du temps, de l'expertise et de l'argent que vous avez à dépenser. FIM (Forefront Identity Manager) est une bonne option si vous cherchez simplement à synchroniser les attributs de base, y compris le nom d'utilisateur et le mot de passe. Cependant ce n'est pas ce que fait mon université, nous avons toujours eu besoin d'un peu plus de flexibilité que les solutions IDM n'ont jamais vraiment offert, c'est pourquoi nous avons développé notre propre middleware interne écrit en perl en utilisant LDAPS. Cela nous permet de script des mises à jour de ce que nous voulons, quand nous voulons, et où nous voulons avec autant de flexibilité que nécessaire. Nous forçons également tous les utilisateurs à utiliser un portail web pour les changements de mot de passe, afin que nos répertoires ne soient pas désynchronisés. Nous synchronisons actuellement un système LDAP SUN ONE avec notre MS Active Directory, et ce depuis 2002.
TL;DR Si vous êtes à court de temps et d'expertise, mais pas d'argent, utilisez FIM, il fera ce que vous voulez. Sinon, vous pouvez écrire votre propre intergiciel dans le langage de codage de votre choix pour faire la même chose.
sysadmin1138
Points
129885
Le seul moyen que je connaisse pour y parvenir est de créer un système Kerberos soutenu par LDAP et d'établir une confiance Kerberos entre le domaine Kerberos non Windows et le domaine Windows (qui est également un domaine Kerberos). Les étapes clés :
-
Configuration du nouveau royaume Kerberos
- Obtenir LDAP comme source d'authentification pour le royaume
- Étant donné qu'il s'agit d'AD, le domaine devra créer les enregistrements SRV du DNS Kerberos.
-
Mise en place de la fiducie
- Comme AD fera confiance au royaume Kerberos, il s'agira d'une confiance à sens unique.
- Les utilisateurs disposant de ces informations d'identification ont pour utiliser une méthode d'accès supportant Kerberos pour l'authentification. Le LDAP d'AD le prend en charge, tout comme SMB (bien que je n'aie pas essayé avec un royaume Kerb non-MS).
Kerberos est la colle qui permet à AD d'utiliser un serveur LDAP externe pour l'authentification.
voretaq7
Points
78924
Je n'ai jamais fait ce que vous décrivez, du moins pas avec seulement LDAP et pas en production.
Les domaines AD ne se limitent pas à l'authentification et nécessitent bien plus qu'un simple répertoire LDAP pour fonctionner. Je pense donc que vous devrez déployer Samba ou autre pour que ce que vous décrivez se produise (bien que vous puissiez faire en sorte que Samba utilise LDAP comme magasin de sauvegarde). Je ne suis pas sûr de l'état des contrôleurs de domaine Samba aujourd'hui, mais je commencerais à chercher. aquí (docs samba.org).
I ont Je recommande cette solution si elle est possible, mais sans en savoir plus sur votre situation, je ne peux pas dire si c'est la bonne solution ou non...
MDMarra
Points
99815
Microsoft FIM, anciennement ILM, permettra la synchronisation des justificatifs d'identité entre les LDAP. Vous devrez toujours utiliser un système AD complet, mais vous pourrez le faire synchroniser les informations d'identification avec le LDAP existant. Cela devrait être transparent pour l'utilisateur.
frameworkninja
Points
628
C'est ma compréhension limitée, je ne l'ai jamais fait fonctionner et je ne connais personne qui l'ait fait.
Selon la documentation éparse de MS, vous pouvez faire en sorte que AD en 2003+ utilise un nom d'utilisateur et un mot de passe provenant d'un autre serveur LDAP. Mais cela exige toujours que vous exécutiez une configuration AD "locale" complète avec des comptes qui sont essentiellement mappés aux comptes LDAP. Il utilise le inetOrgPerson objet. Des informations limitées sont aquí et les instructions encore plus "utiles" pour créer le compte sont les suivantes aquí .
Comme l'a mentionné un autre poster, AD est bien plus qu'une simple authentification et ne joue pas vraiment le jeu de la concurrence comme LDAP *nix.
