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é.
août 19
Copie hors site Hyper-V vers Azure avec Altaro Hyper-V Backup

image

Précédemment, je vous avait présentée une solution de sauvegarde pour Hyper-V, Altaro. En effet cette solution nous permettait de mettre en place la sauvegarde de nos machines virtuelles très rapidement et efficacement. Voici le lien du précédent article en question : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=325

A présent, je vais vous décrire comment faire une copie hors-site de vos machines virtuelles directement dans Azure. cela permettra de disposer de rétentions différentes, et d'avoir une copie hors du site en cas d'incidents majeurs (incendie, ...). La solution consiste à mettre en oeuvre une machine virtuelle dans Azure, et d'établir un lien entre la solution On-Premises et la VM hébergée chez Microsoft Azure.

 

Et comme j'aime bien le faire en PowerShell, alors soyons fou ... Tout d'abord on se connecte à Azure !

#####################

### Connexion Azure

# Informations de l'abonnement Azure

$Azure_SubscriptionId = 'ce050624-xxxx-41dd-xxxx-db17af339fcf'

$Azure_TenantId = 'dd177f3c-1f80-xxxx-1013738baf98'

$Azure_AdminLogin = 'admin@domaine.com'

$Azure_AdminCred = Get-Credential -UserName $Azure_AdminLogin -Message 'Mot de passe'

Add-AzureAccount -Credential $Azure_AdminCred -Tenant $Azure_TenantId

Select-AzureSubscription -SubscriptionID $Azure_SubscriptionId

 

Nous allons préparer les ressources Azure, ici en Europe de l'ouest. Cela comprends essentiellement la création du service, réserver une adresse IP publique, un espace de stockage, ...

#####################

### Création des ressources Azure

$Azure_Location = 'West Europe'

 

# Création d'un Cloud Services

$Azure_CloudService = 'ALTARO-REPLICA'

New-AzureService -ServiceName $Azure_CloudService -Location $Azure_Location

 

# Réservation d'une adresse IP publique

$AzureIP_Name = 'ALTARO_IP'

$AzureIP_Label = 'IP Publique pour la réplication Altaro'

$AzureIP_Reserved = New-AzureReservedIP -ReservedIPName $AzureIP_Name -Label $AzureIP_Label -Location $Azure_Location

 

# Espace de stockage dédié

$Azure_StorageAccount = 'altaroreplica'

$Azure_StorageLabel = 'Réplica backup ALTARO'

New-AzureStorageAccount -StorageAccountName $Azure_StorageAccount -Label $Azure_StorageLabel -Location $Azure_Location

Set-AzureSubscription -SubscriptionId $Azure_SubscriptionId -CurrentStorageAccountName $Azure_StorageAccount

 

# Dernière version de l'image Windows 2012 R2 Datacenter

$AzureVM_LastImageVersion = Get-AzureVMImage |

Where-Object -FilterScript { $_.OS -eq "Windows" -and $_.PublisherName -eq "Microsoft Windows Server Group" -and $_.ImageFamily -eq "Windows Server 2012 R2 Datacenter" } |

Select-Object -Last 1

 

Et là, on passe à la création de la VM. Nous utilisons une machine au modèle Small dans notre cas, mais cela est à adapter si besoin. De plus, nous allons ajouter un 2nd disque dur de données d'1Tb ce qui permettra justement d'y stocker les données de sauvegarde répliquées. Il est important de comprendre que l'on ne peut pas créer de disque > 1023 Gb. Donc si besoin, créer en plusieurs et faire un agrégat ensuite.

# Création de la VM

$AzureVM_Name = 'ALTARO-REPLICA'

$AzureVM_LocalAdminName = 'admintemp'

$AzureVM_LocalAdminPwd = 'Mot2Passe' # doit être changé

$AzureVM_SizeType = 'Small'

$AzureVM_Config = New-AzureVMConfig -Name $AzureVM_Name -InstanceSize $AzureVM_SizeType -ImageName $AzureVM_LastImageVersion.ImageName -DiskLabel $AzureVM_Name'_Disk' -Label $AzureVM_Name |

Add-AzureProvisioningConfig -Windows -AdminUsername $AzureVM_LocalAdminName -Password $AzureVM_LocalAdminPwd

New-AzureVM -ServiceName $Azure_CloudService -VMs $AzureVM_Config -ReservedIPName $AzureIP_Name -WaitForBoot

 

# Ajout d'un 2nd disque dur (max 1023Gb)

$AzureVM_DiskData_Size = 1023

$AzureVM_DiskData_Label = 'altaroreplicadata'

Get-AzureVM –ServiceName $Azure_CloudService –Name $AzureVM_Name | Add-AzureDataDisk -CreateNew -DiskSizeInGB $AzureVM_DiskData_Size -DiskLabel $AzureVM_DiskData_Label -LUN 0 | Update-AzureVM

 

Voilà, la machine virtuelle est crée et disponible désormais. Certains auront surement remarqués, que la VM n'est pas attachée à un Vnet, ou autres configurations propre à un éventuel existant. La VM est purement autonome et utiliser les configurations réseaux standards d'Azure. Il n'est pas nécessaire ici de l'associer à un quelconque domaine AD ou d'avoir des relations réseaux; Seul l'accès Internet est nécessaire.

 

Enfin, nous allons sécuriser les accès réseaux à cette VM exposée publiquement. On supprime donc les accès Remote PowerShell, et on modifie les accès RDP avec en restriction notre adresse IP publique. Puis, il faut ouvrir les ports TCP requis par la solution Altaro (35101 et 35109-35111). La également, l'accès est restreint avec l'adresse IP de l'entreprise.

#####################

### gestion réseau et sécurisation

 

# Création d'une ACL pour l'IP publique autorisée

$AzureEndpoint_AclConfig = New-AzureAclConfig

$AzureEndpoint_RDP_Port = 12345

$AzureEndpoint_AclRemoteIP = '193.x.y.z/32'

$AzureEndpoint_AclRemoteDescription = '3SR'

Set-AzureAclConfig -AddRule -ACL $AzureEndpoint_AclConfig -Order 0 -Action Permit -RemoteSubnet $AzureEndpoint_AclRemoteIP -Description $AzureEndpoint_AclRemoteDescription

Set-AzureAclConfig -AddRule -ACL $AzureEndpoint_AclConfig -Order 1 -Action Deny -RemoteSubnet "0.0.0.0/0" -Description "Deny All"

 

# Sécurisation des services natifs

Get-AzureVM –ServiceName $Azure_CloudService –Name $AzureVM_Name | Set-AzureEndpoint -Name 'RemoteDesktop' -PublicPort $AzureEndpoint_RDP_Port -ACL $AzureEndpoint_AclConfig | Update-AzureVM

Get-AzureVM –ServiceName $Azure_CloudService –Name $AzureVM_Name | Remove-AzureEndpoint –Name 'PowerShell' | Update-AzureVM

 

# création des publication Altaro

$AzureEndpoint_Name_01 = 'Altaro_35101'

$AzureEndpoint_Port_01 = 35101

$AzureEndpoint_Name_02 = 'Altaro_35109'

$AzureEndpoint_Port_02 = 35109

$AzureEndpoint_Name_03 = 'Altaro_35110'

$AzureEndpoint_Port_03 = 35110

$AzureEndpoint_Name_04 = 'Altaro_35111'

$AzureEndpoint_Port_04 = 35111

Get-AzureVM –ServiceName $Azure_CloudService –Name $AzureVM_Name |

Add-AzureEndpoint -Name $AzureEndpoint_Name_01 -Protocol tcp -LocalPort $AzureEndpoint_Port_01 -PublicPort $AzureEndpoint_Port_01 -ACL $AzureEndpoint_AclConfig | Update-AzureVM

Get-AzureVM –ServiceName $Azure_CloudService –Name $AzureVM_Name |

Add-AzureEndpoint -Name $AzureEndpoint_Name_02 -Protocol tcp -LocalPort $AzureEndpoint_Port_02 -PublicPort $AzureEndpoint_Port_02 -ACL $AzureEndpoint_AclConfig | Update-AzureVM

Get-AzureVM –ServiceName $Azure_CloudService –Name $AzureVM_Name |

Add-AzureEndpoint -Name $AzureEndpoint_Name_03 -Protocol tcp -LocalPort $AzureEndpoint_Port_03 -PublicPort $AzureEndpoint_Port_03 -ACL $AzureEndpoint_AclConfig | Update-AzureVM

Get-AzureVM –ServiceName $Azure_CloudService –Name $AzureVM_Name |

Add-AzureEndpoint -Name $AzureEndpoint_Name_04 -Protocol tcp -LocalPort $AzureEndpoint_Port_04 -PublicPort $AzureEndpoint_Port_04 -ACL $AzureEndpoint_AclConfig | Update-AzureVM

 

 

Et une petite astuce, permettre à la fin la commande de connexion RDP requise dans le presse-papier pour s'y connecter depuis le menu exécuter dès à présent ;)

#####################

### Copie de la commande RDP pour se connecter dans le presse-papier

$AzureIP_Address = (Get-AzureReservedIP -ReservedIPName $AzureIP_Name).Address

$AzureRDP_Command = "mstsc /v:" + $AzureIP_Address +":"+ $AzureEndpoint_RDP_Port

$AzureRDP_Command | clip

 

 

Voilà, tous les prérequis côté Azure sont prêts ! Maintenant, il suffit de se connecter à la VM en question pour quelques opérations.

En premier lieu ... on initialise et formate le disque de données !

image

 

Puis on télécharge Altaro Backup Server depuis http://downloads.altaro.com/altarohypervbackupsetup_backupserver.exe et on l'installe avec les options par défaut (Next Next ... Finish !)
clip_image001

Depuis la console de gestion, on crée un compte et un mot de passe ..
clip_image003

... puis on indique le disque dur de destination. Autant prendre le nouveau disque fraichement initialisé et dédié !
clip_image005

Le compte est disponible et visible dans la console. Il n'y a plus d'actions à faire sur le serveur Azure, c'est terminé .. déjà !
clip_image007

 

Il faut configurer ensuite les serveurs On-Premises. Cela va s'effectuer en quelques clics seulement, que je décris ci-dessous.

Nous allons commencer par créer un nouvel espace de stockage hors-site depuis le menu Backup Locations.
clip_image009

Il faut indiquer que l'on utiliser un serveur Altaro
clip_image010

Et c'est là que l'on indique l'adresse IP, et les informations du compte Altaro. Il est possible de valider la communication pour s'assurer que les informations réseaux (Firewall, ...) et de comptes sont valides.
clip_image011

Voilà ! L'espace est crée et disponible. Il ne reste plus qu'à déplacer des VM pour prendre en compte la sauvegarde hors-site.
clip_image012

Lors de l'ajout d'une première VM, il vous sera demandé de créer une clé de chiffrement. Bien entendu à noter de manière sécurisée.
clip_image013

Il faut configurer les options de rétentions hors-site
clip_image015

Et activer les planifications hors-site de vos jobs actuels
clip_image017

 

C'est fini, tout est prêt !!! Il vous sera possible de suivre l'évolution de vos transferts hors-site depuis l'outil de gestion sur la VM Azure.
clip_image019

C'est ainsi qu'avec un minimum de ressource Azure et à faible couts, il est possible d'avoir une copie hors-site de l'ensemble de ces machines virtuelles dans le cloud. Si vous souhaitez plus d'informations, n'hésitez pas à consulter la description de la solution Altaro sur leur site web ou bien me contacter sur www.3sr.fr

mai 11
Gestion des alertes de surveillance Azure en PowerShell (Azure Health Monitoring)

On peut normalement tout faire avec PowerShell, non ? Et pourtant dans notre cas précis, je n’ai pas trouvé de Cmdlet natives permettant de gérer les alertes de surveillance Azure ??? C’est vrai que depuis le portail, ce n’est que quelque clics finalement, … Mais combien de Cloud Services peut-être devez-vous surveiller ? Combien de clics il faudrait en fait ? Et quoi de mieux d’industrialiser pour éviter des erreurs.

Donc, on disait qu’il n’y a pas de commandes natives PowerShell, alors passons directement aux via les API REST de gestion Azure : https://msdn.microsoft.com/library/azure/ee460799.aspx Je tiens à préciser que comme j’ai cherché sur le net avant, j’ai trouvé un article sur lequel je me suis bien inspiré et je me dois d’indiquer la référence car cela a été mon pointeur initial : http://blogs.technet.com/b/keithmayer/archive/2014/11/08/scripts-to-tools-automate-monitoring-alert-rules-in-microsoft-azure-with-powershell-and-the-azure-service-management-rest-api.aspx

 

Tout d’abord on va se connecter à Azure, normal

#####################
### Connexion Azure
$Azure_SubscriptionId = '12345678-abcd-abcd-abcd-123456789012'
$AzureLogin_PublishingFile = 'Azure-AzureConnect.publishsettings'
Import-AzurePublishSettingsFile -PublishSettingsFile $AzureLogin_PublishingFile
Select-AzureSubscription -SubscriptionID $Azure_SubscriptionId

 

Jusque-là pas de problème, mais pour utiliser le REST API il nous faut une connexion avec le certificat. Nous allons le récupérer grâce à la connexion précédente à l’aide des informations étendues

# Get du certificat
$Azure_SubscriptionDetail = Get-AzureSubscription -SubscriptionID $Azure_SubscriptionId -ExtendedDetails
$Azure_SubscriptionCertificate = $Azure_SubscriptionDetail.Certificate

Maintenant, on va juste indiquer en variables le nom exact de la VM cible et un nom simplifiée (pas de caractères spécifiques, sinon ça plante). Le script va se charger de trouver les informations de déploiements, CLoud Services et roles.

################################
# Création d'une alerte Azure
# VM Cible à surveiller
$AzureVM_Name = 'SRV012ABCD'
$AzureVM_SimplifiedName = 'DC Paris'
# Variables de la machine virtuelle
$AzureVM_ServiceName = (Get-AzureVM | Where-Object {$_.Name -eq $AzureVMTarget}).ServiceName
$AzureVM_DeployName = (Get-AzureDeployment -ServiceName $AzureVM_ServiceName).Name
$AzureVM_RoleName = (Get-AzureDeployment -ServiceName $AzureVM_ServiceName).RoleInstanceList.RoleName


Et là on va enfin indiquer les variables de l’alerte. Dans cet exemple, je prends la surveillance réseau d’une VM

# Variables de l'alerte
$AzureAlert_Enabled = 'true'
$AzureAlert_Name = "Alerte VM Network $AzureVM_SimplifiedName"
$AzureAlert_Description = "Plus de reseau pour la VM $AzureVM_SimplifiedName"
$AzureAlert_Mail = 'helpdesk@3sr.fr'
$AzureAlert_MetricName = 'Network Out' # --> 'Percentage CPU','Disk Read Bytes/Sec','Disk Write Bytes/Sec','Network In','Network Out'
$AzureAlert_MetricSize = 'PT5M' # --> PT5M,PT15M,PT30M,PT45M,PT60M
$AzureAlert_MetricOperator = 'LessThanOrEqual'  # 'GreaterThan','GreaterThanOrEqual','LessThan','LessThanOrEqual'
$AzureAlert_MetricThreshold = '0.0'

Bien entendu, il faut créer une requête JSON avec tous les éléments en variables, que l’on encode en UTF8

# Création du GUID de l'alerte
$AzureAlert_GUID = ([GUID]::NewGuid()).Guid
$AzureAlert_ManagementUri = "
https://management.core.windows.net/$Azure_SubscriptionId/services/monitoring/alertrules/$AzureAlert_GUID"

# Création de la requete JSON
$JSONRequest_Header = @{
    "x-ms-version" = "2013-10-01";
    "Accept" = "application/json"
}
$JSONRequest_contentType = "application/json;charset=utf-8"
$JSONRequest_Body = @"
{
    "Id":  "$AzureAlert_GUID",
    "Name":  "$AzureAlert_Name",
    "Description":  "$AzureAlert_Description",
    "IsEnabled":  $AzureAlert_Enabled,
    "Condition":  {
                      "odata.type":  "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.ThresholdRuleCondition",
                      "DataSource":  {
                                          "odata.type":  "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleMetricDataSource",
                                          "ResourceId":  "/hostedservices/$AzureVM_ServiceName/deployments/$AzureVM_DeployName/roles/$AzureVM_RoleName",
                                         "MetricNamespace":  "",
                                         "MetricName":  "$AzureAlert_MetricName"
                                     },
                      "Operator":  "$AzureAlert_MetricOperator",
                      "Threshold":  $AzureAlert_MetricThreshold,
                      "WindowSize":  "$AzureAlert_MetricSize"
                  },
    "Actions":  [
                    {
                        "odata.type":  "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleEmailAction",
                         "CustomEmails":  "$AzureAlert_Mail"
                     }
                ]
}
"@

$JSONRequest_BodyUTF = ([System.Text.Encoding]::UTF8.GetBytes($JSONRequest_Body))

<<<==== Et on balance la sauce ====>>>

Invoke-RestMethod -Method Put -Uri $AzureAlert_ManagementUri -Certificate $Azure_SubscriptionCertificate -Headers $JSONRequest_Header -ContentType $JSONRequest_contentType -Body $JSONRequest_BodyUTF

 

Maintenant, à remettre dans votre contexte (boucle, fonctions, etc…) afin de répondre à votre besoin. Il est bien sûr possible de lister toutes les alertes actuelles. C’est d’ailleurs en récupérant une alerte manuelle avec des paramètres spécifiques, que vous pourrez comprendre la construction exacte du JSON attendue si vous souhaitez accéder à d’autres paramètres que je n’ai pas utilisé dans mon exemple

# Liste les alertes actuelles
$AzureAlert_ManagementUri_All = "
https://management.core.windows.net/$Azure_SubscriptionId/services/monitoring/alertrules"
$AzureAlert_Get = Invoke-RestMethod -Method Get -Uri $AzureAlert_ManagementUri_All -Certificate $Azure_SubscriptionCertificate -Headers $JSONRequest_Header -ContentType $JSONRequest_contentType
$AzureAlert_Get.Value | ConvertTo-Json

Voir même, en supprimer !

# Supprimer une alerte
$Azure_GetAlertID = ($AzureAlert_Get.Value | Where-Object {$_.Name -eq 'Nom de l alerte'}).Id
$AzureAlert_ManagementUri_Alert = "
https://management.core.windows.net/$Azure_SubscriptionId/services/monitoring/alertrules/$Azure_GetAlertID"
Invoke-RestMethod -Method Delete -Uri $AzureAlert_ManagementUri_Alert -Certificate $Azure_SubscriptionCertificate -Headers $JSONRequest_Header -ContentType $JSONRequest_contentType

Vous n’allez pas finir d’aimer POwerShell .. et Azure :=)

mai 07
Comment transférer tout le contenu d’une boite aux lettres Office 365 vers une autre messagerie sans Outlook ! Alors en PowerShell en REST API !

En tant qu’administrateur Office 365, ou encore consultant en SSII, vous avez très certainement du mettre en œuvre des transferts de messagerie d’une boite vers une autre pour des raisons bien spécifiques à l’entreprise. Nativement, un administrateur Office 365 peut configurer ces paramètres, comme l’explique Microsoft sur son site : https://support.office.com/en-au/article/Forward-email-to-another-email-account-1ed4ee1e-74f8-4f53-a174-86b748ff6a0e

Mais que se passe-t-il si cette option est activée après la réception de mails ? Alors la réponse la plus connue à ce jour, consiste à utiliser un client Outlook en empruntant l’identité de la boite aux lettres concernée, de créer une règles de transfert et l’exécuter maintenant. Cela oblige à installer un nouveau profil Outlook néanmoins, à synchroniser, etc… Et si on utilisait plutôt Outlook Web Access ? Oui en effet, on peut créer des règles mais on ne peut pas exécuter une règle sur les messages existants à ce jour. Et de toutes manières, si en plus je dois faire ça pour de nombreuses boites aux lettres ? Bref … C’est peut-être pour ça que vous atterrissez sur mon article !

Alors en premier lieu on pense à PowerShell, en effet mais les CmdLet natives Office 365 ne permettent cette option. Alors on va directement utiliser la REST API d’Office 365 pour y construire des requêtes JSON afin de répondre à notre besoin. Je me suis appuyé sur la documentation en ligne https://msdn.microsoft.com/office/office365/APi/mail-rest-operations

Dans le script décrit ci-dessous, j’ai d’abord créer un dossier “ForwardOK” dans la boite aux lettres. Cela permettra, après chaque transfert de déplacer le message dans le dossier concerné. Nativement, il est renvoyé uniquement 10 messages. En variables je propose ici d’y aller à coup de 30 messages et d’exécuter à nouveau la partie concernée pour 30 messages de plus. Je vous déconseille de tenter des valeurs au delà de 500. Il suffit juste donc de rejouer à plusieurs reprises les deux dernières parties du script ci-dessous.

Bien entendu, dans la première partie il faudra renseigner les informations de la boites aux lettre concernée, ainsi que l’adresse de destination cible pour laquelle tous les messages seront transférés.

 

# Variables
$mailbox_Identity  = 'alexandre.giraud@3sr.fr'
$Forward_Mailbox_Name = 'Nom cible'
$Forward_Mailbox_Mail = 'targetemail@outlook.fr'
$Folder_Dest = "ForwardOK"

# API et authentification
$Rest_API = 'https://outlook.office365.com/api/v1.0/me'
$mailbox_cred = Get-Credential -Message "Mot de passe pour la boite $mailbox_Identity" -UserName $mailbox_Identity

# Get de l'ID du dossier de destination
$Uri_Folder = "$Rest_API/Folders"
$GetFolders = Invoke-RestMethod -Uri $Uri_Folder -Credential $mailbox_cred
$GetFolderId = ($GetFolders.value | Where-Object {$_.DisplayName -eq $Folder_Dest} | Select -First 1).Id

# Construction des requêtes JSON
$contentType = "application/json"
$Body_Forward = "
  {
  ""Comment"": ""Transfert mail THERAVECTYS"",
  ""ToRecipients"": [
    {
      ""EmailAddress"": { ""Name"": ""$Forward_Mailbox_Name"", ""Address"": ""$Forward_Mailbox_Mail"" }
    }
  ]
}
"
$Body_Move = "
  {
  ""DestinationId"": ""$GetFolderId""
}
"

# Get de tous les mails de la Inbox
$limit_messages = 30
$Uri_Messages = "$Rest_API/folders/Inbox/messages?`$top=$limit_messages"
$GetMail = Invoke-RestMethod -Uri $Uri_Messages -Credential $mailbox_cred
$GetMail.value | Select Subject


# Pour chaque email, on recupérer le Message ID pour le forwarder et le déplacer dans un autre dossier
$GetMail.value | foreach-object{
    # Get du Message ID
    $Message_Id = $_.id
    # Construction des Uri
     $Forward_MessagePost = "$Rest_API/messages/$Message_Id/forward"
    $Move_MessagePost = "$Rest_API/messages/$Message_Id/move"
    # Forward et move du mail
    Invoke-RestMethod -Uri $Forward_MessagePost -Method POST -ContentType $contentType -Credential $mailbox_cred -Body $Body_Forward
    Invoke-RestMethod -Uri $Move_MessagePost -Method POST -ContentType $contentType -Credential $mailbox_cred -Body $Body_Move   
}

mai 04
Problème de la fonction Password Writeback depuis le 30 avril, une correction est disponible

Si vous avez activé la fonction Password Writeback avec Azure Active Directory, vous avez peut-être remarqué récemment des problèmes.. et ce depuis le 30 avril ! Le problème a été identité par les équipes produits et une correction est à présent disponible.

Les utilisateurs connus, ont du recevoir un émail de la part de Microsoft pour indiquer le problème. Le message est comme celui indiqué ci-dessous.

clip_image001

 

En fait, Microsoft s’excuse de la gêne occasionnée au sujet du problème qui a été reconnu, mais propose une solution. La solution consiste à mettre à jour le client Azure AD Sync, en téléchargeant la version 1.0.0494.050 depuis le site Microsoft http://www.microsoft.com/en-us/download/details.aspx?id=44225. Il est donc conseillé vivement d’appliquer cette mise à jour.
clip_image003

Après avoir téléchargé la mise à jour, vous pouvez l’exécuter en tant qu’administrateur. La version précédente est détectée, et un menu de mise à jour vous est proposé.
clip_image005

Il faut patienter …. comme d’hab !
clip_image007

Ensuite, il faudra suivre l’assistant afin de confirmer vos paramètres et attendre la fin pour finaliser avec une synchronisation.
clip_image009

A présent, la fonction de Password Writeback devrait être à nouveau fonctionnelle !

avr. 18
Comment modifier la réplication de Sysvol, de NTFRS à DFSR

 

Si vous avez installé un domaine Active Directory directement à partir de Windows 2008, ceci ne vous concerne pas. Si cependant l’historique de votre domaine a été initié avec Windows 2003 et même voir Windows 2000, alors cet article pourrait vous intéresser ;)

Tout d’abord en rappel simplifié, les contrôleurs de domaine synchronisent un dossier Sysvol et il se doit d’être identique sur l’ensemble des DC. Initialement, Microsoft avait utilisé comme moteur de réplication NTFRS. Lorsque Windows 2003 R2 est sorti, un nouveau moteur de réplication est apparu. Il s’agit de DFS-R qui permettait essentiellement de faire des synchro en RDC (Remote Differential Compression). Grâce à ce dernier, uniquement les différences étaient synchronisées. Enfin, depuis Windows 2008 il est possible d’utiliser ce moteur pour la réplication de Sysvol, ce qui est d’ailleurs par défaut depuis.

Alors voilà pour la partie introduction, mais donc à ce jour utilisez-vous bien DFS-R ? Et pourquoi j’utiliserai DFS-R si ma réplication de mon domaine fonctionne très bien en FRS aujourd’hui … Tout d’abord, FRS n’évoluera plus côté Microsoft et est donc désormais obsolète. Toutes les nouveautés et améliorations sont sur DFS-R uniquement. Par ailleurs, cela limite les risques de désycnhro car le moteur est plus fiable et consomme beaucoup moins de bande passante… Donc, il n’y a plus qu’a !

Avant de se lancer dans cette opération, il faut s’assurer que :

  • Que vous n’êtes pas déjà en réplication DFS-R !
  • Tous les contrôleurs de domaine sont au moins en Windows 2008 minimum
  • Le niveau fonctionnel de la forêt/domaine est en Windows 2008
  • La réplication est actuellement fonctionnel (vérifiez avec repadmin)
  • Qu’il n’y a pas de dysfonctionnement dans votre AD
  • et que TOUS les contrôleurs de domaine doivent être en ligne

Si vous remplissez tous ces critères, alors Let’s go ! La procédure que je vais décrire se base sur l’article de Microsoft TechNet https://technet.microsoft.com/fr-fr/library/dd640019(v=ws.10).aspx. L’opération consiste à passer plusieurs différentes étapes, afin de permettre la migration progressive. Un outil intégré (dfsrmig) est déjà disponible et permettra de passer les 3 étapes de migration. Il faudra être patient dans certains cas, notamment en cas de présence de nombreux sites Active Directory et une faible latence. Voilà les différentes étapes.

clip_image002

Alors dans un premier temps, on va passer l’état au mode 1 (Prepared) avec la commande « dfsrmig /setglobalstate 1 ».
clip_image003

Avec la commande « dfsrmig /getmigrationstate » il est possible de voir l’état d’avancement de la migration. Tant que la commande indique que des serveurs sont en cours, il ne faut surtout pas aller à l’étape suivante.
clip_image005

Et si vous avez ce message, alors on peut passer à l’étape suivante
clip_image006

Alors si tout est ok, passons à l’étape 2 (Redirected) avec la commande « dfsrmig /setglobalstate 2 ».
clip_image007

Et comme pour la première étape, on vérifie l’état de migration avec la commande « dfsrmig /getmigrationstate » jusqu’à que cela soit indiqué que tout est cohérent.
clip_image008

Et donc passons à la 3ème étape pour la migration finale, et donc passer en statut « eliminated » avec la commande « dfsrmig /setglobalstate 3 ».
clip_image009

Et sans surprise, on peut vérifier l’état de migration toujours avec la commande « dfsrmig /getmigrationstate »
clip_image010

Parfait, maintenant, le contenu Syvol est synchronisé désormais avec DFS-R ! Donc en étape ultime, comme le moteur FRS n’est plus nécessaire, on va le désactiver. Et quoi de mieux de le faire avec PowerShell. Un petit script pour récupérer tous les DC, et arrêter le service puis le mettre en désactivé.

$allDCs = (Get-ADForest).Domains | %{ Get-ADDomainController -Filter * -Server $_ }
foreach ($DC in $allDCs){
Get-Service -ComputerName $DC -Name NtFrs | Stop-Service
Get-Service -ComputerName $DC -Name NtFrs | Set-Service -StartupType Disabled
}

Et même la commande pour vérifier l’état du service, pour s’assurer que le script est correctement passé.

$allDCs = (Get-ADForest).Domains | %{ Get-ADDomainController -Filter * -Server $_ }
foreach ($DC in $allDCs){
Get-Service -ComputerName $DC -Name NtFrs | ft -Property MachineName,Name,Status
$StartupMode = (Get-WmiObject -ComputerName $DC -Class Win32_Service -Property StartMode –Filter  Name='NtFrs'").StartMode
Write-Host 'Service NTFRS startup Mode is' $StartupMode
}

mars 31
Azure AD Connect Preview 2

Une nouvelle version Azure AD Connect est disponible, la version Preview 2.

De nouvelles fonctionnalités sont disponibles, notamment :

  • La mise à jour depuis DIrSync
  • Filtrage à l’aide de groupes AD
  • La prise en charge d’un système de fédération déjà présent
  • et de nouvelles options de synchronisation et tâches

image

Pour plus d’infos, se rendre sur le blog de l’équipe produit : http://blogs.technet.com/b/ad/archive/2015/03/24/azure-ad-connect-preview-2-is-available.aspx

Cette nouvelle version se télécharge sur http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=53949

mars 25
Altaro Hyper-V Backup, présentation et description de l’installation

clip_image001

Aujourd’hui nous avons vraiment de plus en plus de systèmes virtuels dans les entreprises, une technologie qui désormais bien répandue et notamment avec Microsoft Hyper-V. Je suis confronté régulièrement lors de mes prestations sur Hyper-V, de mettre en place des sauvegardes. Bien entendu, il est possible avec les outils intégrés de Windows Server et un peu de PowerShell d’effectuer des sauvegardes ; Mais la gestion devient vite pénible et notamment dans les environnements Cluster avec des volumes CSV.

Il existe de nombreuses solutions, mais il y a une d’entre elles qui est tout simplement étonnante et qui plus est l’une des moins chères du marché ! Je vais à travers cet article vous démontrer la solution Altaro Hyper-V Backup. La solution est aussi simple que complète, et permet une mise en place très rapide (quelques minutes) sans redémarrages.

Il existe trois versions :

  • Une version Free Edition, gratuite et limité à 2VM
  • Une version Standard Edition qui se limite à 5VM par hôte Hyper-V
  • Et une version Unlimited Edition qui contient toutes les fonctionnalités et n’est pas limité au nombre de machines virtuelles.

Free Edition

Standard Edition

Unlimited Edition

Number of Virtual Machines that can be backed up and restored per host

2 VMs

5 VMs

Unlimited VMs

MS Hyper-V Cluster Support (CSV Support)

clip_image003

clip_image003[1]

clip_image005

Exchange Item Level Restore

Restore individual items from backed up VMs

clip_image003[2]

clip_image003[3]

clip_image005[1]

Remote & Central Management Console

clip_image006

clip_image007

clip_image007[1]

Hot/Live Backups

Back up running VMs without having to stop them

clip_image007[2]

clip_image007[3]

clip_image007[4]

Fast & Small Backups - Compression

clip_image007[5]

clip_image007[6]

clip_image007[7]

Offsite Backups over WAN/Internet Connection (WAN Acceleration)

clip_image006[1]

clip_image007[8]

clip_image007[9]

Military Grade (AES) Encryption of Backups

clip_image006[2]

clip_image007[10]

clip_image007[11]

ReverseDelta Incremental Backup Technology

clip_image007[12]

clip_image007[13]

clip_image007[14]

File Level Restore

clip_image006[3]

clip_image007[15]

clip_image007[16]

Restore Clone

Can restore VMs to the same Hyper-V Host but with a different name i.e. does not overwrite existing VM.

clip_image007[17]

clip_image007[18]

clip_image007[19]

Restore VMs to a different Hyper-V host

clip_image006[4]

clip_image007[20]

clip_image007[21]

Sandbox Restore

Build and test a recovery plan to ensure you're covered in case of a disaster.

clip_image006[5]

clip_image007[22]

clip_image007[23]

Community Forum Support

clip_image007[24]

clip_image007[25]

clip_image007[26]

Priority Technical Support

clip_image006[6]

clip_image007[27]

clip_image007[28]

Pour plus d’informations, vous pouvez vous rendre sur le site de l’éditeur à cette adresse : http://www.altaro.com/hyper-v-backup ou encore sur leur blog : http://www.altaro.com/hyper-v

Prérequis :

Avant de se lancer dans l’installation en mode, il faut bien vérifier que les hyperviseurs sont au moins en Windows 2008 R2, Windows 2012 et Windows 2012 R2 (versions core incluses). Néanmoins il sera possible d’installer des consoles de gestions sur des postes Windows 7 et Windows 8 x64. De plus les composants .Net Framework seront nécessaires sur les serveurs, à savoir la version 3.5 pour 2008 R2 et 4.0 pour 2012 et plus.

Enfin, au niveau des paramètres des machines virtuelles il faut s’assurer que les clichés instantanés sont activés au niveau des services d’intégration, comme le montre l’impression écran ci-dessous.
clip_image009

Deux liens intéressant à consulter sur le site de l’éditeur, pour comprendre les prérequis :

· les prérequis : http://support.altaro.com/customer/portal/articles/808716-what-are-the-system-requirements-for-altaro-hyper-v-backup-

· Note concernant VSS : http://support.altaro.com/customer/portal/articles/808575-what-are-the-requirements-for-live-backups-of-a-hyper-v-guest-vm-

Téléchargement :

La solution peut être téléchargée directement depuis le site, et permet d’avoir accès à 30 jours d’évaluation avec toutes les fonctionnalités. C’est cette même version qu’il faudra télécharger lorsqu’il y a une acquisition de licence, donc il n’y a aucun problème à installer cette version d’évaluation : http://www.altaro.com/hyper-v-backup/download-versions.php

Remplissez le formulaire, et vous recevrez votre version d’évaluation immédiatement.
clip_image011

Installation de la solution :

La solution est très compliquée à installer, vous allez voir !!! La longueur de l’article est surtout liée aux impressions écrans ! L’installation ici concerne un serveur Hyper-V Windows 2012 R2 Standalone, mais la procédure initiale est identique sur un environnement de type Cluster Hyper-V. Il suffit donc de copier localement le fichier de setup précédemment téléchargé, puis de l’exécuter.

clip_image013
Cliquez sur Next
clip_image015
Il faut lire le contrat de licence, l’accepter et cliquez sur Next.

clip_image017 Sélectionnez un dossier d’installation ou laissez celui par défaut, et cliquez sur Next encore.
clip_image019 
Et enfin sur Install.
clip_image021

Veuillez patienter … disons 40s environ !
clip_image023
Et voilà pour l’agent, vous pouvez cliquer sur Finish.
clip_image025
L’installation du composant serveur sera lancée automatiquement ensuite, cliquez sur Install.
clip_image027
Et encore Finish.

Il s’est à peu près écoulé 2mn et l’installation des binaires est terminé, le téléchargement a du pu prendre plus de temps surement.

Notez, qu’il est n’est pas nécessaire de redémarrer l’hyperviseur ! Et comme il n’y a pas d’agent à déployer sur les VM invités, alors la solution est déjà prête à l’emploi !

Configuration de la solution en 3 étapes, voir même seulement 2 dans certains cas :

La solution étant à présent installée, nous allons effectuer une configuration initiale afin de mettre en place les espaces de stockage des sauvegardes, les planifications, les paramètres, … Tout d’abord, on se connecte à la console de gestion
clip_image029

Nous arrivons sur un tableau de bord avec des étapes simplifiées, 3 seulement. Dans le cas d’un environnement Cluster, il faudra déployer les agents Altaro Hyper-V Backup sur l’ensemble des nœuds de la ferme. C’est une action qui se fait directement depuis ce tableau, et en mode installation distante silencieuse. Ainsi, étant donné que la première étape est terminée, il suffit d’indiquer où devront se situer les sauvegardes avec l’étape 2.

clip_image031

Concernant les destinations de sauvegardes, il y a plusieurs choix possibles. Cela peut être des disques locaux USB, iSCSI, … et réseaux comme un NAS, un partage réseau, …
clip_image033

Dans l’exemple ici, je prends un disque local à l’aide d’un volume iSCSI. J’ai donc juste à sélectionner la lettre de lecteur concernée
clip_image035

Après analyse du disque, il vous sera indiqué si la destination est seine et l’espace disque disponible.
clip_image037

Et c’est là où va commencer toute la mécanique simplifiée de la solution, qui est plus fonctionne très bien avec un écran tactile ! Il suffit juste de cliquer-glisser les machines virtuelles souhaitées, pour les assigner à un emplacement de sauvegarde !
clip_image039

Etape suivante ? Oui, il faut prendre une sauvegarde initiale bien entendu.
clip_image041

On sélectionne l’ensemble des machines virtuelles souhaitées, et juste Take Backup.
clip_image043

Dans la zone de notifications, il sera possible de suivre l’état d’avancement des opérations de sauvegarde.
clip_image045

Et magie ? Non, efficace ! Toutes les VM ont à présents effectuées une sauvegarde initiale. D’ailleurs, il est à noter les performances de sauvegarde (dans mon cas à travers un réseau en iSCSI). La majorité des machines virtuelles sont entre 15 et 35Gb, et la sauvegarde intégrale a pris entre 6 et 15mn chaque VM.
clip_image047

Voilà, c’est donc avec en moyenne un temps de configuration entre 5mn et 10mn qui a suffi pour configurer la solution et être prêt pour les sauvegardes de machines virtuelles.

Planification et rétention ?

Nous sommes pour l’instant à des paramètres par défaut, il est possible de configurer des planifications de sauvegarde spécifiques (quotidiennes, hebdomadaires, ..). Comme cela a été montré précédemment, il suffira d’assigner les machines virtuelles à l’aide d’un cliquer-glisser, à la planification associée.
clip_image049

Toujours avec cette méthode, il sera possible de définir des stratégies de rétention.
clip_image051

Installation de la clé de licence ?

Votre période d’évaluation saura très rapidement vous satisfaire forcément, donc il suffira de vous acquitter d’une licence. Il est possible de me contacter pour obtenir une licence.
Après réception de la licence, le fichier PDF qui l’accompagne contiendra une clé. Il suffit de copier la valeur de la clé de licence dans votre presse papier.
clip_image053

Et une fois connecté à la console de gestion Altaro Hyper-V, il suffit de se rendre les paramètres de l’hôte.
Cliquez ainsi sur le message orange indiquant la version d’évaluation.
clip_image055

Puis renseignez la clé de produit, précédemment copié dans le presse-papier.
clip_image057

A présent, vous verrez que la licence est indiquée comme valide ! En cas d’utilisation de Failover Cluster, il sera possible de voir l’ensemble de tous les hôtes et de renseigner la clé sur tous les nœuds du Cluster depuis cette même console, sans se connecter sur chaque serveur.
clip_image059

Quelques exemples de restauration ?

Jusqu’à maintenant nous avons étudié les différentes options de sauvegarde, ce qui est tout à fait normal pour une solution de sauvegarde me diriez-vous ! Mais bien que je ne vous le souhaite pas, souvent la restauration est une opération qui doit être effectuée en urgence suite à un crash serveur, perte de disque, etc… Une opération que de bons nombres d’administrateurs redoutent ! Donc bien entendu, Altaro va permettre de faire des restaurations des machines virtuelles mais pas seulement. Avec Altaro Hyper-V Backup, les administrateurs auront la possibilité de restaurer une machine virtuelle, explorer les fichiers de sauvegarde pour restaurer un fichier précis et même restaurer des éléments de messagerie Exchange ! Enfin, il est même possible de faire des tests de restauration à l’aide de la fonction Sandbox et de vérifier l’intégrité des sauvegardes.

Concernant la restauration des machines virtuelles, il est possible de restaurer la VM directement sur celle d’origine (en écrasant la précédente) ou encore d’en restaurer sur une machine clone afin de pouvoir conserver les deux en même temps. Il sera même possible à l’administrateur d’effectuer la restauration sur un hôte Hyper-V différent.
clip_image061

Comme expliqué plus haut, il est même possible de parcourir les versions de sauvegarde afin de permettre des restaurations de fichiers (ou dossiers) sans devoir restaurer une machine virtuelle intégrale.
clip_image063

Je n’ai pas pu tester la fonctionnalité de restauration Exchange, car je dispose que d’une version de messagerie full Office 365. Mais si vous souhaitez plus d’informations vous pouvez consulter cet article : Altaro Exchange Item Level Restore

Pour aller encore plus loin …

Il y a encore de très nombreuses options avancées, et oui un outil simple à installer mais avec tout de même de très nombreuses fonctionnalités. Cependant, j’aborderais d’autres sujets ultérieurement dans ce blog notamment la possibilité d’avoir une copie hors-site des sauvegardes sur Microsoft Azure !

clip_image065
Si vous souhaitez de plus amples informations sur la solution de sauvegarde Hyper-V avec Altaro, sachez que 3SR est une entreprise certifiée Altaro. 3SR peut vous accompagner dans vos projets de sauvegarde Microsoft Hyper-V et vous fournir les licences. N’hésitez pas à me contacter en consultant mes coordonnées sur www.3sr.fr.

Plus d’informations sur Altaro :

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
1 - 10Suivante
MVP Forefront

 ‭(Masqué)‬ Liens d'administration