Vidéo Microsoft sur la Surface HUB.
Catégorie : UC Page 1 of 2
Comme chaque année, Gartner délivre son analyse du marché technologique avec les Magic Quadrant et classe les différents acteurs d’un domaine. Les domaines qui nous intéressent sont « Les communications unifiées (Unified Communications) » et la téléphonie (Corporate Telephony) afin de savoir où se positionne Microsoft là dedans.
Cette année, Microsoft n’est pas en tête au niveau UC mais se positionne et reste largement leader avec Cisco. Concernant la téléphonie, Microsoft est très bien placé surtout quand on connaît la « jeunesse » de l’écosystème.
Voici les graphiques associés :
KEMP est très présent dans le monde Microsoft pour publier & sécuriser des environnements Exchange, ADFS, Skype for Business / Lync ou Sharepoint, etc.
KEMP reste cependant un ADC (Application Delivery Controller), c’est à dire un équipement capable de répartir des flux quelque soit le type (tant que cela est de l’UDP ou TCP) et d’effectuer des actions au niveau 7 (niveau applicatif).
Vous pouvez donc utiliser des équipements KEMP comme Load Balanceur ou Reverse Proxy évolués
Petite vidéo que j’ai découverte durant le RDV de l’ecosystème Lync, évènement qui s’est déroulé chez Microsoft le mardi 30 septembre 2014.
Voici le lien Youtube de la vidéo : https://www.youtube.com/watch?v=m_yeUuaJ3oY
Les RDV de l’écosystème permettent de rencontrer et découvrir toutes les solutions et partenaires travaillant autour du système Lync.
[MAJ 23/10/2014] Simplification de la procédure suite au fait que le rôle PKI de Windows génère par défaut un webservice pour la mise à disposition des informations (mais cependant n’est pas appliqué par défaut).
Les certificats sont des éléments sensibles qui permettent de sécuriser l’ensemble de l’infrastructure mais peuvent aussi provoquer quelques désagréments aux administrateurs si ceux-ci n’ont pas été correctement implémentés.
En dehors des échanges et tests effectués directement entre la ressource présentant son certificat et le système y accédant, ce même système accédant va en parallèle valider avec l’autorité de certification plusieurs éléments (L’autorité de certification étant le système tiers fournissant le certificat à la ressource publiée).
Les éléments validés avec l’autorité de certification sont entre autres la fameuse liste de révocation (CDP / CRL) et les méthodes d’accès à l’autorité (AIA). Ainsi par exemple le système accédant va rechercher le fichier crl (liste de révocation) afin de vérifier que le certificat présenté n’est pas présent dans cette liste et qu’il n’a pas été compromis ou révoqué.
Pour trouver le chemin de la CRL ou l’accès à l’autorité, le système lit tout simplement le certificat présenté par la ressource car c’est lui qui indique où se trouve ces informations.
La problématique :
En fonction de l’application, ces contrôles sont plus ou moins fort cependant par exemple par défaut IE va générer une erreur s’il n’arrive pas à récupérer le fichier crl ou si le nom ne correspond pas.
Or, une PKI Interne de type Windows Server Enterprise ne diffuse ces éléments (extensions CDP & AIA) que via un chemin LDAP par défaut et ainsi cela provoque une inaccessibilité aux informations pour tous les PC hors du domaine accédant aux ressources depuis votre réseau (en fonction de l’application).
Prenons un exemple concret, un PC hors du domaine accédant depuis l’interne à une conférence Lync présentant un document PPT via Office Web Apps. Vous avez beau mettre le certificat racine de votre PKI interne sur votre PC, une erreur de validation du certificat va apparaitre. Alors oui vous pouvez désactiver les contrôles dans IE dans ce cas, cependant cela rend votre navigateur moins sécurisé.
Voici ce qui peut arriver : Un problème s’est produit lors de la vérification du certificat sur le serveur.
