|
|
|
|
|
|
|
|
|
|
Accueil -
<--- Le blog d'Alexandre GIRAUD (Alex117) MVP Forefront --->
|
|
|
Articles et annonces sur toute la gamme Microsoft Forefront et autres outils de sécurité. |
02/07/2010J'avais déjà rédigé un article sur l'explication concernant la suppression d'un périphérique désactivée. Cette action était notamment utile lorsque l'on remplace une carte réseau sans avoir libérer l'adresse IP pour avoir un message indiquant que l'adresse IP est déjà assignée par une autre carte réseau. Voir mon article ici : http://www.alexgiraud.net/blog/Lists/Categories/Category.aspx?Name=Windows%207
En effet, suite à un remarque d'un internaute cela ne fonctionne pas tout à fait pareil avec Windows Vista, Windows 7 ou encore Windows 2008. Il faut tout simplement élever le niveau de privilèges pour les commandes saisies.
Ensuite vous pouvez saisir les commandes normalement, comme expliquée dans mon précédent article
Vous verrez maintenant les cartes réseaux débranchées après avoir activé la vue des périphériques cachés
  Un rollup pour Forefront Protection 2010 for Exchange Server est disponible en téléchargement. Il comprend 23 corrections, qui sont détaillés dans l'article de la base de connaissance Microsoft KB2181692 : http://support.microsoft.com/kb/2181692
Le package est à télécharger directement depuis la KB, en effectuant la demande située en haut à gauche.
 24/06/2010
6 mois déjà que Microsoft Forefront TMG, le successeur de Microsoft ISA Server 2006, et les développeurs viennent de nous livrer le premier service Pack du produit. Le service Pack est téléchargeable à cette adresse : Microsoft Forefront TMG SP1 Download
Alors qu'apporte comme nouveauté ce nouveau service Pack :
- Améliorations sur les rapports
- Améliorations sur la gestion des catégories d'url
- Prise en charge des scénarios Branch Office
- Supporte la publication de SharePoint 2010
C'est surtout que maintenant il est possible de permettre aux utilisateurs d'outrepasser une mauvaise gestion de catégorisation url. Scénario idéale lors de la mise en œuvre de cette nouvelle fonctionnalité au sein d'une entreprise qui en était dépourvue jusqu'à présent.
Pour tous les détails techniques concernant les nouveautés se rendre sur :
Et pour l'installation, sur le site Technet : http://technet.microsoft.com/en-us/library/ff717843.aspx
Bonne install ;) 23/06/2010
Je me suis rendu compte récemment que si j'ai un compte utilisateur qui dispose d'un mot de passe trop long (>20 caractères) UAG fait une erreur d'authentification.
Par exemple, ici je tente de passer une authentification sur le compte alexandre avec un mot de passe 123456789012345678901234567890 , ce qui lui fait une longueur de 30 caractères.
Avec HttpWatch je regarde la valeur POST. Cette dernière a été tronqué à 20 caractères.
En fait c'est une fonctionnalité du produit, c'est donc une erreur normale. Pour permettre à UAG d'utiliser des mots de passe avec une longueur supérieur à 20 caractères, il suffit de copier le fichier C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\customDefault.inc dans le dossier : C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate. Ensuite il faut l'éditer comme ceci :
Il faut donc indiquer dans le fichier la modification de la variable PasswordLimit, qui par défaut est à 20 vers une valeur supérieure. Pour finir, activez la configuration !
Vous trouverez des informations officielles sur ce site : http://technet.microsoft.com/en-us/library/ff607319.aspx
18/06/2010
Sur un de mes labs virtuels, j'ai rencontré une erreur lors d'une tentative de mise à jour UAG avec l'Update 1.
Voir le billet sur UAG Update 1 : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=131
Le message d'erreur indique : « Microsoft Forefront UAG Update 1 Setup Wizard ended prematurely »
Au niveau de mon journal d'évènements, j'ai un code d'erreur Windows Installer 1603 :
L'emplacement du fichier de log est indiqué dans le détail de l'erreur, je vais donc le localiser :
Il suffit de faire une recherche dans ce fichier contenant la chaîne de caractère suivante « UAG CA: Error ». Voilà ce que dit le fichier de log :
Lors de la tentative de la création d'un package de type Windows Cabinet, l'étape échoue sans trop donner de détails … L L'erreur complète est :
UAG CA: Error: Caught error (will rethrow after rollback): Microsoft.UAG.Transformer.Util.CabinetException: Failed to create cabinet.
at Microsoft.UAG.Transformer.Util.CabUtil.MakeCab(String sourcePath, String searchPath, String cabinetPath)
at Microsoft.UAG.Transformer.Core.PersistanceGateway.SaveConfigurationIntoStorage()
at Microsoft.UAG.Transformer.Core.PersistanceGateway.Commit()
at Microsoft.UAG.Transformer.Core.SchemaConversionRuntime.Run() |
J'ai donc procédé à de nombreuses petites corrections, comme m'assurer que NLA (Network Location Awareness) est fonctionnel (voir billet : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=130 ), j'ai également tenté en désactivant l'UAC, lancer la mise à jour en tant qu'administrateur et même vérifié Windows Update :
Avec toutes ces mises à jours oubliées, je pensais que cela était un début de solution bien que sans explications ; hélas ce ne change rien après l'application des patchs et le redémarrage du système. J'ai ensuite tenté une réparation de Microsoft Forefront UAG à l'aide du composant ajout/suppression de programmes
Et là encore, rien n'y fait. L'installation de cette mise à jour ne peut être effectuée avec succès … Mon idée est de rendre plus « verbeux » le journal de log Windows installer pour mieux détecter la raison de cette erreur. Pour cela je saisis la commande suivante dans un interprète de commande MS-Dos : « msiexec /p ForefrontUAG_KB981323_ENU.msp /lv c:\log.log ». Cependant le log ne donne pas plus d'informations, cet update n'a peut-être pas été prévu pour être plus verbeux
Finalement, c'est en échangeant avec Ben Ari de Microsoft qu'il m'a mis sur la piste. Il avait déjà rencontré ce problème. Cela vient des fichiers de personnalisation (CustomUpdate) qui ne peuvent être sauvegardés dans un fichier cabinet (.cab) à l'aide des fonctions MakeCab.
J'ai donc sauvegardé et supprimé tous les fichiers de personnalisation situés dans les dossiers CustomUpdate.
Puis j'ai activé la configuration UAG depuis la console de gestion, un Reload de la configuration et une dernière activation.
Pour finir, un bon IISRESET et j'ai tenté de réinstaller l'Update 1 … et cette fois-ci avec succès !
Sur un de mes labs virtuels, j'ai rencontré une erreur lors d'une tentative de mise à jour UAG avec l'Update 1.
Voir le billet sur UAG Update 1 : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=131
Le message d'erreur indique : « Microsoft Forefront UAG Update 1 Setup Wizard ended prematurely »
Au niveau de mon journal d'évènements, j'ai un code d'erreur Windows Installer 1603 :
L'emplacement du fichier de log est indiqué dans le détail de l'erreur, je vais donc le localiser :
Il suffit de faire une recherche dans ce fichier contenant la chaîne de caractère suivante « UAG CA: Error ». Voilà ce que dit le fichier de log :
Lors de la tentative de la création d'un package de type Windows Cabinet, l'étape échoue sans trop donner de détails … L L'erreur complète est :
UAG CA: Error: Caught error (will rethrow after rollback): Microsoft.UAG.Transformer.Util.CabinetException: Failed to create cabinet.
at Microsoft.UAG.Transformer.Util.CabUtil.MakeCab(String sourcePath, String searchPath, String cabinetPath)
at Microsoft.UAG.Transformer.Core.PersistanceGateway.SaveConfigurationIntoStorage()
at Microsoft.UAG.Transformer.Core.PersistanceGateway.Commit()
at Microsoft.UAG.Transformer.Core.SchemaConversionRuntime.Run() |
J'ai donc procédé à de nombreuses petites corrections, comme m'assurer que NLA (Network Location Awareness) est fonctionnel (voir billet : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=130 ), j'ai également tenté en désactivant l'UAC, lancer la mise à jour en tant qu'administrateur et même vérifié Windows Update :
Avec toutes ces mises à jours oubliées, je pensais que cela était un début de solution bien que sans explications ; hélas ce ne change rien après l'application des patchs et le redémarrage du système. J'ai ensuite tenté une réparation de Microsoft Forefront UAG à l'aide du composant ajout/suppression de programmes
Et là encore, rien n'y fait. L'installation de cette mise à jour ne peut être effectuée avec succès … Mon idée est de rendre plus « verbeux » le journal de log Windows installer pour mieux détecter la raison de cette erreur. Pour cela je saisis la commande suivante dans un interprète de commande MS-Dos : « msiexec /p ForefrontUAG_KB981323_ENU.msp /lv c:\log.log ». Cependant le log ne donne pas plus d'informations, cet update n'a peut-être pas été prévu pour être plus verbeux
Donc c'est en échangeant avec Ben Ari de Microsoft, qui m'expliquait avoir déjà rencontré ce problème. En fait cela vient de la création d'un fichier cabinet de ces fichiers. Pour cela j'ai donc sauvegardé tous les fichiers situés dans les dossiers CustomUpdate.
Par exemple :
Ensuite j'ai sauvegardé la configuration UAG depuis la console de gestion, puis un reload et encore une activation de la configuration.
Après un bon IISRESET, j'ai tenté d'appliquer la mise à jour Update 1 ; et là succès !
07/06/2010
Microsoft continue dans la liste des analyseurs de conformité de configuration. Nous avions parlé récemment de la nouvelle version de BPA prévue pour TMG à travers cet article : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=108 et voilà qu'un nouvel outil est dédié à UAG.
Le nouvel outil est disponible à cette adresse : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d24994ef-8670-4324-957a-805d35f1244e
Cet outil permettra d'analyser la configuration UAG, afin de savoir si cette dernière est conforme aux exigences de l'éditeur. Cependant, cela n'exclut pas d'installer également TMGBPA car UAGBPA n'analyse que les services UAG.
L'installation est très simple et à l'habitude (Next, Next, … Finish J) et son utilisation comme les autres solutions BPA. Les points suivants sont analysés :
- Configuration UAG
- UAG DirectAccess
- Publication Exchange
- Publication SharePoint
Voilà un exemple de rapport :
Pour chaque erreurs/avertissements, une KB est à disposition localement
Alors reste plus qu'à … installer UAGBPA et TMGBPA sur tous vos serveurs UAG J 12/05/2010
Le 11 Mai 2010, Microsoft a mis à jour l'image d'installation des binaires d'UAG sur le site MSDN. Cela corrigera surement les problèmes connus avec certaines installations difficiles ..
22/04/2010 Ca y est Office 2010 est disponible aux abonnés MSDN en version RTM ! Vous y trouverez une version x86 et x64 ainsi que pour Visio, Project, Office Web Apps ….
Et il y a bien sûr sans oublier : SharePoint 2010 uniquement en x64 évidemment.
Alors vous connaissez la musique, y'a plus qu'à télécharger et tester J
13/04/2010
Microsoft vient de publier la première Update pour Microsoft Forefront UAG 2010. La première grosse amélioration que l'on verra, c'est la prise en charge des services de bureaux à distance (RDS) pour Vista et XP désormais !
De nombreuses autres améliorations ont été apportées pour SharePoint, DirectAccess, …. Tous les détails ici : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a862c57f-5c27-4cd0-8528-91b3cc5cd758
• Remote Desktop access from Windows Vista and Windows XP: Client endpoints running Windows Vista and Windows XP can now access RemoteApps and Remote Desktops published through Forefront UAG.
• Support for Microsoft SharePoint Server 2010: Forefront UAG now supports SharePoint Server 2010.
• Support for MSOFBA: Forefront UAG now supports the Office Forms Based Authentication protocol to allow rich clients to directly access applications published through Forefront UAG.
• Support for site cookies: Forefront UAG now supports the use of site cookies for non-alternate access mapping applications, in addition to domain cookies.
• Support for large CustomUpdate files: Forefront UAG now supports CustomUpdate files up to 1.5 GB in size.
• Changes in Group Policy Object (GPO) provisioning for DirectAccess clients: Update 1 fixes an issue that caused the export script that creates GPO objects to fail, and an issue that caused the GPO to be applied to all authenticated users in the domain (including computer accounts), instead of to DirectAccess clients only. |
08/04/2010J'ai rencontré à de nombreuses reprises un problème lorsque je tenter de réaliser un projet DirectAccess. Le problème survenait si les interfaces réseaux étaient mal configurés, et Windows ne permettait pas de détecter correctement quelle interface réseau était connectée au domaine, et celle au réseau public.
Parfois, malgré une configuration correcte les interfaces étaient fusionnées. C'est le service de localisation réseau (NLA) qui configure cette partie.
Si la configuration est correcte au niveau réseau, il est possible de redémarrer les services de localisation pour s'assurer que les interfaces ne se fusionnent plus. Pour cela la commande : « net stop nlasvc /y & net start netprofm » permettra au serveur Windows 2008 R2 de vérifier la localisation de chaque interface.
Ainsi dans cette configuration (interfaces fusionnées,) lorsque l'on tente d'activer une configuration UAG on a droit à un message d'erreur indiquant que la configuration DirectAcess ne peut être activée : « The adapter configured as external-facing is connected to a domain ». Cela peut même arriver si les interfaces ne sont plus fusionnées … même si la configuration DirectAccess est en « Disabled » L
Pour éviter définitivement ce message, voilà la solution de contournement. Elle a été validé sur 3 environnements différents, donc à mon avis répondra à votre besoin … surtout si vous lisez ce message actuellement J Il faut fermer la console de gestion (MMC) Microsoft Forefront UAG 2010 après le redémarrage, puis redémarrer les services de localisation avec la commande déjà citée plus haut : « net stop nlasvc /y & net start netprofm »
Il faut vous assurer ensuite que les interfaces ne sont plus fusionnées et clairement distinct avec une interface connecté au domaine, et une autre au réseau public. Ensuite il suffit de redémarrer tous les services UAG. Pour cela il faut ouvrir la console de service et recherchez le service : « Microsoft Forefront UAG Log Server ».
Il vous sera demandé de confirmer le redémarrage de services dépendants
Pour ceux qui aiment le faire en ligne de commande : « net stop whlerrsrv /y & net start w3svc & net start ConfigMgrCom & net start uagqessvc & net start uagrdpsvc & net start TSGateway »
Vous pouvez à présent ouvrir à nouveau la console de gestion UAG et activer la configuration. Le message ne devrait plus apparaître ; bon courage J 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. Microsoft avait publié un document concernant les paramètres nécessaires à mettre en œuvre sur un antivirus fichier sur un serveur ISA. Le document avait pour prendre en compte IAG, et depuis peu pour TMG et UAG 2010.
Tous les dossiers que vous devez exclure pour vos serveurs TMG et UAG préférés, rendez-vous ici : http://technet.microsoft.com/en-us/library/cc707727.aspx
|
|
|
|
|
|
|
|
 |
|
|
|
|