0365 : Quand une fonctionnalité en chasse une autre / Team Accès invité VS MailUser

English version here

Bonjour

Il y a quelque temps nous avions identifié que si des personnes (Mail user) ou compte utilisateur avec l’adresse email renseignée dans le champs mail de votre Active Directory étaient présent dans l’environnement Azure Active Directory de votre tenant, alors ces personnes ne pouvaient être invité en tant qu’invité dans Teams. A priori je dirais que cela est confirmé. La fonctionnalité MAIL user dans Office 365 ne peut plus être utilisée si vous désirez que ces personnes aient la possibilité d’être invité dans team. Car si l’utilisateur peut etre résolu alors ce dernier sera considéré comme interne. Si vous êtes en mode hybride voici le plan d’action que je propose

La situation

• Tous les comptes Utilisateurs avec extension de messagerie (Mail User) sont synchronisés en tant que tel dans 0365
  • Cette synchronisation les fait apparaitre dans le carnet d’adresse de Exchange Online et Exchange On Prem. Teams ne peut pas les voir en tant que personne externe car considéré comme Internes
• Tous les comptes utilisateurs avec l’adresse de messagerie (dans le champ mail) renseignée sont synchronisés en tant que tel dans 0365
  • Cette synchronisation ne les fait apparaitre ni dans Exchange Online ni dans Exchange on Premise. Teams ne peut pas les voir en tant que personne externe, car considéré comme Internes

     

Solution recommandée pour les utilisateurs avec Extension de messagerie (Mail User)

• Inventaires de leurs appartenances aux listes de distribution Exchange
• Conversion de tous les utilisateurs avec Extension de messagerie en tant que Simple utilisateur Active Directory
• Création d’un contact de messagerie avec leur adresse email dans l’environnement 0365 ou Onprem avec synchronisation vers Azure AD
• Repositionnement dans les listes de distribution

Solution recommandée pour les utilisateurs dont l’adresse de messagerie est renseignée dans le champs mail Active Directory

• Arrêt de la synchronisation de ses comptes dans l’environnement 0365

 

 

Publicités

Activation de l’accès invité Team / changement

Bonjour

Pour information les procédures d’activation de l’accès invités dans team tel que documenté par Microsoft ici

https://docs.microsoft.com/fr-fr/microsoftteams/guest-access

ne sont plus valable.

L’activation se fait directement dans l’espace dédié à Team et à Skype : https://admin.teams.microsoft.com/company-wide-settings/guest-configuration

Après avoir activé cette fonctionnalité nous avons remarqué qu’il n’était pas possible d’inviter quelqu’un car team ne reconnaissais pas cette personne comme externe, alors que celle-ci possédait bien un compte sur un autre Tenant 0365

Nous avons ouvert un incident. Le support Microsoft nous a fait exécuter le script suivant.

Install-Module AzureADPreview -Verbose -AllowClobber -Scope CurrentUser
AzureADPreview\Connect-AzureAD
$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq « group.unified »}
$settingsCopy = $template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $settingsCopy
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value « Group.Unified » -EQ).id
$settingsCopy = Get-AzureADDirectorySetting –Id $settingsObjectID
$settingsCopy[« AllowGuestsToAccessGroups »] = « true »
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
(Get-AzureADDirectorySetting –Id $settingsObjectID).Values
$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq « group.unified »}
$settingsCopy = $template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $settingsCopy
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value « Group.Unified » -EQ).id
$settingsCopy = Get-AzureADDirectorySetting –Id $settingsObjectID
$settingsCopy[« AllowToAddGuests »] = « true »
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
(Get-AzureADDirectorySetting –Id $settingsObjectID).Values
Read-Host -Prompt « Press Enter to Quit »

Mais cela n’a pas suffi à résoudre le problème immédiatement. Le processus d’activation des accès invités peut prendre un peu de temps selon le support. Donc soyons patient : 11 Octobre 2018 11 :15 Après 12 heures nous refaisons le test et la …. Magie

 

Autodiscover Outlook 0365 / Partie 1

Dans l’environnement Office 365, les problèmes de connexion voire d’authentification peuvent être nombreux et peuvent être issu de différentes causes. Dans cet article nous allons expliquer comment procéder pour déterminer la causalité de ces problèmes de connexion.

Nous attacherons spécifiquement au client Outlook 2016 dans un environnement Windows 7 ou Windows 10. L’objectif de ce document est donc de vous proposer une méthodologie d’investigation qui devrait vous permettre de comprendre et de résoudre ses problèmes récurrents.

Les problèmes d’authentification de connexion dans un environnement Office 365 peuvent avoir effectivement plusieurs causes. Ces causes sont souvent directement liées à l’environnement de production mais également à l’environnement de connexion.

En effet le client Outlook réagit, s’adapte en fonction de l’environnement qu’il soit uniquement basé sur Office 365, ou basé sur un environnement hybride, comportant des serveurs Microsoft Exchange sur site, et une partie des boîtes aux lettres sur Exchange Online.

Selon votre environnement, et selon l’emplacement des ressources auxquelles Outlook va tenter d’accéder le diagnostic sera plus complexe à établir. En effet dans les environnements hybrides il n’est pas rare de constater qu’une partie des ressources de type boîte aux lettres soit répartie entre les deux environnements Exchange Online et Exchange sur site. Dans ce cas, le client Outlook devra vraisemblablement se connecter sur ses deux environnements et il est possible que vous constatiez des fenêtres d’authentification liée spécifiquement à un environnement bien déterminé. L’objectif de ce document est donc de vous familiariser avec ces processus de connexion pour vous puissiez déterminer quelle en est la cause.

Cas 1 : toutes les ressources de messagerie sont hébergées sur Exchange Online

Pour commencer nous allons partir d’un cas très simple qui consiste à considérer que toutes les boîtes aux lettres ainsi que toutes les autres sources de messagerie, sont hébergées dans l’environnement Exchange Online.

Dans ce cas précis environnement hybride n’existe pas. Si vous rencontrez des problèmes de connexion à ce stade, la première chose à faire, et de vérifier via un client Web si vous pouvez avoir accès à la boîte aux lettres. Cette première étape qui permettra de savoir si la boîte aux lettres est correctement paramétrée et si celle-ci est fonctionnelle. Dans la plupart des cas la connexion va s’effectuer via une interface Web et une authentification dite moderne. C’est authentification va générer un jeton d’accès qui sera réutilisé si celui-ci n’est pas effacé, lors des connexions suivantes, évitant à l’utilisateur de ressaisir ces informations connexion.

Si vous avez pu avoir accès à la boîte aux lettres de l’utilisateur c’est que celle-ci fonctionne correctement. Reste alors à savoir pourquoi le client Outlook ne se connecte pas.

La plupart du temps, les problèmes de connexion d’un client Outlook vers Exchange Online, proviennent de deux facteurs que sont la résolution DNS et les services de proxy. Ainsi la première chose à faire, et de vérifier depuis le poste de travail en question si la résolution DNS vers les services Office 365 est correcte et si les services proxy ne vous empêchent pas de vous connecter à l’environnement Exchange Online.

Pour ce qui est du DNS voici quelques vérifications que vous devez effectuer. En utilisant une fenêtre de commande depuis la station de travail, effectuez les commandes suivantes et vérifier que la résolution DNS fonctionne en plus du Ping.

Si la résolution de ces deux noms ne fonctionne pas alors il s’agit d’un problème DNS. Si cette résolution fonctionne, nous allons vérifier que la connexion via le protocole https peut s’effectuer. Pour cela nous allons utiliser le programme client Telnet qu’il vous faudra peut-être installer sur la machine Windows. En utilisant les deux commandes suivantes, vous allez tenter depuis le poste en question une connexion sur le port 443 utilisée par le protocole https vers les points de connexion Exchange Online.

Si la connexion s’établit l’écran sur sa fiche avec un curseur qui clignote.

Dans le cas contraire l’interface de commande vous renvoi un message d’erreur.

Si vous ne parvenez pas à établir ses connexions cela signifie que le port 443 n’est pas ouvert vers l’environnement Office 365 ou que votre serveur proxy vous empêche d’établir ces connexions. Pour vérifier la connexion via votre serveur proxy si votre station de travail en utilise un, utilisez cette technique.

Depuis votre explorateur essayer de joindre cette URL

https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml

Vous devriez être inviter à entrer vos informations de connexion.

Dans le cas contraire soit le port 443 est fermé soit votre serveur proxy ne vous autorise pas accéder à cette ressource. En entrant vos informations de connexion vous devriez obtenir le résultat suivant

 

Cela peut provenir soit de votre système de protection installée sur votre poste de travail, soit de votre pare-feu qui protège votre réseau local d’Internet.

Dans ce cas il faudra prendre contact avec les services de votre entreprise pour vérifier faire ouvrir ses ports de connexion à destination des services Exchange Online.

Pour comprendre comment s’établi la découverte automatique d’un client Outlook vous devez assimiler les différentes étapes que ce dernier parcours dans sa quête de boite aux lettres. Elles sont au nombre de 11 et sont détaillées ci-dessous :

Etape d’autodécouverte suivie par le client Outlook 2016

Étape 1 : Vérification des scénarios de redémarrage

Dans certains cas, par exemple lorsque vous ajoutez un deuxième compte pendant l’exécution d’Outlook, l’information Autodiscover est mise en cache dans un fichier local pour être utilisée lors du redémarrage du client Outlook. La toute première étape d’Autodiscover est de vérifier dans le registre les informations spéciales de « boot » qui indiquent à Outlook que vous êtes au milieu d’un de ces scénarios de redémarrage et de lire l’information d’Autodiscover dans le fichier local spécial.

Étape 2 : Vérification de la préférence pour les données locales

Outlook fournit une GPO permettant aux administrateurs de déployer un fichier XML Autodiscover spécifique à utiliser pour la configuration. Si l’administrateur a déployé cette clef de registre et créé un fichier autodiscover.xml, Outlook lit l’information Autodiscover de ce fichier. Encore une fois, il s’agit d’un cas rare qui n’est généralement pas la cause des problèmes génériques d’Autodiscover.

Étape 3 : Vérification des données du dernier bien connu (LKG)

Lorsque l’autodiscover récupère avec succès une information XML à n’importe quelle étape, l’information peut être mise en cache localement en tant que configuration « last known good ». Le chemin du dernier bon fichier XML connu provient du profil Outlook.
L’étape LKG sert uniquement à découvrir la configuration de la boîte aux lettres principale. Si la recherche d’Autodiscover concerne une boîte aux lettres non primaire (boîte aux lettres alternative, déléguée, dossier public, boîte aux lettres de groupe, et ainsi de suite), l’étape LKG est alors automatiquement ignorée.

Étape 4 : Vérifier si O365 est prioritaire

Outlook utilise une méthode heuristique pour déterminer si le compte utilisateur fourni provient d’Office 365. Si Outlook détermine que vous êtes un utilisateur O365, il essaie de récupérer l’information Autodiscover à partir des points de connexion O365 connus (généralement https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml ou https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). La clef de registre servant à contrôler ce comportement est : ExclureExplicitO365Endpoint.

Étape 5 : Vérification des données SCP

Si l’ordinateur est relié à un domaine, Outlook exécute une requête LDAP pour récupérer les données du point de connexion de service qui renvoie un chemin d’accès du fichier XML Autodiscover. Chaque URL renvoyée par la recherche SCP est ensuite essayée pour tenter de récupérer l’information Autodiscover. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 6.

Etape 6 : Vérifier le domaine racine

Pour cette étape, Outlook construit une URL à partir du nom de domaine de l’adresse initiale dans le format https://<domain>/autodiscover/autodiscover.xml et essaie de récupérer l’information de l’URL résultante. Comme de nombreux domaines racine ne sont pas configurés pour Autodiscover, Outlook réduit volontairement au silence les erreurs de certificat qui se produisent pendant la tentative de récupération. Si cette étape ne permet pas de récupérer une information Auodiscover, Outlook passe à l’étape 7.

Etape 7 : Vérifier le domaine Autodiscover

Pour cette étape, Outlook construit une URL à partir du nom de domaine de l’adresse initiale dans le format https://autodiscover.<domain>/autodiscover/autodiscover.xml et essaie de récupérer l’information de l’URL résultante. Comme il s’agit de l’URL principale généralement utilisée pour les données Autodiscover, Outlook ne supprime pas les erreurs de certificat qui se produisent lors de la tentative de récupération. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 8, dont la valeur de contrôle est la suivante : ExclureHttpsAutoDiscoverDomain.

Étape 8 : Vérification des données locales

Dans l’étape 2, Outlook a vérifié si l’administrateur avait déployé une stratégie pour vérifier spécifiquement l’information Autodiscover en tant que préférence. S’il n’y a pas de politique en place, mais que les étapes précédentes n’ont pas permis de récupérer une information, Outlook tente de récupérer une information à partir du fichier local, même sans le paramètre PreferLocalXML en place. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 9.

Etape 9 : Vérifier les redirections Http

Pour cette étape, Outlook envoie une requête à l’URL du domaine Autodiscover (http://autodiscover.<domain>/autodiscover/autodiscover.xml) et teste les réponses de redirection. Si une information XML Autodiscover réelle est retournée et non une redirection, Outlook ignore la réponse XML Autodiscover réelle car elle a été récupérée sans sécurité (http). Si la réponse est une URL de redirection valide, Outlook suit la redirection et tente de récupérer une information XML depuis la nouvelle URL. Outlook effectuera également des vérifications de certificats pour empêcher la redirection vers des URL potentiellement nuisibles lors de cette étape. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 10. Vous pouvez contrôler ce comportement via la clef de registre : ExclureHttpRedirect.

Étape 10 : Vérifier les données sur les SRV

Pour cette étape, Outlook fait une requête DNS en « _autodiscover._tcp.<domain name> » et parcourt les résultats à la recherche du premier enregistrement qui utilise https comme protocole. Outlook essaie alors de récupérer l’information à partir de cette URL. Si cette étape ne permet pas de récupérer une information, Outlook passe à l’étape 11. Vous pouvez contrôler ce comportement via la clef de registre : ExclureSrvRecord

Étape 11 : Vérification de l’O365 en tant que Sécurité-Défaut

Si toutes les étapes précédentes n’ont pas retourné une information d’autodécouverte, Outlook utilise une méthode heuristique moins restrictive pour décider si une dernière tentative aux points de connexion O365 est potentiellement utile. Si Outlook décide qu’une tentative en vaut la peine, il essaie les points de connexion Autodiscover connus au cas où le compte est un compte O365. Cette tentative utilise les mêmes URL cibles que l’étape 4, et ne diffère que par le fait qu’elle est utilisée en dernier recours et non plus tôt dans le processus Autodiscover. Vous pouvez contrôler ce comportement via la clef de registre : ExclureExplicitO365Endpoint.

L’emplacement des clef de registre peuvent étre trouvée ici HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover et pour rappel sont les suivante

• PreferLocalXML
• ExclureHttpRedirect
• ExclureHttpsAutoDiscoverDomain (DécouverteDomaine)
• ExclureHttpsRootDomain
• ExclureScpLookup
• ExclureSrvRecord
• ExclureLastKnownGoodURL (s’applique uniquement à Outlook 2010 version 14.0.7140.5001 et versions ultérieures)
• ExclureExplicitO365Endpoint (s’applique uniquement à Outlook 2016 version 16.0.6741.2017 et versions ultérieures)

Comment connaitre la méthode que votre Outlook Utilise pour retrouver l’information Autodiscover ?

Vous pouvez utiliser les étapes suivantes dans Outlook pour déterminer la méthode par laquelle Outlook essaie de récupérer les informations d’Autodiscover dans Exchange :

Lancez Outlook.

• Appuyez sur la touche CTRL, cliquez avec le bouton droit de la souris sur l’icône Outlook dans la zone de notification, puis cliquez sur Test E-mail AutoConfiguration.
• Vérifiez que l’adresse e-mail est correctement saisie dans la zone Adresse e-mail.
• Entrez votre mot de passe si vous n’êtes pas connecté à un domaine ou si vous accédez à une boîte aux lettres différente de la vôtre.
• Cliquez sur pour décocher les cases Utiliser Guessmart et Authentification Guessmart sécurisée.
• Cliquez sur Tester.
• Passez en revue les détails dans l’onglet Journal.

Dans la seconde partie nous étudierons le comportement d’autodécouverte en environnement Hybride

Laurent TERUIN

 

 

 

 

 

 

 

BitTitan: Failed to validate endpoint Autodiscover (403 Forbiden)

When creating a connection point through the Bititan interface you may have noticed that communication between BT services and your Exchange 2010 could not be established.

The error message is as follows:

Failed to validate endpoint Autodiscover cloudMenow of type ExchangeServer.
Exchange Error: (403) Forbidden{« $type »: »System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.String, mscorlib]], mscorlib », »errorCode »: »EndpointValidationFailure », »Message »: »Failed to validate endpoint Autodiscover cloudMenow of type ExchangeServer.\nExchange Error: (403) Forbidden »}

IF you test from the Microsoft remote connectivity you can observe this

Exception details:
Message: The request failed. The remote server returned an error: (403) Forbidden.
Type: Microsoft.Exchange.WebServices.Data.ServiceRequestException
Stack trace:
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
at Microsoft.Exchange.WebServices.Data.ExchangeService.InternalBindToFolders(IEnumerable`1 folderIds, PropertySet propertySet, ServiceErrorHandling errorHandling)
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.Tools.ExRca.Tests.GetOrCreateSyncFolderTest.PerformTestReally()
Exception details:
Message: The remote server returned an error: (403) Forbidden.
Type: System.Net.WebException
Stack trace:
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)

Elapsed Time: 437 ms.

 

To fix that I try to configure EWS with these options

Set-OrganizationConfig -EwsApplicationAccessPolicy:$null (Not Sufficient)
set-casmailbox -Identity bittitan -EwsEnabled:$true (Not Sufficient)
get-casmailbox -Identity bittitan | set-casmailbox -EwsApplicationAccessPolicy:$null (Not Sufficient)
get-casmailbox -Identity bittitan | set-casmailbox -EwsBlockList:$none (Not Sufficient)
get-casmailbox -Identity bittitan | Set-CASMailbox -EwsAllowEntourage:$true (Not Sufficient)
get-casmailbox -Identity bittitan | Set-CASMailbox -EwsAllowMacOutlook:$true(Not Sufficient)

Set-OrganizationConfig -EwsEnabled:$true (Not Sufficient)
Set-OrganizationConfig -EwsBlockList:$none

 

Trying to open directly the URL from an Internal Machine.

And…. It is working internaly !

So let see what’s going on on my old TMG2010.

And surprise on the listener that use the publication rules (Sounds Not Good right? )

Let change that with

and the result is (With Remote Connectivity)

So now lets try to check with bittitan .

 

 

 

 

 

 

 

Impossible d’inviter une personne invitée dans l’environnement Team

Si dans votre tenant vous avez ouvert l’environnement Team pour les accès invités, il est possible que celui-ci ne fonctionne pas dans le cas suivant :

John.doe@mothercompany.com partage un Teams pour inviter John.adams@subcontractorcompany.com qui se trouve être un compte 0365 sur un autre tenant. Ce dernier possédant une licence E1 ou E3 sur le tenant 0365 hébergeant subcontractorcompany.com

Lors du partage l’application team résout ce nom car john.adams possède un simple compte Active Directory avec dans le champ mail son adresse de messagerie externe. De plus ce compte est synchronisé depuis votre active directory vers 0365.

La solution pour résoudre ce problème passe par

• Soit la non synchronisation de ce compte dans Office 365
• La suppression de son adresse Email dans son compte Active Directory

Cordialement

WARNING : Impossible de vous connecter après la mise à jour vers Office 2016 build 16.0.7967 ou version ultérieure sous Windows 10.

Vous pouvez avoir des problèmes de connexion avec les symptômes suivants :

• « we couldn’t connect to one of the services we needed to sign you in.0XCAA70007 »
• Need Password
• Demande d’authentification intempestives sous Outlook 2016
• Lorsque vous essayez d’ouvrir ou d’enregistrer un document dans Microsoft SharePoint en ligne, OneDrive pour les entreprises ou SharePoint, vous êtes invité à entrer vos identifiants. Une fois que vous avez saisi vos informations d’identification, le système vous invite à nouveau à le faire.
• Les clients Office ProPlus vous invitent à vous connecter via un écran d’activation même si vous êtes déjà activé. Lorsque vous entrez une valeur de UserID ou UserPrincipalName, l’écran disparaît avant que vous puissiez entrer le mot de passe.
• {« Action »: « BlockedRequest », « HRESULT »: « 0xc0f10005 » dans un environnement VDI lors de l’activation

 

Par défaut, Microsoft Office 365 ProPlus (version 2016) utilise l’authentification basée sur le framework Azure Active Directory Authentication Library (ADAL). À partir de la version 16.0.7967, Office quant à lui, utilise la couche Web Account Manager (WAM) pour les connexions sur les versions Windows postérieures à 15000 (Windows Version 1703, build 15063.138).

 

Pour éviter des problèmes de connexion vous pouvez ajouter la valeur de registre suivante

• [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
• « DisableADALatopWAMOverride »=dword:00000001

Remarque Après la publication d’un correctif pour ce problème, vous devez supprimer cette solution de contournement du registre, sinon les expériences d’authentification risquent d’être dégradées. Cette valeur de registre ne doit pas être utilisée comme une solution à long terme. Microsoft devrait apporter un correctif bientôt.

 

Azure AD Connect / Intégration avec Ping Federate

 

L’intégration de la configuration PingFederate avec l’assistant Azure AD Connect est désormais disponible. Ceci devrait offrir aux clients de PingFederate une méthode simple et fiable pour fédérer Active Directory sur site avec Azure AD. La configuration de PingFederate et Azure AD offre aux clients un accès transparent et sécurisé à Office 365.

L’adoption des options d’authentification AD Cloud d’Azure augmente incroyablement rapidement, mais la plupart des grandes entreprises choisissent toujours d’utiliser des serveurs de fédération. Parmi les grandes entreprises, la plupart de nos clients utilisent ADFS, le serveur de la fédération de Microsoft. Mais PingFederate est aussi un choix très populaire et est utilisé pour authentifier plus de quatre millions d’utilisateurs uniques d’Azure AD chaque mois. Ainsi, simplifier la configuration de PingFederate pour travailler avec Azure AD est un excellent moyen de faciliter la gestion des déploiements de cloud hybride pour ces clients.

Pour voir comment fédérer Azure AD avec PingFederate, lisez notre documentation Configurer la fédération avec PingFederate. Visitez la page des partenaires Ping Identity et Microsoft pour en savoir plus sur la sécurisation de l’accès à toutes les applications pour des millions d’employés de l’entreprise.

Business Email Reflections

When we centralize Email with Exchange Online and remove local SMTP servers in subsidiaries or remote locations, the question arises as to which model we want to propose so that the business applications of the different agencies will continue to be able to send emails.

Some of them, sometime, send a large number of electronic messages for business needs. The question is therefore to determine which model should be adopted, to allow its agencies to legally send messages to the Internet.

Communicating applications.

The applications that have the need to send messages can be diverse and varied. These can be printers, scanners whose configuration must be done locally, but also business applications directly in relation to customers and therefore can be particularly sensitive.

In most cases, changing the parameters of its applications, scanners, printers, monitors are very time consuming for the Agencies. In addition, some applications can be complex to update. To complicate matters, some of them do not know how to use encryption layers or simply cannot authenticate themselves on a mail server.

The question is therefore which model should be proposed to take all these constraints into account and ensure that agencies can continue to use electronic messaging, without calling into question a level of control and security that could be described as satisfactory.

Two models can be proposed.

Centralized model

The first consists in specifying to each agency that they must change all of its business applications to use a simple and unique centralized SMTP service (UCSS) located in a unique datacenter

In this case the services of this UCSS for security reasons will have to set up access controls for each application that does not know how to authenticate itself. For applications that can authenticate themselves, UCSS will have to create application accounts for each remote application.

For each new application, agencies will have to apply for an authorization

This model certainly works but does not take into account the risks linked to the breakage of interconnection lines which could generate the need to reassign smtp service, quickly if the case arises the messaging flow to another SMTP relay. (Changing SMTP settings on each application can indeed generate several days of work).

it will also imply a heavier workload for the teams in charge of this UCSS

This model also implies that each Subs station sending SMTP streams to UCSS is identifiable by its IP address, which can be complicated in the case where address translation is used.

The following picture illustrates a possible centralized SMTP service organization

 

Distribution model

The distribution model consists in keeping a smtp relay in each Subs that can be used by local applications. This SMTP server will be from a UCSS, easily identifiable by its unique IP address but also by the fact that it will use authentication mode.

Thus, in the event of a problem with the Subs, the UCSS site can easily « turn off the tap » by simply deactivating the connector account.

In addition, firewalls could be set to leave only the SMTP stream from that IP address precisely, eliminating the risk of attack from different remote internal workstations.

In case the company would like to move the SMTP service point, only the Subs SMTP server would be concerned, unlike the centralized model, where the change would have to take place on all applications of the entire company environment.

This model would allow a better reactivity, and a load distribution towards the agencies which would not have any more the need to have to declare centrally each business application having to send messages.

It is also compatible with the possible presence of address translation provided that an IP address translation (1 For 1) for the Local SMTP server can be established between the company network and the agency network.

This model is also much more tolerant to possible MPLS or VPN link breaks that could occur between the Subs networks and the UCSS network.

Safety issues

In terms of security, I think it is important that the company, which will bear the main burden of forwarding the messages of each Subs, should at least

• be able to quickly identify the emission source
• close the communication tunnel in the event of « mail flooding » for example.

In both cases you should be making recommendations to the Subs to establish a clear and documented service agreement with them.

Laurent TERUIN

Microsoft Teams pour Windows Phone est en train d’être retirée.

L’application Windows Phone pour Microsoft Teams doit être retirée. Après l’entrée en vigueur de ce changement, cette application ne sera plus disponible en téléchargement sur Microsoft Store, et Microsoft ne fournira plus de support.

Bien que Microsoft continue de prendre en charge Windows 10 Mobile, ils ne se concentrons pas sur la création de nouvelles fonctionnalités pour le système. Ils continueront d’investir dans les applications mobiles Microsoft Teams pour iOS et Android et dans les applications de bureau pour Windows et Mac.

À compter du 20 juillet 2018, l’application Microsoft Teams pour Windows Phone ne sera plus disponible sur le Microsoft Store. Les utilisateurs actuels pourront continuer à utiliser l’application jusqu’au 20 octobre 2018. Après le 20 octobre, l’application Microsoft Teams ne fonctionnera plus et les utilisateurs recevront un message d’erreur lorsqu’ils tenteront de se connecter.

Si vous avez besoin de continuer à utiliser Microsoft Teams sur Windows Phone, nous vous recommandons d’installer l’application avant le 20 juillet 2018. Cependant, sachez que l’application ne fonctionnera plus après le 20 octobre 2018.

Cordialement

Laurent TERUIN

Un service Web pour la gestion des points de terminaison 0365

Microsoft a récemment publié un article sur Office 365 qui fournit des conseils pour obtenir des performances et une connectivité optimale à ces services. Le premier de ces principes est d’identifier et de différencier le trafic réseau Office 365 en utilisant les points de connexion publiés par l éditeur. Ces points de connexion comprennent les adresses IP et les URL utilisées pour se connecter à Office 365 mais également des niveaux de criticité.

Microsoft a donc publié un aperçu d’un nouveau service Web qui publie ces points de connexion. Ce qui devrait faciliter l’évaluation, la configuration et la gestion des mise à jour apportées aux points de connexion d’Office 365. Ces services Web remplaceront les données HTML, XML et RSS publiées à ce jour sur http://aka.ms/o365ip. La documentation d’utilisation des services Web d’adresse IP et d’URL est détaillée dans Managing Office 365 Endpoints – Web Service.

Microsoft publie donc trois catégories pour les points de connexion réseau Office 365

• Optimisé : pour un petit nombre de points de terminaison qui nécessitent une connectivité « sans entrave » à faible latence qui devrait contourner les serveurs proxy, le réseau SSL, les dispositifs d’inspection.
• Autorisé : un nombre plus important de points de connexion qui doivent bénéficier d’une connectivité « sans entrave » à faible latence. Microsoft recommande pour ces derniers de contourner les serveurs proxy, de ne pas « couper » le flux SSL et d’éviter l’inspection SSL. Une bonne connectivité à ces points de terminaison est en somme, nécessaire pour que Office 365 fonctionne normalement.
• Par défaut : Sont concerné, les autres terminaux Office 365 qui peuvent être dirigés vers la sortie Internet par défaut.

Les avantages de ce service Web Office 365 IP Address et URLs et les nouvelles catégories sont les suivants :

• L’Automatisation de la publication des données et des modifications des points de terminaison Office 365
• Données lisibles par le système pour l’intégration directe des périphériques réseau, compatibles le scripting.
• Données disponibles au format JSON pour les scripts ou au format CSV pour Excel.
• Inclut la première version de la nouvelle version Optimisé, autorisé, & par Défaut
• Inclut l’indication « ExpressRoute routable » pour chaque point d’extrémité.
• Avis de changement de version publié en même temps que les données.
• Tous les attributs fournis sont supportés par des équipes de développement.
• Bientôt disponible : Modèles de fichiers PAC basés sur les détails des points de terminaison.

Cordialement

Laurent TERUIN

https://support.office.com/en-us/article/managing-office-365-endpoints-99cab9d4-ef59-4207-9f2b-3728eb46bf9a#ID0EADAAA=4._Web_service&ID0EACAAA=4._Web_service