06
OCT
2014

Publication OWA via ADFS Claims-based en Powershell

tag : ,
comment : 0

Dans cet article, nous allons aborder la mise en place de l’authentification basée sur les revendications sur une infrastructure Exchange 2013. L’objectif principal est de fournir une méthodologie pour l’implémentation de ce type d’authentification pour le service Outlook Web App.

A partir de la version Exchange 2013 SP1, il est possible de configurer les services de Webmail OWA et ECP afin d’utiliser l’authentification « claimed-based ». Pour cela, il convient de configurer un serveur permettant de gérer ces revendications et faire la liaison entre la plateforme Exchange 2013 et Active Directory : Un serveur Windows ADFS (à minima en version 2.0)

L’authentification basée sur les revendications ADFS remplacent les méthodes d’authentifications traditionnelles dépendantes de chaque serveur à configurer : Windows (NTLM), Basic, Digest, Formulaires, LiveID et certificats.

Ce mécanisme permet donc une centralisation de l’authentification grâce aux fonctionnalités du serveur ADFS. Cela permet d’authentifier toutes les personnes provenant de domaines avec qui le serveur ADFS possède une relation de confiance. De plus, grâce au rôle WAP (Web Application Proxy) disponible depuis Windows Server 2012 R2, il est possible de configurer les accès externe de manière sécurisée (Exemple : Architecture trois tiers).

En pratique :

L’architecture proposée est la suivante :

  • Un domaine Active Directory domaine.com
  • Un contrôleur de domaine en Windows Server 2012 R2
  • Un serveur ADFS: adfs.domaine.com (résolution DNS IP local)
  • Un serveur WAP: adfs.domaine.com (résolution DNS IP public)
  • Un serveur Exchange 2013 SP1

SCHEMA

La configuration s’effectue à trois niveaux :

  1. Au niveau du serveur WAP
  2. Au niveau du serveur ADFS
  3. Au niveau des serveurs d’accès clients Exchange 2013 SP1

 

Le principal enjeu pour configurer l’authentification basée sur les « claims » est de comprendre comment interagissent les certificats en fonction des serveurs et des services proposés.

Prérequis :

  • Un serveur ADFS en version 3 sur Windows Server 2012 R2
  • Un serveur Exchange 2013 SP1 sur Windows Server 2012 R2
  • Un serveur WAP (pour les accès externe) sur Windows Server 2012 R2
  • Un contrôleur de domaine en Windows Server 2012 (minimum)

 

Etape 1: Configuration du serveur ADFS

Nous allons nous intéresser à deux certificats présents sur le serveur ADFS :

  • Service de communication

    Ce certificat est utilisé par le serveur ADFS pour authentifier les utilisateurs. C’est ce certificat qui est présenté aux utilisateurs se connectant à partir du réseau interne
  • Token signing

    Ce certificat permet de chiffrer les échanges entre les serveurs Exchange 2013 et ADFS
    Il doit être installé sur toutes parties de confiance s’il est auto-signé ou être délivré par une autorité de certification reconnue.

L’authentification par les claims requiert la configuration d’une partie tierce de confiance, aussi appelé  « relying party trust ». A cette fin, il convient de disposer des éléments suivant :

Exécuter les lignes suivantes dans une session PowerShell :

Configuration ADFS
#Stockage des variables en mémoire
$owaURL = « https://webmail.domaine.com/owa »
$ecpURL = « https://webmail.domaine.com/ecp »

#Règle d’acceptation de base
$IssuanceAuthorizationRules=@’
@RuleTemplate = « AllowAllAuthzRule »    => issue(Type = http://schemas.microsoft.com/authorization/claims/permit »,Value = « true »);
‘@

#Les règles de transformation
$IssuanceTransformRules=@’
@RuleName = « ActiveDirectoryUserSID »  c:[Type == « http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname », Issuer == « AD AUTHORITY »]    => issue(store = « Active Directory », types = (« http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid »), query = « ;objectSID;{0} », param = c.Value);
@RuleName = « ActiveDirectoryGroupSID »    c:[Type == « http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname », Issuer == « AD AUTHORITY »] => issue(store = « Active Directory », types = (« http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid »), query = « ;tokenGroups(SID);{0} », param = c.Value);
@RuleName = « ActiveDirectoryUPN »    c:[Type == « http://schemft.com/ws/2008/06/identity/claims/windowsaccountname », Issuer == « AD AUTHORITY »]    => issue(store = « Active Directory », types = (« http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn »), query = « ;userPrincipalName;{0} », param = c.Value);
‘@

Note : Retirer les espaces si vous copier/coller ce code dans un bloc note

Création de la « Relying party trust OWA-2013 et ECP »
Add-ADFSRelyingPartyTrust -Name « OWA-2013 » -Enabled $true -Notes « Confiance pour $owaURL » -WSFedEndpoint $owaURL -Identifier $owaURL -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

Add-ADFSRelyingPartyTrust -Name « ECP-2013 » -Enabled $true -Notes « Confiance pour $ecpURL » -WSFedEndpoint $ecpURL -Identifier $ecpURL -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

Il convient ensuite de vérifier que les Relying Party trust ont bien été créées :

ADFS-CONF

Notez également qu’il est possible de réaliser la même configuration via l’interface graphique.

Etape 2: Configuration du serveur Exchange 2013 SP1

Il convient également de configurer les répertoires virtuelles OWA et ECP afin de prendre en compte l’authentification basée sur les claims. Pour réaliser la configuration des serveurs Exchange 2013, il convient de renseigner l’empreinte du certificat « Token-Signing ». Pour l’obtenir, exécutez directement la commande suivante sur le serveur ADFS : Get-AdfsCertificate | Where-Object {$_.CertificateType -eq « Token-Signing »} | Select Thumbprint

Configuration du serveur Exchange 2013 SP1

#Importer du certificat auto-signé Token-signing sur le serveur Exchange
$owaURL = « https://webmail.domaine.com/owa »
$ecpURL = « https://webmail.domaine.com/ecp »
$uris = @($owaURL,$ecpURL)
$ADFSIssuerURL= « https://adfs.domaine.com/adfs/ls/ »
$ADFSSigningCertificateThumbprint = « C9889C37DD3BFE09A08307A618152D5DD314D0A9 »

#Ajout des informations du serveur ADFS au niveau de l’organisation Exchange
Set-OrganizationConfig -AdfsIssuer $ADFSIssuerURL -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint $ADFSSigningCertificateThumbprint

#Configuration des répertoires virtuels OWA et ECP   
Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like « Version 15.0* »} | Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false

Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like « Version 15.0* »} | Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false

A ce stade, redémarrer les services web des serveurs d’accès client (iisreset /noforce)

Vérification de la configuration:

Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like « Version 15.0* »} | Get-EcpVirtualDirectory | Select Server,Name,*Auth*ECP

Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like « Version 15.0* »} | Get-OwaVirtualDirectory | Select Server,Name,*Auth*OWA

Etape 3: Configuration du serveur WAP

Pour rappel, le serveur WAP remplace le rôle « ADFS Proxy » utilisé dans les versions précédente d’ADFS et a pour rôle de transmettre les requêtes provenant de l’extérieur vers les serveurs ADFS de l’organisation.
Ce dernier permet un premier filtrage par URL. De plus, lorsque l’authentification claim est configurée sur les serveurs applicatifs, il n’est pas obligatoire que ce serveur soit installé dans le domaine Active Directory.
WAP est un rôle de Windows Server 2012 R2.

Afin de permettre un accès en Webmail en dehors de l’organisation, il convient d’effectuer les actions suivantes :

Stockage des variables

$owaURL = « https://webmail.domaine.com/owa »
$ecpURL = « https://webmail.domaine.com/ecp »
$WebApplicationProxyCertThumpbrint= »A9CDD7E0E2872D6343B2A638991ADF9F52C7D9CF »

La variable $WebApplicationProxyCertThumpbrint correspond au certificat utilisé pour l’application à publier. Il doit à minima contenir webmail.domaine.com.
Pour l’obtenir : dir cert:localmachine\my
Le paramètre ADFSRelyingPartyName correspond au nom de la partie tierce de confiance crée précédemment sur le serveur ADFS.

Configuration de la Web Application

Accès OWA :
Add-WebApplicationProxyApplication -BackendServerUrl « $owaURL/ » -ExternalCertificateThumbprint $WebApplicationProxyCertThumpbrint -ExternalUrl « $owaURL/ » -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘OWA-2013’

Accès ECP :
Add-WebApplicationProxyApplication -BackendServerUrl « $ecpURL/ » -ExternalCertificateThumbprint $WebApplicationProxyCertThumpbrint -ExternalUrl « $ecpURL/ » -Name ‘EAC’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘ECP-2013’

Pour debugger une infrastructure ADFS, il est possible d’utiliser :

  1. Journal d’évènement : Event Viewer > Applications and Services Logs > AD FS > Admin
  2. Logs IIS

 

En conclusion :

L’authentification via les claims est relativement simple à mettre en place.
Grâce à ce nouveau mode d’authentification, Microsoft permet à ses clients de bénéficier d’une authentification unique (SSO) aussi bien pour les clients présents dans l’organisation que ceux à l’extérieur. Ainsi, il est possible de bénéficier du SSO entre vos applications comme par exemple vos accès aux sites Sharepoint et webmail Exchange.

Publication OWA via ADFS Claims-based en Powershell
1 vote, 5.00 avg. rating (97% score)
A propos de l'auteur
Passionné des technologies Microsoft Exchange / Lync / O365

Laisser un commentaire

*