Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archives d’un auteur

Les nouvelles conditions de Microsoft pour Office 365 : Nous n’utiliserons pas vos données à des fins de publicité ou de profilage

Posted by Teruin laurent sur janvier 17, 2020


Traduit de l’anglais : https://www.zdnet.com/article/microsofts-new-office-365-terms-we-wont-use-your-data-for-advertising-or-profiling/²

Microsoft a déployé une nouvelle version de ses conditions de services en ligne en réponse aux griefs soulevés par le ministère néerlandais de la Justice concernant les données de télémétrie que Microsoft a recueillies auprès des utilisateurs d’Office 365 Plus et d’Office 365.

Le ministère de la justice néerlandais a accusé Microsoft de violer le Règlement général sur la protection des données de l’UE (GDPR), déclenchant une enquête du Contrôleur européen de la protection des données (CEPD), qui a déclaré avoir de « sérieuses préoccupations » concernant les contrats de Microsoft.

Microsoft a annoncé en novembre qu’il mettrait à jour ses contrats de cloud computing au niveau mondial pour les entreprises et les petites entreprises clientes afin de tenir compte des changements demandés par le CEPD et le MoJ néerlandais.

Les clients sont maintenant libres de parcourir deux documents de conditions Microsoft : les conditions de 159 pages sur les produits de licences en volume Microsoft et les conditions de 40 pages sur les services en ligne Microsoft (OST). Microsoft fournit un lien vers ces documents dans un nouveau billet de blog.

Les nouvelles OST intègrent les modifications contractuelles que Microsoft a développées avec le ministère néerlandais de la Justice, a déclaré en novembre Julie Brill, responsable de la protection de la vie privée chez Microsoft et vice-présidente de l’entreprise chargée de la protection de la vie privée et des affaires réglementaires au niveau mondial.

Microsoft décrit plusieurs changements apportés à l’OST dans ses  » clarifications et résumé des changements  » dans le nouveau document. Aucun changement important n’est mentionné dans le document sur les modalités du produit.

Selon Microsoft, les termes de protection des données, les clauses contractuelles standard et les détails du GDPR de l’UE ont été supprimés du document OST. Ils figurent désormais dans un document séparé appelé Online Services Data Protection Addendum (DPA), qui est disponible en ligne.

La mise à jour de l’OST/DPA remplace le langage précédent de l’OST autorisant Microsoft à traiter les données des clients  » uniquement pour fournir aux clients les services en ligne, y compris à des fins compatibles avec la fourniture de ces services  » avec des instructions et des limitations plus spécifiques « , indique Microsoft dans le nouvel OST.

L’un des principaux changements apportés à la mise à jour de l’OST est qu’il n’autorise pas Microsoft à traiter les données des clients ou les données personnelles à des fins de  » profilage, de publicité ou à des fins commerciales similaires, ou d’étude de marché « , à moins que le client ne l’autorise explicitement.

Les quatre changements  » de haut niveau  » que Microsoft note sont que le document :

Autorise Microsoft à traiter les données clients et les données personnelles en tant que sous-traitant pour trois objectifs autorisés : la fourniture des services, le dépannage et l’amélioration continue.


Exclut le traitement des Données clients et des Données personnelles à des fins de profilage, de publicité ou à des fins commerciales similaires, ou d’études de marché, sauf si cela est fait conformément aux instructions documentées du client.

Précise que Microsoft a les responsabilités d’un contrôleur de données s’il traite les Données clients et les Données personnelles pour certaines autres  » opérations commerciales légitimes  » énumérées, avec des limitations spécifiques.

Ajoute de la clarté et des détails supplémentaires basés sur les commentaires des clients (par exemple, sur la manière dont les clients peuvent s’engager avec Microsoft pour auditer le traitement des données de Microsoft conformément à la GDPR).

Au moment de l’annonce des changements de l’OST, M. Brill a déclaré que Microsoft  » augmentera ses responsabilités en matière de protection des données pour un sous-ensemble de traitement dans lequel Microsoft s’engage lorsque nous fournissons des services d’entreprise « .

La mise à jour de l’OST  » préciserait que Microsoft assume le rôle de contrôleur des données lorsque nous traitons des données à des fins administratives et opérationnelles spécifiques liées à la fourniture des services en nuage couverts par ce cadre contractuel, tels que Azure, Office 365, Dynamics et Intune « .

 » Ce sous-ensemble de traitement de données sert à des fins administratives ou opérationnelles telles que la gestion des comptes, l’établissement de rapports financiers, la lutte contre les cyberattaques visant tout produit ou service Microsoft et le respect de nos obligations légales « , a-t-elle ajouté.

Le DPA sur les conditions des services en ligne couvre les questions de propriété liées aux données traitées, le traitement des données personnelles selon les règles GDPR, les notifications d’infraction, les questions juridiques relatives au transfert de données entre pays, la conservation des données, la divulgation et la conformité aux demandes de données des forces de l’ordre, les réglementations HIPAA et le nouveau California Consumer Privacy Act (CCPA). Microsoft applique les règles de la CCPA à tous les utilisateurs américains.

Pour les demandes d’application de la loi concernant les données stockées sur les serveurs Microsoft, la société promet de ne pas divulguer les données traitées, sauf si la loi l’exige.

 » Si les forces de l’ordre contactent Microsoft avec une demande de données traitées, Microsoft tentera de rediriger l’organisme chargé de l’application de la loi pour demander ces données directement au client. Si elle est obligée de divulguer des Données traitées aux forces de l’ordre, Microsoft en informera rapidement le Client et lui fournira une copie de la demande, sauf si la loi l’interdit « , déclare Microsoft.

Posted in Non classé | Leave a Comment »

TEAMS DEVICE AND THE PROXY

Posted by Teruin laurent sur janvier 15, 2020


As mentioned in a previous article, Teams devices should be able to go out over the Internet through the company’s security policy. Policy that more and more forces the exits on the Internet through proxy services. Proxy services in Saas as Websense or Zscaler or traditionally hosted on site.

These proxy services can be set up in 3 types of configuration

– Transparent: On the IP route to the Internet between the device and the service connection point

– Declared and authenticated : Authenticated in Basic mode or others

– Declared and anonymous:

In addition to these 3 types, there are two types of proxy. Either Saas or On premise.

In the case of a Saas service like Zscaler or Websense, one of the interests of the solution is to send all the https flows to the Proxy service which goes according to the urls (0365 or not) to carry out treatments such as inspection for example. In this type of configuration, the company no longer has to manage the numerous Office 365 URLs because they are directly managed by the proxy service provider.

Otherwise the company can use a proxy.pac that will describe whether or not the device should use proxy services. In this case it is the company that updates its configuration files according to the changes in the Office 365 URLs. The routing decision is made in this case or at the device level.

To set up a proxy in a Teams phone, the phone must still allow it. The illustration below shows the Proxy service configuration interface within a Yealink T55 phone with a very recent firmware version.



This configuration, if manageable by auto configuration, would make it possible to make this type of device plug and play within the company network. It remains to be seen whether all the Skype devices you are going to migrate to teams will have the same possibilities.

The other issue you’ll have to manage is that most Saas services like Zscaler or Websense do SSL decryption. In other words,

1 – the https stream of a site like https://www.google.com is sent to websense services that pretend to be it,

2 -Decrypts the stream, inspects it, then re-transmits it to the final site. A bit like a « man in the middle » but one you trust.

This solution is effective but implies that your devices « trust » the websense service. Without this, your workstation will report an SSL error because the certificate presented by Websense is not the one expected. Below is an extract from the documentation of websense



 

To date we have not been able to configure Teams devices that take this mode of operation into account and we are working with the various parties involved to find a « plug and play » solution if possible.

Laurent TERUIN

 

Posted in Non classé | Leave a Comment »

Périphériques Teams à l’épreuve des proxy ?

Posted by Teruin laurent sur janvier 15, 2020


Comme précisé dans un précèdent article, les périphériques Teams devront pouvoir sortir sur Internet à travers la politique de sécurité de l’entreprise. Politique qui de plus en plus contraint les sorties sur internet à travers des services proxy. Services Proxy en Saas comme Websense ou Zscaler ou traditionnellement hébergé sur site.

Ces services proxy peuvent être paramétrés selon 3 types de configuration

  • Transparent : Sur la route IP vers internet entre le périphérique et le point de connexion du service
  • Déclaré et authentifié : Authentifié en mode Basique ou autres
  • Déclaré et anonyme :

A ces 3 types s’ajoute deux types de proxy. Soit Saas soit On premise.

Dans le cas d’un service Saas Comme Zscaler ou Websense, un des intérêts de la solution et d’envoyer tous les flux https vers le service Proxy qui va selon les urls (0365 ou pas) effectuer des traitements comme de l’inspection par exemple. Dans ce type de configuration, l’entreprise n’a plus à gérer les nombreuses URL d’Office 365 car directement gérés par le fournisseur de services de proxy.

Dans le cas contraire l’entreprise peut utiliser un proxy.pac qui va décrire si le périphérique doit ou pas utiliser les services proxy. Dans ce cas c’est l’entreprise qui met à jour ses fichiers de configuration en fonction des changements des URL d’Office 365. La décision de routage s’effectue dans ce cas ou niveau du périphérique.

Pour configurer un proxy dans un téléphone Teams encore faut -il que ce dernier puisse le permettre. L’illustration ci-dessous présente l’interface de configuration du service Proxy au sein d’un téléphone Yealink T55 avec une version très récente du firmware.


Cette configuration si elle est gérable par une auto configuration permettrait de rendre plug and play ce type de périphérique au sein du réseau de l’entreprise. Reste à savoir si l’ensemble des périphériques Skype que vous allez migrez vers teams auront les mêmes possibilités.

L’autre problème que vous aurez à gérer est que la plupart des services Saas comme Zscaler ou Websense est que ces services font du déchiffrement SSL. En d’autres termes,

1 – le flux https d’un site comme https://www.google.com est envoyé aux services websense qui se font passer pour ce dernier,

2 -Déchiffre le flux, l’inspecte, puis le réémette vers le site final. Un peu comme un « man in the middle » mais auprès duquel vous faites confiance.

Cette solution est efficace mais implique que vos périphériques « trustent » le service websense. Sans cela, votre poste remontera une erreur SSL car le certificat présenté par Websense n’est pas celui attendu. Ci-dessous un extrait de la documentation de websense


 

A ce jour nous n’avons réussi à configurer des périphériques Teams prenant en compte ce mode de fonctionnement et travaillons avec les différents intervenants pour trouver une solution « plug and play » si possible

Laurent TERUIN

Posted in Non classé | Leave a Comment »

Migration Teams Telephony and Internet access of peripherals

Posted by Teruin laurent sur janvier 15, 2020


One of the particular aspects of the migration of telephony to Teams is related to the migration of devices formerly known as Skype to the Teams client. As you may know some devices that are embedded in the Teams client are « upgradable » to a Teams client, others will not work or will work degraded. Still others will be able to run both Skype and Teams, or others will only manage the Teams client.

These constraints related to your devices are well to take into account in your migration strategy and more particularly when you are going to switch the Meeting function to Teams.

If you are considering a gradual migration of meeting functionality one of the risks identified is that part of the business may be using Teams meeting rooms with conferences that will not be reachable on Skype devices and vice versa.

On the other hand, and this is a bit new for companies that have an On-premise telephony environment, it will now be necessary for all of its devices, often confined to a voice VLAN, to be able to access Microsoft’s Internet services. In theory, this sounds simple, but in practice it is a little more complicated, especially because of the increasing presence of proxy services. (Zscaler, WebSense etc…)

The security and the control of external accesses of companies having been reinforced for several years, the quasi systematic presence of anonymous or authenticated proxies will not simplify things. Indeed the absence of proxy configuration in some Teams phones means that they will not be able to authenticate themselves to Microsoft services if they have to go through a non-transparent proxy (Proxy declared). Indeed contrary to the Skype client, the Teams client uses https services for signaling and therefore will try to exit via this protocol to Microsoft services. Extract from Microsoft documentation (https://docs.microsoft.com/fr-fr/microsoftteams/upgrade-prepare-environment-prepare-network)

« For teams to work properly, you must open TCP ports 80 and 443 from the clients to the Internet, and UDP ports 3478 to 3481 from the clients to the Internet. TCP ports are used to connect to Web content such as SharePoint Online, Exchange Online, and team chat services. Plug-ins and connectors also connect via these TCP ports. The four UDP ports are used for multimedia content such as audio and video files, to ensure that the flow works properly. »

It is obvious that in addition to accessing Microsoft resources, Teams devices will need to be able to resolve their names through the company’s DNS services.

Faced with this problem of 443 TCP access, several solutions are possible.

The first one is that manufacturers include in their firmware the detection or setting of proxy services

The second is to open the Voice Vlan to the Internet without a proxy. Solution that may nevertheless offend the security department.

The first solution will allow the plug and play notably of phones without additional configuration.

Posted in Non classé | Leave a Comment »

Migration Teams Téléphonie et accès internet des périphériques

Posted by Teruin laurent sur janvier 10, 2020


Un des aspects particuliers touchant la migration de la téléphonie vers teams est lié à la migration des périphériques anciennement Skype vers le client Teams. Comme vous le savez peut-être certains périphériques embarquant le clients Teams sont « migrables » vers un client Teams, D’autre ne fonctionneront pas ou fonctionneront de façon dégradée. D’autre encore seront capable de fonctionner à la fois en Skype et Teams, ou d’autre ne seront gérer que le client Teams

Ces contraintes liées à vos périphériques sont bien à prendre en compte dans votre stratégie de migration et plus particulièrement lorsque que vous allez basculer la fonction Meeting vers Teams.

Si vous envisager une migration progressive des fonctionnalités de réunion un des risques identifiés est qu’une partie de l’entreprise utilise depuis des salles de réunions Teams avec des conférences qui ne pourront pas être joignable sur des équipements Skype et inversement.

D’autre part, et c’est un peu nouveau pour les entreprises qui ont un environnement de téléphonie On-premise, il faudra désormais que l’ensemble de ses périphériques bien souvent cantonnés dans un VLAN voix puisse accéder aux services Internet de Microsoft. Si en théorie cela parait simple, dans la pratique cela s’avère un peu plus compliqué notamment en raison de la présence de plus en prégnante de services de proxy. (Zscaler, WebSense etc..)

La sécurité et le contrôle des accès externes des entreprises s’étant renforcer depuis plusieurs années, la présence quasi systématique de proxy anonymes, ou authentifiés ne vont pas simplifier les choses. En effet l’absence de configuration proxy dans certains téléphone Teams font que ces derniers ne seront pas capables de s’authentifier auprès des services Microsoft s’ils doivent ne serais ce que traverser un proxy non transparent (Proxy déclaré). En effet contrairement au client Skype, le client Teams utilise les services https pour la signalisation et donc tentera de sortir via ce protocole vers les services Microsoft. Extrait de la documentation Microsoft (https://docs.microsoft.com/fr-fr/microsoftteams/upgrade-prepare-environment-prepare-network)

« Pour que teams fonctionne correctement, vous devez ouvrir les ports TCP 80 et 443 des clients vers Internet, ainsi que les ports UDP 3478 à 3481 des clients vers Internet. Les ports TCP sont utilisés pour se connecter à du contenu Web tel que SharePoint Online, Exchange Online et les services de chat d’équipe. Les plug-ins et connecteurs se connectent également via ces ports TCP. Les quatre ports UDP sont utilisés pour les contenus multimédias tels que les fichiers audio et vidéo, afin de s’assurer que le flux fonctionne correctement. »

Il est bien évident qu’en plus d’accéder aux ressources Microsoft les périphériques Teams devront être ne mesure de résoudre leurs noms via les services DNS de l’entreprise

Face à cette problématique d’accès 443 TCP, plusieurs solutions sont possibles.

  • La première étant que les constructeurs incluent dans leurs firmware la détection ou le paramétrage de service proxy
  • La seconde étant d’ouvrir les Vlan voix vers Internet sans proxy. Solution qui risque néanmoins de froisser le département sécurité.

La première solution permettra le plug and play notamment des téléphones sans configuration additionnelles.

 

 

 

 

 

 

Posted in Non classé | Leave a Comment »

EXO: Supprimer un Domaine SMTP en environnement Hybride Exchange

Posted by Teruin laurent sur janvier 6, 2020


Parfois, en informatique il est préférable de faire un peu de ménage . Dans le cadre d’Exchange Online, il peut être nécessaire de supprimer certains domaines SMTP qui ne sont plus utilisés ou ont été céder à d’autres entités.

Si en théorie l’opération peut simplement consister à supprimer le domaine accepté dans la configuration de votre tenant , vous vous apercevrez assez rapidement que l’interface d’administration d’Office 365 vous refusera la suppression de ce domaine SMTP si des boites aux lettres ou des listes de distribution utilisent des adresses Proxy avec ce domaine.

Note : Exchange 2016 On premise vous laisse supprimer le domaine accepté, mais ne supprime pas automatiquement les adresses proxy sur les boites aux lettres. .Dans Office 365, pour supprimer un domaine SMTP , vous ne pouvez pas le faire directement depuis l’interface Exchange / MailFlow / accepted Domain. C’est dans la gestion des domaines de votre tenant que vous devez le supprimer. Allez Dans Settings/ Domains pour ce faire ; mais avant il faut supprimer toute référence a ces domaines SMTP

La commence les problèmes. Identifier manuellement les boites aux lettres ou les listes de distribution qui possèdent une adresse de messagerie utilisant le ou les domaines SMTP que vous voulez supprimer, puis supprimer ces adresses manuellement peut s’avérer un peu fastidieux.

Heureusement, Microsoft fourni un script Powershell qu’il est assez simple d’adapter et qui va d’une part identifier les boites aux lettres concernées puis supprimer les adresses du domaine en question d’autre part.

Etape 1 : Avant toute chose il faut repérer si une stratégie d’adresse positionne automatiquement ces adresses SMTP sur toute nouvelles boites aux lettres. Pour voir tous les domaines utilisés dans les stratégies d’adresse de messagerie, exécutez la commande suivante dans l’Environnement de ligne de commande Exchange Management Shell

Get-EmailAddressPolicy | Format-List Name,*EmailAddressTemplate*

Supprimer ou modifier ensuite la stratégie d’adresse responsable de l’attribution de ce nom de domaine SMTP

Etape 2 : utilisation des deux scripts suivants pour le nettoyage des boites aux lettres et des listes de distribution.

Le script suivant supprime toutes les adresses proxy du domaine remove.com depuis l’unité organisationnelle OU=Users

 

$OUScope = « OU=USers,DC=eu,DC=myorg,DC=com »

$N = 0

Write-Host « Searching mailboxes in $OUScope…. »

foreach($Tmailbox in Get-Mailbox -organizationalunit $OUScope -ResultSize Unlimited)

{

$Tmailbox.EmailAddresses | ?{$_.AddressString -like ‘*remove.com’} | %{

Set-Mailbox $Tmailbox -EmailAddresses @{remove=$_}

Write-host « Removing $_ from $Tmailbox Mailbox »

$N++

}

}

 

Si vous voulez juste avoir un extract avant de d’exécuter la suppression de l’addresse proyx il suffit simplement de mettre en commentaire la ligne # Set-Mailbox
$Tmailbox
-EmailAddresses @{remove=$_}

Le script suivant fait la meme chose pour les listes de distribution

 

$OUScope = «  OU=USers,DC=eu,DC=myorg,DC=com »

$N = 0

Write-Host « Searching DL in $OUScope…. »

foreach($Tmailbox in Get-distributionGroup -organizationalunit $OUScope -ResultSize Unlimited)

{

$Tmailbox.EmailAddresses | ?{$_.AddressString -like ‘*remove.com’} | %{

Set-distributionGroup $Tmailbox -EmailAddresses @{remove=$_}

Write-host « Removing $_ from $Tmailbox Mailbox »

$N++

}

}

 

Une fois réalisé, il faut attendre une réplication d’azure AD connect pour que ces entrées disparaissent. Une fois la réplication terminée, l’interface d’administration devrait vous autoriser à supprimer le ou les domaines en question

Cordialement

Laurent TERUIN

Posted in Non classé | Leave a Comment »

YEALINK & RIBBON SECURISENT LA TELEPHONIE TEAMS

Posted by Teruin laurent sur décembre 2, 2019


Le déploiement des services de téléphonie via Teams pose le problème de la résilience de la téléphonie d’entreprise en cas de rupture du lien Internet. Naturellement les liens peuvent être doublés mais ce doublement à un cout financier surtout s’ils doivent être généralisés à l’ensemble de vos agences.

Une alternative très intéressante est proposée par les entreprises Yealink et Sonus Ribbons.

Cette solution consiste à paramétrer le Téléphone Yealink pour que ce dernier utilise un lien de secours vers une passerelle Sonus SBC.

Lorsque l’Edge SBC est déployé sur site, le fonctionnement avec les clients TEAMS Yealink est le suivant :

  • Les clients TEAMS de Yealink et de SBC Edge ont un accès continu au système téléphonique pour la signalisation et le contrôle des médias.
  • Les clients TEAMS Yealink utilisent le système téléphonique (le « serveur d’appels principal ») pour établir les appels intra-bureau, inter-bureau et vers le PSTN.
  • SBC Edge agit en tant que SBC certifié Teams Direct Routing pour l’accès des clients TEAMS au PSTN ou à une infrastructure vocale tierce, non-Teams.
  • En complément des services d’appel du système téléphonique TEAMS, les clients TEAMS Yealink s’inscrivent auprès du SBC Edge (le « serveur d’appel secondaire ») via la signalisation SIP.


En cas d’indisponibilité du service Phone system

– Les clients des équipes Yealink utilisent les services du SBC Edge ( » Secondary Call Server « ) via la signalisation SIP pour établir des appels intra-bureau, inter-bureau et publics sur le PSTN


Une solution très prometteuse qui va rassurer les entreprises sur le fait de migrer leurs téléphonies sur TEAMS !!

Posted in Non classé | Leave a Comment »

Skype 2015: may not have a private key that is capable of key exchange or the process may not have access rights for the private key [Solved]

Posted by Teruin laurent sur novembre 18, 2019


Version Skype 2015 Server version 6.0.9319.562 (CU10) / Windows Server 2012 Standard Edition

Today when I try to renew a Skype certificate on the PTchat server I’ve got this error message.

Skype for Business Server 2015, Persistent Chat could not start due to the following exception:

at System.ArgumentException: It is likely that certificate ‘CN=EUPGDSGCP021.xxx, O=xxx, L=xxx, S=xx, C=xx’ may not have a private key that is capable of key exchange or the process may not have access rights for the private key. Please see inner exception for detail. —> System.Security.Cryptography.CryptographicException: Invalid provider type specified.

 

After checking the right on the certificate all looks fine



 


I try to assign the Certificat with deploy program I ve got a warning that indicate the presence of more than one certificate for this computer. So I decided to remove the old one and reassign the certificate. Thus no warning error message.


When I try to start the service I ve got this error message.


And the Event viewer


So, I decided to restart the computer and check if I can start the service. Same issue

The weird thing is that all the Certificate issue operation and the assignment looks okay.

 

Check Root and Intermediates containers

Because Skype for Server has been written by fundamentalists of certificate management, I decided to check in the certificate container if Root certificates are only in the Trusted Root certification Authorities container and same for the Intermediate Certification Authorities. Perfect ! . To determine root and not root certificate you only have to check if the issue by and issue to has the same value. If yes, it is a root certificate.

 

So I ve cleaned this mess and try to restart my server…and… same issue


 

I ve checked again the Root certificate and the intermediate certificate containers in the server and I discover that some Root certificate authority are duplicated. I have remove them and check again if only the roots certificate are only int the roots containers and same for intermediate. . I have restarted the server again.

Same Issue. The service Persistent Chat could not start

 

I try to regenerate the Request



 


Sumitted the request with certreq generate the certificate and assign with deploy skype server . Rebbotting the server . Same Result

 

Certificate request from Windows 2008 R2

After searching on the Web I found this

https://blogs.perficient.com/2013/12/09/lync-support-for-cryptoaping-certificates/

This article talk about Lync… but maybe ….

So I tried to make a certificate request from a Windows 2008 R2 and export the certificate to my Ptchat server . Importation , assignment to skype server and reboot

Same issue .

 

Certificate with server and Client Authentication function

I will try to generate the certificate for Server and client authentication following this article

https://social.msdn.microsoft.com/Forums/en-US/7b7bd2a8-b2dc-4700-a657-826754217068/cryptographicexception-invalid-provider-type-specified?forum=wcf

I regenerate a certificate on the Ptchat server and assign the right to read the private key to the Network service. Reboot the server

Same Issue.

Setting everyone access to the Private key

and restart

Same issue


 

 

Trying to use deploy to generate the request

Another attempt is to use the deploy skype executable to create the request


Certifcate has been assigned . reboot . and Solved !!!!!!

 

 

 

 

 

 

 

 

 

 


 

Posted in Non classé | Leave a Comment »

Microsoft Active ARC pour Exchange Online

Posted by Teruin laurent sur novembre 15, 2019


Microsoft a activé l’ARC (Authenticated Received Chain) pour toutes les boîtes aux lettres hébergées Office 365 afin d’améliorer la détection anti-spoofing et de vérifier les résultats de l’authentification dans Office 365. ARC est un protocole conçu pour fournir une  » chaîne de contrôle  » authentifiée pour les messages permettant à chacun des utilisateurs qui traitent un courriel de voir ce que d’autres entités ont traité précédemment, ainsi que de déterminer son évaluation d’authentification à chaque étape du processus de livraison.

Le protocole ARC complète les protocoles d’authentification des courriels DMARC et DKIM dans le cadre des efforts déployés par les Internet Mail Handlers pour lutter contre l’usurpation d’identité des courriels, notamment lorsqu’ils traitent des messages transférés.

ARC conserve les résultats de l’authentification des courriels de tous les intermédiaires participants, ou sauts, lorsqu’un courriel est acheminé du serveur d’origine vers la boîte aux lettres du destinataire. » L’activation des boîtes aux lettres hébergées ARC for Office 365 permet d’éviter que les résultats de l’authentification des e-mails échouent après avoir atteint la boîte de réception d’un destinataire en raison de modifications apportées pendant le routage par des intermédiaires tels que les règles de redirection ou les listes de diffusion.Avec ARC activé, Office 365 peut vérifier l’authenticité de l’expéditeur d’un e-mail à l’aide de la conservation cryptographique automatique des résultats de l’authentification. Au début, ARC ne sera utilisé que pour vérifier les résultats de l’authentification dans Office 365, mais Microsoft prévoit également d’ajouter la prise en charge des tiers signataires.

Cordialement

Posted in Non classé | Leave a Comment »

Supprimer SMB V1 Oui mais …. Comment à l’échelle de l’Entreprise

Posted by Teruin laurent sur novembre 8, 2019


Bonjour

« En avril 2017, des attaquants se faisant appeler les Shadow Brokers ont publiquement révélé des outils offensifs, qui proviendraient du groupe Equation, annoncé comme lié à la NSA. Quatre de ces outils permettent d’exploiter des vulnérabilités liées à SMBv1 (ETERNALROMANCE, ERRATICGOPHER, ETERNALCHAMPION et ETERNALBLUE). Le bulletin d’actualité CERTFR-2016-ACT-039 du 26 septembre 2016 précise les faiblesses de ce protocole et rappelle que les systèmes d’exploitation supportant uniquement SMBv1 sont désormais obsolètes (Windows 2000, Windows XP et Windows 2003). Pour des raisons de compatibilité, Microsoft continue d’activer ce protocole, même dans les versions récentes de Windows. Il est ainsi recommandé de désactiver SMBv1. » (Agence nationale de la sécurité des systèmes d’information)

il est donc fortement conseillé de supprimer l’usage du protocole SMB V1 qui pour rappel permet le partage de ressources (fichiers et imprimantes) sur des réseaux locaux en environnement Microsoft.

Même s’il est assez simple de supprimer unitairement l’usage de ce protocole, la tâche est un peu plus compliquée en entreprise au regard d’une part, du nombre de serveurs qu’elles possèdent et d’autre part, en fonction du nombre d’applications susceptibles de recourir à ce protocole. Vous trouverez à la fin de cet article une liste non exhaustive des produits tiers susceptibles d’utiliser SMB V1

Comment procéder ?

1 – Inventaire Rapide en environnement Microsoft : La première approche est de faire un inventaire rapide des produits rapidement identifiables qui seraient susceptibles de recourir à ce protocole.

  • Les Windows XP, Windows 2000 ou encore Windows Server 2003 utilisent ce protocole nativement et son usage ne peut pas être désactivé. Par conséquent, si vous disposez encore des serveurs ou stations de travail avec ces versions, ils ne pourront plus se connecter sur des serveurs plus récents dont le protocole SMB V1 a été désactivé.
  • Les Windows 7.0, Windows 2008, Windows 2008R2, Windows Vista , Windows 8.1, Windows 10, Windows 2012 R2 et Windows Server 2016 utilisent ce protocole mais il peut être désactivé facilement

 

Note : seuls les produits Windows 10 et Windows Server 2016 utilisent la version SMB 3.1.1 qui est la dernière en date.

2 – Tester la désactivation

Faire un inventaire complet des services, serveur, stations de travail a l’échelle d’une entreprise peut être très compliqué et très long voir même incertain. L’approche consistant à une désactivation progressive me parait l’approche la plus pragmatique.

Après avoir réalisé un inventaire rapide du site en question et s’être assurer de l’absence de produit incompatible avec la suppression du protocole SMB V1, elle consiste sur un site précis à identifier des serveurs comme les contrôleurs de domaine pour tester la suppression protocolaire et estimer les effets de bord. Les opérations de suppression du protocole SMB V1 étant réversible en cas de souci, rassurez-vous, le retour arrière est rapidement possible. Evidement cette méthode fait courir un risque d’exploitation localisé & maitrisé et mais ce risque est à comparer à celui de conserver encore longtemps ce protocole non sécurisé. Il est évidement conseillé de commencer par un site relativement petit et qui ne possèdent pas d’infrastructure complexes.

Une fois désactivé, il sera nécessaire de recourir à une période d’observation de plusieurs jours avant de procéder à la désactivation sur les autres serveurs Windows. Une fois réalisé, vous pourrez passer à la désactivation sur les stations de travail

Vous trouverez l’ensemble des procédures ici : https://support.microsoft.com/fr-fr/help/2696547/detect-enable-disable-smbv1-smbv2-smbv3-in-windows-and-windows-server

 

3 – Liste non exhaustive des produits qui utilisent encore ce protocole

Posted in Non classé | Leave a Comment »