Au début, j'ai simplement pensé avoir oublié quelque chose, ou m'être trompé quelque part. Et bien non, il est important de savoir qu'OCS R2 et MOC R2 restreignent un peu plus la securité sur le trafic crypté des protocoles de voix sur IP.
Je m'explique:
- L'intégration d'OCS 2007 et d'Exchange UM se faisait traditionnellement en "SIP Secured", à savoir utiliser le MTLS pour le protocole SIP entre OCS et Exchange, mais utilisant le RTP/RTCP non chiffré pour la voix (dans ce cas, en RTAudio)
- MOC 2007 autorise par défaut les communications RTP/RTCP non chiffrées, ce qui ne posait aucun souci. MOC 2007 R2 quant à lui, force par défaut l'utilisation du trafic en SRTP, ce qui cause une erreur de type "Incompatible security settings" lors d'un appel aux contacts Exchange UM (Voicemail ou AutoAttendant).
- Il existe deux solutions, elles doivent être étudiées en fonction de ce qui vous semble le plus approprié pour votre environnement:
- Solution 1: passer le Dial Plan OCS R2 en "Secured", ce qui aura pour effet d'activer le SRTP entre Exchange UM et le client. Ce precepte est d'autant plus important si vous planifiez d'utiliser des téléphones Tanjay. C'est la solution recommandée.
- Solution 2: laisser les communications en SIP Secured et RTP et utiliser MOC 2007 ou configurer MOC 2007 R2 afin de ne pas forcer le SRTP. Cela peut s'effectuer par le biais d'une Stratégie de Groupe (locale ou depuis AD) au niveau de la partie machine (HKLM) ou utilisateur (HKCU) dans \Software\Policies\Microsoft\Communicator - Il suffit de créer une valeur de type REG_DWORD nommée "PC2PCAVEncryption" et de la positionner à 0 (zéro). Les valeurs possibles étant 0 (accepte l'encryption mais ne la force pas), 1 (force l'encryption) ou 2 (force la non encryption, une communication cryptée échouera).
Ayant refait mon lab, je me suis retrouvé bêtement béa devant un détail que j'avais oublié vis à vis des SRV:
Toujours selon la tradition des déploiements OCS 2007, on voit souvent les implémentations basées sur un ou plusieurs nom de pool (ou de pool de Directors) ayant comme nom complet qualifié (FQDN) quelque chose du style nomdupool.domaine.local. Or, le nom du domaine SIP est typiquement domaine.com. En quoi est-ce un problème ?
Si le domaine SIP est domaine.com, alors les enregistrements SRV _sip._tls.domaine.com et _sipinternaltls._tcp.domaine.com doivent pointer vers un nom de Pool nomdupool.domaine.com et plus précisément (idéalement) sip.domaine.com. Les certificats mis en oeuvre sur les frontaux et/ou Directors doivent donc avoir en SAN les noms nécessaires à la bonne vérification du nom DNS VS nom du Pool.
Si tel n'est pas le cas, MOC ignorera ces SRV et tentera en dernier recours (ou s'il ne peut résoudre les SRV pour une raison X ou Y) d'utiliser sip.domaine.com pour se connecter. Il est donc d'autant plus important de ne pas oublier ce nom lors de la création du certificat !
En l'occurence, si vous avez défini les SRV, que vous pouvez les résoudre à coup de nslookup, et que vous voyez ceci dans le journal d'évènement "Applications" (n'oubliez pas d'activer le logging dans MOC):
Communicator was unable to locate the login server. The DNS SRV record that exist for domain domain.com point to an invalid server nomdupool.domaine.local which is not trusted to provide support for the domain because the server's domain is not an exact match.
Resolution:
The network administrator will need to double-check the DNS SRV record configuration to make sure that the SRV record for the domain points to a server name that conforms to the DNS naming convention in the server deployment guide.
En fait, la vérification du nom de domaine VS le nom du pool constitue une barrière de protection primaire contre les attaques du type "man in the middle" et s'assurer que le nom du pool est en fait dans la même zone DNS que les enregistrements utilisés pour la découverte.
Voilà, c'est tout pour aujourd'hui, amusez-vous bien !
Articles
Aucun commentaire:
Enregistrer un commentaire