Hello Everyone,

Si vous souhaitez découvrir les Datacenters Azure de plus près et en savoir plus sur les différentes couches logicielles et matérielles qui les composent, incluant le « Compute /Storage /Network », je vous invite donc à consulter cette présentation.

Très bonne PPT, par le grand Mark Russinivoch, CTO MS Azure Corp.

Bonne lecture à tous.

HK o__O.

Publicités

Hello Azure Guys,

Great News 🙂

Azure Availability Zones est désormais disponibles (in Public Preview pour l’instant) sur les deux Régions Azure suivantes :

  • États-Unis de l’Est 2 (US Est 2)
  • Europe de l’Ouest (West Europe)
Pourquoi  « ‘Azure Availability Zone » ?

Azure Availability Zones (ou Zones de Disponibilités Azure) vous permet de protéger vos ressources Cloud en cas de perte d’un Datacenter Azure en entier.

En effet, ces Zones (Datacenters) sont situés au niveau d’une même Région Azure et fonctionnent de manière indépendante (Alimentation électrique, climatisation, réseau…). Pour assurer une résilience, il existe au moins trois zones (3 Datacenters) distinctes dans toutes les régions supportant l’Availability Zones.

La séparation physique et logique des zones dans une région protège vos données et ressources Cloud en cas de problème ou défaillance sur un Datacenter.

Azure Availability Zones & Services Cloud pris en charge

Au moment de l’écrire du présent post, seuls les services Azure suivants prennent en charge l’Azure Availability Zones :

  • Linux Virtual Machines
  • Windows Virtual Machines
  • Zonal Virtual Machine Scale Sets
  • Managed Disks
  • Load Balancer
Azure Availability Zones & Familles de VMs Azure pris en charge

Seules les séries de VMs Azure suivantes prennent en charge l’Azure Availability Zones :

  • Av2
  • Dv2
  • DSv2

 

HowTo : Activer Azure Availability Zones sur votre abonnement (Subscription) Azure

Tout d’abord, vous devez « Sign-up » ici  : comme mentionné précédemment, Azure Availability Zones est en mode « Preview » pour l’instant

Connectez-vous ensuite à votre abonnement et activer A-A-Z

 

Useful Links

Je vous invite à consulter les liens ci-après pour en savoir plus :

https://docs.microsoft.com/en-us/azure/availability-zones/az-overview

https://azure.microsoft.com/en-us/updates/azure-availability-zones/


Ce post a été updaté le 16/10/2017


 

Hello tout le monde,

Si vous souhaitez récupérer (exporter) toute la structure de vos OUs, présentes sur un environnement AD spécifique et la migrer vers un nouvel environnement avec un nouveau domaine AD, cet article est fait pour vous :).

Un de mes clients a simplement souhaité récupérer la structure complètes des OUs et leur sous-OU ainsi que les groupes et m’a fait part de ce besoin récemment.

J’ai donc décidé de partager la technique permettant de réaliser cette opération avec vous :).

Alors comment ça marche ?!

D’abord, quels outils utilisés o__O ?

The best of the Best pour ce type d’opération reste le Wonderful CLI : LDIFDE.exe

Cet outil en ligne de commande est natif dans les OS Windows Server 2012 /2012 R2 et ultérieur.

HowTo ?
La structure d’OUs « Source »

Mon environnement /domaine AD source (hkvlab.lan) présente la structure d’OUs suivante :

 

Pour exporter toute la structure /arborescence d’OUs, la commande suivante est exécutée depuis une invite de commande (CMD.exe), lancée en tant qu’Administrateur :

ldifde -f c:\All_OUs.ldf -r “(objectClass=organizationalUnit)” -l objectClass,description

Note important : avant d’importer le fichier ldf « All_OUs.ldf », vous devez d’abord l’éditer et remplacer l’ancien DN du domaine par le nouveau.

To Do : Notez que dans le fichier All_OUs.ldf exporté, une entrée pour l’OU par défaut « Domain Controllers » existe. Celle-ci doit être supprimée du fichier car l’OU « Domain Controllers » existe déjà sur votre domaine de destination. Si vous ne supprimez pas le bloc de texte illustré dans l’image ci-dessous, la procédure d’import échouera !

Dans l’exemple suivant, le D(istinguished) N(ame) de mon ancien domaine est le suivant : DC=hkvlab,dc=lan

Le DN du nouveau domaine est : DC=hknewvlab,dc=lan

Une fois modifié, mon fichier ldf ressemble à l’image ci-après :

Enfin, ouvrez une Session sur un DC du nouveau Domaine (Domain de destination) ou une machine d’administration ayant les outils RSAT AD DS installés, copiez /collez le fichier ldf précédemment modifié avec le DN du nouveau domaine, et saisissez la commande suivante pour importer correctement votre structure d’OUs :

ldifde -i -f c:\All_OUs.ldf

Comme vous pouvez le constater, 27 entrées ont été modifiées suite à l’import via le fichier All_OUs.ldf, il s’agit des 27 OUs et sous-OUs importées.

Vous pouvez le vérifier en lancant la console DSA.msc depuis votre DC appartenant au nouveau domaine AD et visualiser la structure d’OUs :

N’hésitez pas à vous abonner pour être informé pour toute nouvelle publication sur mon Blog.

HK o____O

 

GPO Guys, Hello Again :),

Dans le cadre d’un projet de migration vers Windows Server 2016, une task intéressante faisant partie du plan de migration consistait à convertir toutes les GPOs locales de certains serveurs (en mode WorkGroup) placés en DMZ vers des GPOs de domaine A(ctive) D(irectory).

J’aimerais donc partager avec vous à travers cet article la méthode /outils utilisé pour réaliser cette action, qui n’est malheureusement pas décrite dans les K(nowledge) B(ase) de MS.

Alors comment ça marche ?

Tout d’abord, vous devez faire le listing de toutes les machines ayant des GPOs locales, à transformer en GPOs de domaine.

Téléchargez ensuite l’outil LGPO.exe et placez-le sur toutes les machines Windows ayant des GPOs Locale à récupérer.

LGPO.exe est un outil en ligne de commande très puissant qui vous permet d’accélérer la gestion de vos stratégies de groupes locales (LGPO : Local Group Policy Objects).

Actuellement disponible en V2.0, LGPO.exe prend désormais en charge les MLGPO (Multiple Local Group Policy Objects) ainsi que les valeurs de Registre REG_QWORD 64-bit.

LGPO.exe fait partie du package « Microsoft Security Compliance Toolkit 1.0« .

 

Vous pouvez le télécharger gratuitement ici.

HowTo : Transformer une GPO locale >> GPO de domaine

Dans l’exemple suivant, nous allons convertir une GPO locale, configurée sur un de mes serveurs d’administration et la transformer /migrer vers un domaine Active Directory.

Je vais commencer par placer (via un Copy/Paste) l’outil LGPO.exe sur mon serveur d’administration (l’outil sera placé dans le dossier C:\GPOTools) et je lancerai ensuite l’Invite de Commande (CMD.exe) en tant qu’Administrateur.

Enfin, la commande suivante est exécutée pour faire un Backup de la GPO locale :

LGPO.exe /b C:\LocalGPOs_Backup /n MyLocalGPO

Maintenant que le Package de GPO Locale est généré, lancez l’outil GPMC.msc depuis un Domain Controller ou une machine d’administration ayant les outils RSAT installés et suivez les instructions suivantes :

  • Copiez /Collez le Package de GPO généré précédemment sur votre DC ou Machine d’Administration
  • Faites un clic-droit sur le noeud « Group Policy Objects » (ou Objets de stratégie de groupe si votre OS Server est en FR) et sélectionnez « Import Settings…« 

  • L’assistant d’importation de paramètres GP apparaît, cliquez sur « Next /Suivant » pour continuer
  • Spécifiez l’emplacement de la sauvegarde GPO locale créée précédemment :

  • Vérifiez les informations concernant votre GPO locale et cliquez sur « Next /Suivant » :

  • Une fois les paramètres importés, cliquez sur « Finish » pour lancer /confirmer le processus d’importation au niveau de la GPO de domaine

  • L’assistant vous affiche le statut post-importation des paramètres : Succeeded si l’opération s’est bien déroulée 🙂 :

  • Enfin, vérifiez que les paramètres de votre GPO locale sont bien présents au niveau de la GPO de domaine :

Et voilà le tour est joué :).

HK.

 

Hello GPO Guys,

Une « Trick » sur les GPOs qui peut vous être utile si vous faites régulièrement des audits GPOs.

J’ai récemment audité une infrastructure système « Windows Server 2012 R2 /2016 » assez complexe avec un peu plus de 1000 GPOs implémentées.

La phase /Step 1 de mon audit GPO était de lister et supprimer (après validati/on du client) toutes les GPOs vides, le but étant de réduire rapidement le nombre de GPOs de domaine « inutiles » (MAIS qui sont quand même répliquées dans tous les sens, lors de la réplica AD ^-^).

Alors comment ça marche ?

Lancez PowerShell ISE depuis un D(omain) C(ontroller) ou une machine d’administration ayant les outils RSAT ADDS installés et Copiez /Collez le bloc de code PS suivant :


$GPOVides = Get-GPO -All
foreach ($item in $GPOVides)
{
if ($item.Computer.DSVersion -eq 0 -and $item.User.DSVersion -eq 0)
{
write-host $item.DisplayName est vide !
}
}


Dans l’exemple suivant, le script me retourne les GPOs listées ci-dessous :

Notez que ce script PS est disponible en téléchargement gratuit sur la Gallery TechNet.

Téléchargez-le ici.

A bientôt

HK T___T

Resource Manager « Locks », qu’est ce que c’est ?!

Le modèle de déploiement ARM (Azure Resource Manager) inclut une fonctionnalité qui va sûrement intéresser les IT en charge d’administrer et de sécuriser les services et ressources Azure : il s’agit de « Resource Manager Locks »

Ces verrous vous permettent de protéger vos ressources Azure jugées « Critiques » en mettant en place des règles de restrictions pour empêcher toute modification et/ou suppression accidentelle. Les Locks Resource Manager n’ont aucun rapport avec une hiérarchie RBAC (Role-Based Access Control) car une fois appliqués, ils positionnent des restrictions sur la ressource pour TOUS les utilisateurs. Cela devient très utile quand vous souhaitez protéger des « Ressources Azure Critiques » contre toute modification ou suppression, même accidentelle.

Notez qu’il existe deux niveaux de verrouillage, à savoir :

  • CanNotDelete : ce niveau empêche tous les utilisateurs de supprimer la(es) ressource(s) Azure sur la(es) quelle(s) le verrou est activé. Les ressources Azure restent en revanche accessibles en lecture et peuvent être modifiée à tout moment.
  • ReadOnly : ce niveau rend les ressources Azure accessibles en « Lecture seule » uniquement. Les utilisateurs ne peuvent donc ni modifier ni supprimer la(s) ressource(s) sur la(es) quelle(s) le verrou est activé. Appliquez ce niveau de verrouillage a le même effet /impact que d’attribuer le rôle « Lecteur » à vos utilisateurs, en effet, les mêmes autorisations accordées par le rôle « Lecteur » sont appliquées via le Lock « ReadOnly ».

Les « Locks » Resource Manager peuvent être appliqués aux :

  • Abonnements (Azure Subscriptions)
  • Groupes de Ressources (Azure Resources Group)
  • Ressources (Azure Resources)

Note importante : quand vous appliquez un verrou au niveau d’un abonnement, toutes les ressources placées dans cet abonnement (y compris celles que vous créerez plus tard) héritent le même niveau de verrouillage. De plus, et contrairement au RBAC, une fois appliqués, les Locks impactent tous les utilisateurs, quelque soit leur rôle. Donc, si la modification ou suppression d’une ressource (déjà Lockée) devient vraiment nécessaire, vous devrez d’abord supprimer le verrou associé à la ressource avant de la modifier ou la supprimer.


Les Permissions : ce que vous devez connaître !

Les permissions qui vous permettent de créer et supprimer les verrous nécessitent l’accès à l’une des permissions RBAC suivante :

  • Microsoft.Authorization/*
  • Microsoft.Authorization/locks/*

Par défaut, ces actions /permissions sont prédéfinies pour les rôles « Owner /Propriétaire » et « User Access Administrator /Administrateur de l’accès Utilisateur ». Si nécessaire, vous pouvez les ajouter à des rôles spécifiques /personnalisés.

 

Logs /Traçabilité 

Les opérations de « Création & Suppression » de verrous sont (par défaut) inscrites dans les Journaux d’Activité Azure (Azure Activité Logs).

Les utilisateurs qui tente de supprimer ou modifier une ressource ayant un « Lock » déjà en place recoivent le message d’erreur suivant :

Au niveau du New Azure Portal (portal.Azure.com) :

Au niveau de l’interface Azure CLI, l’Admin IT reçoit le message suivant :

The scope ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-dev-rg/providers/Microsoft.Storage/storageAccounts/hkcriticalstorage1’ cannot perform delete operation because following scope(s) are locked: ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c’. Please remove the lock and try again.

Même chose côté PowerShell, le message d’erreur suivant est retourné à l’Admin IT :

Remove-AzureRmResource : ScopeLocked : The scope ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-dev-rg/providers/Microsoft.Storage/storageAccounts/hkcriticalstorage1’
cannot perform delete operation because following scope(s) are locked: ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c’. Please remove the lock and try again.

 

HowTo : Créer vos « Verrous /Locks »

Les « Locks » Resource Manager peuvent être créés soit au moment de la création de la ressource (au niveau du Template ARM) ou ultérieurement via le nouveau portal Azure (portal.Azure.com), Windows PowerShell ou encore l’interface en ligne de commande (Az CLI 2.0).

Création des « Locks » lors de la création d’une Ressource

La création de Verrous lors de la configuration du Template ARM est le meilleur moyen de s’assurer que votre protection est bien place une fois vos ressources Azure créées /provisionnées.

Les Verrous sont des ressources ARM de « Haut Niveau », ils ne font pas partis de la configuration (sous-couche) des ressources Azure mais plutôt référence à la (aux) ressource(s) à verrouiller, celles-ci doivent donc d’abord exister pour pouvoir créer des « Locks ».

Dans l’exemple suivant, nous allons créer un compte de stockage nommé hkcriticalstorage1 et ensuite verrouiller cette ressource contre la suppression. Notez que le paramètre « Type » fait référence au type de ressource que vous voulez « Verrouiller ».

 

{
« type »: « Microsoft.Storage/storageAccounts »,
« name »: « hkcriticalstorage1 »,
« apiVersion »: « 2015-01-01 »,
« location »: « [resourceGroup().location] »,
« tags »: {
« displayName »: « hkcriticalstorage1 »
},
« properties »: {
« accountType »: « Standard_LRS »
}
},
{
« name »: « [concat(‘hkcriticalstorage1’, ‘/Microsoft.Authorization/criticalStorageLock’)] »,
« type »: « Microsoft.Storage/storageAccounts/providers/locks »,
« apiVersion »: « 2015-01-01 »,
« properties »: {
« level »: « CannotDelete »
}
}
]

 

Le niveau de verrouillage peut être défini à « ReadOnly » simplement en changeant la valeur du paramètre « Level » et la définissant à ReadOnly

Création des « Locks » via le Portail Azure

Comme expliqué précédemment, les verrous s’appliquent à différent niveau : abonnement, groupe de ressource ou encore à des ressources individuelles.

Pour ajouter un « Lock », il suffit de sélectionner l’objet sur lequel vous souhaitez l’appliquer, et cliquez (depuis le volet gauche) sur :

Verrous (ou Locks si votre portail Azure est en En« glish ») : s’il s’agit d’un Groupe de Ressources ou une Ressource individuelle

 

 

 

 

Verrous de ressources (ou Resource Locks si votre portail Azure est en En« glish ») : s’il s’agit d’un Abonnement Azure

 

 

 

 

 

 

Dans l’exemple suivant, nous allons ajouter un « Lock » au niveau de mon abonnement (Visual Studio Premium avec MSDN) en spécifiant les informations suivantes :

  • Nom du Verrou : hk-subscription-lock-del(etion)
  • Type de verrou : Supprimer
  • Remarques : Ce Verrou permet d’empêcher tout utilisateur de supprimer les ressources de l’abonnement Azure « VS Prem MSDN » de HK

Pour ce faire, il faut simplement cliquer sur « Verrous de ressources » > Ajouter > et spécifier ensuite les informations de configuration:

Pour confirmer que les ressources Azure hébergées au niveau de l’abonnement héritent bien ce « Lock » nouvellement créé, cliquez sur n’importe quelle ressource de l’abonnement et rendez-vous ensuite sur « Verrous » ou « Locks », constatez l’apparition du « Lock », précédemment créé :

Création des « Locks » via Windows PowerShell

Le code PS ci-après peut être utilisé pour ajouter un « Lock » à une ressource existante. Encore une fois, le type de ressource (paramètre ResourceType) dépend du type de la ressource que vous souhaitez verrouiller.

Pour supprimer le Verrou, vous devez utiliser la Cmd-let Remove-AzureRmResourceLock.

 

Création des « Locks » via Azure CLI 2.0

Note : si vous n’avez pas encore connecter votre Interface Azure CLI 2.0 à votre compte Azure, je vous invite à consultez cet article.

La commande qui vous permet de créer et gérer les « Verrous » est : Az Lock

Depuis l’interface CLI 2.0, saisissez Az Lock -h pour faire apparaître l’aide en ligne de cette commande :

Pour créer un « Lock » de type « ReadOnly » et l’appliquer au niveau de votre abonnement Azure, la commande suivante est utilisée :

az lock create –name criticalStorageLock –resource-group hk-criticalstorage-rg –lock-type ReadOnly

Je vous invite à consulter cet article très bien rédigé par l’équipe MS Azure pour en savoir plus sur toute la syntaxe et paramètre disponibles avec la commande Az Lock.

 

Ce qu’il faut retenir

Notez que les Locks permettent seulement la protection contre toute suppression ou modification accidentelle des ressources Azure « Critiques », ceux-ci ne permettent pas une restriction totale car les Admins Azure peuvent facilement supprimer les verrous et récupérer les droits de « Supprimer et/ou Modifier » les ressources Azure.

Perso, je considère les Locks comme une couche de protection supplémentaire des ressources Azure car, ils s’appliquent à TOUS les utilisateurs, quelque soit leur rôle (hiérarchie RBAC), cela permettra donc une amélioration de la sécurité /protection de l’infrastructure Cloud, Azure.

What Next ?

Je vous laisse créer et tester vos new Resource Manager Locks sur vos ressources Azure et me faire part de votre feedback pour cette fonctionnalité.

Restez connecté, plusieurs articles autour de l’Azure sont en cours de finalisation et verront le jour très prochainement sur mon blog :).

A bientôt.

Scott Manchester, RDS PPM (Principal Program Manager) vous explique les Upcoming Updates pour RDS (Securité, Cloud, MFA, Scalability …Etc)

Watch & Enjoy 🙂