Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Azure – S’octroyer des permissions sur des souscriptions en tant qu’administrateur global

Les souscriptions, des ressources Azure aux permissions isolées

 

Le rôle Azure administrateur global (global administrateur) est le rôle absolu, il octroie le droit de vie ou de mort sur un tenant Azure, cependant, les irrésistibles souscriptions (subscriptions) n’en ont que faire et un global administrator se fera jeter comme un simple utilisateur s’il tente d’accéder à une ressource Azure auquel il n’a pas accès si tenté qu’il puisse déjà la voir, à moins que..

 

S’octroyer les permissions sur toutes les souscriptions

 

Il existe une fonctionnalité Azure qui permet à un Global admin de se conférer des droits sur toutes les subscriptions existantes et ceci en un clic, pour ce faire :

Connectez-vous à portal.azure.com avec votre compte Global admin et dans la liste déroulante de gauche, ouvrez Properties

En bas de la fenêtre dans la section Access management for Azure ressources basculez le bouton en Yes

 

Attention, ce rôle ne fournit pas le rôle Propriétaire (Owner) sur les subscriptons, il fournit le rôle User Access Administrator à la racine ce qui permet d’accéder au RBAC Azure de la subscription et de s’octroyer les droits voulus.

Pensez à retirer vos droits de la subscription avant de basculer à nouveau le bouton évoqué précédemment en No

 

Pour aller plus loin

Article officiel de Microsoft sur la délégation de permissions sur les souscriptions Azure en tant qu’administrateur global

Article officiel de Microsoft sur le RBAC Azure

Active Directory GPO – Faire du security filtering

Security filtering quésaco ?

 

Les GPO ou group policy management permettent de modifier le comportement des ordinateurs d’un parc Active Directory (AD), allant du simple changement d’écran à l’installation d’un logiciel.
Les GPO sont liés (link) à des Organizational Unit (OU) qui contiennent des objets utilisateurs et/ou ordinateurs.

Il existe des cas ou on souhaiterait appliquer une GPO à une population restreinte d’ordinateurs contenu dans une OU qui contient des ordinateurs qui ne doivent pas recevoir la GPO. C’est la que le filtre de sécurité (security filtering) entre en jeu, à travers l’appartenance à un groupe AD, on peut restreindre l’application d’une GPO aux membres du groupe.

Configurer une GPO pour faire du security filtering

 

Les étapes suivantes ne seront pas évoquées :

  • Création d’une GPO
  • Linker la GPO sur une OU
  • Ajout d’un objet utilisateur/ordinateur dans un groupe de sécurité

 

Etape 1 : modifier les security filtering de la GPO dans l’onglet Scope

 

Voici la configuration par défaut du security filtering d’une nouvelle GPO :

 

Authenticated Users indique que la GPO s’appliquera à n’importe tout objet utilisateur et/ou ordinateur qui sont contenus dans les OU ou la GPO est linkés.

 

On va donc supprimer Authenticated Users et ajouter notre propre groupe de sécurité (Group-Security-Filtering-Test) dans lequel on aura placé un object utilisateur/ordinateur.

A noter que la GPO n’a pas besoin d’être linké sur l’OU qui contient le groupe, elle doit cependant être linkée à l’OU qui contient les utilisateurs/ordinateurs du groupe.

 

Etape 2 : modifier les security filtering de la GPO dans l’onglet Delegation

 

Il faut ensuite se rendre dans l’onglet Delegation et ajouter Authenticated Users (ou Utilisateurs Authentifiés), pour rappel Authenticated Users inclut les utilisateurs et les ordinateurs, inutile donc de chercher un groupe Authenticated Computers inexistant.

 

Il nous est ensuite demander quelle permission on souhaite donner au groupe Authenticated Users on choisit Read

 

Dans l’onglet Delegation on a indiqué à quelle population a le droit de lire la GPO, c’est la configuration effectuée dans l’onglet Scope qui détermine si la GPO doit s’appliquer ou non à l’utilisateur/ordinateur

Azure PowerShell – Forcer la connexion à Azure lorsque le réseau est instable

Un peu de contexte

 

Dans certains environnements la connexion réseau vers Internet et notamment vers Azure peut présenter des défaillances.

Lorsque qu’un administrateur se connecte de façon interactive en PowerShell à Azure, un simple échec importe peu et une nouvelle tentative est souvent fructueuse, lorsque c’est une tâche automatisée qui est exécutée c’est une autre histoire, toutes les actions qui dépendent de cette connexion échouerons si la connexion vers Azure AD est un échec.


Le code

$i = 0 #Variable qui sera incrémentée à chaque nouvelle tentative de connexion à Azure
$ConnectAzureAD = "Fail" #Variable qui permet de sortir de la boucle si une tentative de connexion vers Azure AD est réussite
do #Do until permet d'exécuter un script en boucle tant qu'une condition n'est pas atteinte
{
    try #Try catch permet de choisir comment les erreurs de cmdlet seront gérés, ici on s'en sert pour attendre avant la prochaine tentative de connexion et potentiellement faire du logging
    {
        $i++ #Permet d'incrémenter la variable $i
        Connect-AzureAD #Cmdlet qui permet de se connecter à Azure AD, dans un script automatisé, les identifiants d'un compte de service seront utilisé à l'aide du paramètre -Credential $Credentials (objet PSCredential à créer)
        $ConnectAzureAD = "Success" #La connexion à Azure AD est un succès puisque nous sommes dans le try, on peut donc modifier la variable $ConnectAzureAD pour pouvoir sortir de la boucle, code qui fonctionne de paire avec la condition dans le until 
        #Il est recommandé de consacrer une ligne pour faire du logging
    }

    catch 
    {
        #A nouveau il est recommandé de consacrer une ligne pour faire du logging
        Start-Sleep 10 #Permet de faire une pause de 10 secondes avant la nouvelle tentative de connexion
    }
}
until ($ConnectAzureAD -eq "Success" -or $i -eq 6) #Si une connexion vers Azure AD est réussie ou si 6 tentatives infructueuses ont été observées, le script arrêtera d'essayer de se connecter à Azure AD

 

 

En résumé, le script tentera de se connecter à Azure AD en powershell jusqu’à ce qu’une connexion soit établie ou que 6 tentatives de connexions aient échouées.