vdu

La publication sur internet de Microsoft CRM 2013 pose un problème de taille suivant qu’on souhaite y accéder depuis un réseau interne ou depuis l’internet. En effet soit l’url est différente, soit l’authentification devra se faire via un formulaire d’authentification, même depuis le réseau interne ( l’authentification Windows ne fonctionne pas ).

Pour résoudre ce problème, il existe deux solutions élégantes à savoir, ajouter des règles de réécriture d’url au niveau des fronteaux Web de CRM, ou d’ADFS.

Ajout de règles au niveau d’ADFS

L’objectif de la règle de réécriture, consiste à détecter l’origine des requêtes et en fonction de leurs origine, supprimer le paramètre “wauth” de la querystring.

Le paramètre wauth, indique au serveur le type d’authentification qui sera utilisé par ADFS:

Si ce paramètre n’est pas utilisé dans l’url, c’est la première méthode d’authentification spécifiée dans le Web.config qui sera utilisé, par défaut l’authentification Windows.

<microsoft.identityServer.web>
    <localAuthenticationTypes>
      <add name="Integrated" page="auth/integrated/" />
      <add name="Forms" page="FormsSignIn.aspx" />
      <add name="TlsClient" page="auth/sslclient/" />
      <add name="Basic" page="auth/basic/" />
    </localAuthenticationTypes>

Donc pour qu’ADFS propose une authentification Windows, il suffit que l’url de la requête d’authentification adressée au serveur, ne contienne pas de paramètre wauth et que la première authentification configurée dans le fichier web.config soit “integrated”.

La solution pour avoir une authentification Windows depuis l’interne consiste donc à réécrire les url, en supprimant le paramètres “wauth” pour les requêtes ne provenant pas de l’internet.

Généralement les requêtes provenant d’internet peuvent être détectées via le header “X-Forwarded-For”. Si ce n’est pas possible il est aussi possible de détecter l’origine des requêtes venant du réseau interne via la variable d’environnement “REMOTE-ADDR”.

Exemple de règle basée sur le header “X-Forwarded-For”:

<system.webServer>
<rewrite>
      <rules>
        <rule name="Strip wauth parameter" enabled="true" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
                        <add input="{HTTP_X_Forwarded_For}" pattern="\b(?:192)\.(?:168)\.(?:1).(?:1)\b" negate="true" />
                        <add input="{QUERY_STRING}" pattern="(.*)(wauth=.*)(.*)" />
          </conditions>
          <action type="Rewrite" url="{R:0}?{C:1}" appendQueryString="false" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>

Cette règle supprime le paramètre “wauth” pour toutes les requêtes dont le header X_Forwarded_For est différent de 192.168.1.1.

Ajout de règles au niveau de CRM

Le principe de la règle reste le même, puisqu’il consiste à détecter l’origine de la requête. Mais dans ce cas on redirige la requête via un 302 vers le site interne.

Supposons que l’url externe de notre organisation soit http://orga.contoso.com et que l’url interne soit http://crm.contoso.com/orga. L’accès à l’url externe est protégé par un formulaire tandis que l’url interne est protégée par l’authentification Windows intégré.

L’objectif étant que l’accès se fasse via la même url de l’interne et de l’externe à savoir http://orga.contonso.com, mais avec une authentification différente, il suffit d’intercepter les requêtes en provenance du réseau interne et de les rediriger vers l’url http://crm.contonso.com/orga.

Exemple de règle basée sur le header “X-Forwarded-For”:

<rule name="Redirect Internal Connections" stopProcessing="true">
    <match url="(.*)" />
        <conditions trackAllCaptures="true">
            <add input="{HTTP_X_Forwarded_For}" pattern="\b(?:192)\.(?:168)\.(?:1).(?:1)\b" negate="true" />
            <add input="{HTTP_HOST}" pattern="([^\.]*)\.(.*)" />
        </conditions>
    <action type="Redirect" url=http://crm.contoso.com/{C:1}/{R:1} appendQueryString="true" redirectType="Found" />
</rule>

Cette règle renvoie un 302 vers http://crm.contoso.com/orga/* à chaque requête http://orga.contoso.com/* dont le header X_Forwarded_For est différent de 192.168.1.1.