J'ai quelques sites Web pour le travail qui vivent en dehors du réseau local d'entreprise - et, par conséquent, de la plage de communication directe d'Active Directory (A / D) - mais pour lequel je voudrais pouvoir authentifier Utilisateurs contre les serveurs A / D d'entreprise ainsi qu'un référentiel secondaire d'utilisateurs / rôles ***. Le pseudo code de cette activité est-ce:
*** L'idée est que nous ne voulons pas mettre des dizaines - potentiellement des centaines de sous-traitants et des affiliés dans Active Directory lors de leur journalisation uniquement dans nos serveurs Web externes. D'où le schéma d'autorisation secondaire.
3 Réponses :
Je pense qu'il y a quelques couches ici, chacune sa propre question:
Comment puis-je accéder à un service Web à l'intérieur de mon réseau local de la DMZ?
Ceci est difficile car il brise vraiment le concept d'une séparation DMZ / LAN. Généralement, les connexions entre LAN et DMZ ne sont autorisées que (et sur une base limitée) du côté LAN - cette manière, une DMZ comprise ne peut pas initier le contact avec le réseau local et est extrêmement limité dans ce qu'il peut faire (il ne peut pas émettre Demandes arbitraires, répondant uniquement aux demandes du LAN).
Comment puis-je utiliser un service sur un autre ordinateur pour authentifier un nom d'utilisateur / mot de passe?
Encore une fois, c'est un problème collant - vous passez des mots de passe sur un réseau - est-il possible pour eux d'être interceptés. Avec AD Ceci est résolu avec Kerberos - un système de défi / réponse garantissant que le mot de passe n'est jamais réellement transmis. Bien sûr, Kerberos et des protocaux similaires sont assez complexes - vous ne devriez jamais essayer de rouler le vôtre car il sera probablement moins sûr, puis utilisez quelque chose existant - par exemple votre service Web pourrait fonctionner sur https, de sorte que au moins les mots de passe ne soient que sifflent sur le Deux serveurs et non la liaison de communication entre elles. Les certificats peuvent également être utilisés pour empêcher le trafic destiné à votre service Web LAN d'être redirigé vers une machine DMZ comprimé (la machine DMZ comprise ne pourra pas simuler le certificat, et votre système peut donc déterminer qu'il est connecté à un faux serveur avant Envoi de détails pour l'authentification)
Dans ma propre expérience, ces problèmes donnent une annonce en dehors du réseau local, tout simplement pas fait. Les entreprises choisissent d'obtenir des personnes à l'extérieur du réseau local à l'aide de VPN authentifiés avec des clés RSA (ces petits porte-clés qui montrent un ensemble de numéros constamment changeant) ou utilisent un ensemble entièrement séparé de connexions pour les services de la région DMZ.
Les serveurs Web "externes" sont dans le DMZ et ne peuvent pas accéder directement aux serveurs A / D. Il existe toutefois une règle de pare-feu pour autoriser le trafic Port 80/443 à partir des iPaddresses DMZ spécifiques des serveurs Web externes à l'adresse Port / IP spécifique du serveur d'applications interne (ASP.NET). À l'avenir, nous pourrions co-lo les serveurs hors site entièrement, mais la même exception de pare-feu par Port and IP permettrait toujours aux serveurs Web externes d'appeler des appels de service Web sur le serveur d'applications interne.
Vous voudrez peut-être jeter un coup d'œil à ces deux ressources. Le premier vous fournira tout ce que vous voulez savoir sur Active Directory, et la seconde vous montrera comment vous connecter.
Vous pourriez avoir des problèmes de connexion au serveur AD distant. Donc, comme un travail potentiel autour, j'envisagerais que l'application Web appelle un service Web d'authentification qui réside sur le réseau d'entreprise.
Je pense que vous avez voulu séparer les liens: codeProject.com/kb/system/euvertinad.aspx MSDN.microsoft.com/en-us/Library/aa302397. Aspx
Oui, mais je n'ai autorisé qu'un seul lien actuel, et les deux sont nécessaires. Je les ai trouvés extrêmement utiles pour une mise en œuvre d'un problème similaire que j'avais.
Vous pourrez peut-être simplifier cela en donnant un portail de connexion différent aux entrepreneurs / affiliés.
Les applications en question seront utilisées à la fois par les utilisateurs internes (A / D) et des utilisateurs externes (non A / D). Un identifiant doit gérer les deux scénarios.
Il est intéressant de regarder ces anciennes questions qui sont devenues «bien résolues» par les nouvelles technologies. Je me souviens du scénario et du travail qui a motivé cette question; Ces jours-ci entre Azure A / D et solutions telles que OAuth (tout simplement effectué un projet avec Identity Server), il est facile d'oublier à quel point l'authentification et l'autorisation plus compliquées aiment une décennie.