Comment faire pour activer l'authentification windows par l'intermédiaire d'un proxy inverse?

Désolé si c'est un doublon, car je ne suis pas un de sécurité, ni réseau d'experts j'ai peut-être raté le bon lingo pour trouver de l'information.

Je suis en train de travailler sur une application pour intercepter et modifier des requêtes et des réponses HTTP entre un navigateur web et un serveur web (voir comment intercepter et de modifier des requêtes HTTP sur le serveur? pour le fond). J'ai décidé de mettre en place un reverse proxy en ASP.Net qui transmet les demandes du client pour le serveur HTTP, traduit les liens et les en-têtes de la réponse à l'correctement "proxified" de l'URL, et envoie la réponse au client, après en avoir extrait les informations pertinentes à partir de la réponse.

Il fonctionne comme prévu, sauf pour la partie authentification: le serveur web utilise l'authentification NTLM par défaut, et il suffit de transférer les requêtes et les réponses à travers le proxy inverse ne permet pas à l'utilisateur de s'authentifier sur l'application à distance. À la fois le proxy inverse et l'application web sont sur la même machine physique et sont exécutés dans le même serveur IIS (Windows server 2008/IIS 7 si ce qui compte). J'ai essayé à la fois de l'activation et de la désactivation de l'authentification sur le proxy inverse app avec pas de chance.

J'ai cherché de l'information à ce sujet, et il semble être lié à la "double-hop problème", que je ne comprends pas. Ma question est: est-il un moyen pour authentifier l'utilisateur sur l'application à distance à travers le proxy inverse, l'utilisation de NTLM? Si il n'y a aucun, existe t il d'autres méthodes d'authentification que je pourrais utiliser?

Même si vous n'avez pas de solution à mon problème, il suffit de m'indiquer les informations pertinentes à ce sujet pour m'aider à sortir de la confusion serait génial!

InformationsquelleAutor jeremy-george | 2010-12-06
  1. 10

    J'ai trouvé quel était le problème (et c'est NTLM): afin que le navigateur demande à l'utilisateur pour ses informations d'identification, la réponse doit avoir un code de statut 401. Mon reverse proxy qui a été transmission de la réponse au navigateur, donc IIS a été l'ajout d'un code HTML pour expliquer la page demandée ne peut pas être consulté empêchant ainsi le navigateur de demander des informations d'identification.
    Le problème a été résolu en supprimant le contenu de la réponse lorsque le code d'état est un 401.

    Avec tout le respect que j'ai pour celui qui a répondu qu'il y a quelques années, je dois avouer que ce n'est manifestement faux. Le problème a été en effet résolu APRÈS avoir retiré le contenu de la réponse lorsque le code d'état est un 401, mais il n'avait rien à voir avec le problème initial..
    La vérité est que l'authentification windows a été faite pour authentifier les gens sur les réseaux windows, où aucun serveur proxy n'est présent ou même nécessaire.
    Le principal problème avec l'authentification NTLM est que ce protocole ne permet pas d'authentifier la session HTTP, mais la connexion TCP sous-jacente, et autant que je sache, il n'existe aucun moyen d'accéder à partir d'un code asp.
    Chaque serveur proxy, j'ai essayé cassé l'authentification NTLM.
    L'authentification Windows est confortable pour un utilisateur car il ne sera jamais besoin d'entrer votre mot de passe pour n'importe quelle application que réside peut-être dans votre intranet, effrayant pour un gars de la sécurité, car il s'agit d'une auto-login, sans même une invite si le domaine du site est de confiance par IE, choquant pour un administrateur de réseau, car il fond à la demande, le transport et la couche réseau dans certains "windows boule de mug" au lieu de simplement le trafic http.

    • allez-y fonzo!
    InformationsquelleAutor jeremy-george
  2. 6

    NTLM ne fonctionnera pas si les paquets TCP sont pas transmis exactement comme le reverse proxy reçu > eux. Et c'est pourquoi de nombreuses reverse proxy ne fonctionne pas avec l'authentification NTLM. (comme nginx) >, Ils transmettent les requêtes HTTP correcty mais pas les paquets TCP.

    Nginx a la fonctionnalité de travailler avec l'authentification NTLM. Keepalive doit être activé, ce qui n'est disponible que par l'http_upstream_module. En outre, à l'emplacement de bloc, vous devez spécifier que vous allez être en utilisant le protocole HTTP/1.1, et que la "Connexion" champ d'en-tête doit être effacé pour chaque proxy demande. Nginx config devrait ressembler à quelque chose comme:

    upstream http_backend {
    server 1.1.1.1:80;

    keepalive 16;
}

server {
...

location /{
       proxy_pass http://http_backend/;
       proxy_http_version 1.1;
       proxy_set_header Connection "";
    ...
    }
 }

    Je me grattais la tête depuis quelques temps avec cette question, mais le ci-dessus fonctionne pour moi. Notez que si vous avez besoin de proxy HTTPS trafic, séparé en amont du bloc est jugé nécessaire. Pour préciser un peu plus, "keepalive 16;" spécifie le nombre de connexions simultanées à l'amont de votre procuration est autorisé à conserver. Ajuster le nombre que par le nombre de visiteurs simultanés sur le site.

    • Merci, cela fonctionne. J'ai aussi ajouté proxy_set_header Hôte, X-Real-IP, X-Forwarded-For; à l'emplacement " / " tag.
    • Soyez prudent avec cette approche, la première lecture de mailman.nginx.org/pipermail/nginx/2016-February/049889.html. Les sessions utilisateur peut obtenir mélangés, de sorte qu'un utilisateur peut accidentellement dans une autre session de l'utilisateur.
    InformationsquelleAutor Paf
  3. 4

    Bien que c'est un vieux post, je veux juste signaler qu'il fonctionne très bien pour moi avec un Apache2.2 reverse proxy et le keepalive=en option. De toute évidence, ce qui maintient la connexion entre le proxy et le SharePoint hôte ouvert et "épinglé" pour le client<>connexion proxy. Je ne sais pas exactement mécanismes à l'origine de cela, mais il fonctionne assez bien.

    Mais: Parfois, mes utilisateurs rencontrent le problème qu'ils êtes connecté en tant qu'un autre utilisateur. Il semble donc y avoir un mélange à travers des séances. Je vais devoir donner à ce des tests supplémentaires.

    Solution pour tout (dans le cas où vous avez un valide, certificat SSL signé): Commutateur de IIS pour l'Authentification Basique. Cela fonctionne tout à fait bien, et même Windows (c'est à dire de Bureau avec SharePoint connexion, tous les WebClient à base de processus, etc.) ne me plaindrai pas du tout.
    Mais ils seront quand vous êtes juste en utilisant http, sans SSL/TLS, et aussi avec des certificats auto-signés.

    InformationsquelleAutor Nico R
  4. 3

    Je confirme que cela fonctionne avec "keep-alive=on" sur apache2.2

    J'ai examiné les trames avec Wireshark, et je sais pourquoi ça ne marche pas. NTLM ne fonctionnera pas si les paquets TCP sont pas transmis exactement comme le reverse proxy reçus. C'est pourquoi de nombreux proxys inverses, comme nginx, ne fonctionnent pas avec l'authentification NTLM. Les proxys inverses de transférer les demandes HTTP correctement mais pas les paquets TCP.

    NTLM nécessite une connexion TCP proxy inverse.

    InformationsquelleAutor devylJon