Sécurité et Tolérance de panne en ligne de commande

Parfois, configurer la sécurité du serveur gérant les accès clients (rôle CAS) est un véritable challenge. Quoiqu’il en soit, c’est une étape importante pour sécuriser l’ensemble des communications externes ! Pour chiffrer les communications, le serveur CAS utilise Secure Sockets Layer (SSL) qui requiert l’utilisation d’un certificat.

Les clients de messagerie doivent faire confiance à l’autorité de certification qui a généré le certificat. Il existe trois types de certificats : Voir Tableau 1 Nativement, Exchange utilise des certificats auto-signés pour sécuriser les communications. Si un client de messagerie accède au serveur CAS depuis l’extérieur, il est nécessaire de changer ce certificat par un certificat issu d’une autorité de certification de confiance.

De plus, les certificats auto-signés ne peuvent pas être utilisés avec Outlook Anywhere. Afin de mettre en place un certificat, il est important de respecter le processus suivant :

1- Générer le certificat

Evidemment, PowerShell est là pour nous aider grâce à la Cmdlet « New- Exchange Certificate » ! Sans paramètre, cette Cmdlet génère un certificat auto-signé qui expire au bout d’une année. Sur notre serveur CAS, pour générer un certificat valide pour plusieurs noms DNS (type de certificat le plus utilisé !) nous ferons donc ainsi : New-ExchangeCertificate ` –GenerateRequest :$true ` –FriendlyName ContosoCert ` –PrivateKeyExportable:$true ` –Path ‘c:\temp\CertRequest.req’ ` –SubjectName ‘C=FR, S=Ile de France, L=Paris, O=Contoso,OU=IT, CN=webmail.contoso.com’ ` –DomainName webmail.contoso.com,autodiscover.contoso.com

Dans cet exemple, les utilisateurs accèderont à leur messagerie avec OWA par l’URL « webmail.contoso.com ». L’autodiscover permettra aux clients Outlook 2007 de se configurer automatiquement de manière sécurisée par ce certificat.

2 – Obtenir le certificat

L’obtention du certificat dépend de l’autorité de certification que l’on souhaite utiliser ! Dans le cas où nous avons une autorité de certification racine de confiance dans notre entreprise, nous pouvons lui soumettre le fichier généré dans l’étape précédente. Notre certificat nous sera alors délivré. Il est aussi possible d’acheter un certificat à une autorité de certification publique comme VeriSign.

3 – Importer le certificat

Dans cette étape, nous allons importer le certificat obtenu sur la même machine qui a fait la requête car la sécurité du certificat est liée à la machine qui l’a généré ! Si nous importons notre certificat sur une autre machine, nous n’aurons pas la clé privée. Sur notre serveur CAS nous allons donc utiliser à nouveau notre outil en ligne de commande :

Import-ExchangeCertificate –Path c:\temp\CertRequest.req Sachez qu’il existe une Cmdlet pour supprimer un certificat importé en cas d’erreur : « Remove-ExchangeCertificate » !

4- Activer le certificat

Cette avant dernière étape lie le certificat à un service Exchange. Pour cela et comme d’habitude, une Cmdlet fait le travail : « Enable-ExchangeCertificate ». Elle prend en paramètre l’identifiant unique du certificat à activer que nous pouvons obtenir via la Cmdlet « Get-ExchangeCertificate » et le service Exchange auquel lier le certificat. Par Exemple : Enable-ExchangeCertificate ` –Thumbprint A7810FE86C10091EB8A764B5430CC7681ABBA410 ` -Services IIS

5 – Copier le certificat

Lorsque dans une organisation Exchange il y a plusieurs serveurs CAS ou bien un serveur ISA chargé de publier les services Exchange, il est nécessaire d’importer le certificat sur ces machines. Pour cela, nous devons dans un premier temps l’exporter avec la console MMC au format PFX incluant la clé privée puis l’importer sur les autres machines: Import-ExchangeCertificate –Path c:\temp\CASCert.pfx ` -Password (Get-Credential).Password

Dans l’exemple, le mot de passe de la clé privée sera demandé interactivement. Rien de vraiment compliqué !