PI Services

Le blog des collaborateurs de PI Services

Activer SSPR sur Azure

Qu'est-ce que SSPR ?

SSPR ou Self-service password reset est une fonctionnalité d'Azure Active Directory permettant aux utilisateurs de réinitialiser eux-même leur mot de passe.

 

Quels sont les avantages de SSPR ?

  • Autonomie des utilisateurs pour réinitialiser leur mot de passe et par conséquent réduction du nombre de sollicitations des IT
  • Les méthodes de récupérations proposées par SSPR sont connus et facile à prendre en main : question secrètes, vérification par SMS etc
  • Les options de configuration de SSPR peuvent être aisément changées
  • L'utilisation de SSPR est loguée et ces logs sont facilement accessible

 

Comment configurer SSPR ?

 

1. Rendez-vous dans portal.azure.com et connectez-vous avec un compte qui possède le rôle Global Administrator

2. Cliquez sur l'icone des triples barres horizontales pour afficher le menu du portail Azure puis cliquer sur Azure Active Directory

3. Dans le menu cliquez sur Password Reset

 

4. Vous arrivez directement dans l'onglet Properties, choisissez si vous voulez que SSPR soit activé pour l'ensemble des utilisateurs All ou pour un nombre restreint Selected

 

5. Cliquez sur Authentication methods et choisissez les paramètres voulus : méthodes de récupération disponible pour les utilisateurs, nombre de méthodes de récupération minimum nécessaire etc

 

6. Cliquez sur l'onglet Registration, vous pouvez forcer l'inscription des utilisateurs à SSPR lors de leur prochaine connexion au portail office. Vous devez également choisir au bout de combien de jours les utilisateurs doivent confirmer leurs informations de méthodes de récupération.

 

7. Vous avez d'autres options de configurations dans les onglets Notifications et Customization. L'onglet On-premises integration est quant à lui utilisé dans les environnements hybrides.

 

Quelle est l'expérience utilisateur lors de l'inscription à SSPR ?

 

1. Si vous n'avez pas obligé l'utilisateur à s'inscrire, vous devez lui fournir ce lien : aka.ms/ssprsetup sinon il aura l'image suivante à sa prochaine connexion

 

2. L'utilisateur devra ensuite confirmer son mot de passe actuel puis sera invité à s'inscrire à SSPR, les méthodes de récupération que vous avez choisi précédemment seront proposées à l'utilisateur. Il peut les configurer en cliquant sur set up now à coté de la méthode de récupération

 

3. Après avoir configuré le nombre minimum de méthodes de récupération, il peut alors cliquer sur looks good pour finir son inscription à SSPR

 

Comment l'utilisateur peut utiliser SSPR pour réinitialiser son mot de passe ?

 

1. L'utilisateur peut soit utiliser le lien suivant : aka.ms/sspr soit se rendre sur portal.office.com et cliquer sur Can't access your account?

 

2. Il lui sera alors demandé d'entrer l'UPN de son compte et de valider un captcha. Il pourra ensuite choisir parmi les méthodes de récupération qu'il a configuré pour réinitialiser son mot de passe

 

3. L'utilisateur sera alors invité à saisir un nouveau mot de passe

 

O365 : Modification de l'UPN

Dans certain cas de figure (mariage, divorce...) les utilisateurs de l'AD change de nom, ceux qui a pour impact un renommage du compte Active Directory, jusque la pas de problème mais (parce qu'il en faut un) lorsque vous utilisez "AD Connect" pour synchroniser vos utilisateurs locaux (votre Active Directory) avec Office 365 (Azure Active Directory), certains paramètres ne sont pas synchronisés.

Parmi ces paramètres le UserPrincipalName, plus communément appelé UPN ne peut être modifié depuis l'AD et répliqué vers O365.

Pour modifier l'UPN côté O365 vous devrez utiliser la commande Powershell suivante:

Set-MsolUserPrincipalName -UserPrincipalName AncienUPN@mondomaine.com -NewUserPrincipalName NouvelUPN@mondomaine.com

 

 

Outils Azure : récupérer le certificat du proxy transparent

L’utilisation d’Azure et d’outils qui s’appuient dessus (tels que Storage Explorer, Azure Migrate, Azure CLI, Visual Studio et VS Code…) est devenue presque banale et quotidienne pour beaucoup d’entre nous.

Cependant, dans un environnement d’entreprise, un problème récurrent se présente : la connexion d’un de ces outils à Azure échoue avec un message indiquant un certificat racine incorrect ou autosigné ; comme par exemple ici « Self-signed certificate in certificate chain » :

clip_image002

Une vérification dans les journal d’événement CAPI2 de la machine où s’exécute l’outil devrait permettre d’identifier quel certificat empêche la connexion et, bien souvent il s’agit du proxy d’entreprise qui fonctionne en mode « transparent », interceptant ainsi tous les flux sortants.

Deux solutions sont alors possibles : demander à l’administrateur du proxy de mettre en liste d’exclusion les flux nécessaires à l’application, ou récupérer le certificat racine du proxy afin de l’intégrer au magasin des autorités de confiance de votre machine ou dans les certificats de confiance de l’application, si elle le supporte (c’est le cas pour Storage Explorer).

C’est bien entendu le second cas qui nous intéresse ici. Pour récupérer le certificat, il est nécessaire de passer par l’outil OpenSSL qui n’est pas présent nativement sous Windows. Fort heureusement, il est possible de télécharger des binaires déjà compilées et de les exécuter directement depuis l’invite de commande : https://sourceforge.net/projects/openssl/

Une fois l’archive téléchargée et décompressée, la commande suivante permet de récupérer la chaine de certificats réellement reçus par le système lors d’une requête HTTPS :

s_client –showcerts –connect urldeconnexionauservice.test.com:443

clip_image004

On retrouve ici l’erreur « self signed certificate in certificate chain » ainsi que les certificats présents, inclus entre les lignes ----BEGIN CERTIFICATE---- et ----END CERTIFICATE---- :

clip_image006

Il ne reste plus qu’à copier cette chaine de caractères dans un fichier texte, à renommer ce fichier avec une extension .cer et à l’importer dans l’outil ou directement dans le magasin Windows des autorités de certification approuvées.

Azure – Privileged Identity Management

Privileged Identity Management

Privileged Identiy Mangement (PIM) une une fonctionnalité de Microsoft Azure qui permet de déléguer des droits et des ressources dans Azure, Office 365 et Intune.

Mise en place

Prérequis

Pour mettre en place PIM il est indispensable d’avoir sur les comptes qui l'utiliseront :

  • Une license Enterprise Mobility + Security (EMS) E5 ou à minima une license Azure AD Premium P2
  • Le MFA activé

2019-02-26_163601

Par défaut, PIM n’est pas actif dans Azure. Pour l’activer, il faut se rendre sur le portail Azure (https://portal.azure.com) avec des droits d'"administrateur global" et rechercher Privileged Identity Management.

Une page nous invite à vérifier notre identité via le MFA.

2019-02-26_113903

Une fois la vérification d’identité effectuée il est possible d’activer la fonctionnalité.

2019-02-26_114134

Quelques instants après le service est disponible.

2019-02-26_114203

Il est ensuite nécessaire de se déconnecter / reconnecter du portail Azure.

2019-02-26_114253

Configuration des rôles

Depuis PIM, dans la section Manage puis Roles, il existe par défaut une quarantaine de rôle que l’on peut modifier.

2019-02-26_114442

Dans cet article, je vais modifier le rôle Exchange Administrator pour qu’il soit actif durant 3H et qu'il nécessite une validation (par défaut le rôle est en auto-validation pour une durée d’une heure). Les utilisateurs Adminstrator et Megan auront le pouvoir d’accepter ou non la demande d’accès au rôle.

Pour ça, dans PIM, dans la section Manage puis Settings, je sélectionne Roles.

2019-02-26_165956

Je sélectionne le rôle Exchange Administrator et je change les paramètres.

2019-02-26_160256

Je peux ensuite depuis PIM, dans la section Manage puis Roles ajouter un utilisateur à mon rôle.

2019-02-26_160402

2019-02-26_160418

Obtention du rôle

Une fois le rôle ajouté sur l’utilisateur, celui-ci reçoit un mail pour le prévenir.

2019-02-26_161344

Depuis le lien présent dans le mail il est alors possible de faire la demande pour activer le rôle.

2019-02-26_160440

Une vérification d’identité via MFA est nécessaire à cette étape également.

2019-02-26_160451

Une fois l’identité confirmée, il est possible de demander l’activation du rôle.

2019-02-26_160641

Je peux réduire le temps d’activation du droit (de 30 minutes à 3h) et je dois indiquer un message pour obtenir les droits.

2019-02-26_160739

Une fois la demande effectuée, il ne reste plus qu’à attendre la validation par un administrateur.

2019-02-26_160822

Les administrateurs reçoivent un mail indiquant qu’une demande d’activation de rôle est en attente.

2019-02-26_161426

Depuis le lien présent dans le mail, il est possible d’accepter ou de refuser la demande.

2019-02-26_160841

Un message est obligatoire pour approuvé la demande.

2019-02-26_160907

L’utilisateur reçoit alors un mail lui indiquant qu’il dispose des droits d’administration.

2019-02-26_161353

Depuis le portail PIM l’utilisateur peut voir ses droits en cours et passés.

2019-02-26_161022

Il a également accès à la tuile Admin et bien évidement à la page d’administration d’Exchange dans notre cas.

2019-02-26_161144

2019-02-26_161635

Log

L’ensemble des droits demandées, validées et refusées est loggé dans PIM, section Activity puis Directory roles audit history.

2019-02-26_160953

Les administrateurs ont également le mail prouvant la validation au rôle.

2019-02-26_161436

Voila qui conclut ce billet sur PIM !

Azure : La valse des CLI ... (Partie 2)

Bonjour à tous !

Dans cette seconde partie, nous allons voir quels sont les outils cross-platformes en ligne de commande étant à notre disposition afin de gérer la plateforme Microsoft Azure.

PowerShell 6

Cette version de PowerShell est une petite révolution dans le monde Microsoft, car elle est construite autour de .NET Core (au lieu de .NET Framework) ce qui lui permet d'être nativement cross-platforme. Appelée quelque peu abusivement PowerShell 6, il vaudrait mieux parler de PowerShell Core 6 pour être exact.

La dernière version stable en date est la version 6.1 (Janvier 2019).

Compatibilité (en Janvier 2019)

Pour Windows :

  • Windows 7 SP1, 8.1 et 10
  • Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019

Pour Linux :

  • Ubuntu 18.04
  • Debian 8.7+ et Debian 9
  • CentOS 7
  • RHEL 7
  • OpenSuse 42.3
  • Fedora 27, 28

Pour MacOS :

  • macOS 10.12+

Les avantages

  • Compatibilité cross-plateforme native
  • Performances accrues comparées à Windows PowerShell 5.1
  • Peut coexister à coté de Windows PowerShell 5.1 (Exécutable powershell.exe pour la version 5.1 et pwsh.exe pour la version 6)
  • S'installe rapidement et facilement (Package MSI sous Windows ou ZIP sous Mac/Linux)
  • Sera utilisée pour toutes les futures évolutions de PowerShell (au contraire de la version 5.1 qui restera figée au niveau des nouvelles fonctionnalités)
  • La version 6.1 apporte un module de compatibilité (Microsoft.Windows.Compatibility) permettant d'utiliser certaines fonctionnalités de PowerShell 5.1 pas encore portées sous PowerShell Core.

Les inconvénients

  • Ne reprends pas encore 100% des fontionnalités de Windows PowerShell 5.1
  • N'est pas encore installée par défaut sous aucun OS (même Windows)
  • Cycle de vie réduit (Doit être mis à jour dans les six mois de la sortie d'une branche 6.X pour être supportée)

Installation des modules Azure

Une fois PowerShell Core 6 installé sur votre OS, l'installation des modules PowerShell Azure se déroule de la même manière qu'avec PowerShell 5.1. Par exemple, pour installer le module Az, vous pouvez toujours utiliser la commande suivante :

Install-Module -Name Az -AllowClobber

Les commandes des modules restent également les mêmes.

Azure CLI

Comme vu précédemment, PowerShell Core 6 a permis d'apporter une solution de gestion d'Azure cross-plateforme à base de PowerShell. Microsoft a décidé d'aller encore plus loin avec Azure CLI, en conservant toujours une approche cross-plateforme mais cette fois en pouvant s'affranchir complètement de PowerShell.

Azure CLI représente un environnement complet en ligne de commande permettant de gérer des ressources Azure. Je vais détailler ci-après les principales différences par rapport aux outils PowerShell existant :

  • Environnement complet écrit en Python. Concrètement, vous pouvez le lancer à partir d'une invite de commande Cmd Windows ou d'une console Bash ou d'un Terminal Mac, c'est un CLI dans un CLI.
  • Les commandes de gestion s'affranchissent de la logique PowerShell Verb-AzNoun. Elles sont de la forme az resource action --options

Azure CLI 1.0 (ASM + ARM)

Azure CLI 1.0 / Azure Xplat CLI ou connue également sous le nom de Azure CLI Classic a été la première itération de Azure CLI et sera abandonée par Microsoft à terme.

Contrairement à sa version 2.0, elle n'est pas écrite avec une base Python mais avec une base NodeJS.

Le seul intérêt de son utilisation réside aujourd'hui en sa capacité à pouvoir gérer des ressources Azure de type Classic (ou ASM pour les intimes).

Il existe actuellement trois méthodes d'installation :

  • Installation à partir d'un package NPM (Version 4.0 min recommandée pour Node JS)
npm install -g azure-cli
  •  Installation à partir d'un programme d'installation MSI (Windows) TAR (Linux) ou DMG (Mac)

Sources

  • Déploiement d'un conteneur Docker (La version 0.10.17 est la dernière supportant Azure CLI Classic pour Docker)
docker run -it microsoft/azure-cli:0.10.17

Une fois Azure CLI Classic installé, vous pouvez utiliser le même type de commande que pour Azure CLI 2.0, elles sont de la forme azure resource action --options (az est donc remplacé par azure). Voici un exemple :

azure vm create [options] <resource-group> <name> <location> -y "Windows"

Bien que nous vous conseillons fortement l'utilisation d'Azure CLI 2.0 pour gérer des ressources Azure de type ARM, vous pouvez les gérer depuis Azure CLI 1.0 avec la commande suivante :

azure config mode arm

Pour retourner en mode ASM, vous pouvez taper la commande suivante :

azure config mode asm

Il est à noter que vous ne pouvez gérer qu'un seul type de ressource (ASM ou ARM) suivant le mode que vous activez.

Azure CLI 2.0 (ARM only)

Azure CLI 2.0 ou connue également sous le nom de Azure CLI tout court est la deuxième itération de Azure CLI qui est désormais basée sur Python. Il est important de noter qu'elle ne permet de gérer que des ressources de type ARM.

4 méthodes de déploiement sont disponibles :

  • Installation à partir d'un programme d'installation MSI (Windows)

Source et Procédure

  • Installation à partir de Homebrew (Mac)

Procédure

  • Installation à partir d'un repository ou manuellement (Linux)

Via Apt Via Yum Via Zypper Manuellement

  • Déploiement d'un conteneur Docker
docker run -it microsoft/azure-cli

Une fois Azure CLI installée, vous pouvez utiliser des commandes de la forme az resource action --options. Voici un exemple :

az vm create [options] <resource-group> <name> <location> -y "Windows"

La liste complète des commandes est disponible ici : Azure CLI ARM commands

Il est à noter que cette version d'Azure CLI dispose également d'un mode Interactif facilitant la prise en main de l'interfaçe avec une saisie semi-automatique, des exemples et des descriptions de commande. Pour l'activer, vous pouvez utiliser la commande suivante :

az interactive

Azure Cloud Shell

Le petit dernier dans la liste des outils pour administrer Azure en ligne de commande est Azure Cloud Shell, et c'est celui que je vous recommanderai s'il fallait en choisir un parmis ceux présentés précédemment.

Azure Cloud Shell est une interfaçe en ligne de commande vous permettant d'administrer votre plateforme Azure directement depuis un navigateur web ou même depuis une application mobile (Azure Mobile App). Elle est accéssible depuis le portail d'administration Azure (https://portal.azure.com) ou directement à l'URL suivante : https://shell.azure.com/.

Voici ses principales caractéristiques et avantages :

  • Uniquement basée sur un navigateur web (plus de dépendances à installer ni de RSSI à soudoyer pour ouvrir des flux)
  • Offre un CLI complet basé sur Bash ou PowerShell Core 6 et toujours à jour
  • Est déjà fournie avec tous les outils existants en ligne de commande permettant de gérer Azure (modules PowerShell AzureRM, Azure et Az, ainsi que les CLI Azure CLI Classic et Azure CLI (2.0))
  • Possibilité d'envois de scripts/fichiers pour de la persistance de données via un partage Azure Files
  • Persistance du $HOME (que ce soit avec Bash/PowerShell) (taille de l'image de base 5 GB)
  • Possibilité d'éditer des fichiers présents sur le partage de fichiers via l'éditeur Monaco (commande code)
  • La liste des fonctionnalités complète se trouve ici : https://docs.microsoft.com/fr-fr/azure/cloud-shell/features#tools

Il faut cependant faire attention aux points suivants :

  • L'environnement CLI n'est pas persistant (mais le stockage et le $HOME oui)
  • Toute session se ferme au bout de 20 minutes d'inactivité
  • Le partage Azure Files utilisé pour la persistance est payant (Tarif standard d'un compte de stockage Azure)

Voilà pour ce tour d'horizon des différents outils utilisable pour gérer la plateforme Azure en ligne de commande.

Azure – Introduction à Azure Information Protection

Azure Information Protection c’est quoi ?

Azure Information Protection abrégé en AIP est une solution disponible dans Azure qui permet de classifier et de protéger des documents / e-mails.

Une fois le document / e-mail classifié il est possible de voir et de contrôler comment celui-ci est utilisé. Par exemple, il est possible d’interdire l’édition du document ou le transfert d’un mail.

Comment ça marche ?

Prérequis

AIP est présent dans les licences Office 365 à partir de la licence E3 avec comme fonctionnalités :

  • Licence E3 et + : Classification et protection des documents / e-mails par défaut et automatiques (géré par l’administrateur)
  • Licence EMS, AIP Plan 1 : Classification et protection des documents / e-mails par défaut, automatiques et manuels
  • Licence EMS, AIP Plan 2 : Prise en compte du chiffrement via HYOK (Hold your own key, chiffrement à partir d’une clé isolée du cloud afin d’augmenter la sécurité)

Le détail de l’ensemble des fonctionnalités est disponible au lien suivant https://azure.microsoft.com/en-us/pricing/details/information-protection/.

2019-01-03_145308

Mise en place

Depuis le portail Azure, rechercher Azure Information Protection.

2019-01-03_145421

 Labels

Par défaut la page d’administration d’AIP s’ouvre sur les Labels de classification. Il en existe 5 par défaut : Personnel, Public, Général, Confidentiel, Hautement Confidentiel.

2019-01-03_145450

A la création d’un label, il est possible de proteger le document. Le chiffrement s’effectue alors via une clé dans Azure ou via une clé de type HYOK.

2019-01-03_152720

Il est ensuite possible d’ajouter des permissions sur le label.

2019-01-03_145858

Policy

Une fois le label créé, il est nécessaire de créer une politique et de l’appliquée sur les utilisateurs.

2019-01-03_153007

Résultats

Il est possible d’installer sur les postes de travail le client AIP (https://www.microsoft.com/en-us/download/details.aspx?id=53018) afin d’avoir un bouton Protéger dans Outlook, Word, Excel…

En sélectionnant dans Protéger le label, un message apparaît pour informer que le mail intègre la protection.

2019-01-10_141548

Azure : La valse des CLI ... (Partie 1)

Bonjour à tous !

Le management d'une plateforme de cloud computing publique est souvent à l'image de la vie de celle-ci, c'est à dire mouvementée !
La plateforme de Microsoft, Azure, n'échappe pas a cette règle. Il est donc temps de faire un point sur les differents outils de ligne de commande mis a notre disposition pour gérer cette plateforme.

Preparation de l'environnement PowerShell

PowerShell

Powershell a été jusqu'à une période assez récente le langage privilégié pour gérer la plateforme Azure en ligne de commande, c'est pourquoi nous commencerons par lui.
La manière la plus simple de récupérer la dernière version des modules Powershell Azure est d'utiliser PowerShellGet.

La disponibilité de PowerShellGet varie suivant la version de Powershell utilisée, à toute fin utile, voici les versions de PowerShell qui sont installées par défaut avec votre OS Microsoft Windows :

  • PowerShell 2 : Windows Server 2008 R2 / Windows 7 SP1
  • PowerShell 3 : Windows Server 2012 / Windows 8
  • PowerShell 4 : Windows Server 2012 R2 / Windows 8.1
  • PowerShell 5 : Windows 10 1507 et 1511
  • PowerShell 5.1 : Windows Server 2016 et 2019 / Windows 10 1607 et supérieur

Les modules PowerShell Azure ne fonctionnant qu'à partir de la version 5 de PowerShell, si vous êtes sous Windows 7 SP1, 8.1 ou Windows Server 2008 R2 SP1, 2012, 2012 R2, il est nécéssaire de passer à la version 5.1 directement en installant le package MSI suivant : Windows Management Framework 5.1

Note : Pour ceux étant sous Windows 7 SP1 ou Windows Server 2008 R2 SP1, c'est un peu moins simple, il faut au préalable installer la version 4.5.2 du .NET Framework avant d'installer le WMF 5.1. Celle-ci est disponible ici : .NET Framework 4.5.2

Note 2 : Vous pouvez vérifier la version de PowerShell installée sur votre OS Windows avec la commande suivante :

$PSVersionTable.PSVersion

PowerShellGet

Pour ceux qui ne sont pas familier avec PowerShellGet, celui-ci permet d'installer des modules ou des scripts PowerShell à partir du repository PowerShell Gallery contenant les modules PowerShell nous intéréssant (mais beaucoup d'autres également). Les personnes connaissant l'univers des distributions Linux retrouveront ici des notions familières.

PowerShellGet, qui est lui même un module PowerShell, est présent par défaut à partir de la version 5 de PowerShell. Celà étant dit, il est préférable de le mettre à jour avant de récupérer des modules avec celui-ci. Pour se faire, deux étapes sont nécéssaires.

On installe d'abord le fournisseur de package .NET Framework NuGet (Equivalent de Apt-Get dédié au .NET Framework pour les connaisseurs). Celui-ci permet à PowerShellGet de pouvoir récupérer des modules à partir du repository PowerShell Gallery qui est de type NuGet. Il permet également à PowerShellGet de se mettre a jour puisque le module est publié lui même sur PowerShell Gallery. Voici la commande pour installer NuGet :

Install-PackageProvider Nuget –Force

Une fois que NuGet est installé, on va pouvoir mettre à jour le module PowerShellGet avec la commande suivante :

Update-Module -Name PowerShellGet

Si pour une raison X ou Y, le module n'est pas déjà installé, vous pouvez le faire avec la commande suivante :

Install-Module –Name PowerShellGet –Force

Nous pouvons donc à présent passer au coeur du sujet à savoir les modules PowerShell Azure.

Modules Azure pour PowerShell

Si vous êtes sous la version 5.X de PowerShell, il vous faut au préalable mettre à jour la version de votre .NET Framework vers la version 4.7.2 via l'installeur suivant .NET Framework 4.7.2 avant de pouvoir installer les modules PowerShell dédiés à Azure.

Module AzureRM (ARM only)

Plus récement, jusqu'en Décembre 2018, c'est le module AzureRM qui est utilisé afin de gérer la plateforme.

Officiellement, Microsoft continue de le supporter après cette date pour des corrections de bugs mais aucune nouvelle fonctionnalité Azure ne sera administrable avec. Pour cela il faudra passer par le module Az.
Les commandes sont de la même forme que celles de PowerShell, à savoir de type Verb-Noun. Exemple :

Get-AzureRmLoadBalancer

Le module est installable avec la commande suivante :

Install-Module -Name AzureRM -AllowClobber

Module Azure (alias ASM)

Pour ceux ayant débuté Azure avant l'arrivée du mode de gestion ARM (Azure Ressource Management), il y avait le mode de gestion ASM (Azure Service Management) dont le portail aujourd'hui n'est plus en activité (RIP !).

Cependant, vous avez pu remarquer que certaines ressources de type ASM persistent au sein du portail ARM sous le nom de Classic. Il est toujours possible de gérer ce type de ressources via PowerShell mais il faut installer un module supplémentaire qui vient en complément du module AzureRm. Il est installable via la commande suivante :

Install-Module -Name Azure -AllowClobber

Module Az (ASM + ARM)

C'est donc le remplaçant officiel du module AzureRm ainsi que du module Azure depuis fin 2018.
Il est installable via la commande suivante :

Install-Module -Name Az -AllowClobber

Les changements concernent principalement la partie technique du module, son utilisation est très similaire à celle de l'ancien module.
Il suffit de remplacer toutes les commandes Verb-AzureRMNoun par Verb-AzNoun. Exemple :

Get-AzLoadBalancer

Microsoft, afin de faciliter la transition, a ajouté des alias qui vous permettront d'utiliser vos anciens scripts adaptés au module AzureRm. L'activation des alias se fait via la commande suivante :

Enable-AzureRmAlias

Cependant, attention, si vous décidez d'utiliser les alias du nouveau module Az, il est impératif de désinstaller toutes les versions précédentes du module AzureRM. 

Il est possible techniquement de faire cohabiter les deux modules en les installant tous les deux sur la même machine mais Microsoft recommande la désinstallation de toutes les versions des modules AzureRm avant d'installer le module Az.

Et pour les autres OS/langages ?

Microsoft, devant le succès de sa plateforme Azure, a constaté le besoin de pouvoir administrer celle-ci depuis un poste autre que Windows ou depuis des périphériques BYOD.

C'est ainsi que son nés PowerShell 6, l'environnement Azure CLI ou encore Cloud Shell. Ces moyens d'adminitration cross-plateformes feront donc l'objet de la deuxième partie de ce billet.

Azure–Présentation d’Azure ADDS

Présentation

Les services de domaine Azure Active Directory fournissent des services de domaine gérés tels que la jonction de domaine, la stratégie de groupe, le protocole LDAP, etc. Vous pouvez utiliser ces services sans avoir à déployer gérer et apporter des correctifs aux contrôleurs de domaine.

Microsoft à créé ce service pour faciliter aux entreprises la création d’un environnement full cloud dans Azure et de répondre aux différents besoins qui sont principalement le coût et la surcharge administrative.

image


Configuration

La particularité d’Azure ADDS est qu’on ne peux pas manager l’AD depuis son interface. Il faut obligatoirement passer par d’autres services, par exemple :

  • Pour la gestion des comptes il faut passer par le service Azure AD ou un AD On-Prémisse synchronisé.

image

  • Pour la gestion des GPO, des OU il faut passer par une VM du domaine et y installer les outils d’administrations.

image


Voici un schéma qui résume l’esprit d’Azure ADDS :

aadds-overview-onpremise


Information

Pour la création de VM Azure il est conseillé d’utiliser la série B. Cette série est une nouvelle offre qui a pour avantage d’être la plus basse car elle s’appuie sur un système de crédit. Elle est prévu en majorité pour des charges de travail ne sollicitant pas en permanences le processeur comme par exemple un serveur web ou un environnement de test. Ces machines sont disponibles dans les régions : US – West 2, US – East, Europe – West, et Asia Pacific – Southeast.

Pour plus d’information concernant la configuration d’Azure ADDS, Consulter le lien suivant : https://azure.microsoft.com/en-us/services/active-directory-ds/

Azure - Gestion des licences par groupe avec des groupes dynamiques

Description

Pour attribuer une licence a un utilisateur de votre annuaire Azure, cela nécessite l’une des étapes suivantes :

  • Attribution de licences directement aux utilisateurs par l’intermédiaire du portail, de PowerShell ou des API.
  • Attribution de licences à des groupes dans le portail Azure.

Quand vous attribuez des licences à un groupe, tous les membres de ce groupe disposent d’une licence. Si des utilisateurs sont ajoutés au groupe ou en sont supprimés, la licence appropriée leur est attribuée ou retirée.

Vous pouvez utiliser l’attribution de licence basée sur le groupe pour configurer des règles telles que les suivantes :

  • Tous les utilisateurs de votre annuaire obtiennent automatiquement une licence
  • Toute personne avec la fonction appropriée obtient une licence

Configuration

Pour créer un groupe il faut utiliser votre compte d’administration Azure et se rendre à l’adresse suivante : https://portal.azure.com.

Une fois connecté vous devez aller dans le menu « Azure Active Directory ».

clip_image001

Créer un groupe dans le sous menu « Utilisateurs et groupes ».

clip_image002

clip_image003[4]

Puis revenir dans l’onglet « Azure Active Directory » et cette fois ci sélectionner « Licences ».

clip_image004[4]

Une fois que vous êtes dans le menu de vos licences sélectionnez le produit sur lequel vous voulez créer un groupe dynamique et cliquez sur « Attribuer ».

clip_image005[4]

Choisissez le groupe que vous avez crée et configuré le les options de la licence. Cette étape est importante car tous les utilisateur qui seront dans le groupe hériterons de ces options.

clip_image006[4]

clip_image008

Ajouter les membres

clip_image010

L’utilisateur ci-dessous hérite maintenant du groupe «DL_O365_E5»

clip_image011

Information :

Pour plus d’information concernant la configuration, je vous invite à consulter le lien suivant :

Manage Azure Active Directory licencing

Récupération des binaires d’installation de Windows Azure Pack installation Express en Local

 

Tout d’abord récupérer l’exécutable Microsoft Web Platform Installer disponible ici :

https://go.microsoft.com/?linkid=9737537

Procéder ensuite à son installation.

Une fois installé, ouvrez une fenêtre PowerShell.

Taper : cd 'C:\Program Files\Microsoft\Web Platform Installer'

Taper ensuite :

.\WebpiCmd.exe /offline  /Products:"WAP_SingleMachineInstallation" 
/Path:"C:\WAP_Offline"
/XML:
https://www.microsoft.com/web/webpi/5.0/webproductlist.xml
/Log:"C:\WAP_Offline.log

(si vous souhaiter récupérer les binaires de WAP dans une version antérieure, le XML référencé doit être modifié. Par exemple pour récupérer la version 4.6, le commutateur /XML aura pour valeur : https://www.microsoft.com/web/webpi/4.6/webproductlist.xml )

 

La récupération des binaires s’exécutent

image

Et se finit.

image

Notre répertoire de destination contient désormais l’ensemble des binaires nécessaire pour l’installation de WAP en offline.

image