Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

system

déc. 02
Etude d'une solution libre de serveur mandataire inverse ou "reverse proxy" pour Sharepoint 2013

Dans cet article, nous nous attacherons à trouver et à mettre en place une solution de serveur mandataire inverse ou « reverse proxy » compatible avec une authentification NTLM.

Nous ne discuterons pas de l'utilité de la mise en place d'un serveur mandataire pour des applicatifs accessibles depuis internet, vous trouverez de la documentation ici [1] et là [2].

Microsoft propose certains produits de serveurs mandataires inverses pour Sharepoint [3], on peut également jeter un coup d'œil du côté des serveurs mandataires fonctionnant avec Skype for Business [4].

Le tableau ci-dessous regroupe quelques solutions [5] qui répondent à notre besoin :
      

Solution Informations Evaluation
Windows Server 2012 R2 avec serveur mandataire d'application web (WAP)PropriétaireNon testé
Forefront Threat Management Gateway (TMG) 2010Propriétaire. Le support du produit est assure jusqu'au 14/04/2020Non testé
F5 BIG-IPPropriétaireNon testé
Citrix NetScalerPropriétaireNon testé
Sophos UTMPropriétaireNon testé
KempPropriétaireNon testé
WatchGuardPropriétaireNon testé
SonicwallPropriétaireNon testé
SquidLibreNon testé, théoriquement fonctionnel mais certains problèmes peuvent exister [6]
Nginx « Libre » mais le module NTLM est payantNon testé
ApacheLibreTesté avec le module mod_security mais authentification impossible [7]. Cependant certains l'on fait fonctionner [8]
HAProxyLibreTesté, et fonctionnel

  

Nous avons retenu le logiciel HAProxy.

Dans la suite de ce guide nous allons présenter la configuration nécessaire pour que HAProxy agisse comme un serveur mandataire inverse pour Sharepoint 2013.

Pré requis : 

 

  • Une instance Sharepoint 2013 fonctionnelle (serveur IIS en écoute sur le port HTTP
  • Un système d'exploitation de type Unix sur lequel nous installerons le paquet HAProxy, nous avons choisi CentOS Linux 7.5.1804

Procédure :

  

1.    Installer le paquet HAProxy

sudo yum install haproxy

 

2.    Configuration minimale de HAProxy via le fichier haproxy.cfg dans /etc/haporxy/

global
        user haproxy
        group haproxy
        daemon
 
defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http
 
frontend frontend_test
  bind 192.168.1.1:80
  mode http
  default_backend backend_test
 
backend backend_test
  mode http
  server test 192.168.1.2:80


 

3.    Redémarrer le service HAProxy

sudo systemctl restart haproxy

 

4.    Tester le service via un navigateur web. Pour le test, on peut modifier le fichier host (/etc/hosts sous Unix ou C:\Windows\System32\drivers\etc\hosts sous Windows) de la machine pour pointer directement sur le serveur mandataire inverse (192.168.1.1 dans notre exemple).

 

Nous venons de mettre en place un serveur mandataire inverse avec une authentification NTLM.

Aller plus loin :

 

Le protocole HTTP/1.1 est sans état [10], c'est-à-dire que au sein de la même connexion TCP chaque requête est indépendante, or le protocole d'authentification NTLM lui, authentifie la connexion ce qui viole une exigence de la norme HTTP [11]. Ainsi l'authentification NTLM passant par un serveur mandataire est compliquée car il faut que le « reverse proxy » différentie et maintienne chaque connexion TCP pour chaque client [12] [13]. Le comportement pas défaut de HAProxy est en mode « Keep-Alive » qui va maintenir la connexion TCP ouverte côté client et serveur ce qui rend l'authentification NTLM possible [14] .

L'authentification NTLM qui repose sur un échange « challenge/response » qui est facilement décryptable en écoutant passivement le réseau via un logiciel tel que Cain&Abel. Un autre type d'attaque possible est « pass-the-hash » qui utilise le hash de l'utilisateur, stocké dans le « Local Security Authority Subsystem Service (LSASS) » pour s'authentifier au d'autres machine Windows du réseau. Il faut donc préférer l'authentification Kerberos à NTLM [15].

Ressources externes :

 

[1] https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_TLS_NoteTech.pdf

[2] https://www.ssi.gouv.fr/uploads/2017/01/guide_hygiene_informatique_anssi.pdf

[3] https://docs.microsoft.com/fr-fr/sharepoint/hybrid/configure-a-reverse-proxy-device-for-sharepoint-server-hybrid

[4] https://docs.microsoft.com/en-us/SkypeForBusiness/certification/infra-rev-proxy

[5] https://www.reddit.com/r/sysadmin/comments/34e3o5/recommendation_for_microsoft_tmg_replacement/

[6] http://squid-web-proxy-cache.1019090.n4.nabble.com/Problems-with-NTLM-authentication-td4674800.html

[7] http://apache-http-server.18135.x6.nabble.com/Apache-Reverse-Proxy-and-NTLM-Authentication-Help-td5040129.html

[8] https://itgration.blogspot.com/2016/12/apache-reverse-proxy-to-sharepoint-2013.html

[9] https://www.howtoforge.com/setting-up-a-high-availability-load-balancer-with-haproxy-keepalived-on-debian-lenny

[10] https://tools.ietf.org/html/rfc7231

[11] https://tools.ietf.org/html/rfc4559

[12] https://stackoverflow.com/questions/41936501/reverse-proxying-an-ntlm-protected-website

[13] https://serverfault.com/questions/375858/haproxy-and-windows-auth

[14] https://www.haproxy.com/fr/documentation/aloha/7-5/traffic-management/lb-layer7/http-modes/#keep-alive-kal-mode

[15] https://www.ssi.gouv.fr/uploads/2015/01/NP_NavigateurSecurise_FireFox_1-1.pdf

Commentaires

Aucun commentaire sur ce billet.