> Tech > Les contraintes techniques de la fédération

Les contraintes techniques de la fédération

Tech - Par Renaud ROSSET - Publié le 04 mars 2013
email

Lors de la mise en place d’un seul serveur EDGE au sein de l’architecture Lync de l’entreprise, les contraintes de mise en place sont essentiellement liées aux flux de communication à autoriser au niveau des équipements de type Pare-Feu (Firewall).

Les contraintes techniques de la fédération

Redondance et interopérabilité

Dans le cadre de la mise en place de solution de redondance des serveurs Lync Edge, il faudra prêter une attention particulière à la solution retenue avec Lync 2010. Lync 2010 supporte deux architectures pour la redondance qui sont, soit la mise en place d’équipements d’équilibrage de charge (HLB ou Hardware Load Balancing), soit l’utilisation des fonctionnalités de DNS Load Balancing (DNSLB). L’architecture HLB est celle qui existait déjà dans les architectures précédentes avec OCS 2007 R2. C’est la seule architecture supportée pour permettre l’interopérabilité et la fédération avec des entreprises qui disposent d’architecture Office Communication Server OCS 2007 R2.

L’usage de HLB assure donc une ‘universalité’ de la solution de fédération, mais représente un coût. L’usage de DNSLB, nouvelle technologie supportée uniquement par Lync 2010, permettra la fédération uniquement avec des entreprises ou partenaires qui utilisent une architecture Lync 2010.

Certificats et DNS

En complément du ou des serveurs Lync Edge, il est nécessaire de mettre en place des enregistrements DNS et un certificat sur le ou les serveurs Lync Edge.

Côté certificat, la solution est simple. Si vous souhaitez faire une fédération ouverte ou publique, sans avoir à gérer la mise en place de chemins de communication spécifiques et sans devoir distribuer votre certificat racine, il sera indispensable d’avoir recours à un certificat issu d’une autorité de certification publique. Ce certificat sera dans tous les cas de type SAN (noms multiples) pour supporter au minimum les noms sip, meet, dialing et lyncdiscover associés à votre nom de domaine sip.  Ces différents noms devront aussi être renseignés au sein des DNS publics. Si vous ne souhaitez pas disposer d’une fédération ouverte, mais uniquement avec certains partenaires, vous pouvez par exemple utiliser un nom différent de SIP.votredomain.com pour accéder à votre serveur Lync Edge.

Dans ce cas, le partenaire qui souhaite faire de la fédération devra renseigner le nom du serveur associée au nom de votre domaine sip au sein de ses serveurs Edge. Il n’y aura pas de découverte automatique. De même, dans le cas de l’utilisation d’un certificat privé, le certificat racine de votre autorité de certification pourra être placé dans le magasin du serveur Lync Edge de l’architecture partenaire. L’usage de ces deux approches permet la mise en place d’une fédération fermée ou restreinte au niveau architecture. Mais dans ce cas, il sera impossible de faire une fédération avec certaines entreprises et aussi et surtout il sera impossible d’utiliser une interconnexion avec les réseaux et fournisseurs de messagerie instantanées publics (PIC) tels que Microsoft Windows Live Messenger, AOL, et Yahoo!.

Validations des utilisateurs

Une que l’infrastructure requise pour permettre la fédération est mise en place au sein de l’entreprise, il faut définir les stratégies pour l’accès à la fédération ainsi que les utilisateurs autorisés à utiliser la fédération avec les autres entreprises. L’activation des utilisateurs de votre entreprise pour l’accès aux  entreprises fédérées passe par une étape de configuration qui doit être effectuée au travers de la console Web de gestion de Lync, soit au travers des commandes Powershell de Lync. Il faut en premier lieu définir une stratégie d’accès externe (External access policiy). Par défaut, cette stratégie initiale existe sous le nom de ‘default Global Lync External Access Policy’, mais il est recommandé d’en créer une nouvelle pour l’entreprise lors de la mise en place de la fédération. Ce type de stratégie permet de définir les droits des utilisateurs auxquels est affectée cette stratégie (communication avec des utilisateurs fédérés, communication avec des utilisateurs de messageries instantanées publiques (PIC) et accès externe à Lync au travers d’une connexion Internet (sans VPN).

La création d’une nouvelle stratégie d’accès externe s’effectue avec la cmdlet New-CsExternalAccessPolicy. Pour mettre en place les paramètres de cette stratégie en Powershell, il faut utiliser cette cmdlet ou la cmdlet Set-CSExternalAccessPolicy avec les paramètres –EnablePublicCloudAccess, -EnablePublicCloudAccess  ou encore – -EnableOutsideAccess.

Une fois définies, une ou plusieurs stratégie d’accès externe, il faut affecter la stratégie adaptée aux utilisateurs Lync 2010 à l’aide de la cmdlet Grant-CsExternalAccessPolicy. La gestion au travers de l’interface graphique Web de ces paramètres se situe sur la page des propriétés de chacun des utilisateurs.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 04 mars 2013