PI Services

Le blog des collaborateurs de PI Services

[O365] - Extraire la liste des OneDrive qui sont partagés avec des externes.

Si un jour vous souhaitez faire un état des lieux de ce qui est déjà en place en terme de partage, voici quelques liges de Powershell qui permettent de sortir la liste des OneDrive ayant un partage avec un invité.

Prenez soin de remplacer l'url de connexion au portail d'admin Sharepoint.

# Connect to Sharepoint Online
Connect-SPOService -Url https://MonTenant-admin.sharepoint.com/

# Collect all Sharepoint Sites and filter on OneDrive
$AllOneDrive = Get-SPOSite -IncludePersonalSite $true -Limit all -Filter "Url -like '-my.sharepoint.com/personal/'"

# Define variabes 
$ArrayOneDriveMembers = @()
$SortOneDrive = $AllOneDrive | sort Url

$SortOneDrive | foreach {
    $OneDriveUrl = $_.Url
    $OneDriveOwner = $_.Owner
    $OneDriveStorageQuota = $_."Storage Quota"
    $OneDriveTitle = $_.Title
    # Get the list of members for the current OneDrive
    Try {
        $OneDriveMembers = Get-SPOUser -Site $OneDriveUrl -ErrorAction stop
        }
    Catch {
        Write-Output "$OneDriveUrl;$OneDriveTitle" | Add-Content C:\temp\Onedriveerrors.txt
        }
    
    # Define a new variable
    $OneDriveExternal = $OneDriveMembers.where({$_.Usertype -eq "Guest"})

    # Check if the new variable is empty, if not collect logs
    If ($OneDriveExternal.count -ne 0) {
        
        # Display some informations
        Write-Host "External Users are present in $OneDriveTitle" -ForegroundColor Green
        $OneDriveExternal.count

        # Store Data
        $OneDriveExternal | foreach {
            $DisplayName = $_.DisplayName
            $LoginName = $_.LoginName
            
            $ArrayOneDriveMembers += New-Object psobject -Property @{
                OneDriveUrl = $OneDriveUrl
                OneDriveOwner = $OneDriveOwner
                OneDriveStorageQuota = $OneDriveStorageQuota
                OneDriveTitle = $OneDriveTitle
                DisplayName = $DisplayName
                LoginName = $LoginName
                }
            # Release Variables
            $DisplayName = $null
            $LoginName = $null
            }
        }
    
    # Release variables
    $OneDriveUrl = $null
    $OneDriveOwner = $null
    $OneDriveStorageQuota = $null
    $OneDriveTitle = $null
    $OneDriveMembers = $null
    }

$ArrayOneDriveMembers | Export-Csv c:\temp\ExternalOneDriveMembers.csv -Encoding UTF8 -Delimiter ";" -NoTypeInformation

 

Azure - Combiner les informations de sécurité SSPR et MFA

SSPR et MFA

Face aux nombreuses attaques informatique ces dernières années, les entreprises répondent en renforçant la sécurité de leur système d'information (SI).

SSPR (Self-Service Password Reset) et MFA (Multi-factor authentication) y contribuent.

SSPR permet à un utilisateur de réinitialiser son mot de passe dans Azure de façon autonome via des méthodes de récupération qu'il aura configuré préalablement, SMS, appel téléphonique, questions secrètes..

MFA demande à un utilisateur un deuxième moyen de prouver son identité, c'est par exemple parfois le cas suite à un achat en ligne, un code à usage unique (OTP) pour valider la transaction est envoyé par SMS à un téléphone dont le numéro a été communiqué au fournisseur de service en amont. D'autres méthodes existent tel que l'application Microsoft Authenticator ou l'appel d'un numéro de téléphone.

 

On observe donc que certaines méthodes d'authentification sont communes entre SSPR et MFA, les utilisateurs seront donc invités à renseigner plusieurs fois les mêmes informations ce qui détériore leurs expériences et par conséquent amoindris leurs adhésions à ces outils.

 

Combiner les informations de sécurité SSPR et MFA

 

Il existe dans Azure un paramètre qui permet de combiner les informations de sécurité SSPR et MFA.
Se connecter avec un compte administrateur global à portal.azure.com > User settings > Manage user feature settings

 

Choisir ensuite All dans User can use the combined security information registration experience

Selected permet d'activer ce paramètre pour des utilisateurs nominatif

 

Pour aller plus loin

Documentation officielle Microsoft sur la combinaison des informations de sécurité SSPR et MFA

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

Azure PowerShell - Forcer la connection à 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.

Azure Accès Conditionnel - Les dépendances de Teams

Vous avez créé un accès conditionnel pour bloquer toutes les applications à l'exception de Teams mais Teams est toujours bloqué ?

 

Vous êtes au bon endroit, cet article vous explique tout ce qu'il y a à savoir sur les dépendances de Teams dans l'accès conditionnel Azure.

 

La configuration de l'accès conditionnel

Commençons par rappeler la configuration de l'accès conditionnel dont il est question:

Ci-dessous l'utilitaire qui permet de créer un accès conditionnel :

  • Block access
    • Cet accès conditionnel applique un refus de connexion (en opposition à grant/autoriser)
  • All cloud apps included and 1 app excluded
    • Cet accès conditionnel concerne toutes les applications Azure à l'exception d'une application
  • Exclude 
    • Permet d'exclure des applications de l'accès conditionnel
  • Microsoft Teams
    • Teams est exclu de l'accès conditionnel

 

Les dépendances de Teams

Teams est dépendant d'autres applications Microsoft : SharePoint, Exchange, Planner, etc.

Ces applications doivent être également exclues dans l'accès conditionnel pour que Teams puisse fonctionner pleinement.


A noter qu'il existe deux types de dépendances :

  • Des applications qui sont Early-bound policy enforcement
    • Cela signifie que la vérification que l'application dont dépend Teams est présente dans l'accès conditionnel se fait avant la connexion de l'utilisateur. En d'autres termes si l'application n'est pas dans la liste d'exclusion de l'accès conditionnel l'utilisateur ne pourra pas se connecter.
  • Des applications qui sont Late-bound policy enforcement
    • En opposition au Early-bound policy enforcement, l'utilisateur pourra se connecter à Teams mais ne pourra pas bénéficier des services d'une application non exclue dans l'accès conditionnel

 

Voici un schéma récapitulatif :

  • Les traits pleins sont des Early-bound policy enforcement
  • Les traits en pointillés sont des Late-bound policy enforcement

 

 

 

Pour aller plus loin


Article officiel de Microsoft sur les dépendances de Teams dans l'accès conditionnel

O365 : Forcer le changement de mot de passe

Il arrive dans certain cas de figure que nous souhaitions forcer le changement de mot de passe des comptes O365.

S'il s'agit d'un seul utilisateur voici la commande :

Set-MsolUserPassword -UserPrincipalName jdupont@mondomaine.com -ForceChangePasswordOnly $true -ForceChangePassword $true

Prenez soin de modifier le Userprincipalname de la commande sous peine d'obtenir une erreur.

 

En revanche si l'on veut forcer l'intégralité de la société à changer de mot de passe cela va nécessiter quelques lignes de plus.

# Variables
$LogFolder = "C:\temp"
$LogFile = "$LogFolder\LogO365_Reset.txt"
$LogFileError = "$LogFolder\LogO365_Reset_Error.txt"

# check
If (!(Test-Path $LogFolder)) {
    New-Item $LogFolder -ItemType Directory
    }

# Exceptions
$FilteredUsers = "Userprincipalname1", "Userprincipalname2", "Userprincipalname3" # Ajouter les UPN à ne pas reset (exemple  le compte Admin du Tenant)

# Connect to O365
Connect-MsolService

# Get users
$AllUsers = Get-MsolUser -MaxResults 10000 | select UserPrincipalName

# Force to change Password
$AllUsers | foreach {
    $UPN = $_.UserPrincipalName
    If ($FilteredUsers -eq $UPN) {
        Write-Host "Do not reset Password For $UPN because we had filtered him" | Add-Content $LogFile
        }
    Else {
        Try {
            Set-MsolUserPassword -UserPrincipalName $UPN -ForceChangePasswordOnly $true -ForceChangePassword $true
            Write-Output "Succesfully reset Password For $UPN" | Add-Content $LogFile
            }
        Catch {
            $Date = Get-Date
            Write-Warning "At $Date the following Error Appear $($_)" | Add-Content $LogFileError
            }
        }
    }

 

Bon courage au service IT pour le nombre d'appel qu'il va recevoir. 

 

O365 : Réaliser un hard match

 

Comme expliqué dans l'article précédent "O365 : Soft Match (SMTP) et Hard Match (ImmutableID)" le Hard Match intervient lorsque le Soft Match n'a pas fonctionné.

Les étapes à suivre sont les suivantes:

  1. Récupérer le GUID du compte dans l'Active Direcotry
  2. Convertir ce dernier en ImmutableID
  3. Appliqué cet ImmutableID au compte Azure Active Directory
  4. Relancer une synchronisation via Ad connect 

Voici donc les commandes pour cela.

# Get GUID for User
$User = Get-ADUser jdupont | select ObjectGUID,UserPrincipalName
$Upn = $User.UserPrincipalName
$Guid = $User.ObjectGUID.Guid

# Convert GUID to ImmutableID
$ImmutableId = [System.Convert]::ToBase64String(([GUID]($User.ObjectGUID)).tobytearray())

# Connect MsolService
Connect-Msolservice

# Set ImmutableID to msoluser
Set-MsolUser -UserPrincipalName $Upn -ImmutableId $ImmutableId

 

Et voila, vous n'avez plus qu'a relancer une Synchor AD Connect via la commande suivante.

Start-ADSyncSyncCycle -PolicyType Delta

 

 

Azure - Activer SSPR

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.