27/03/2010Nous avions vu avec le billet précédent http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=128 que l'accès à des documents protégés pour des utilisateurs extérieurs à l'organisation interne posait quelques difficultés. Dans notre cas, nous utilisons Windows Live Id pour utiliser les services de Microsoft RMS Online pour permettre à des comptes Passport.Net d'accéder aux licences de documents. Cependant, les services web RMS licensing interne à l'organisation nécessitent une authentification. Ce paramètre impliquait aux administrateurs de créer un compte Active Directory pour chaque utilisateur externe, … ceci n'est donc pas envisageable si le nombre d'utilisateurs est conséquent et surtout pour des raisons de sécurité.
Ainsi pour palier à ce problème, plusieurs scénarios sont possibles :
- Soit on travaille essentiellement avec un partenaire connu, et dans ce cas l'installation des services RMS dans l'organisation externe puis une relation d'approbation RMS entre les deux organisations permettrait de répondre à ce besoin. Cependant cela limite l'échange entre des partenaires connus et une infrastructure RMS doit être disponible dans chaque organisation.
- On peut également rajouter un nouveau cluster RMS dans une DMZ au sein de notre organisation et établit un lien d'approbation avec notre cluster RMS interne. On pourra créer une forêt dédiée pour ce cluster RMS et y créer les utilisateurs externes. Ceci implique tout de même de connaître les utilisateurs et de créer un compte pour chacun d'entre eux. Cela ne permet donc pas une autonomie à un collaborateur.
- En se basant sur le précédent scénario, où un nouveau cluster RMS est en DMZ, mais au lieu de créer une forêt dédié pour y placer des comptes on peut mettre en œuvre une autorisation de type anonyme. Il faut cependant mesurer les conséquences à cet accès.
A travers cet article, je vais explorer le 3ème scénario pour bien comprendre les risques à ouvrir mes services Web RMS de manière anonyme. Pour des raisons de performances, je ne vais pas installer un second serveur RMS et établir une relation d'approbation. Cela fera l'objet d'un prochain article dédié. Je vais utiliser mon RMS principal et autoriser les connexions anonymes, et modifier la règle de publication TMG pour être en adéquation avec ce nouveau fonctionnement anonyme.
Pour cela il faut se rendre sur le serveur RMS et ouvrir la console de gestion IIS. On va rechercher l'application web « _wmcs » et paramétrer l'authentification
On va activer l'authentification anonyme
A présent, sur le serveur TMG (ou ISA) on va modifier la délégation de la règle de publication RMS pour désactiver la délégation comme ceci
On va modifier l'écouteur web de RMS pour indiquer qu'il n'y aura pas d'authentification et appliquer la configuration de TMG
Et pour finir, ne pas oublier d'indiquer All Users dans la règle
Pour vérifier que les changements ont bien été pris en compte et fonctionnel, depuis un poste sur Internet tentez de vous rendre sur l'External URL de RMS. Un message similaire devrait vous être affiché :
Ceci nous permet à présent de remplir les conditions du 3ème scénario. Sur un poste Internet avec un compte .net valide et autorisé dans le document pourra ouvrir le fichier protégé sans messages additionnels. On voit bien au niveau du pare-feu, lorsque l'utilisateur tente d'ouvrir le document la tentative de connexion qui accède jusqu'au serveur RMS
 25/03/2010Dans mon précédent billet, on remarque que si un utilisateur interne souhaite travailler sur un document confidentiel avec un utilisateur externe, cela ne fonctionne pas. Par ailleurs un utilisateur interne en mode nomadisme, ne pourra pas non plus ouvrir le document. On va donc couvrir cette partie-là en modifiant la configuration de RMS, et la publication des licences RMS pour les utilisateurs nomades et externes.
Depuis l'outil d'administration de RMS, on peut configurer les URLs extranet. On va donc rajouter les urls publiques
Ensuite, il faut également autoriser les comptes en Windows live Id
A présent on va créer la règle de publication sur notre Reverse Proxy TMG
Impression écran | Description | 
| On va nommer la règle | 
| On autorise le flux | 
| Un seul site
Si on avait plusieurs serveurs RMS en haute disponibilité on utilisera l'option Web farm | 
| On utilise SSL bien entendu ! | 
| On indique le nom interne complet du serveur RMS | 
| On ajoute le chemin _wmcs/* | 
| Le nom public rms.brazil.com qui doit être enregistré dans le DNS public | 
| Vous utilisez un Web Listener RMS avec une authentification http
Et un bon certificat SSL
| 
| Utilisez la délégation NTLM | 
| Et pour tous les utilisateurs | 
| Voilà, c'est fini. Vous pouvez utiliser le bouton « Test Rule » pour valider le bon fonctionnement.
|
A présent, un utilisateur externe peut lire un document grâce à son Windows Live ID depuis un réseau public. Cependant, il a été nécessaire qu'il utilise un compte du domaine pour être authentifié au niveau du TMG, puis la délégation NTLM vers les Web Services de RMS. Donc cela n'est pas une solution de créer un compte pour chaque personne externe à mon avis, … à creuser encore. Maintenant que nous avons un serveur RMS installé sans configuration additionnelle et nos clients déployés, procédons à quelques tests avec Office Word 2007.
Depuis un poste XP membre du domaine, on va tenter de protéger un document Word. Les options sont disponibles depuis le menu ci-dessous
Note : Si vous êtes invité à vous authentifié à l'aide d'une popup d'authentification basique. Si cela vous arrive, c'est que vos paramètres Internet Explorer ne sont pas corrects. Rajouter donc l'url du serveur RMS dans les sites de confiance ou Intranet. Ensuite, l'authentification sera transparente pour l'utilisateur final.
Il vous sera demandé de confirmer l'utilisateur, en fonction de l'utilisateur connecté dans le domaine.
Puis de définir les utilisateurs autorisés à l'aide de leurs adresse mail, et le niveau de protection du document (ici un exemple avec Word)
Vous noterez que cela se base sur une adresse email. Si l'utilisateur n'a pas de champs emails disponible, vous ne pourrez pas le sélectionner depuis l'annuaire Active Directory. A présent si Jean tente d'ouvrir le document il sera invité à valider l'accès aux informations de licence du document
Les informations seront en cours de téléchargement
Jean peut donc consulter le document mais en lecture seule. J'ai beau tenté de faire un copier/coller du texte, un 'Print Screen' (dans le but de faire de l'OCR), renommer le fichier, .. rien n'y fait. Je n'ai pas la possibilité d'extraire ou modifier les données.
J'ai une solution de contournement basé sur de l'impression écran, en faisant un 'imprim écran' si la machine est une VM ou en utilisant une connexion RDP en mode fenêtré. Cela veut donc dire que cela se base sur un pc hôte et sa fonction d'impression interne. Mais ceci ne me permettra pas de modifier le document, mais seulement de contourner la fonction d'impression. Ainsi, une solution de signature de document serait complémentaire pour s'assurer de l'intégrité du document.
Si un autre utilisateur de l'organisation non autorisé va tenter d'ouvrir le document, même l'administrateur du domaine et oui … aura droit à un refus. Si l'utilisateur qui a protégé le document a permis les demandes d'autorisations, l'utilisateur refusé sera invité à effectuer cette demande.
Et que se passe-t-il si je tente d'ouvrir le document depuis un poste qui ne fait pas partie de l'organisation ? Je vais prendre l'exemple ou je tente de voler le document par un moyen détourné et l'ouvre localement sur mon poste équipé d'Office. Je suis de suite invité à m'inscrire sur les services IRM. En cas de refus ou d'annulation, il me sera impossible d'ouvrir le document. (screenshot de Office 2007 vs Office 2010)
 
Alors je vais tenter d'utiliser mon Windows Live Id pour suivre (A noter qu'il est possible d'en créer un pendant l'assistant, si l'utilisateur n'en a pas)
A la fin de cette mini configuration, je suis invité tout de même à me connecter au serveur RMS interne … L
Et arrive forcément à un échec
Alors on va tenter de protéger le document avec un Windows Live Id externe, au lieu d'un email de l'organisation interne
L'utilisateur est à nouveau inviter à consulter les licences RMS qui sont en internes dans l'entreprise, malgré son Windows Live Id.
Une configuration supplémentaire est donc à rajouter au serveur RMS, ainsi qu'à sa publication. Cela fera l'objet du prochain billet. Pour permettre l'utilisation des fonctions RMS, il est nécessaire de disposer d'un client installé sur les postes. Le client est nativement installé avec Windows Vista, 2008 et Windows 7. Pour les autres systèmes tel que XP et 2003 il faudra installer le client. Le client en disponible en version x86, x64 et IA64.
Source : http://technet.microsoft.com/en-us/library/dd772753(WS.10).aspx
Il est possible d'utiliser l'Active Directory pour déployer le client RMS sur les postes legacy ; ou d'autres solutions comme notamment System Center Configuration Manager (SCCM).
Pour récupérer la version Windows Installer (MSI), téléchargez la version adéquate et pour extraire rajouter l'argument -x. Ici, on va reprendre la procédure pour déployer le client RMS uniquement pour les postes XP SP3.
Vous aurez à présent les fichiers extraits :
Maintenant, on va créer un filtre WMI dans GPMC
On va créer une GPO vide en sélectionnant le filtre WMI précédemment crée
Pour optimiser la GPO on va désactiver la configuration utilisateur
A présent on va éditer la GPO pour ajouter le package MSI (Pensez à utiliser un chemin réseau \\server\share même si le fichier est disponible localement)
Et vous l'utilisez en mode « Assigned »
Le package sera visible dans la GPO
Maintenant il faut assigner la GPO à l'unité d'organisation qui contient vos stations de travail cibles
Au redémarrage des postes XP SP3 auront l'installation automatique du client RMS
Voilà à présent, vos postes Legacy auront le client RMS déployé et concernant Vista/7 pour rappel le client est déjà intégré. Passons à des tests basiques pour voir déjà les premiers aspects sans rentrer dans les détails. Je parle souvent de la technologie IAG/UAG pour de la confidentialité des données, d'éviter la perte de données, … dans un scénario de mobilité essentiellement. A travers quelques articles que je vais publier on va découvrir ensemble un module, pour lesquels les entreprises s'intéressent de plus en plus. D'autant que ce module est désormais intégré dans Windows 2008 et 2008 R2. Nous allons donc parler de RMS, qui permettra de faire de la protection de données de manière très avancée.
Microsoft RMS existait déjà avec Windows 2003, et avait pour numéro de version 1.0. Ce composant est gratuit et devait être téléchargé séparément. Actuellement la dernière version de RMS 1.0 est en Service Pack 2 : http://www.microsoft.com/downloads/details.aspx?familyid=5794538F-E572-4542-A5BD-901B2720F068&displaylang=en
Microsoft RMS 2.0 change de nom, Windows Active Directory RMS et est uniquement disponible pour Windows 2008, alors que la première version ne l'est que pour 2003. Au cours des articles qui vont être écrits sur le sujet, nous ne verrons que la version 2.0 en tant que nouvelle installation. Mais alors, à quoi sert RMS ? Pour la version longue vous pouvez vous rendre sur le site de Microsoft (http://technet.microsoft.com/fr-fr/library/cc771627(WS.10).aspx); vous y trouverez les prérequis nécessaire par la même occasion sur ce lien. Sinon pour simplifier, AD RMS va permettre à une entreprise de protéger activement ces documents et informations sensibles. Cette protection consiste à donner des droits sur un document ou un mail, quel que soit l'emplacement du document. En effet, sur un partage on connait les droits NTFS, mais comment faire si on envoie un document par mail à un collaborateur … Ce dernier le possède désormais et pourra l'imprimer, le transférer, le modifier, … Avec RMS l'utilisateur qui envoie un document sensible pourra définir si son correspondant à le droit de l'imprimer, le transférer, le modifier et toutes autres actions pouvant nuire à la confidentialité de ce document. Ceci peut marcher également avec les utilisateurs extérieurs à une entreprise. Nous allons donc explorer ce rôle, et pour information les services RMS de Microsoft sont gratuits.
Dans ce premier billet, nous allons commencer par installer RMS. L'installation du rôle de RMS n'est pas recommandée pour être installé sur un DC, mais ce sera mon cas à travers ce dossier pour des raisons de performances sur ma maquette.
Impression écran | Description | 
| Pour installer RMS, il faut se rendre dans l'ajout de rôle et sélectionner : « Active Directory Rights Management Services ». | 
| Des composants supplémentaires seront nécessaires, ils vous sont proposés d'être installé. Validez l'installation. | 
| Dans les composants de rôle RMS, il est possible d'installer « Identity Federation Support ». Ce composant permettra de s'appuyer sur de la fédération avec ADFS.
Pour plus d'informations : http://technet.microsoft.com/en-us/library/cc771425(WS.10).aspx
| 
| Lors de la création du premier serveur, seule la première option est disponible.
Il sera possible d'ajouter d'autres serveurs ultérieurement pour assurer une haute disponibilité des services en utilisant la seconde option. | 
| L'assistant va vous proposer de sélectionner une base de données. Si l'utilisation de RMS au sein de l'entreprise ne nécessite pas une haute disponibilité, une petite organisation ou seulement pour un lab l'utilisation de la base de données intégrée est suffisante.
En cas de besoin avancées et de haute disponibilité, il faut alors utiliser un serveur SQL. Dans ce cas, il faudra fournir les informations du serveur SQL.
Il sera possible de modifier ce paramètre ultérieurement avec un outil complémentaire que nous borderons plus tard. | 
| Les services RMS nécessitent l'utilisation d'un compte de service. Le compte doit être un compte standard sans droits spécifiques. Si cependant, vous avez décidé d'installer sur un DC, alors il faudra un compte membre des Domain Admins.
Pour finir, le compte utilisé ne doit pas être le compte avec lequel vous être connecté pour installer RMS. | 
| A présent, il vous est demandé comment sera stockée la clé de sécurité nécessaire pour signer les certificats.
Il est possible d'utiliser un matériel spécifique ou un service de cryptographie spécifique ou encore de la stocker de manière centralisée à l'aide d'un mot de passe.
Pour plus d'informations : http://technet.microsoft.com/en-us/library/cc754905.aspx
| 
| Dans mon cas, n'ayant pas de matériel HSM je vais utiliser le chiffrement par mot de passe. Je suis donc inviter à le spécifier ici. | 
| AD RMS nécessite l'utilisation d'IIS pour y installer des Web Services. Il faut donc indiquer le site web qui sera utilisé.
Si vous voulez dédier le site web, et ne pas utiliser le Default Web Site alors il faudra créer le site au préalable. | 
| La connexion aux Web Services peut être effectuée avec SSL, ce que je vous recommande. Dans ce cas-là il faut s'assurer d'avoir déjà installé le certificat serveur dans IIS.
Le bouton « Validate » permettra de vérifier que les paramètres sont ok. | 
| Indiquez ici un nom convivial du certificat RMS | 
| Comme dit plus haut, RMS nécessite Active Directory car les services RMS vont créer un point de connexion (SCP).
Pour enregistrer le SCP il faut que l'utilisateur actuellement connecté pour l'installation de RMS soit membre du groupe « Entreprise Admins ». | 
| Les composants IIS supplémentaires vous sont rappelés ici, validez avec Next. | 
| Un récapitulatif vous est affiché, avant de valider l'installation. | 
| A la fin de l'installation il n'est pas nécessaire de redémarrer le serveur.
Cependant il faudra faire une fermeture puis ouverture de session pour prendre en compte les changements. Cela fait suite surtout aux modifications des groupes de membre dans l'AD. |
Voilà à présent l'installation de RMS est finie. Pour les prochains billets on va rentrer dans la configuration du serveur, des clients, et reprendre des scénarios typique d'une entreprise. |
|
|
|
|