Puis-je détecter les utilisateurs de domaine authentifiés dans IIS / ASP.NET sans demander à tous les autres de s'identifier ?

Cette solution n'est probablement pas disponible OOTB (out of the box).

Nous avons SharePoint 2010 dans notre environnement et lorsque nous l'ouvrons via IE, il ne demande pas d'informations d'identification. Dans tous les autres cas, le nom d'utilisateur et le mot de passe du domaine sont demandés à chaque visite. Je pense que s'il y avait une solution, MS l'aurait fournie avec SharePoint car ce message est très ennuyeux.

Auparavant, un projet avait un besoin similaire qui a ensuite été réorienté vers l'authentification des formulaires (sur la base de règles commerciales révisées). Aujourd'hui, je m'attends à être confronté à un besoin similaire dans un futur proche et je n'ai vu aucun exemple de travail pour ce besoin depuis les jours du scénario précédent.

A part demander aux utilisateurs d'utiliser IE (pour ce genre de choses), la solution immédiate qui me vient à l'esprit est d'avoir un plugin de navigateur qui communiquera avec active directory et gèrera ce problème au niveau du backend. Malheureusement, même s'il est valide, il n'est pas possible pour la majorité des développeurs confrontés à ce problème (y compris moi) d'opter pour cette solution.

J'ai également fait des recherches à ce sujet et je me suis creusé les méninges pour savoir comment faire fonctionner ce système, et j'ai finalement trouvé la solution. Je me suis donc dit que j'allais donner à tout le monde ma façon de faire. Ce n'est pas très propre, mais ça marche. Ce processus pourrait être appliqué à d'autres pages et à d'autres méthodes de création de pages.

J'ai créé une page en PHP avec un formulaire de connexion. Elle utilise une connexion LDAPS pour authentifier les utilisateurs. Cela fonctionne bien. Ensuite, j'ai voulu être aventureux et le modifier, de sorte que les personnes qui sont déjà sur le domaine, n'ont pas besoin de se connecter. Cela fonctionne bien en lisant le champ $_SERVER['REMOTE_USER'], mais me demande d'activer l'authentification Windows. C'est très bien, mais cela ignore complètement mon formulaire de connexion, et il y a quelques utilisateurs qui sont des utilisateurs de débogage et de test et des sous-traitants que nous ne voulions pas ajouter à AD, donc ils sont conservés dans une base de données MySQL. Sans le formulaire de connexion, ils ne peuvent pas se connecter ! De plus, si l'utilisateur utilise Firefox, il ne transmet pas les informations d'identification $_SERVER['REMOTE_USER'] de toute façon.

Pour corriger la page de connexion, j'ai copié la page, ajouté un _SSO (single sign on) après elle. Ainsi, mon application est maintenant "www.mywebsite.com/testapp", alors qu'elle serait "www.mywebsite.com/testapp_sso/". L'une aura l'authentification Windows, l'autre le login anonyme. Ensuite, j'utilise IIS7 URL Rewrite, de sorte que lorsqu'ils accèdent à l'application test, et que leur adresse IP, qui est $_SERVER['REMOTE_HOST'], se trouve dans notre sous-réseau, l'URL est réécrite dans le dossier _SSO.

L'étape suivante consiste à ajouter une autre règle de redirection d'URL pour "firefox" _SERVER["HTTP_USER_AGENT"]. Cela obligerait tout le monde, même s'ils sont dans la plage IP, à tomber sur la page qui n'est pas _SSO. Ainsi, même s'ils sont sur notre réseau, les utilisateurs de Firefox verront toujours la bonne vieille page de connexion que tout le monde voit au lieu de la fenêtre contextuelle d'authentification de Windows qui est horrible.

L'étape finale consiste à ajouter un masquage d'URL, de sorte que les utilisateurs ne sachent pas qu'ils sont sur testapp_SSO, ou testapp.

Ce sera tout pour les utilisateurs. Mais maintenant, chaque fois que vous voulez mettre à jour une page, vous devez également la copier dans le dossier _SSO. Vous pouvez créer une synchronisation à l'aide d'un logiciel de synchronisation, mais vous pouvez aussi créer un lien symbolique en dur ! Les autorisations fonctionneront entre les deux dossiers, et vous n'aurez à en mettre qu'un seul à jour.

Oui oui, si c'était Linux, ce serait tellement plus facile. Mais nous devons utiliser IIS ici.