Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Accueil - Le blog d'Alexandre GIRAUD MVP Forefront
Alexandre GIRAUD - MVP Forefront > Le blog d'Alexandre GIRAUD MVP Forefront
Articles et annonces sur toute la gamme Microsoft Forefront et autres outils de sécurité.
févr. 03
Azure AD Connect Health, comment surveiller et auditer vos services de fédération depuis Azure

AAD Health Logo

Azure AD Connect Health est une nouvelle solution Azure, disponible actuellement en version Preview. L’objectif de ce connecteur est de pouvoir surveiller les architectures d’identités locales, notamment de fédération avec les serveurs ADFS (et leurs Reverse Proxy). Cela permettra de bénéficier d’une vue globale sur son architecture d’identité, et permettra d’identifier rapidement des éventuels problèmes.

En d’autres termes, Azure AD Connect Health va surtout vous donner une vision sur les statistiques d’authentification, la conformité de la configuration, les remontées d’alertes, l’analyse des hotfix critiques, …. Comment cela fonctionne ? il faut déployer un agent sur vos serveurs ADFS et sur vos serveurs Reverse Proxy (WAP). Cela est compatible également avec ADFS 2.0, et pas seulement avec ADFS Windows 2012 R2. L’agent va pouvoir récupérer des informations locales à la machine, et ainsi que les différents audit afin de constituer les statistiques. Ces informations sont envoyés sur un service en ligne dans le portail Azure, que vous pourrez consulter. A noter que l’accès à ce service est gratuit, mais nécessite néanmoins l’utilisation d’Azure AD Premium.

 

Alors tout d’abord, le service doit s’activer depuis le Marketplace sur le nouveau portail Azure. L’application est disponible dans la catégorie Identité.

clip_image002

 

Après avoir activé le service, il faudra donc télécharger l’agent. Le lien est directement disponible depuis le portail Azure, ou sinon le voici : http://go.microsoft.com/fwlink/?LinkID=518973
Il faut procéder à l’installation de cet agent sur l’ensemble de vos serveurs ADFS/WAP.

clip_image004

 

Afin de pouvoir faire la relation avec votre abonnement Azure, il faut enregistrer le connecteur à l’aide d’une commande Powershell : Register-ADHealthAgent
Il sera nécessaire ici d’indiquer les informations de l’administrateur global de votre tenant Azure AD.

clip_image005

Et maintenant ? Rien de plus, il vous suffit de vous reconnecter à votre portail Azure pour découvrir les remontées d’informations concernant votre architecture d’identité ADFS. Un tableau de bord avec un scrolling horizontal vous permettra de découvrir les différentes fonctionnalités remontées par l’agent. On peut voir très rapidement les éventuelles erreurs et/ou avertissements découvert lors de l’analyse. L’objectif étant d’en prendre connaissance et de pouvoir les corriger rapidement.

clip_image007

Par exemple ici, il nous est indiqué qu’un patch important n’est pas installé sur un des serveurs

clip_image011

 

A l’aide des audits de connexions, il est possible de bien comprendre l’activité de l’entreprise afin de détecter les pics d’utilisation (authentifications aux heures de pointes). En cas de lenteur remontés par les utilisateurs, il sera possible de déterminer les prérequis matériels pour assurer les montées en charge. L’outil de statistique indique le nombre d’authentification par heure, ce qui vous permettra d’évaluer au mieux les spécifications matérielles nécessaire à l’aide du Capacity Planning.

image

L’ensemble des alertes est clairement disponible afin de permettre une visualisation rapide et efficace.

clip_image013

 

Enfin, il ne faut pas oublier que l’objectif est de mettre tout au vert et de s’assurer que cela le restera !

image

Plus d’informations :

- https://msdn.microsoft.com/en-us/library/dn906722.aspx
- http://azure.microsoft.com/en-us/updates/public-preview-azure-active-directory-connect-health
- http://blogs.technet.com/b/ad/archive/2015/01/29/azure-ad-conditional-access-and-azure-ad-connect-health-now-in-preview.aspx

janv. 13
Comment sécuriser les accès RDP sur Azure, avec Azure MFA et RDS Gateway ?

image Vous êtes de plus en plus nombreux à utiliser les services Azure, et notamment les services de machines virtuelles. Que ce soit pour de la production, de la pré-production ou voir même pour mettre en place des environnements de développements, … Dans tous les cas, les connexions aux machines virtuelles se font tout le temps à travers une connexion bureau à distance (RDP). Ce moyen de connexion étant déjà très largement utilisé, pour administrer les serveurs Microsoft pour les environnements On-Premises, se retrouve donc également dans Azure aussi !

Pour permettre une connexion bureau à distance RDP pour des VM dans Azure, les exploitations passent à travers un “Endpoint” qui est fourni par défaut lors de la création d’une nouvelle VM Azure. C’est en fait un NAT qui permet de rediriger un port TCP vers le port TCP 3389 de la machine virtuelle. Malgré les processus de cryptage et d’authentifications avec NLA (http://technet.microsoft.com/en-us/library/cc732713.aspx), cela expose tout de même le port RDP de votre VM sur Internet. En cas d’éventuelle faille connue, ou de mots de passe simple, cela pourrait laisser une opportunité à un éventuel hacker.

Nous allons donc voir comment on peut sécuriser les infrastructures de machines virtuelles, à l’aide de deux technologies. La première, RDS Gateway, permettra ici de ne plus exposer les ports RDP et forcer les connexions dans un tunnel SSL à travers une passerelle dédiée. Nous répondrons ici à une problématique d’audit également, puisque toutes les connexions seront enregistrées et il nous est possible de mettre en place des politiques avancées (autorisation, méthode d’authentification, sources, destinations, …). Puis, à l’aide d’Azure MFA, il sera possible d’effectuer une authentification forte. Et c’est donc là, que il sera possible d’apporter un second facteur d’authentification à l’aide d’un simple téléphone. Il n’est pas donc pas nécessaire de faire l’acquisition de Token, et la solution devient donc très abordable.

Et la mise en oeuvre ? Très simple et rapide ! Nous allons d’ailleurs décrire les éléments de configuration ci-après, en détaillant les principales étapes de configuration. Dans cet environnement, nous utilisons 3VM. CONSOTO-DC1 sera le contrôleur de domaine et assurera un rôle Radius (NPS), puis CONTOSO-MFA sera le serveur d’authentification forte et enfin CONTOSO-RDGW1 sera la passerelle RDS.

 

Configuration du serveur NPS

Dans notre scénario, afin de minimiser les VM nous utilisons le rôle NPS directement sur le contrôleur de domaine. Nous allons donc installer le rôle NPS en PowerShell : Add-WindowsFeature NPAS-Policy-Server –IncludeManagementTools

Ainsi, cela va nous installer un serveur Radius sur le serveur actuel. Cela implique de mettre le serveur dans un groupe spécique ‘RAS and IAS Servers’. Comme le serveur RDGW deviendra lui aussi un serveur NPS ultérieurement, nous allons profiter de les mettre tous deux dans le groupe à l’aide de cette commande PS : Add-ADGroupMember 'RAS and IAS Servers' CONTOSO-DC1$,CONTOSO-RDGW1$

Bien entendu, cela nécessite un redémarrage pour prendre en compte l’attribution du groupe aux comptes ordinateurs !

Puis il faut configurer NPS, avec 3 paramètres. Il faut d’abord créer un client Radius qui correspond au serveur CONTOSO-MFA
image

Il faut créer une politique d’accès réseau, en autorisant un groupe AD par exemple
image

Et enfin, une particularité spécifique à cette architecture. Il faut modifier les paramètres d’authentification, afin de permettre une authentification sans négociation. C’est le Radius en amont qui le fera (MFA).
image

 

Configuration de la passerelle RD Gateway

Maintenant que le serveur NPS est configuré, nous allons configurer la passerelle RDP. Il suffit déjà d’installer le rôle et à l’aide de PS, c’est encore mieux ! Add-WindowsFeature RDS-Gateway –IncludeManagementTools

Ensuite, nous devons mener quelques configurations simples. Il est important de mettre en place un certificat SSL. L’idéal est d’utiliser bien entendu un certificat public, mais en cas d’utilisation d’un certificat auto-signé il faut fournir le certificat aux exploitants afin de l’approuver dans les autorités racines de confiance.
image

Toujours au niveau des propriétés de RDGW, il faut indiquer que les stratégies d’accès ne sont pas hébergés localement mais sur un serveur distant NPS. C’est là qu’il faut indiquer le serveur MFA, dans notre cas CONTOSO-MFA.
image

Au niveau de la stratégie RAP il faut indiquer quel est le groupe AD autorisé.
image

Enfin, une particularité ici concerne les temps d’expiration. Comme la cible est d’effectuer un appel téléphonique, il faut prendre en compte l’accès aux services, la prise en charge de l’appel, la validation de l’appel, … Il faut donc augmenter le temps d’expiration. Ici, il a été paramétré 90s, ce qui suffit généralement.
image

 

Azure MFA

Aure MFA sera la solution qui permettra d’assurer le second facteur d’authentification à l’aide d’un téléphone. Azure MFA est une solution qui peut être accessible depuis le portail Azure. Il existe sous deux formes d’utilisation, soit à l’utilisateur activé ou par lot d’authentifications. Cela dépendra des scénarios, mais cela reste un coût très bas comparé aux autres solutions du marché. Ci-desous comment créer le service Azure MFA.
image

Au niveau d’Azure Active Directory (AAD) il y a un espace dédié aux fournisseurs d’authentifications multi-facteur. On y découvre le connecteur MFA précédemment créé. Le sélectionner et cliquez sur Gérer.
image

Il sera possible ensuite de pouvoir télécharger l’agent; Les fichiers d’installation de l’agent doit être déposés sur le serveur qui sera prévu pour MFA (CONTOSO-MFA). Lors de l’installation il sera demandé des informations d’identifications. Cette identification se fait en cliquant sur “Générer de nouvelles informations d’identification d’activation". Ces informations sont valides pendant 10mn seulement ! Si le temps de l’installation vous prends plus de 10mn, revenez ici afin de générer de nouvelles id d’activation.
image

Le téléchargement de l’agent peut être assez rapide suivant votre connexion internet, ici à 15Mb/s cela ne prends que quelques secondes pour télécharger 121Mb !
image

A présent sur le serveur CONTOSO-MFA, il faut au préalable installer .Net Framework 2.0 (Add-WindowsFeature NET-Framework-Features), puis lancez l’installation à l’aide du setup.
image

Et c’est là que l’on indiquez les informations d’activation
image

Après l’installation, un assistant va vous accompagner pour créer une configuration initiale. Indiquez ici le mode RADIUS
image

Tout d’abord on doit indiquer les informations Radius du serveur RD Gateway. Il faut se rappeler du secret lors de la création des informations Radius précédemment lors de la configuration NPS de RDGW.
image

Et on doit renvoyer la requête au serveur NPS sur CONTOSO-DC1, donc RADIUS Server
image

Et c’est là maintenant que l’on mets les informations Radius du serveur NPS.
image

Enfin, il faut configurer l’agent MFA afin de créer les comptes utilisateurs; soit manuellement ou via une synchronisation AD. Il est important bien entendu que le téléphone de la personne est bien renseigné !
image

 

Conclusion

A présent le scénario utilisateur est lorsqu’il va se connecter en RDP (avec les paramètres de passerelle RDGW) un appel téléphonique sera effectué à l’utilisateur pendant la tentative de connexion. Il sera évalué tout au long de cette connexion que l’utilisateur est bien authentifié (couple user/pwd AD), que les politiques sont sont conformes (sources, destination, groupe, …) et que le second facteur (appel téléphonique) a bien été validé. Si tous les éléments sont valides, alors l’accès RDP à une machine interne est validée.

Après validation du bon fonctionnement de l’architecture, il est donc possible de supprimer l’intégralité des points de terminaison RDP sur les VM, et de ne laisser que le port HTTPS sur le serveur RD Gateway.
image

nov. 05
Self Service Reset Password avec Azure AD (SSPR Password WriteBack)

Il existe une problématique depuis de nombreuses années dans les entreprises, et qui souvent sont le résultat d’un fort cout (humain, production, ..), au sujet des pertes de mots de passes. Les utilisateurs sont souvent amenés à devoir connaitre de nombreux mots de passes, surtout quand les entreprises n’utilisent pas de systèmes SSO. Les collaborateurs d’une entreprise vont être confrontés à les retenir, mais après un retour de congés ou toutes autres situations personnelles il arrive “d’oublier” son mot de passe !

Certaines entreprises ont donc investi aussi bien dans des solutions SSO, afin que l’utilisateur n’ai qu’un seul mot de passe à retenir. Il existe aussi des solutions à l’aide d’une carte à puce, ou seul un code PIN est à retenir et donc plus simple qu’un mot de passe. Pour finir, cela empêche bien souvent des entreprises à mettre en place des stratégies complexes de mots de passe, afin de ne pas accentuer ce phénomène de pertes de mots de passes.

Les solutions de Self Reset Password vont permettre de réduire les frais de Helpdesk et d’améliorer la productivité des utilisateurs (l’utilisateur peut rapidement retrouver son mot de passe et réutiliser son poste de travail immédiatement). Jusqu’à présent, il existait des solutions logicielles comme Password Center de Imanami (http://www.imanami.com/groupid/password-center/) et bien entendu la solution avec Forefront Identity Manager avec le module SSPR (Self Service Password Reset) : http://technet.microsoft.com/en-us/library/jj134295(v=ws.10).aspx. Ces deux solutions ont leurs différents avantages et inconvénients, mais dans tous les cas demande une implémentation de serveurs, des licences, un maintien en condition opérationnel, des mises à jours, des contrats de supports, …

 

Dans cet article, nous allons ici décrire une nouvelle solution en mode “As A Service” disponible depuis Windows Azure avec Windows Azure AD Premium. En fait la solution ici est totalement en mode Cloud et ne nécessite pas de serveurs dédiés. L’objectif est à travers une page web de fournir un processus de validation pour vérifier l’identité de la personne, puis permettra d’effectuer le changement du mode de passe de l’utilisateur après qu’il soit vérifié. Le processus de vérification est celui avec Azure Multi Factor Authentication, à l’aide soit d’un appel téléphonique ou l’envoi d’un SMS pour faire cette vérification de second facteur. Le changement de mot de passe est donc soumis au contrôleur de domaine On-Premises, et est donc soumis aux stratégies de mot de passes de l’entreprise.

Cela veut donc dire que ce type de scénario peut d’une part prendre en compte les utilisateurs nomades sans mettre en place une publication service. En effet, c’est le serveur de synchronisation (DirSync ou AAD Sync) qui va analyser si une demande de mot de passe est en cours (Service BUS). Ce flux est uniquement sortant, et ainsi il n’est pas nécéssaire de prévoir une architecture avec une DMZ, Reverse Proxy, etc… Seul le serveur de synchronisation a besoin du flux SSL en sortie vers Azure. Lorsqu’une demande de réinitialisation de mot de passe est détecté, cette tentative de changement est renvoyé au contrôleur de domaine On-Premises depuis le serveur de synchronisation. C’est en effet le contrôleur de domaine qui décidera si le changement du mot de passe de l’utilisateur concerné est conforme (complexité, longueur, historique, …). Cela nécessite donc la synchronisation des identités On-Premises vers Azure Active Directory comme pré-requis, mais il n’est pas nécessaire de mettre en place des scénarios comme la synchro de mot de passes (AD->AAD), ou encore avec fédération de comptes (ADFS), etc… juste une simple synchronisation basique avec comme seul pré-requis la synchronisation du numéro de téléphone (pour permettre l’authentification forte) ! Si ce prérequis n’est pas possible (syncho du numéro de téléphone non présent dans l’annuaire AD), il est possible de fournir un portail d’enrôlement aux utilisateurs afin qu’ils puissent renseigner eux-mêmes leurs numéros de téléphone.

image

 

Et comment ça se passe au niveau de l’expérience utilisateur ? L’utilisateur doit se rendre sur cette URL : https://passwordreset.microsoftonline.com/ et il devra indiquer son identité (souvent par défaut l’UPN ou Email) et valider un captcha code.
image

L’utilisateur devra ensuite choisir la méthode de vérification, entre soit l’envoi d’un SMS ou la réception d’un appel téléphonique. Puis il doit valider son numéro de téléphone.
image

Si le choix est de recevoir un appel téléphonique, la personne devra décrocher et appuyer sur la touche #. Dans le cas d’utilisation de la vérification par SMS, vous recevrez un code OTP. Ce code devra être saisi dans le formulaire.
image

Après validation de l’utilisateur, l’utilisateur est invité à proposer un nouveau mot de passe et le confirme. Si cependant, il ne respecte pas les stratégies de l’entreprise l’utilisateur est invité à saisir à nouveau un nouveau mot de passe.
image

Si cependant, le mot de passe répond aux politiques de l’entreprise alors son mot de passe est réinitialisée. La prise en compte du changement sur le contrôleur de domaine est immédiate ! Car si ce message survient, cela veut donc bien dire que le contrôleur de domaine l’a bien pris en compte. Cependant, dans les grandes organisations il se peut qu’il y ai besoin d’un temps pour la réplication en fonction des différents sites.
image

Le serveur de synchronisation indique dans son journal d’évènements les différentes tentatives, avec un ID 31001 dès qu’une demande est initiée, puis soit un évènement 31002 pour indiquer un succès ou encore 6329 et 33008si une erreur est détectée (voir différents ID en fonction de l’erreur).
image

 

Pour l’utilisation de ce type de fonction, il faut bien prendre en compte au moins ces deux prérequis :

  • Outil de synchronisation à jour
    • DirSync avec la version 1.0.6862.0000 au minimum
    • Toutes versions de AAD Sync
  • Licences Azure AD Premium
nov. 04
Azure Cloud App Discovery : La solution pour avoir des statiques d’utilisation de nos applications Cloud

image

A force d’avoir de plus en plus d’applications Cloud, aussi bien à l’aide de périphériques mobiles ou depuis des postes de travail, il est de plus en plus difficile aujourd’hui aux directions informatiques de savoir ce que l’on consomme réellement ! Il est de plus en plus demandé des rapports d’utilisations, de consommations de données, …

Microsoft fournit une solution à travers Azure, nommée Cloud App Discovery. Le produit est actuellement en mode Preview, mais permet déjà d’avoir une bonne idée de ses possibilités. De plus, son utilisation est gratuite ! Pour s’enregistrer et découvrir la solution, se rendre sur http://appdiscovery.azure.com/

Actuellement la solution nécessite la mise en œuvre d’un agent sur les postes de travail. L’agent est compatible à partir de Windows 7 et au-delà. Après la création de l’accès à Azure App Discovery, l’administrateur peut télécharger l’agent (https://appdiscovery.azure.com/Tenant/Download/winclient) afin de pouvoir le déployer sur son parc. Cela peut être fait soit directement à travers une GPO (MSI), SCCM ou d’autres solutions de déploiements. L’archive (.zip) téléchargé contient un fichier certificat qui permettra d’identifier le tenant concerné. Si vous utilisez un partage réseau, il faut positionner l’attribut Read-Only sur le fichier tenant.cert car il est automatiquement supprimé après l’installation de l’agent sur le poste de travail !

image

 

On ouvre donc un compte gratuit sur Azure, puis on déploie des agents … Mais cela donne quoi à la fin ? Désormais, il sera possible de surveiller l’ensemble des utilisations d’applications, des utilisateurs, des volumes de données, etc…

La vue du tableau de bord permet déjà d’avoir une vue synthétique de l’ensemble des utilisateurs, les applications découvertes, celle les plus utilisés et l’utilisation de données.
image

Ensuite il est très simple d’identifier les catégories principales utilisées, et de voir les applications associées
image

Et pour terminer de voir également comment est réellement utilisé une application, en terme de requêtes, accès, volume, … ce qui permettra de déterminer si des applications sont “gourmandes” ou voire même inutilisés au sein de l’entreprise. Dans ce dernier cas, cela permettrai de réduire des couts en résiliant des abonnements devenus obsolètes au sein d’une entreprise.
image

Comment cela fonctionne ? Les agents qui seront installés sur les périphériques contacteront les Web Services via Azure AD afin d’analyser les différentes transactions, puis les données seront stockées sur Azure. Le portail permettra ainsi d’articuler les données ainsi récoltées.

Par défaut, les données sont stockées dans les services privées d’Azure. Mais il est possible d’utiliser un stockage personnalisé pour lequel vous êtes propriétaires. Pour cela, il suffit de créer un Azure Blob Storage, et de configurer Cloud App Discovery pour exporter les données dans ce nouvel espace de stockage.
image

 

Cela créera ainsi un container dans l’Azure Blob Storage, et une table pour chaque agent. Les données pourront être ainsi privées et peuvent être exploitées.
image

Si vous téléchargez l’un de ces fichiers, à savoir que les données sont tabulées simplement et donc exploitable déjà avec un simple tableau Excel ;)
image

Vous pouvez voir en vidéo comment est présenté la solution : http://channel9.msdn.com/Series/EMS/Azure-Cloud-App-Discovery

nov. 04
Azure AD en 3 versions, Free, Basic and Premium !

4ac52e5b-b3ac-4fbd-bbc7-bd4bae8403da

Windows Azure Active Directory est un annuaire Cloud disponible dans Azure. Initialement Azure AD n’était disponible qu’à travers une unique version, avec des fonctions standards. Azure AD était surtout utilisé, sans le savoir dans certains cas, pour des besoins comme Office 365, Dynamics CRM Online, Intune, … En effet, dès lors que l’on crée un tenant Office 365, cela crée indirectement un annuaire Azure AD.

Depuis Avril 2014, une nouvelle version Azure AD a fait son apparition. Azure AD Premium est une version avec de nombreuses fonctionnalités supplémentaires avancées. Cela permettait de personnaliser les pages de login, gestion d’accès granulaires, authentification Azure MFA, … (une version d’évaluation est possible : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=306).

Mais il existe une troisième version, intermédiaire entre la version gratuite et Premium. La version “Basic” est disponible depuis Septembre 2014 '(http://blogs.technet.com/b/ad/archive/2014/09/15/azure-active-directory-basic-is-now-ga.aspx). Elle a pour avantage d’avoir des fonctionnalités avancées par rapport à la version Free, qui peuvent être dans certains scénarios suffisant à une entreprise sans avoir besoin de la version Premium.

Comparaison des différentes version (mise à jour le 29/10/2014)

image

Pour plus d’informations sur les version Basic et Premium : http://msdn.microsoft.com/en-us/library/azure/dn532272.aspx

nov. 03
Désactiver / Disable the Azure AD Sync Scheduler task en command line ou PowerShell ?

Lorsque vous souhaitez reconfigurer Azure AD Sync, un message vous indiquera qu’une tâche planifiée doit être désactivée avant de pouvoir effectuer une modification.
image

En effet AAD Sync installe une tâche planifiée “Azure AD Sync Scheduler” afin de planifier une synchronisation régulière.
image

 

Cela peut devenir contraignant d’ouvrir en GUI le gestionnaire de tâches planifiées, donc comment le faire en ligne de commande version old-school ou plus sexy directement avec PowerShell ! Ci-dessous les commandes pour activer et désactiver la tâche planifiée.

 

En ligne de commande classique :

schtasks.exe /change /TN:"Azure AD Sync Scheduler" /DISABLE
schtasks.exe /change /TN:"Azure AD Sync Scheduler" /ENABLE

image

Et en version PowerShell :

$TaskName = 'Azure AD Sync Scheduler'
Disable-ScheduledTask -TaskName $TaskName
Enable-ScheduledTask -TaskName $TaskName

image 

nov. 03
Mise à jour / Upgrade Azure AD Sync

 

clip_image002 Nous avons vu dans de précédents articles, commet mettre à jour DirSync et même comment mettre à niveau DirSync vers AAD Sync.

Microsoft vient de publier une nouvelle version AADSync en 1.0.470.1023 : http://www.microsoft.com/en-us/download/details.aspx?id=44225 Nous allons donc analyser la procédure de mise à jour avec AAD Sync.

Après le téléchargement et l’exécution de la mise à jour localement sur le serveur Azure AD Sync, l’assistant détecte une verion précédent et vous propose directement de faire une mise à jour :
clip_image004

L’assistant mettra quelques temps en fonction des performances du serveur et du réseau … Comptez environ 3 à 4 minutes max
clip_image006

Et enfin, il vous sera demandé de valider les paramètres, mais tout sera déjà pré-rempli. SI vous n’avez donc pas de changements majeurs, ou de nouvelles fonctionnalités à ajouter il suffit de cliquer sur Next quelques fois.
clip_image008

Et ? C’est déjà fini ! Il est éventuellement possible d’ouvrir Azure AD Sync et l’option « about » pour vérifier le numéro de version actuelle.
clip_image010

Si vous souhaitez vérifier les dernières versions en cours, un seul lien : http://msdn.microsoft.com/en-us/library/azure/dn835004.aspx

nov. 03
Microsoft Forefront UAG 2010 SP4 Rollup 1 KB2922171

 

Malgré tout, Microsoft fournit toujours des mises à jours sur Forefront UAG. Ici, ce sont les équipes support qui fournissent un Rollup 1 pour le Service Pack 4, afin de corriger un ensemble de fix .. 23 fix !

KB number Title
http://support.microsoft.com/kb/2997481/ FIX: You are not authorized to access applications published through Forefront Unified Access Gateway
http://support.microsoft.com/kb/2997483/ FIX: Source IP and user name missing from Event ID 14 in the Web Monitor log file
http://support.microsoft.com/kb/2997485/ FIX: "An unknown error occurred while processing the certificate" error when you access an application that is hosted on an Apache web server
http://support.microsoft.com/kb/2997486/ FIX: The Forefront Unified Access Gateway portal may be unavailable
http://support.microsoft.com/kb/2997487/ FIX: "You have attempted to access a restricted URL" error when you try to access OWA and are close to the idle session time-out period
http://support.microsoft.com/kb/2998352/ FIX: "Your client does not support opening this list with Windows Explorer" error when you try to open a SharePoint document library
http://support.microsoft.com/kb/2998733/ FIX: You cannot start a RemoteApp application when its name contains accented characters
http://support.microsoft.com/kb/2998739/ FIX: The VPN connection disconnects immediately when a Unified Access Gateway 2010 client uses SSTP
http://support.microsoft.com/kb/2998752/ FIX: "Authentication failed" error when you try to log on to Unified Access Gateway by using the UPN format
http://support.microsoft.com/kb/2998769/ FIX: Exception occurs when you use the Export2Tspub application to export the configuration to a .tspub file
http://support.microsoft.com/kb/3003977/ FIX: "Sign-in Error" errors for Internet Explorer 11 clients when they access a Unified Access Gateway portal trunk that has ADFS 2.0 authentication
http://support.microsoft.com/kb/3004023/ FIX: Client connections for Form-based SSO fail authentication in Forefront Unified Access Gateway 2010 SP4
http://support.microsoft.com/kb/3006827/ FIX: Forefront Unified Access Gateway 2010 template improvements for SharePoint Server 2013
http://support.microsoft.com/kb/3006828/ FIX: Forefront Unified Access Gateway 2010 template improvements for Exchange Server 2013
http://support.microsoft.com/kb/3006892/ FIX: Windows Firewall is detected as running after a third-party firewall is installed on a computer that is running Forefront Unified Access Gateway 2010
http://support.microsoft.com/kb/3006938/ FIX: Soft lockout does not apply if Outlook Anywhere uses KCD for SSO to Exchange Server
http://support.microsoft.com/kb/3006940/ FIX: Portal toolbar is not displayed in Forefront Unified Access Gateway 2010
http://support.microsoft.com/kb/3007519/ FIX: "Bind the source IP address to the session" option does not work correctly in Forefront Unified Access Gateway 2010
http://support.microsoft.com/kb/2997456/ FIX: French client access to Unified Access Gateway trunk by using two-factor authentication fails when user password nears expiration
http://support.microsoft.com/kb/2997493/ FIX: "Invalid URL path" error when an external user tries to connect to a shared calendar
http://support.microsoft.com/kb/3007842/ FIX: "The website cannot display the page" or "HTTP 500" error if the first user logon is unsuccessful
http://support.microsoft.com/kb/3009885/ FIX: Applications that use the Socket Forwarder component may stop responding in Forefront Unified Access Gateway 2010
http://support.microsoft.com/kb/3009904/ FIX: "You cannot access this site due to an internal error" error when you log on to Outlook Web App again

 

Pour le télécharger, se rendre sur la KB : http://support.microsoft.com/kb/2922171/en-us

oct. 05
Windows Azure Active Directory Sync, en version finale désormais. Comment migrer depuis DirSync ?

Windows Azure Active Directory Sync (AAD Sync) est le nouvel outil de synchronisation d’identités, qui vient remplacer la précédente version connue DirSync. C’est avec cet outil que les entreprises vont pouvoir par exemple synchroniser les identités Active Directory On-Premises vers Azure AD pour des projets comme Office 365, SharePoint Online, Intune, etc…

Cette nouvelle version apporte de nouvelles fonctionnalités, et permettra de répondre à de nouveaux enjeux dans les entreprises, comme notamment :

· La prise en charge multi forêt

· Les fonctions de Password Write Back natives

· Gestion avancée des attributs/comptes à synchroniser

· Etc.. plus d’infos sur : http://msdn.microsoft.com/en-us/library/azure/dn790204.aspx

Note : Il y a une fonctionnalité de DirSync qui n’est pas encore disponible dans AADSync, le Password Hash Sync. Bien que peu utilisé (dans mon cas du moins) cette fonctionnalité sera rajouté ultérieurement.

La nouvelle version AADSync est disponible depuis le 16 septembre 2014 en version finale, et permet de s’installer sur un serveur 2008, 2008 R2, 2012 ou encore 2012 R2 bien entendu. En terme de pré-requis, il faut juste .Net Framework 4.5 et PowerShell (3.0 minimum).

Cas de migration de DirSync vers AADSync :

Si vous utilisez déjà une version de DirSync, il est alors possible de migrer vers AADSync ; Soit directement sur le même serveur, ou sur un nouveau serveur. Dans le dernier cas, il faut bien vous assurer de ne pas faire tourner les deux moteurs en même temps. Pour une migration sur le même serveur DirSync, il faut penser à récupérer les éléments de configuration (OU spécifiques et règles de filtrage généralement) puis il faut désinstaller DirSync. Uniquement après, il sera possible d’installer AAD Sync, en le téléchargeant à l’adresse http://go.microsoft.com/fwlink/?LinkId=511690.

clip_image002

Installation de AADSync :

Note : Plus d’infos sur l’installation, disponible à l’adresse http://msdn.microsoft.com/en-us/library/azure/dn757602.aspx

Après avoir téléchargé AADSync, vous pouvez lancer l’exécutable. Un assistant vous accompagnera dans le processus de la configuration.
clip_image004

Pour commencer, il faut rentrer une information d’identité Azure AD d’administration ..
clip_image006

... Puis ceux de votre forêt Active Directory local. Il est possible d’ajouter plusieurs forêts désormais ;)
clip_image008

Voilà la nouvelle fonctionnalité qui va permettre de définir de manière plus fine comment les utilisateurs seront identifiés en multi-forêt, ainsi que l’attribut source à faire matcher. Plus d’infos sur cette nouveauté : http://msdn.microsoft.com/en-us/library/azure/dn757602.aspx#BKMK_ConfigureSynchronizationOptions
clip_image010

De nouvelles options sont disponibles, comme le Password write-back (permet d’écrire un password depuis AAD vers votre AD local). Plus d’infos : http://msdn.microsoft.com/en-us/library/azure/dn757602.aspx#BKMK_OptionalFeatures
clip_image012

Si vous activez l’option Azure AD Apps, il vous sera possible de limiter les applications disponibles.
clip_image014

Enfin, il vous reste à configurer les attributs que vous souhaitez synchroniser
clip_image016

Il ne reste plus qu’à valider et l’installation/configuration va se poursuivre.
clip_image018

Et voilà, tout est configuré ;) Il vous reste à fermer et rouvrir la session sur le serveur puis de reconfigurer vos filtres ;)
clip_image020

juil. 30
Utilisation des fonctions Reverse DNS pour créer des enregistrements PTR

Avec Microsoft Azure, on peut mettre en place des services (VM, Sites, …) et y associer une adresse IP publique. C’est assez pratique, si il est nécéssaire de mettre en place une publication. Il restait ensuite aux administrateurs de mettre en place les enregistrements DNS auprès de son fournisseur DNS (OVH, GoDaddy, …) si l’on souhaite y accéder avec un nom de domaine de l’entreprise au lieu de cloudapp.net.

Mais il n’était pas possible jusqu’à présent de créer les enregistrements inverses (PTR). C’est à dire, que depuis l’adresse IP, on puisse obtenir le nom DNS complet. C’est d’ailleurs utilisé par certains systèmes de protections et sécurité (antispams, …). Mais voilà, vous l’avez peut-être déjà pensé, alors Microsoft l’a fait !

 

Alors prenons l’exemple d’un service que j’ai déjà dans Azure, une machine virtuelle avec une adresse IP publique. Afin d’y accéder j’utilise bien entendu un nom propre à mes besoins, et j’ai donc créer un entrée DNS chez mon fournisseur. Mon enregistrement sts dans la zone 3sr.fr correspond donc à l’adresse IP 137.116.213.217. Cependant, comme le démontre l’impression écran ci-dessous, impossible d’avoir le Reverse DNS !

image

 

Alors tout d’abord en prérequis pour cette manipulation, il faut une version récente du module Azure PowerShell soit la version 0.8.5 :

- Version Download : http://go.microsoft.com/fwlink/p/?LinkID=320376
- Version complète : http://az412849.vo.msecnd.net/downloads03/windowsazure-powershell.0.8.5.msi

Si vous ne savez pas quelle version vous avez, vous pouvez essayer cette commande : Get-Module -ListAvailable | Where-Object {$_.Name -eq 'Azure'} | Select Version

image

 

On se connecte à Azure (on sélectionne son abonnement si plusieurs), puis il suffit de configurer le service déjà existant avec « Set-AzureService » et l’argument « ReverseDnsFqdn ».

Attention, il faut un « . » à la fin. Donc dans mon cas je souhaite mettre en œuvre sts.3sr.fr donc il faudra mettre en variable sts.3sr.fr.

$Azure_Service_Name = 'AZURE3SR-WAP'
$Azure_Service_DNS = 'sts.3sr.fr.'
Set-AzureService –ServiceName $Azure_Service_Name –ReverseDnsFqdn $Azure_Service_DNS

clip_image002

 

Et là, … faut être patient ! Mais pas tant que ça, car dans mon cas j’ai attendu 5mn seulement et j’ai relancé la même commande nslookup exécutée au début de l’article. J’ai déjà la mise à jour DNS de mon enregistrement PTR !

image

 

Plus d’infos sur le blog Microsoft Azure –> http://azure.microsoft.com/blog/2014/07/21/announcing-reverse-dns-for-azure-cloud-services/

1 - 10Suivante
MVP Forefront

 ‭(Masqué)‬ Liens d'administration