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.

Publicités

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

 

Yammer / 14 mai 2018/ Plus de 16 ans

Le 14 mai 2018, les utilisateurs sans identité Office 365 devront vérifier qu’ils ont plus de 16 ans ou qu’ils perdront l’accès sans intervention de l’administrateur.

[Comment cela peut vous affecter ?]
Les utilisateurs de Yammer qui sont âgés de moins de 16 ans et qui ne sont pas connectés avec une identité Office 365 pourraient être affectés par ce changement.À partir du 14 mai, les utilisateurs qui se connectent à Yammer sans identité Office 365 recevront un message leur demandant d’indiquer leur âge. Si l’utilisateur est âgé de moins de 16 ans, son compte sera suspendu dans Yammer. En tant qu’administrateur, vous serez averti via un message dans Yammer et pourrez réactiver le compte de l’utilisateur dans un délai de 14 jours. Après 14 jours, le compte utilisateur sera supprimé.

(Que devez vous faire pour me préparer à ce changement ?)

Si votre organisation n’inclut pas les utilisateurs de moins de 16 ans, vous n’avez rien à faire pour vous préparer à ce changement. Si l’un de vos utilisateurs est âgé de moins de 16 ans :

1. S’assurer qu’ils ont une identité Office 365 ; ou
2. Si un utilisateur est suspendu, réactiver le compte dans les 14 jours pour éviter la suppression du compte.

 

0365: Offcat disparait

Après avoir fourni pendant plus de cinq ans des informations de configuration et des solutions à des problèmes connus, l’équipe OffCAT prévoit de retirer OffCAT du centre de téléchargement Microsoft le 31 mai 2018. La bonne nouvelle est que les principales fonctionnalités OffCAT ont été consolidées avec l’outil Microsoft Support and Recovery Assistant for Office 365 (SaRA) à l’adresse https://diagnostics.outlook.com/.

Cela simplifiera la gamme d’outils de dépannage disponibles pour Outlook tout en offrant le même niveau de capacités d’analyse Outlook que OffCAT. En outre, SaRA offre également plusieurs améliorations, notamment la possibilité d’identifier et de résoudre des problèmes spécifiques avec Outlook, Office Setup, OneDrive for Business et plusieurs autres programmes Office.

Cordialement

Laurent Teruin

0365: Changement protocole SMTP 1 Juin 2018

Un certain nombre de protocoles clients sont offerts par Exchange Online pour permettre aux clients de courrier électronique d’envoyer des courriels à partir de leur boîte aux lettres. L’un des protocoles les plus répandus est SMTP Authenticated Submission (également connu sous le nom de SMTP Client Submission) qui est supporté par la plupart des fournisseurs de services de messagerie. Ce protocole non exclusif est utilisé pour l’envoi de courriels par les anciens clients de courriel, les logiciels et services de tiers et les appareils tels que les imprimantes multifonctions. Les changements que vont apportez Microsoft vis a vis du fonctionnement de ce protocole dans Exchange Online peuvent avoir une incidence négative sur la vitesse à laquelle ces clients ou appareils peuvent envoyer des courriels.
À compter du 1er juin, les changements suivants commenceront à s’appliquer au protocole de soumission authentifiée SMTP :

Les e-mails envoyés seront désormais stockés dans le dossier Eléments envoyés de la boîte aux lettres.

Seules trois connexions simultanées au service 0365 par boîte aux lettres seront autorisées. Les connexions supplémentaires seront rejetées avec l’erreur : 4.3.2 STOREDRV.ClientSubmit ; limite de thread de l’expéditeur dépassée.

Exchange Online utilise un certain nombre de mécanismes pour protéger le service contre les abus et assurer une utilisation équitable par les utilisateurs. L’une de ces protections est la limite du taux de bénéficiaires (RRL) qui limite le nombre de bénéficiaires par jour à 10 000. Le but est de décourager l’envoi de courriels en vrac (et comme mentionné sur la page des limites de service, vous devriez envoyer des courriels en vrac en utilisant un fournisseur tiers spécialisé). Ce changement du protocole SMTP Authenticated Submission protègera davantage le service contre les grandes rafales de courriels dans un court laps de temps des systèmes automatisés. Cela n’affectera pas la majorité des utilisateurs de SMTP Authentification Submission qui n’envoient qu’à partir d’un seul client de messagerie ou d’un périphérique multifonction pour une boîte aux lettres donnée.

Pour les clients qui ont plusieurs appareils qui envoient des courriels en utilisant la même boîte aux lettres (par exemple, printer@contoso.com), il y a une petite chance que plusieurs appareils tentent d’envoyer des courriels en même temps. Tous les dispositifs qui sont rejetés n’ont qu’à réessayer. Il en va de même si une application qui utilise une boîte aux lettres 0365 pour envoyer des courriels tente d’envoyer plusieurs messages en même temps (et ce comportement dépend de la façon dont l’application a été conçue). La plupart des applications et des appareils qui envoient des courriels devraient être capables de gérer les erreurs et de réessayer d’envoyer des courriels. Cependant, le fait de réessayer réduira le taux global d’envoi de courriels.

Si ce changement vous affecte négativement, vous avez quelques options :

Utilisez une boîte aux lettres différente pour chaque application ou appareil.

Si vous essayez d’envoyer des milliers de copies du même message (par exemple, une newsletter) en parallèle à l’aide d’une application tierce, vous devrez peut-être l’envoyer par lots ou utiliser des groupes de distribution.

Si le temps est important (par exemple, un système d’alerte qui génère plusieurs alertes en même temps), vous devrez utiliser un service de livraison tiers conçu pour envoyer de grandes quantités de courriels.

 

Cordialement
Laurent TERUIN

 

Microsoft Mobile Apps and Autodiscover redirection issue

Hi today we will cope with a redirect issue in a scenario where your company would like to integrate a new subsidiary that have an Active Directory and an Exchange 2010 organization

In this scenario the Corporate forest have a mailuser user account for each mailbox user in the Legacy forest. These mailuser accounts are synchronized with Azure AD connect from the corporate forest to 0365 by Azure Ad connect. Because each mailuser account have the same email address of the primary smtp email address of the mailbox user in the legacy forest Azure AD connect will keep the identity coming from the Corporate forest into0365 and the migrated mailbox from the legacy forest will be assigned to this account (see Multiple forests, single Azure AD tenant scenario at this link https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-topologies)

The question is about the Autodiscover process for the mobile devices

If Outlook Client could manage with multiple redirections and prompt user for authentication, the mobile client could have some restriction. During the migration depending where the autodiscover is set, the Mobile client could fail to connect to the mailbox. But let take an example

John.Doe@legacy.com use an Outlook 2016 and Office 2016 Microsoft Mobile application that use autodiscover from external to retrieve the on-premise connection point. The mobile application is set with an account and password that match the legacy identity of the account in Promise that own the mailbox.

When the mailbox is migrated from this agency in the 0365 tenant environment the mailbox in Office 365 is associated with the User AD account synchronized with the corporate Ad user.

• When a Microsoft Outlook Mobile apps from a 4G will try to get his mailbox, he will perform an autodiscover and will use his agency credentials to get this file from the On-premise organization. Then the mobile will be redirected.
• As this step the redirection we suspect that, it will fail because the Mobile do know how to handle this redirection.

Below is an illustration of this scenario

The question is how to force the mobile to retrieve the new connection point? MDM?, Exchange 2013 Client Access server migration (https://blogs.technet.microsoft.com/exchange/2015/03/23/exchange-activesync-on-boarding-to-office-365/)?

 

 

Exchange 2013 Client Access server migration (https://blogs.technet.microsoft.com/exchange/2015/03/23/exchange-activesync-on-boarding-to-office-365/) solution :

If you read with attention this article it works with a single Corporate forest that have an exchange hybrid organization. In this scenario the solution should works if you follow the requirements below

• All on-premises Exchange 2010 Client Access servers handling EAS requests must be running at least Service Pack 3 RU9.
  
• Exchange 2013 Mailbox roles handling EAS requests must be running CU8.
  
• The EAS version on the device should be 14 or higher, and the device must be able to handle 451 redirect responses.
  
• The Exchange on-premises organization has successfully set up hybrid with their Office 365 tenant.
  
• The OrganizationRelationship object must exist in the on-premises Active Directory environment and the TargetOWAURL should be populated with the Office 365 URL.
  
• The username and password for the user must remain the same after the move to Office 365. The user experience will not be seamless if the username or password is changed after the mailbox is moved to Office 365
  

Some interrogations

• First question: How to know if devices are able to handle 451 redirect responses? On IOS / on Android?
• « The username and password for the user must remain the same after the move to Office 365. The user experience will not be seamless if the username or password is changed after the mailbox is moved to Office 365 ». In our environment the user credentials are not the same because (but could be a solution) we are integrating a new subsidiary with a legacy Active Directory Forest.

One solution that could Works maybe

1. Let assume that regarding the legacy exchange requirement we are using Exchange 2013 last service pack and last RU
2. Let assume that all legacy Mobile users use Microsoft Official Mobile Apps with a UPN Username format against their legacy Exchange Organization
3. Let assume that the same UPN is used in the Corporate Forest and that password is synchronized between the two Active Directories
4. Let assume that we could publish The OrganizationRelationship in the on-premises legacy Active Directory environment and the TargetOWAURL populated with the Office 365 URL.

    

 

Cloud Act : Première réponse de l’europe

La réponse de l’Europe ne s’est pas fait attendre suite à l’adoption du cloud Act par les USA.

• « Unfortunately, the US Congress has adopted the US Cloud Act in a fast-track procedure, which narrows the room for the potential compatible solution between the EU and the US, » she said in a statement. »
  
• « Malheureusement, le Congrès américain a adopté la loi américaine sur les nuages dans le cadre d’une procédure accélérée, ce qui réduit la marge de manœuvre pour une solution potentiellement compatible entre l’UE et les États-Unis », a-t-elle déclaré dans une déclaration.
  

EU justice commissioner Vera Jourova

Pour les personnes qui n’auraient pas suivi : Le CLOUD Act cherche à résoudre la portée extraterritoriale de l’ECPA – en modifiant la Stored Communications Act pour autoriser spécifiquement une entité gouvernementale à obliger un fournisseur américain qui stocke les communications de ses clients (comme les courriels, les textes et les chats) à retourner le contenu de ces communications lorsqu’elles sont stockées dans un autre pays. Les fournisseurs pourraient décider d’annuler ou de modifier si la cible n’est pas une personne des États-Unis et si la conformité serait contraire à la loi du pays où les données sont stockées.

Ce qui est assez amusant dans cette histoire c’est l’Europe reproche à juste titre le caractère extraterritorial au Cloud Act alors même que le GDPR inclut cette notion. Tout du moins cette adoption forcera les Européens et les Américains à trouver dans la négociation un terrain d’entente raisonnable. Il est aussi à noter qu’étrangement la régulation sur ses problématiques internationales de droits d’accès aux données informatiques semble beaucoup plus prompte à voir le jour que celles liées au secret bancaire de certains paradis fiscaux. Au mieux elle forcera l’Europe à se protéger dans un cadre légalement négocié. En ce sens le Cloud Act est une clarification du droit, donc plutôt une bonne nouvelle.

Laurent TERUIN

Cloud Data Act : Signé !

En fin d’après-midi vendredi dernier, Donald Trump a signé le projet de loi « omnibus » sur les dépenses. Le projet de loi comprenait la Clarifying Lawful Overseas Use of Data Act, une loi qui va changer la façon dont le gouvernement des États-Unis peut accéder aux données des utilisateurs stockées à l’étranger, entre autres choses.

Bon pas de quoi s’affoler mais de quoi rester vigilant sur les futurs accords entre l’union européenne et les USA.

https://iapp.org/news/a/what-the-cloud-act-means-for-privacy-pros/

Extrait

« La Loi sur les nuages ajuste un domaine complexe et important du droit – quelles règles devraient s’appliquer lorsqu’un gouvernement cherche à obtenir des preuves criminelles, mais les intérêts de la vie privée et de la souveraineté d’un autre pays sont également en cause.

L’effet le plus immédiat de la loi est de rendre caduque l’affaire Microsoft Irlande qui a été plaidée devant la Cour suprême. A l’avenir, les nouvelles dispositions concernant les accords exécutifs deviendront de plus en plus importantes. Il est probable que l’accord déjà négocié avec le Royaume-Uni sera le premier. Sur la table, des discussions avec l’Union européenne et ses États membres. Avec des mesures de protection appropriées, il peut également y avoir des moyens de protéger la vie privée lors de la conclusion d’accords autorisant la création de bureaux spécialisés dans des pays comme l’Inde et le Brésil.

À mesure que ces ententes iront de l’avant, toutes les parties intéressées auront l’occasion d’examiner les ententes proposées et de donner leur point de vue sur la question de savoir si les exigences de la Loi en matière de protection de la vie privée et de droits de la personne sont satisfaites par cette entente. Les accords exécutifs prévoient également un nouveau mécanisme permettant aux États-Unis d’évaluer les demandes de données d’un gouvernement étranger et de s’assurer que les mesures de protection de la vie privée exigées par la Loi sont effectivement respectées. L’adoption de la Loi Cloud ACT ouvre donc la voie à des débats publics continus sur les normes en matière de protection de la vie privée et de droits de la personne pour l’accès du gouvernement aux données. Elle offre l’occasion de promouvoir l’amélioration des pratiques en matière de protection de la vie privée et de droits de la personne avec des pays partenaires partout dans le monde. »