Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

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.

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

Comment déterminer le type de client (OWA, Outlook, Mobile) utilisé pour un mail envoyé

Dans certains cas, on nous demande de déterminer quel type de client a été utilisé pour envoyer un mail particulier. 

Pour ce faire, utiliser les journaux de suivi des messages dans Exchange 2010, Exchange 2013 ou Exchange 2016.

Dans les journaux de suivi des messages, il existe un champ SourceContext qui signale la propriété ClientType pour les événements SUBMIT. Les événements SUBMIT sont générés quand le service de soumission de transport de boîte aux lettres transmet un message au service de transport, c’est-à-dire lorsque le serveur Exchange récupère le courrier électronique de la boîte d’envoi de la boîte aux lettres et le transmet pour remise.

A noter qu’il n’y a pas d’événement SUBMIT lorsqu’un expéditeur externe envoie un e-mail à un utilisateur interne. Cela signifie qu’il n’y a pas de propriété ClientType pour ces e-mails.

  • Pour vérifier le type de client pour un e-mail envoyé, exécuter la commande suivante dans un environnement Exchange powershell et regarder le champ SourceContext pour l’e-mail en question:

Get-MessageTrackingLog -ResultSize Unlimited -Start « 10/20/2021 10:00 » -EventID SUBMIT | fl TimeStamp,Sender,Recipients,MessageSubject,SourceContext

  • La valeur du champ SourceContext peut être :
  • AirSync–> il s’agit du client ActiveSync : le mail est envoyé depuis un périphérique mobile
  • OWA–> il s’agit du client Webmail : le mail est envoyé depuis l’interface exchange web mail
  • MOMT–> il s’agit des clients qui se connectent à l’aide d’Outlook ou toute autre application via RPC/HTTP ou MAPI/HTTP 

 Les e-mails de surveillance ont également un type de client qui est Monitoring