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é.
avril 12
FIM DirSync erreur, ne peut démarrer avec une erreur 2149781504

image

Depuis quelques temps, j’ai découvert que je ne disposais plus de synchronisation DirSync. Pourtant j’ai deux serveurs en haute-disponibilité, un en local et un autre sur Azure. Les deux se sont mis à ne plus fonctionner du jour au lendemain.

Si je regarde, les services “Windows Azure Active Directory Sync” et “Forefront Identity Manager Synchronization Service” sont arrêtés. Dans les journaux d’évènement, j’ai les erreurs ID 7001 et 7024 indiquant les problèmes de dépendances et que le service FIM Sync ne peut démarrer avec l’erreur 2149781504.

Log Name: System
Source: Service Control Manager
Date: 12/04/2014 13:09:42
Event ID: 7024
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DIRSYNC.3sr.local
Description:
The Forefront Identity Manager Synchronization Service service terminated with the following service-specific error:
%%2149781504

Log Name: System
Source: Service Control Manager
Date: 12/04/2014 13:05:01
Event ID: 7001
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DIRSYNC.3sr.local
Description:
The Windows Azure Active Directory Sync Service service depends on the Forefront Identity Manager Synchronization Service service which failed to start because of the following error:
The service has returned a service-specific error code.

Après suppression et réinstallation, mise à jour en dernière version, redémarrage, reconfiguration, réparation MSI, … Bref, aucune solution standard permet de relancer la synchronisation.

Si je regarde en détail, ce problème est apparu après un redémarrage du serveur. Ce redémarrage fait suite à une série de mises à jour Microsoft. Et parmi elles, une attire mon attention

image

La mise à jour GDR 3128 de SQL Server 2012 (KB 2793634) a été installé sur les deux serveurs qui présentent le problème. Alors, il suffit donc de désinstaller cette mise à jour puis on désinstalle DirSync également ensuite.

image

Après la désinstallation de la mise à jour SQL GDR 3128, puis des composants FIM DirSync faites un redémarrage du serveur. Après le redémarrage, tentez à nouveau l’installation de DirSync. Profitez ici de mettre à niveau DirSync si besoin, pour cela voir mon article précédent : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=299

Après l’installation de DirSync, n’oubliez pas de remettre à nouveau vos paramètres de filtrage (Filtrage, Containers, …) avant d’autoriser une première synchronisation. Puis vous vous apercevrez que tout est rentré dans l’ordre à nouveau !.

Cette mise à jour SQL pose donc bien un problème direct avec l’outil de synchronisation Azure Active Directory (DirSync), car le simple fait de la désinstaller permet à nouveau une synchronisation.

avril 06
Recevoir une notification d’expiration de mot de passe grâce à PowerShell

image

Vous avez été peu être confronté un jour, à vous rendre compte que le mot de passe de votre compte (ou ceux de vos utilisateurs) est expiré. Ceci n'est pas un problème lorsque vous êtes au bureau avec une station membre du domaine, une notification vous sera proposée pour changer votre mot de passe directement depuis le Secure Logon Screen.

Mais imaginons que vous avez une infrastructure de VM sur Azure dédiée, avec une Active Directory uniquement en mode Cloud sans VPN site à site … ? Dans ce cas, il ne sera pas possible d'effectuer le changement de mot de passe depuis l'écran de login, d'autant que par défaut sur les serveurs la pré-authentification RDP (NLA) est activée. Alors, soit il faut désactiver le NLA. Mais dans ce cas, cela baisse le niveau de sécurité. Sinon, l'autre option consiste à avertir les utilisateurs que leurs mots de passe vont expirer. C'est cette option que je décris ici.

Pour cela, j'utilise PowerShell avec le script ci-dessous. Il suffit de configurer une tâche planifiée qui s'exécute quotidiennement. Il suffit de modifier les variables surlignés en jaune, et de le paramétrer sur l'un des serveurs disposants du module PowerShell Active Directory.

Contenu du script :

# Variables
$smtpServer = "smtp.domain.local" 
$from = alert-password@domain.local
$smtp_username = "DOMAIN\SmtpUser" 
$smtp_password = ConvertTo-SecureString "Mot2Pass" -AsPlainText -Force 
$smtp_credentials = New-Object System.Management.Automation.PSCredential ($smtp_username, $smtp_password)
$expireindays = 20 
$maxPasswordAge = 90 
$OUpath = "OU=HelpDeskUsers,OU=IT,DC=domain,DC=local" 
$today = (get-date)

 

# Recherche des utilisateurs activés qui ont un mot de passe qui expire
$users = Get-ADUser -SearchBase $OUpath -Properties GivenName,mail,PasswordLastSet -Filter {(PasswordNeverExpires -eq "False") -and (Enabled -eq "True")}
foreach ($user in $users)

{
    # Informations du compte utilisateur  
    $Name = $user.GivenName
    $emailaddress = $user.mail

    # Recherche en jours de la dernière modification du mot de passe
    $passwordSetDate = $user.PasswordLastSet
    $lastset_days = (New-TimeSpan -Start $today -End $passwordSetDate).Days

    # Expire dans x jours en comparaison avec la date de modification, et la durée max autorisée
    $expireson = $lastset_days + $maxPasswordAge 

    # Préparation du message email  
    $subject="IT Services : Attention, expiration du mot de passe dans $expireson jours"      
    $body ="
    Bonjour $name,
    <p> Votre mot de passe IT va &ecirctre expir&eacute dans $expireson jours.<br>
    Merci de vous connecter d'ici ce d&eacutelai et d'effectuer la modification du mot de passe.<br>

    Au del&agrave de ce d&eacutelai, vous ne pourrez plus vous connecter et vous devrez contacter votre administrateur.
    <p>Merci de votre compr&eacutehension<br> 
    </P>"  

    # Envoi du mail si l'expiration est < 20 jours  
    if ($expireson -lt $expireindays)
    {
        echo "Attention : Le compte de $Name expire bientôt ($expireson jours). Envoi d'un mail vers $emailaddress en cours"       
Send-Mailmessage -smtpServer $smtpServer -from $from -to $emailaddress -subject $subject -body $body -bodyasHTML -priority High -credential $smtp_credentials  
    }
else 
{
        echo "Information : Le compte de $Name expire dans $expireson jours. Aucun émail vers $emailaddress ne sera envoyé"
}
}

 

 

mars 23
Le 8 Avril 2014, la fin de Windows XP seulement ? et du support de Forefront UAG SP2 aussi !

image

En lisant Internet, on dirait que le 8 Avril ça va être la fin du monde presque, mais la fin de quoi en fait ? De Windows XP seulement ?

Fin de Windows XP, bien entendu !

Donc en effet, oui c’est surtout la fin de Windows XP en ce mardi 8 Avril 2014 que tout le monde retient, que certains se rappellent surement encore de Whistler ! C’était il y a 12 ans maintenant ! Il nous a bien rendu service, même si je me rappelle de la peur de tout le monde (entreprise et particuliers) avec le Service Pack 2, et que le système était un peu désaimé à cette période. Et aujourd’hui, certains ne souhaitent plus le quitter au point de devenir insociable en famille :

Le fait d’utiliser Windows XP en soi n’est pas interdit, mais l’arrêt des mises à jours de sécurité, de l’intérêt des développeurs, etc… fait que le système vous forcera tôt ou tard à devoir changer de système. Sinon, Microsoft fournit un outil de migration simplifiée et complet : http://windows.microsoft.com/fr-fr/windows7/products/features/windows-easy-transfer

Mais office 2003 également !

Et bien entendu, la version Office XP qui est arrivé presque en même temps que Windows XP? mais très vite remplacé par Office 2003 arrive lui aussi à terme. Il est donc conseillé là encore de prévoir de mettre à jour vos versions d’Office vers les versions 2010 voire 2013 directement.

Et concernant Forefront UAG 2010 ?

Le produit, bien qu’arrêté d’un point de vue développement, est toujours supporté à ce jour. Cependant, souvent les directions informatiques ne font pas attention au niveau de Service Pack minimum. Donc ce sera justement à partir du 8 Avril que le Service Pack 2 ne sera plus supporté ! Il faut donc prévoir, pour les retardataires, une mise à jour vers le Service Pack 3 Rollup 1, voire directement le Service Pack 4.

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

Forefront Unified Access Gateway 2010

mardi 26 janvier 2010

mardi 14 avril 2015

mardi 14 avril 2020

mardi 12 avril 2011

Forefront Unified Access Gateway 2010 Service Pack 1

vendredi 10 décembre 2010

Not Applicable

Not Applicable

mardi 8 octobre 2013

Forefront Unified Access Gateway 2010 Service Pack 2

lundi 6 août 2012

Not Applicable

Not Applicable

mardi 8 avril 2014

Forefront Unified Access Gateway 2010 Service Pack 3

lundi 18 février 2013

Not Applicable

Not Applicable

mardi 13 janvier 2015

Forefront Unified Access Gateway 2010 Service Pack 4

mercredi 20 novembre 2013

Review Note*

Review Note*

 

* Support ends 12 months after the next service pack releases or at the end of the product's support lifecycle, whichever comes first. For more information, please see the service pack policy at http://support.microsoft.com/lifecycle/#ServicePackSupport

Et si il y avait des bonnes nouvelles aussi prévue pour le 8 Avril 2014 ?

Mais bien sûr qu’il y a toujours des bonnes nouvelles, par exemple il est prévu que la mise à jour Windows 8.1 Update 1 soit publiquement disponible justement le 8 Avril 2014, coïncidence ?

image Encore une autre bonne nouvelle ? Oui mais celle-ci est plus personnelle, car c’est en ce prochain mardi 8 Avril 2014 que je fêterai mes 33 ans, où ce nombre d’années coïncidence avec le numéro de mon département qui plus est !

mars 23
Perte des paramètres réseaux pour les machines virtuelles, après une maintenance Azure ?

image

En tant qu’abonné Microsoft Azure, vous deviez recevoir de nombreuses informations par mail de la part de Microsoft Azure. Souvent pour annoncer des nouveautés et la disponibilité générale de nouvelles fonctionnalités. Mais aussi, plus rarement, des avertissements concernant une maintenance…

Cette maintenance n’aura pas vraiment d’impact, surtout si vous avez crée un groupe de haute disponibilité dans Azure. Car en effet, lors des maintenances Microsoft n’impacte jamais 2 régions en même temps. Ce que j’ai pu remarqué néanmoins, à chaque maintenance les machines virtuelles ont été redémarrées et ont perdu des paramètres réseaux spécifiques. Il devient donc impossible de se reconnecter en RDP sur les machines virtuelles à l’aide d’un compte du domaine, seulement à l’aide de comptes locaux. Et bien entendu, les services inhérents à Active Directory ne sont plus fonctionnels.

Si on regarde de plus près, c’est comme si la carte réseau avait été changée car l’ancienne est devenue en périphérique cachée. Pour être supporté, je rappelle qu’il ne faut pas mettre d’adresse IP statique sur les machines virtuelles Azure; Donc il n’est pas important de voir ce point ici. Ensuite les paramètres DNS peuvent (et doivent souvent) être distribués simplement par les paramètres des serveurs DNS du Virtual Network. Mais alors en quoi cela peut poser un problème … ? Il reste en effet les paramètres du suffixe DNS, qui a disparu, et la machine se retrouve avec cloudapp.net par défaut.

On peut aller plus loin, car il n’y a pas les paramètres de Register DNS qui sont revenus par défaut aussi pour les clients membres d’un domaine Active Directory. Et pour finir sur cette introduction, qui dit donc Active Directory dit contrôleurs de domaine. N’avions pas nous appris que les meilleurs pratiques étaient de croiser les DNS entre eux ? C’est à dire que par exemple avec 2 DC (A et B), il faut que le DCA utiliser DCB en tant que serveur DNS primaire, puis lui-même en secondaire; et vice-versa pour DCB.

Nous voyons donc que cette réinitialisation réseau suite à une maintenance Azure peut avoir des impacts sur le fonctionnement de la disponibilité des machines virtuelles, même si on utilise les fonctions de haute-disponibilité natives. Cela concerne dans ce cas-là, le scénario de machines virtuelles membre d’une forêt Active Directory.

La solution ? La solution idéale, serait bien entendu que les services réseaux d’Azure fournissent la possibilité de définir un paramètre pour les suffixes DNS. Nous serions déjà capable ici de gérer 80% du problème, puisque rien que ce paramètre permettrait de localiser à nouveau les ressources du domaine. Cette fonction n’est malheureusement pas disponible encore à ce jour, mais je vous invite très fortement à ajouter un vote au service Feedback d’Azure http://feedback.windowsazure.com/forums/217313-networking-dns-traffic-manager-vpn-vnet/suggestions/4932601-possibility-to-set-a-dns-suffix-on-azure-networks

Et sinon, devons-nous attendre que Microsoft fournisse une option ? Heureusement la réponse est non, à tout problème une solution. Il est par exemple très facile à l’aide de quelques lignes PowerShell de définir les paramètres du suffixe DNS, et par la même occasion d’activer l’enregistrement dynamique.

$dns_suffix = '3sr.ad'
$reg_path = "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces"
$get_dnsdomain = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=TRUE
$interface_guid = $get_dnsdomain.SettingID
reg add $reg_path\$interface_guid /v Domain /t REG_SZ /d "$dns_suffix" /f
$get_NICinfo = Get-NetConnectionProfile | Select InterfaceAlias
$interface_alias = $get_NICinfo.InterfaceAlias
netsh interface ipv4 set dnsservers name="$interface_alias" source=dhcp register=both

On peut même imaginer de faire évoluer le script pour prendre en compte des paramètres spécifiques DNS, pour gérer les paramètres statiques des contrôleurs de domaine. Il suffit de rajouter, en plus du précédent script, deux commandes netsh supplémentaires en fonction des adresses IP des serveurs DNS (uniquement pour les contrôleurs de domaine croisés, car logiquement les paramètres doivent être fournis par le DHCP d’Azure).

netsh interface ipv4 set dns name="$interface_alias" source=static address=$dns_server1 register=both
netsh interface ipv4 add dnsserver name="$interface_alias" address=$dns_server2 index=2

Alors naturellement, on peut se dire : “Je vais créer une GPO, pour rajouter ça en démarrage automatique pour mes serveurs virtuels dans Azure, facile !” … Ma réponse est non, cela ne fonctionnera pas ! Pourquoi, parce que tout simplement, la machine après le redémarrage n’aura plus de suffixe DNS, et ne pourra donc plus localiser les ressources Active Directory, donc GPO inclus ! L’époque du autoexec.bat étant révolue, il faudra donc créer une stratégie de groupe locale, à l’aide de gpedit.msc !

Ce scénario est exactement pareil lorsque votre machine est en mode Deallocated. C’est à dire quand elle est totalement coupée, puis restaurée ensuite. Vous y perdez tous vos paramètres réseaux. L’utilisation de ce type de script de manière automatique, vous évitera de perdre du temps, mais en plus cela deviendra moins gênant d’arrêter plus régulièrement les consommations de vos machines virtuelles, et donc moins cher !

A noter que si vous avez également des besoins d’utilisations d’adresses IP “statiques” pour vos machines virtuelles, sachez que désormais il est possible de créer une réservation. Ainsi, vos machines virtuelles auront l’adresse IP que vous aurez défini. Ceci n’est possible que via PowerShell Azure, en s’assurant d’avoir la dernière version possible : Set-AzureStaticVNetIP -IPAddress 192.168.0.43

Il ne devrai donc exister plus aucune problématiques réseaux désormais, afin que vos projets Azure deviennent possible dès à présent !

mars 02
Nouvelle version de DirSync, comment effectuer une mise à jour ?

Microsoft met régulièrement à jour l’outil DirSync qui permet de synchroniser les comptes d’une Active Directory On-Premises vers Windows Azure Active Directory (WAD). Ainsi, de nouvelles fonctionnalités sont présentes et bien souvent de nouveaux attributs peuvent être synchronisés.

Suite à l’arrivé de la nouvelle fonctionnalité S/Mime dans Office 365 (http://blogs.office.com/2014/02/26/smime-encryption-now-in-office-365 ), il va donc falloir mettre à jour DirSync. Car si vous souhaitez utilisez cette fonction de chiffrement pour Office 365, il est nécessaire d’avoir la version 6635.0043.

Tout d’abord, le téléchargement de la dernière version de DirSync est toujours disponible avec la même URL : http://go.microsoft.com/fwlink/?LinkID=278924. La mise à jour de DirSync peut se faire directement en In-Place Upgrade, à condition que vous aviez une version au moins en 6385.0012. Si vous êtes sur une version antérieure, il faudra désinstaller totalement le client DirSync avant de pouvoir installer la nouvelle version.

Si vous souhaitez connaître l’historique des versions de DirSync : http://social.technet.microsoft.com/wiki/contents/articles/18429.windows-azure-active-directory-sync-tool-version-release-history.aspx A l’heure ou j’écris cet article, la nouvelle version n’est pas encore indiquée, mais cela le sera d’ici peu.

Lors de la mise à jour InPlace, la configuration est détectée et l'a mise à jour se fait normalement.

clip_image003clip_image004

Il faudra tout de même effectuer l’assistant de configuration, afin d’indiquer vos options et vos identifiants (WAD et AD).

clip_image005

A l’aide de cette nouvelle version, on voit bien que l’attribut userSMIMECertificate est déjà ajouté et prêt à être synchronisé. Vous pouvez connaître les évolutions des attributs pris en charge sur le Wiki : http://social.technet.microsoft.com/wiki/contents/articles/19901.list-of-attributes-that-are-synced-by-the-windows-azure-active-directory-sync-tool.aspx 

clip_image006

A noter que si vous aviez des paramètres personnalisés (containers spécifiques, ..) dans votre précédente configuration avant la mise à jour, tout va être repris dans la nouvelle installation sauf … Oui, seul les paramètres de filtres du connecteur sont réinitialisés. Pensez-donc à les remettre ensuite Clignement d'œil

clip_image008

février 10
Comment mettre en place une connectivité réseau entre deux abonnements Azure différents à l’aide d’un Cisco

clip_image002

Il se peut que vous disposiez de plusieurs abonnements Windows Azure, surement grâce à certains avantages (MPN, MSDN, …). Lorsque vous créez un réseau virtuel dans Azure, vous devez indiquer à quel abonnement il doit être assigné. Cela implique donc, qu’il n’est pas possible de faire communiquer les deux souscriptions entre elles même si vous êtes bien un seul et unique propriétaire. Dans ce scénario, nous allons utiliser le réseau VPN Site à Site à l’aide d’un routeur On-Premises pour permettre le routage complet des deux réseaux virtuels.

Mais pourquoi faire ? Alors le premier scénario va concerner surtout des personnes IT (MVP, SSII, Réseaux MPN, …) qui souhaitent exploiter au mieux les différents avantages Windows Azure acquis à travers différents programmes. Ceci est en effet mon cas personnellement. Mais savez-vous que l’on ne peut pas exposer un réseau virtuel Azure sur deux affinités ? Il n’est pas possible aujourd’hui de faire communiquer un réseau en Europe de L’ouest avec un réseau en Asie ou en Amérique. Cette technique, peut donc permettre de créer des ressources sur les différentes plaques géographiques et permettre une communication réseau entre elles.

Pour revenir à mon cas, j’ai donc deux abonnements Azure. Nous allons appeler le premier A avec un subnet en 192.168.100.0/24 et le second B qui aura le réseau 192.168.80.0/24.

image

Tout d’abord, il faut s’assurer qu’il y a bien un VPN Site à Site configuré entre le réseau Azure A et le réseau On-Premises. Pour cela, regardez mon précédent article qui décrit sa mise en œuvre : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=295

Maintenant, il va falloir faire à peu près la même chose pour le second réseau, avec quelques petites exceptions. Nous allons donc créer un second réseau local, en utilisant la même adresse IP de passerelle VPN mais avec le second abonnement désormais. Et c’est là où il faut rajouter dans l’espace d’adressage local, le sous-réseau de l’autre abonnement (en plus du réseau local On-Premises). Le réseau sera donc considéré comme local pour Azure.
image

Après on lance la configuration du nouveau réseau 192.168.80.0/24 sur le nouvel abonnement, et on y assigne en connexion VPN Site à Site le nouveau réseau local. Pour terminer on créer la passerelle VPN et on récupère la clé pré-partagée (pour plus de détails voir mon précédent article). Dans l’impression écran ci-dessous, mon réseau VPN est déjà connecté ; ne pas en tenir compte.
clip_image008

A présent, il faut faire de la configuration Cisco … et oui encore J Mais si vous téléchargez le script généré, puis vous l’appliquez, votre ancienne configuration VPN Site à Site ne fonctionnera plus. Ici l’objectif est bien de faire marcher au même moment les deux VPN Site à Site. De plus, nous avons des points communs de configuration, donc inutile de dupliquer les objets de configuration Cisco.

Vous pouvez conserver les objets de configuration IkeProposal, IkePolicy et IkeKeyring de la configuration Cisco. Il reste seulement dans la configuration de Keyring à rajouter un nouveau peer. Vous y indiquer la pre-shared key associée.
image

Ensuite vous devez créer un nouveau profil Ike. Vous pouvez copier/coller le précédent profil et y changer seulement l’adresse IP publique. Vous devez conserver les paramètres de keyring.
clip_image012

A présent, il faut créer les paramètres IPSec. Hélas, il n’est pas possible de mutualiser les objets de configuration ici. Donc vous devez dupliquer les configurations Crypto Cisco. Dans mon cas j’ai mis un 2 pour différencier les paramètres. Attention, pensez bien à mettre à jour le nom du profil IKE (étape juste au-dessus) en fonction du nom que vous lui avez assigné.
clip_image014

Avant dernière étape, on va créer le tunnel. Dans le script fourni par Azure, il assigne un IP 169.254.0.1. Nous ne pouvons pas la réutiliser, donc ici j’ai mis la 169.253.0.1 pour éviter un overlap. Ensuite, il s’agit d’indiquer les adresses IP publiques et d’associer le profil IPSec que l’on vient juste de créer à l’étape précédente.
clip_image016

Et enfin pour terminer, les règles d’accès et de routage ! On donc rajouter une règle de routage et une règle d’accès comme pour le premier tunnel :

ip route 192.168.80.0 255.255.255.0 Tunnel2
access-list 101 permit ip 192.168.217.0 0.0.0.255 192.168.80.0 0.0.0.255

Normalement, à ce point-là votre réseau On-premises peut communiquer vers le nouveau réseau Azure, donc en d’autres termes seul le réseau On-Premises peut échanger des données avec les deux abonnements, mais pas les abonnements entre eux. Alors il suffit de rajouter une nouvelle access-list qui permet la communication entre le réseau 192.168.100.0/24 et 192.168.80.0/24.

access-list 101 permit ip 192.168.80.0 0.0.0.255 192.168.100.0 0.0.0.255

Et voilà ! Maintenant, vos deux réseaux Azure étant sur deux abonnements différents peuvent communiquer entre eux. Il sera possible de mettre en place des Cloud Services,… répartis sur deux affinités différentes tout en assurant une intercommunication. Cependant cela utilise votre réseau On-Premises pour assurer le routage. Alors la latence sera plus longue que prévue. Dans mon cas, voilà un exemple d’un ping depuis le réseau Azure B vers le réseau On-Premises et le réseau Azure A. On y comprend que passer un seul tunnel apporte une latence de 40 à 50ms max, alors que de repasser à nouveau par un second tunnel la latence est environ de 80/90ms.
clip_image018

février 01
Arrêt des service de PhoneFactor (free version) au 1er Février 2014, passez à Azure Multi-Factor Authentication

Les services de PhoneFactor seront arrêtés le 1er Février 2014. Ceci implique qu'au-delà de cette date, les services ne seront plus opérationnels.

Afin d'avoir une continuité de service, il faut migrer vers la nouvelle solution Azure Multi-Factor Authentication.

Une documentation est fournie, afin de vous permettre cette migration pas à pas sans interruption de services. Elle permet la migration des comptes existants.
Plus d'informations sur : https://www.phonefactor.com/TransitioningfromPhoneFactortoWindowsAzureMFA.pptx

Le point important, est en fait de récupérer l'ID de votre compte Phone Factor et de créer un fournisseur MFA dans Azure ayant exactement le même nom.

v

janvier 29
Création d’un VPN site à site IKE v2 entre un Cisco ISR et Microsoft Azure

Vous ne le saviez peut-être pas, mais il est possible de créer un VPN site à site entre votre infrastructure locale (On-Premises) et la plateforme de Cloud Windows Azure.

Ainsi, il vous sera possible d'accéder directement aux machines virtuelles et autre services, directement depuis votre réseau local. Ceci est d'ailleurs nécessaire pour certaines scénarios, comme avoir des contrôleurs de domaines de votre forêt sur Azure, ou dans des modes hybrides (SQL On-Premises, Web Services dans Azure, etc…). La connexion deviendra donc permanente et toujours accessible.

Tout d'abord, il faut savoir que tous les périphériques VPN ne sont pas supportés. A ce jour vous avez surtout quelques modèles Cisco (ASA, ISR), Juniper (SRX, ISG, …), Watchguard, F5, Citrix et bien sûr le service RRAS de Windows 2012/201R2. Retrouvez ici, la liste complète des spécifications et des modèles supportés à jour : http://msdn.microsoft.com/fr-fr/library/windowsazure/jj156075.aspx

Vous aurez le choix de créer le tunnel en deux modes, soit avec routage statique ou dynamique. Dans le premier mode, ce sera IKE dans sa version 1 qui sera utilisé. Le mode dynamique quant à lui, sera basé sur de l'IKE v2. Ci-dessous un extrait de l'article MSDN détaillant les paramètres en fonction de chaque phase.

Phase 1 IKE

Propriété

Passerelle VPN à routage statique

Passerelle VPN à routage dynamique [Preview]

Version IKE

IKEv1

IKEv2

Groupe Diffie-Hellman

Groupe 2 (1 024 bits)

Groupe 2 (1 024 bits)

Méthode d'authentification

Clé prépartagée

Clé prépartagée

Algorithmes de chiffrement

AES256
AES128
3DES

AES256
3DES

Algorithme de hachage

SHA1(SHA128)

SHA1(SHA128)

Durée de vie d'association de sécurité de phase 1 (temps)

28,800 secondes

28,800 secondes

 

Phase 2 IKE

Propriété

Passerelle VPN à routage statique

Passerelle VPN à routage dynamique [Preview]

Version IKE

IKEv1

IKEv2

Algorithme de hachage

SHA1(SHA128)

SHA1(SHA128)

Durée de vie d'association de sécurité de phase 2 (temps)

3,600 secondes

-

Durée de vie d'association de sécurité de phase 2 (débit)

102,400,000 Ko

-

Offres d'authentification et de chiffrement d'association de sécurité IPsec (par ordre de préférence)

ESP-AES256
ESP-AES128
ESP-3DES
N/A

Voir Offres d'association de sécurité IPsec pour passerelle à routage dynamique

PFS (Perfect Forward Secrecy)

Non

Non

Détection d'homologue mort

Non prise en charge

Prise en charge

 

Dans cet article nous allons utiliser un modèle Cisco ISR 867 VAE. C'est un routeur d'entrée de gamme compatible ADSL/VDSL (http://www.cisco.com/en/US/products/ps11999/index.html ). Pour rappel, dans un précédent article, j'ai décrit la configuration nécessaire pour permettre à ce routeur d'être connecté en vDSL avec Orange en fournisseur : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=293

 

1ère étape : Création des paramètres réseax Azure et de la passerelle VPN

Pour commencer, il faut se connecter à votre portail d'administration Azure. Il faut, au niveau des paramètres réseaux, indiquer votre configuration locale.
Il s'agit ici, d'indiquer l'adresse IP publique de votre routeur qui aura le rôle de l'initiateur VPN. Ici j'utilise l'adresse 193.238.86.86 et j'indique également le range de mon réseau local 192.168.17.0/24.
Attention, l'adresse IP publique doit être directement adressée au périphérique VPN concerné. Cela ne fonctionne pas en NAT.

Ensuite, il suffit de créer un réseau virtuel Azure en déclarant un range. Dans mon cas, je vais utiliser le 192.168.100.0/24.

Et enfin, il suffit de créer une passerelle. C'est là ou vous aurez le choix entre IKEv1 et IKEv2, soit respectivement les choix de routage statique et dynamique.
Ce choix dépend des capacités de votre appareil, ici le Cisco 867 en IOS 15.2 est compatible IKEv2, donc je sélectionne routage dynamique.

Il va falloir être quelque peu patient … cela peut durer 10 à 15mn environ.

Quand le processus sera terminée, vous découvrirez l'adresse IP publique Azure qui vous sera réservée.
Dans notre cas, l'adresse 137.116.118.137 sera donc le point de terminaison VPN côté Azure.

Avant de passer aux paramètres, vous pouvez récupérer la clé pré-partagée en cliquant sur le bouton en bas « Gérer la clé ».
La clé actuelle vous sera affichée, mais vous pouvez si vous le souhaitez en générer une nouvelle.

Et enfin, vous pouvez télécharger les modèles de scripts fournis directement par Azure. Ces modèles sont déjà très bien avancés, et sont juste à compléter avec le minimum de données. Toutes les données en possession par Azure seront déjà inscrites dans ce script.

Voilà ce qu'Azure me propose désormais. On découvre donc en vert, les paramètres qu'Azure a déjà auto-complété (IPs publiques, ranges, PreShared Key, …) et en jaune la seule chose à compléter, à savoir le nom de l'interface externe du routeur. Autant dire, que tout est prêt finalement !

! Microsoft Corporation

! Windows Azure Virtual Network

 

! This configuration template applies to Cisco ISR 2900 Series Integrated Services Routers running IOS 15.1.

! It configures an IPSec VPN tunnel connecting your on-premise VPN device with the Azure gateway.

 

! ---------------------------------------------------------------------------------------------------------------------

! ACL rules

!

! Proper ACL rules are needed for permitting cross-premise network traffic.

! You should also allow inbound UDP/ESP traffic for the interface which will be used for the IPSec tunnel.

access-list 101 permit ip 192.168.17.0 0.0.0.255 192.168.100.0 0.0.0.255

 

! ---------------------------------------------------------------------------------------------------------------------

! Internet Key Exchange (IKE) configuration

!

! This section specifies the authentication, encryption, hashing, and Diffie-Hellman group parameters for the Phase

! 1 negotiation and the main mode security association.

crypto ikev2 proposal azure-proposal

encryption aes-cbc-256 aes-cbc-128 3des

integrity sha1

group 2

exit

 

crypto ikev2 policy azure-policy

proposal azure-proposal

exit

 

crypto ikev2 keyring azure-keyring

peer 137.116.118.137

address 137.116.118.137

pre-shared-key SIOAdj67vjifkwoa4oW71Pz7hZfKuMHqG2k

exit

exit

 

crypto ikev2 profile azure-profile

match address local interface <NameOfYourOutsideInterface>

match identity remote address 137.116.118.137 255.255.255.255

authentication remote pre-share

authentication local pre-share

keyring azure-keyring

exit

 

! ---------------------------------------------------------------------------------------------------------------------

! IPSec configuration

!

! This section specifies encryption, authentication, tunnel mode properties for the Phase 2 negotiation

crypto ipsec transform-set azure-ipsec-proposal-set esp-aes 256 esp-sha-hmac

mode tunnel

exit

 

! ---------------------------------------------------------------------------------------------------------------------

! Crypto map configuration

!

! This section defines a crypto profile that binds the cross-premise network traffic to the IPSec transform

! set and remote peer. We also bind the IPSec policy to the virtual tunnel interface, through which

! cross-premise traffic will be transmitted. We have picked an arbitrary tunnel id "1" as an example. If

! that happens to conflict with an existing virtual tunnel interface, you may choose to use a different id.

crypto ipsec profile vti

set transform-set azure-ipsec-proposal-set

set ikev2-profile azure-profile

exit

 

int tunnel 1

ip address 169.254.0.1 255.255.255.0

ip tcp adjust-mss 1350

tunnel source <NameOfYourOutsideInterface>

tunnel mode ipsec ipv4

tunnel destination 137.116.118.137

tunnel protection ipsec profile vti

exit

 

ip route 192.168.100.0 255.255.255.0 tunnel 1

 

2nde étape : Configuration du routeur Cisco 867 VAE

On considère ici que bien entendu, la configuration du routeur est déjà opérationnelle et que ce dernier dispose d'une adresse IP publique.

Comme indiqué ci-dessus avec le modèle de configuration Azure, il ne reste plus qu'à indiquer seulement le nom de l'interface externe. Si le routeur Cisco est connecté à votre FAI, alors cela devrait être Dialer1. Il suffit donc de remplacer les deux occurrences <NameOfYourOutsideInterface> avec Dialer1, et tout sera prêt. On se met donc en mode configuration (conf t) et on « copier colle » tout simplement le script généré complété dans l'interface Telnet (ou console).

Attention, dans mon cas il y a une erreur dans le script généré (peut-être lié à me version d'IOS). Car la commande keyring associé au nom azure-keyring ne fonctionne pas. Il faut indiquer si l'association keyring est soit locale ou en AAA.

La partie concernée est au niveau de la création du profil ikev2 :

crypto ikev2 profile azure-profile

match address local interface <NameOfYourOutsideInterface>

match identity remote address 137.116.118.137 255.255.255.255

authentication remote pre-share

authentication local pre-share

keyring azure-keyring

exit

 

Il suffit de rajouter local entre keyring et azure-keyring

crypto ikev2 profile azure-profile

match address local interface <NameOfYourOutsideInterface>

match identity remote address 137.116.118.137 255.255.255.255

authentication remote pre-share

authentication local pre-share

keyring local azure-keyring

exit

 

 

3ème étape : Activation de la configuration

Comme Azure tout se veut simple, il y a donc juste un bouton « Connecter » en bas. Cliquez dessus et patienter.

Et pour les non-initiés à Cisco, pensez à valider votre configuration définitivement si vous ne voulez pas perdre votre config (running-config) au prochain démarrage (startup-config) à l'aide de la commande wr mem.

 

Dernière étape ?

Si à ce moment-là, cela ne marche pas alors ce sera orientation Troubleshooting. Alors ce fut mon cas sur un bon moment, car j'avais une configuration déjà spécifique sur mon Cisco, avec du NAT, Vlan, Dialer en IPCP, … Bref, j'ai dû un peu revoir la configuration. Si vous avez une configuration standard, tout devrait marcher du premier coup. Vous pouvez vérifier l'état de négociation avec les commandes sh crypto ikev2 sa et sh crypto ikev2 session.

R887VAE#sh crypto ikev2 sa

IPv4 Crypto IKEv2 SA

 

Tunnel-id Local Remote fvrf/ivrf Status

1 193.238.86.86/4500 137.116.118.137/4500 none/none READY

 

Encr: 3DES, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/26 sec

 

R887VAE#sh crypto ikev2 session

IPv4 Crypto IKEv2 Session

 

Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1

 

Tunnel-id Local Remote fvrf/ivrf Status

1 193.238.86.86/4500 137.116.118.137/4500 none/none READY

 

Encr: 3DES, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/29 sec

Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535

remote selector 0.0.0.0/0 - 255.255.255.255/65535

ESP spi in/out: 0x7EF5B2CB/0x5B12C6E4

 

Et si vraiment vous n'y arrivez toujours pas, alors faudra faire un debug sur votre routeur. Attention, ça pique un peu : http://www.cisco.com/en/US/tech/tk367/technologies_tech_note09186a0080bf3128.shtml

De plus, vous pouvez optimiser quelques points et y apporter plus de personalisations à l'aide de cet article : http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ikevpn/configuration/15-1mt/Configuring_Internet_Key_Exchange_Version_2.html#GUID-00855DB8-3FD8-4C5F-AA8B-A434E11024C0

 

Mais sinon, tout rentre dans l'ordre et vous le verrez graphiquement depuis le portail Azure. Il ne reste plus qu'à configurer vos scénarios hybrides désormais ;)

janvier 27
Skydrive va devenir OneDrive suite au procès de BSkyB !

 

Skydrive ? Tout le monde connaît Skydrive aujourd'hui je pense ; Et même les entreprises avec la solution Skydrive Pro.

Si vous avez suivi l'actualité, la société audiovisuelle britannique BSkyB (pour British Sky Broadcasting) avait fait la demande à Microsoft de renommer sa solution estimant que le nom Skydrive était emprunté à leur société. De plus, les utilisateurs xBox en Angleterre pouvait accéder aux chaînes Sky et de nombreux services en lignes portait des noms comme Sky Store & Share, …

Une décision de justice, le 28 juin 2013, a donné raison à la société BSkyB contraignant ainsi Microsoft à devoir renommer la solution Skydrive : http://www.bailii.org/ew/cases/EWHC/Ch/2013/1826.html

 

6 mois se sont écoulés, et Microsoft vient d'annoncer le futur nom de SkyDrive qui sera tout simplement OneDrive ! Dans OneDrive on peut comprendre un peu le tout en un, à savoir stocker toutes ses données sur un unique point. Cela fait penser aussi à Xbox One. Dans tous les cas, quelque soit la raison ce sera donc OneDrive qu'il faudra désormais dire !

Cela va donc impliquer que les applications actuelles vont être mises à jour (Windows, Phone, …) et le site web aussi. Actuellement, il est possible d'être alerté des informations en s'enregistrant sur cette page https://preview.onedrive.com/ et il existe un blog dédié à OneDrive http://blog.onedrive.com/

janvier 27
Annonce : Changement majeur dans la gamme Microsoft Forefront

Nous attendions avec impatience les nouvelles Roadmap des solutions qui composent la gamme Forefront. Il est important de comprendre que Forefront, n'est pas un nom de produit mais un terme marketing lancé par Microsoft il y a maintenant 10 ans. Forefront n'est donc pas un produit, ni une équipe. Ainsi, les équipes de Forefront UAG ne sont pas les mêmes que Forefront FIM par exemple, même si parfois elles peuvent bien entendu collaborer ensemble.

L'année dernière, il a été annoncé l'arrêt de l'évolution majeure de la solution TMG. A cette même occasion, on y apprend que les solutions antimalwares prenaient une nouvelle orientation. Pour rappel voici l'annonce officielle : http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Sur cette fin d'année 2013, Microsoft nous annonce un nouveau changement majeur dans la gamme de produit Forefront : http://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx. Le terme marketing Forefront est donc amené à disparaître.

 

Concernant Microsoft Forefront Identity Manager 2010

Microsoft maintient son investissement dans le produit Identity Manager (FIM) avec l'annonce d'une prochaine version majeure, courant 2015. Les premières informations disponible à son sujet font état de :

  • La prise en charge des scénarios de type Hybride avec l'intégration avec Windows Azure Active Directory.
  • La gestion des accès et des utilisateurs
  • L'audit et la conformité
  • D'autres nouvelles fonctionnalités, notamment avec Azure, sont à venir

 

Il est à noter que le composant « DirSync » de FIM, est incontournable dans tous les projets Office 365 et autres scénarios Azure. Il permet de mettre en œuvre une synchronisation d'annuaire On-Premise vers Azure Active Directory (AAD) nécessaire pour Office 365. FIM est donc juste incontournable pour tous les projets nécessitant des synchronisations d'annuaire et de gestion des identités. Dans un contexte de sécurité, les principales attaques/vol d'identités viennent de la non-gestion (utilisateurs, groupes, permissions) des identités dans AD.

Ainsi la prochaine version de la solution de gestion des identités changera très certainement de nom, et perdra tout naturellement la dénomination « Forefront » dans son appellation marketing. Nous le découvrirons sous peu, et vous le partagerons dès que possible.

 

Concernant Microsoft Forefront UAG 2010

Microsoft a pris la décision d'arrêter ses investissements dans le produit Forefront Unified Access Gateway 2010. Le produit restera supporté par Microsoft jusqu'au 14 Avril 2015 pour la phase de support standard et s'arrêtera le 14 Avril 2020 pour la phase de support étendue. Les clients disposant d'un contrat de type « Software Assurance » à la date du 1er décembre 2013 seront en mesure de déployer de nouveaux serveurs et prendre en charge de nouveaux utilisateurs sans cout de licence additionnel.

Néanmoins, le produit peut continuer de publier des ressources de manière sécurisée et s'assurer que seuls les utilisateurs autorisés puissent y accéder. Microsoft a récemment mis à disposition le Service Pack 4. Ce dernier Service Pack, prend en charge la publication de services tel que Sharepoint 2013 ou Exchange 2013. Il prend en compte les dernières versions des clients (Windows 8.x & Internet Explorer 11). En plus de quelques autres améliorations mineures, le SP4 permet aussi la prise en charge de RemoteApp et les autres services RDS de Windows 2012/2012R2.

Pour les clients disposant déjà d'une solution UAG dans votre SI, il n'est pas obligatoire de migrer rapidement vers une autre solution comme WAP. La flexibilité d'UAG, la mise à jour récente du SP4 et un support jusqu'en 2020 doit permettre de répondre encore longtemps à vos besoins actuels.

Il y a toujours une forte communauté autour de la solution UAG, animée par la présence de nombreux MVP et experts communautaires. Cela permet d'apporter un support continu à la solution UAG, même au-delà de 2020. Le forum à consulter est sur le site de Technet : http://social.technet.microsoft.com/Forums/forefront/en-US/home?forum=forefrontedgeiag

 

Rappel au sujet des accès VPN et DirectAccess dans UAG :

Cela a déjà été évoqué il y a un peu moins de deux ans, depuis la sortie de Windows 2012, Microsoft recommande de privilégier le rôle Unified Remote Access de Windows Server 2012/2012 R2 en lieu et place d'UAG pour implémenter DirectAccess. Microsoft n'apportera plus d'évolution à l'implémentation DirectAccess au sein de Foreront UAG 2010.

Les implémentations de DirectAccess réalisées sur UAG devront donc être migrées vers Windows 2012 R2. Avec la solution Unified Remote Access, il est également possible de faire du VPN PPTP, L2TP et SSTP tout en ayant DirectAccess.

 

Scenario de publication :

Windows 2012 R2 apporte un nouveau rôle nommé WAP (Web Application Proxy). Ce celui-ci permet de prendre en charge certains scénarios jusqu'alors assurés par Forefront UAG 2010. Le tableau-ci-dessous synthétise les fonctionnalités offertes par les deux solutions:

Scenario

Solution possible

Publication simple d'Exchange

WAP ou Forefront UAG

Publication simple de SharePoint

WAP ou Forefront UAG

Publication de Lync WebServices

WAP ou Forefront UAG

Publication Web simple

WAP ou Forefront UAG

Publication d'Exchange avec customisation

Forefront UAG

Publication de SharePoint avec customisation

Forefront UAG

Publication Web avancée

Forefront UAG

Prise en charge de la conformité des postes

Forefront UAG

Mise en œuvre d'un portail

Forefront UAG

Single-sign-on entre les applications publiées

Forefront UAG

Personnalisation avancée

Forefront UAG

BYOD

WAP

Fédération

WAP

 

Si la solution Forefront UAG est déjà existante dans un réseau il n'est pas nécessaire de migrer vers la solution WAP pour le moment, en effet cette dernière est une solution encore jeune avec certaines limite :

  • Ne propose à ce jour que des scénarios de mise en œuvre « Basiques »
  • Principalement basé sur une pré-authentification AD FS ou pass-through
  • La haute disponibilité se base que sur des répartiteurs de charge matérielle
  • La configuration se trouve stockée dans l'infrastructure AD FS
  • La translation d'URL possède des limitations

 

Voici quelques articles qui présentent comment réaliser la publication des services les plus courants :

 

En conclusion, la majorité des scénarios de publication courants que nous avions à disposition avec Forefront UAG sont aussi disponibles avec la fonctionnalité Web Application Proxy de Windows Server 2012 R2. A ce jour, la migration de Forefront UAG 2010 vers WAP ne peut être envisagée que pour les scénarios pour lesquels WAP propose le même niveau de fonctionnalité d'UAG. 

 

Auteurs :

1 - 10Suivante
MVP Forefront

 ‭(Masqué)‬ Liens d'administration