PI Services

Le blog des collaborateurs de PI Services

SCOM – Supprimer un management pack directement dans la base de données

Préambule : cette manipulation n’est pas supportée par Microsoft, vous ne devriez pas vous en servir sur une infrastructure de production en dehors des instructions que vous fournirait le support.

Ceci étant dit, revenons-en au sujet.
Il peut arriver que certains Management Packs aient écrit tellement de données dans la base que leur suppression via la console ou via Powershell échoue après 30 minutes de travail :

clip_image002

Remove-SCOMManagementPack : The requested operation timed out

On entre alors dans un cercle vicieux : plus on attend pour les supprimer, plus il y aura de données à supprimer ; sans compter que ces management packs ont la facheuse tendance à noyer la base de données et à provoquer le redouté événement 2115 (mais c’est une autre histoire…).

Heureusement, il existe une procédure stockée qui permet de supprimer un Management Pack et toutes les données qu’il a enregistrées dans la base, sans craindre de timeout : p_ManagementPackRemove.

Afin de l’exécuter, il est d’abord nécessaire de récupérer l’id du management pack à supprimer :

SELECT ManagementPackId,MPName
FROM [OperationsManager].[dbo].[ManagementPack]
where MPName like ‘%MP à supprimer%’

Puis la procédure s’appelle simplement avec la requête suivante :

exec [dbo].[p_ManagementPackRemove] ‘ManagementPackId‘
go

Il ne vous reste alors plus qu’à patienter… à titre d’exemple, la suppression du MP Dell (Detailed) sur un environnement contenant plusieurs centaines de serveurs physiques a nécessité plus de 4h !

SCOM – Utiliser une propriété issue du workflow dans une Recovery

Au programme de cet article, une nouvelle astuce méconnue : comment utiliser une propriété issue du changement d’état d’un moniteur dans une tâche de remédiation (Recovery).

Prenons pour exemple un moniteur de service tout ce qu’il y a de plus classique :

 clip_image002

Imaginons maintenant que nous ayons besoin de déclencher une Recovery lorsque ce moniteur repasse à l’état Healthy (oui, c’est parfaitement réalisable en XML même si impossible directement dans la console), par exemple pour aller écrire le Process ID de l’exécutable sous-jacent au service dans un fichier de log.

Le PID fait partie des informations contenues dans le PropertyBag qui entraine le passage du moniteur en Healthy :

clip_image004

Il faudrait donc pouvoir passer la valeur de cette propriété en entrée de notre Recovery.

On pense alors immédiatement à la notation couramment utilisée pour afficher ces valeurs dans les alertes :
$Data/Context/Property[@Name=’ProcessId’]$
Malheureusement, elle ne fonctionne pas dans le cadre d’une Recovery…

La syntaxe correcte, très peu utilisée et documentée, est en réalité la suivante :

$Data/StateChange/DataItem/Context/DataItem/Property[@Name=’ProcessId’]$

Elle résulte de la structure du MonitorTaskDataType qui encapsule un PropertyBag dans un autre lors de la circulation des données dans un workflow de moniteur, tel que le montre cet exemple sur MSDN : https://docs.microsoft.com/en-us/previous-versions/system-center/developer/ee533651(v=msdn.10)

Cette astuce ne vous servira probablement pas tous les jours, mais elle m’a déjà été bien utile… peut-être vous le sera-t-elle aussi !

SCOM - La variable $Data$ ou comment utiliser Powershell n’importe où dans un module

L’article d’aujourd’hui s’adresse en priorité aux développeurs de management packs aguerris puisqu’il nécessite que vous maitrisiez déjà des notions d’authoring avancé comme la composition de modules personnalisés, de data source, de probe et donc les concepts de property bags et de circulation des données au sein d’un module.

Si ce n’est pas votre cas, ne partez pas tout de suite : cela pourrait quand même vous donner envie d’en savoir plus sur ces sujets !

Revenons-en donc au sujet qui nous intéresse : ne vous êtes-vous jamais retrouvé frustré par l’impossibilité de récupérer un Property Bag complet dans une probe Powershell afin de le traiter dans son ensemble avant de le réinjecter dans le workflow d’un module personnalisé ?
Par exemple pour travailler sur l’ensemble des données retournées par un SnmpWalk (ma bête noire !), d’une requête SQL issue de la Datasource OleDB native ou plus généralement lorsqu’une datasource renvoie un résultat dont les propriétés sont en nombre variable et imprévisible ; pour produire à partir de ces derniers des PropertyBags formatés à votre guise afin de les réutiliser plus loin dans votre module ?

Si ce n’est pas le cas, tant mieux ! Mais cela m’est arrivé plus d’une fois… Jusqu’à ce que je me souvienne d’un article de l’illustre Daniele Grandini qui, je dois bien l’admettre, ne m’avait pas interpelé plus que ça lors de ma première lecture. Ces préoccupations étaient alors bien éloignées de mes besoins en authoring, encore modestes !
Il y met en lumière la problématique que j’exposais plus haut, et propose pour la résoudre un module de type ConditionDetection de sa propre conception qui permet de « reconstruire » un property bag complet afin de le passer dans le workflow.

S’il s’agit assurément d’un grand pas en avant, une solution encore largement supérieure proposée par « bobgreen84 » (alias Validimir Zelenov) se cache dans les commentaires de l’article : en décompilant la ProbeAction powershell native de SCOM (Microsoft.EnterpriseManagement.Modules.PowerShell.dll – SCOM n’utilise pas directement l’exécutable original de powershell présent dans toute installation de Windows lors de l’utilisation de ProbeAction powershell), il a remarqué que celle-ci disposait d’une possibilité à ma connaissance non documentée ni utilisée dans aucun management pack.

Mais avant d’aller plus loin sur cette découverte, revenons rapidement sur l’aspect d’un PropertyBag et le fonctionnement d’une Probe powershell.

Voici un PropertyBag classique, issu d’une Datasource quelconque.
Il s’agit d’un bloc de code XML formaté d’une façon bien spécifique qui permet au moteur de SCOM de faire circuler les données entre les différents composants d’un module.
Celui-ci contient les propriétés nommées Value1 et Value2, dont les valeurs sont respectivement 10 et 5 :

image

Voici maintenant une Probe powershell qui exécute un script dont le but est simplement d’additionner deux valeurs qui lui sont passées en paramètre, puis de retourner le résultat de cette addition dans un PropertyBag.
Les valeurs de ces paramètres proviennent du PropertyBag précédent et sont récupérées à l’aide de la notation habituelle $Data/Property[@Name=’nomdelapropriété’]$ .

clip_image004

Le PropertyBag résultant de l’exécution de cette probe ressemblera donc à ceci :

clip_image006

Rappelons par ailleurs que la notation  $Data/Property[@Name=’nomdelapropriété’]$ est héritée de xQuery, une notation standard permettant de naviguer et de lire des données dans un fichier xml.

Votre mémoire étant maintenant rafraichie, revenons-en au code découvert par Vladimir Zelenov :

clip_image008

Ce que dit ce code, c’est que si vous passez la variable $Data$ en paramètre de votre ProbeAction et non pas une variable utilisant la notation habituelle vue ci-dessus, ce ne seront plus les valeurs des propriétés du PropertyBag mais bien le PropertyBag complet qui sera envoyé au script !

Prenons un exemple concret :

clip_image010

Intégrée dans un module personnalisé, cette probe très simple vous permettra de copier l’intégralité du Propertybag qui y entre dans un fichier texte.
Cela peut s’avérer extrêmement utile lors du debug d’un module, lorsqu’on ne comprend pas pourquoi l’on n’obtient pas les résultats attendus !

Il est évidemment possible de créer des scripts beaucoup plus complexe, d’autant plus que Powershell permet nativement de typer un objet en tant que XML et donc de naviguer dans son arborescence.
L’exemple suivant (fictif) récupère le résultat de la requête SnmpWalk d’un tableau snmp contenant des métriques systèmes et en réorganise le contenu afin de créer des PropertyBags plus lisibles :

clip_image012

Bref, les possibilités sont infinies…A vous de jouer !

Script Powershell - Archive log files to Zip

Le script ci-dessous archive des fichiers de log plus ancien que $daysthreshold vers une archive zip existante ($zipfilepath). Il crée le sous dossier et l'archive zip horodatée si elle n'existe pas.

ArchiveLogToZip.ps1

 

###############################################################
### ArchiveLogs.ps1                                    ###
### Add Log Files older than $days to existing zip archive. ###

### Params
### $logpath: Log Folder
### $archpath: Archive Folder
### $zipfilePath: zip file path
### $daysthreshold: Treat log older than $daysthreshold days
###############################################################
 
Param(
$logpath = "C:\MyLogFolder", 
$archpath = "C:\MyLogFolder\Archive\",
$zipfilePath =  "$archpath"+"*.zip",
[int]$daysthreshold = 0 
)
 



# Test if $archpath exist
If ( -not (Test-Path $archpath)) {New-Item $archpath -type directory} 
 
# Get items to archive
$ItemsToArc = Get-Childitem -Path $logpath -recurse | Where-Object {$_.extension -eq ".log" -and $_.LastWriteTime -lt (get-date).AddDays(-$daysthreshold)}

# Log and exit if  No items to archive
If (! $ItemsToArc)
    {
    Write-Host -F Yellow "No items to archive - Check the existence of the logs"
    exit 0
    }



# If the zip file not exist, create it
if (!(Get-Item $zipfile -ErrorAction SilentlyContinue))
{
$date = $(Get-Date).ToString("MM-dd-yyyy_HH-mm-ss")
New-Item -Path "$archpath$date.zip"
$zipfile = $(Get-Item "$archpath$date.zip").FullName
}
Else
{
$zipfile = $(Get-Item $zipfilePath).FullName
}


# Create a com object that will represent the zip file
$Zip = New-Object -ComObject Shell.Application

write-progress -activity "Archiving Data" -status "Progress..." 

try
{
$ItemsToArc | foreach {$Zip.namespace($zipfile).Movehere($_.fullname,8) ; start-sleep -Seconds 3}
}
catch
{
Write-Host "Error during File add to Zip"
}

 

Script Powershell - Fonction de test de ports reseaux

Ci-dessous une fonction dont le besoin est récurrent, pour tester la disponibilité d'un ou plusieurs ports réseaux sur une ou plusieurs machines.

 test-port.ps1 (10,05 kb)

# TEST-PORT
<#
.SYNOPSIS
         CHECK AVAILABILITY OF NETWORK PORT CONNECTION ON REMOTE COMPUTERS
.OUTPUTS 
         Return Open Status and details
.PARAMETER 
        $computer: One or more target computers
        $port: One or more port to test
        $TCPtimeout: Timeout for TCP, in ms
        $UDPtimeout: Timeout for UDP, in ms
        $TCP: Precise TCP connection
        $UDP: Precise UDP connection
                 

.USAGE:
#Test-Port -computer (get-content .\servers.txt) -port 3389
#Test-Port -computer (get-content .\servers.txt) -port 80,443,23000,17990 -TCP -TCPtimeout 1000
#Test-Port -computer myserver -port 8080,8443,10443,3389,443,80,22 -TCP -UDP
#>



function Test-Port{  




 
[cmdletbinding(  
    DefaultParameterSetName = '',  
    ConfirmImpact = 'low'  
)]  
    Param(  
        [Parameter(  
            Mandatory = $True,  
            Position = 0,  
            ParameterSetName = '',  
            ValueFromPipeline = $True)]  
            [array]$computer,  
        [Parameter(  
            Position = 1,  
            Mandatory = $True,  
            ParameterSetName = '')]  
            [array]$port,  
        [Parameter(  
            Mandatory = $False,  
            ParameterSetName = '')]  
            [int]$TCPtimeout=500,  
        [Parameter(  
            Mandatory = $False,  
            ParameterSetName = '')]  
            [int]$UDPtimeout=500,             
        [Parameter(  
            Mandatory = $False,  
            ParameterSetName = '')]  
            [switch]$TCP,  
        [Parameter(  
            Mandatory = $False,  
            ParameterSetName = '')]  
            [switch]$UDP                                    
        )  
    Begin {  
        If (!$tcp -AND !$udp) {$tcp = $True}  
        
        $ErrorActionPreference = "SilentlyContinue"  
        $report = @()  
    }  
    Process {     
        ForEach ($c in $computer) {  
            ForEach ($p in $port) {  
                If ($tcp) {    
                    #Create temporary holder   
                    $temp = "" | Select hostname,Server, Port, TypePort, Open, Notes  
                    #Create object for connecting to port on computer  
                    $tcpobject = new-Object system.Net.Sockets.TcpClient  
                    #Connect to remote machine's port                
                    $connect = $tcpobject.BeginConnect($c,$p,$null,$null)  
                    #Configure a timeout before quitting  
                    $wait = $connect.AsyncWaitHandle.WaitOne($TCPtimeout,$false)  
                    #If timeout  
                    If(!$wait) {  
                        #Close connection  
                        $tcpobject.Close()  
                        Write-Verbose "Connection Timeout"  
                        #Build report  
                        $temp.hostname= [System.Net.dns]::Resolve($c).hostname
                        $temp.Server = $c  
                        $temp.Port = $p  
                        $temp.TypePort = "TCP"  
                        $temp.Open = "False"  
                        $temp.Notes = "Connection to Port Timed Out"  
                    } Else {  
                        $error.Clear()  
                        $tcpobject.EndConnect($connect) | out-Null  
                        #If error  
                        If($error[0]){  
                            #Begin making error more readable in report  
                            [string]$string = ($error[0].exception).message  
                            $message = (($string.split(":")[1]).replace('"',"")).TrimStart()  
                            $failed = $true  
                        }  
                        #Close connection      
                        $tcpobject.Close()  
                        #If unable to query port to due failure  
                        If($failed){  
                            #Build report 
                            $temp.hostname= [System.Net.dns]::Resolve($c).hostname 
                            $temp.Server = $c  
                            $temp.Port = $p  
                            $temp.TypePort = "TCP"  
                            $temp.Open = "False"  
                            $temp.Notes = "$message"  
                        } Else{  
                            #Build report
                            $temp.hostname= [System.Net.dns]::Resolve($c).hostname  
                            $temp.Server = $c  
                            $temp.Port = $p  
                            $temp.TypePort = "TCP"  
                            $temp.Open = "True"    
                            $temp.Notes = ""  
                        }  
                    }     
                    #Reset failed value  
                    $failed = $Null      
                    #Merge temp array with report              
                    $report += $temp  
                }      
                If ($udp) {  
                    #Create temporary holder   
                    $temp = "" | Select Server, Port, TypePort, Open, Notes                                     
                    #Create object for connecting to port on computer  
                    $udpobject = new-Object system.Net.Sockets.Udpclient
                    #Set a timeout on receiving message 
                    $udpobject.client.ReceiveTimeout = $UDPTimeout 
                    #Connect to remote machine's port                
                    Write-Verbose "Making UDP connection to remote server" 
                    $udpobject.Connect("$c",$p) 
                    #Sends a message to the host to which you have connected. 
                    Write-Verbose "Sending message to remote host" 
                    $a = new-object system.text.asciiencoding 
                    $byte = $a.GetBytes("$(Get-Date)") 
                    [void]$udpobject.Send($byte,$byte.length) 
                    #IPEndPoint object will allow us to read datagrams sent from any source.  
                    Write-Verbose "Creating remote endpoint" 
                    $remoteendpoint = New-Object system.net.ipendpoint([system.net.ipaddress]::Any,0) 
                    Try { 
                        #Blocks until a message returns on this socket from a remote host. 
                        Write-Verbose "Waiting for message return" 
                        $receivebytes = $udpobject.Receive([ref]$remoteendpoint) 
                        [string]$returndata = $a.GetString($receivebytes)
                        If ($returndata) {
                           Write-Verbose "Connection Successful"  
                            #Build report
                            $temp.hostname= [System.Net.dns]::Resolve($c).hostname  
                            $temp.Server = $c  
                            $temp.Port = $p  
                            $temp.TypePort = "UDP"  
                            $temp.Open = "True"  
                            $temp.Notes = $returndata   
                            $udpobject.close()   
                        }                       
                    } Catch { 
                        If ($Error[0].ToString() -match "\bRespond after a period of time\b") { 
                            #Close connection  
                            $udpobject.Close()  
                            #Make sure that the host is online and not a false positive that it is open 
                            If (Test-Connection -comp $c -count 1 -quiet) { 
                                Write-Verbose "Connection Open"  
                                #Build report
                                $temp.hostname= [System.Net.dns]::Resolve($c).hostname  
                                $temp.Server = $c  
                                $temp.Port = $p  
                                $temp.TypePort = "UDP"  
                                $temp.Open = "True"  
                                $temp.Notes = "" 
                            } Else { 
                                <# 
                                It is possible that the host is not online or that the host is online,  
                                but ICMP is blocked by a firewall and this port is actually open. 
                                #> 
                                Write-Verbose "Host maybe unavailable"  
                                #Build report
                                $temp.hostname= [System.Net.dns]::Resolve($c).hostname  
                                $temp.Server = $c  
                                $temp.Port = $p  
                                $temp.TypePort = "UDP"  
                                $temp.Open = "False"  
                                $temp.Notes = "Unable to verify if port is open or if host is unavailable."                                 
                            }                         
                        } ElseIf ($Error[0].ToString() -match "forcibly closed by the remote host" ) { 
                            #Close connection  
                            $udpobject.Close()  
                            Write-Verbose "Connection Timeout"  
                            #Build report 
                            $temp.hostname= [System.Net.dns]::Resolve($c).hostname 
                            $temp.Server = $c  
                            $temp.Port = $p  
                            $temp.TypePort = "UDP"  
                            $temp.Open = "False"  
                            $temp.Notes = "Connection to Port Timed Out"                         
                        } Else {                      
                            $udpobject.close() 
                        } 
                    }     
                    #Merge temp array with report              
                    $report += $temp 
					$temp
                }                                  
            }  
        }                  
    }  
    End {  
        #Generate Report  
        $report |ft -AutoSize 
    }
}





 

SCCM : Failed To Run Task Sequence on Hyper-V VM Generation 2

Les messages d'erreur sont parfois frustrant par exemple celui ci-dessous:

En plus de ne pas être des plus explicit, une multitude de cas sont exposé sur internet avec des code erreur divers et variés.

Sans l'accès au log tout devient plus dificile, dans le cas de figure ici présent j'ai voulu déployer une VM de génération 2 sous Hyper-V via un média de boot (clés USB), je pensais que j'allais y passer des heures, mais en fait non 10 minutes tout au plus.

1 - Les causes

Les VM de génération 2 sous Hyper-V, ont par défaut le Secure boot activé.

Le secure boot est une fonctionnalité qui vérifie que le "Boot Loader" est signé par une autorité de confiance de la base UEFI pour empêcher l'exécution non authorisé d'un "Firmware", "OS" ou "Driver"  au démarrage.

Sauf que dans notre cas cela nous empêche de créer la partition pour le "Staging" du WinPe.

2 - Les solutions

désactivez le secure boot.

  1. Lancez Hyper-V management.
  2. Sélectionnez votre VM.
  3. Faites un clic droit "Properties".
  4. Dans "Settings for xxxxxx on xxxxxx" sélectionnez "Security".
  5. décochez la case "Enable Secure boot".
  6. Validez.

 

Créez une partition UEFI.

En cherchant dans les logs on pourrait trouver l'erreur suivante "Unable to find the partition that contains the OS boot loaders. Please ensure the hard disks have been properly partitioned".

  1. Après avoir désativer le sécure boot, démarrez votre VM et faites "F8" durant le démarrage.
  2. Dans l'invite de commande exécutez les commandes suivantes:
    1.  Diskpart (lancez l'utilitaire Diskpart)
    2. List Disk (Listez les disque)
    3. Select disk 0 (sélectionnez le disque 0 qui représente le disque système de la VM)
    4. Clean (permet d'effacer les données)
    5. Convert gpt (permet de convertir le disque)
    6. Create partition efi size=200 (création d'une partition Efi)
    7. Assign letter=s (Assignez un lettre disponible à la partition)
    8. Format quick fs=FAT32 (Formatez la partition)
    9. Create partition msr size=128 (création d'une partition msr)
    10. Create partition primary (création d'une partition Windows)
    11. Assign letter=c (Assignez la lettre C)
    12. Format quick fs=NTFS (Formatez en NTFS)
    13. Exit (quittez Diskpart)
  3. Normalement vous devriez maintenant pouvoir lancer la séquencce de tâche sans encombre.

 

Hyper-V : Arreter une VM bloquee (Version Powershell)

Bonjour à tous,

Voici une version Powershell du billet suivant : https://blog.piservices.fr/post/2014/12/17/HyperV-2012-R2-Arreter-une-VM-bloquee

Symptomes :

Des actions lancées sur vos VMs (une extinction par exemple) ne s'éxécutent pas.

Le probleme reste présent quelque soit l'outil utilisé (Hyper-V Manager, Failover Cluster Manager ou encore SCVMM).

La VM est donc dans un état instable et il peut etre necessaire de la redémarrer malgrès que celle-ci ne répond plus du tout à aucune action.

Parfois, vous pouvez avoir un status plus explicite sur l'état de la VM via le Failover Cluster Manager, celle-ci sera marquee comme Locked.

Solution :

Il faut tuer le processus VMWP.exe correspondant à la VM directement sur l'hote Hyper-V concerné.

La version Powershell a l'avantage de sa rapidité (vous pouvez le faire en RemotePS directement) ainsi que de minimiser le risque d'erreurs de manipulation (Le GUID n'étant pas un identifiant des plus lisible).

Voici les commandes :

$VMGUID = (Get-VM VM_Name).ID
$VMWMProc = (Get-WmiObject Win32_Process | ? {$_.Name -match 'VMWP' -and $_.CommandLine -match $VMGUID})
Stop-Process ($VMWMProc.ProcessId) –Force

A bientot !

Introduction à Microsoft Advanced Threat Analytics

ATA

Advanced Threat Analytics (ATA) est une plateforme OnPremise qui permet d’analyser l’ensemble des actions effectuées (accès à des ressources, verrouillage de compte, déplacement latéral…) avec des comptes Active Directory.

ATA fonctionne avec un serveur central qui récupère l’ensemble des logs des contrôleurs de domaines.

Ces logs peuvent être récupérés de deux façons :

  • Via un agent installé sur les DC (nommé Lightweight Gateway)
  • Via du port mirroring (nommé Full Gateway)

Ce billet s’intéressera uniquement à la configuration d’ATA avec des Lightweight Gateway.

Mise en place

Prérequis pour les Lightweight Gateway

Pour qu’ATA soit efficace il est impératif d’installer l’agent sur l’ensemble des DC du domaine Active Directory.

Pour la mise en place il faut

  • l’ouverture du port TCP 443 entre les DC et le serveur ATA
  • un compte de service (sans droit d’administration) présent dans l’AD
  • un certificat SSL (optionnel, il est possible d’utiliser un certificat auto-signé pour la console d’administration)

 

Installation du serveur ATA

L’installation du serveur d’administration est très simple et se fait via l’assistant d’installation.

Il est possible de paramétrer le chemin d’installation, le chemin des logs et le certificat qui sera utiliser pour la console web.

image

image

image

image

image

image

La fin de l’installation s’effectue depuis l’interface d’administration web (https://localhost depuis le serveur ATA).

Le compte de service est nécessaire à ce moment pour lire l’AD.

2019-02-01_152514

L’étape suivante consiste à télécharger le setup pour les DC.

2019-02-01_152537

2019-02-01_152547

Installation des Lightweight gateways

L’installation de l’agent sur les DC se fait à travers l’assistant d’installation. Il est possible de paramétrer le chemin d’installation.

2019-02-01_153332

2019-02-01_153525

2019-02-01_153810

2019-02-01_153830

2019-02-01_153911

Une fois l’agent installé, celui-ci démarre automatiquement et le DC est visible dans l’interface d’administration.

Il est nécessaire de modifier la configuration d’un des DC dans l’interface d’administration pour le désigner comme Domain synchronizer candidate.

Tout DC défini comme Domain synchronizer candidat peut être responsable de la synchronisation entre ATA et le domaine Active Directory.

2019-02-01_152654

Analyse

Depuis l’interface d’administration les différentes alertes remontent automatiquement. Celles-ci sont classées par niveau de criticité : High, Medium et Low.

2019-02-27_114458

Il est possible de configurer des alertes mail et/ou d’envoyer l’ensemble de ces logs dans un SIEM.

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.