Aunque no dejo de lado el tema de Lync, revisando entre todo mi correo, me encontre una pregunta que debia bloguear hace mucho tiempo.
Cuantos certificados en definitiva, son lo necesarios para dejar BIEN instalada una infraestructura de OCS 2007 R2?
ademas, como puedo soportarla con documentacion Microsoft al respecto?
pues bien, para una infraestructura bien implementada son por lo menos 3 Certificados de tipo publico si se desea los siguientes servicios:
- Acceso a logon desde cualquier OCS sin requerimiento de distribucion de mi llave privada de certificacion. ***
- Federacion con Public IM Connectivity – PIC (yahoo, AOL, Hotmail)
- posibilidad de crear invitaciones de Live Meeting a personas externas a la compania y usuarios “anonimos”.
si quiere que en el web browser de Communications Web Access CWA tenga una entrada “limpia”. sin advertencia de que esta accesando a un sitio no seguro y si desea continuar, en tonces requiere de un certificado mas. en total serian 4 certificados.
pero vayamos por partes. ustedes se preguntaran porque puse 3 asteriscos en “Acceso a logon desde cualquier OCS sin requerimiento de distribucion de mi llave privada de certificacion. ***”
esta mala costumbre se hizo creciente con la entrada de OCS y eso tengo que admitirlo. ante la necesidad y la emocion de poner esta “maravilla” en produccion y habilitar a los clientes Microsoft Office Communicator MOC a funcionar, entregabamos la llave privada o cadena de certificacion para ser implementada en los PC que no estaban en el dominio o que pertenecian a usuarios ajenos a la empresa.
se nos olvido la teoria de seguridad y de la teoria de encripcion basica de cuarto de educacion basica elemental (Primaria). recuerden que al entregar la porcion privada de la llave de encripcion doy pie a que esa o esas personas pueda abrir cualquier contenido encriptado al interior de mi organizacion. o sea RMS, EFS, Correo encriptado y todo lo que use esta llave quedo expuesto y vulnerable. inclusive el trafico entre controladores de dominio.
a veces los oficiales de seguridad se preocupan de que si el puerto 443 es seguro o no y no se dan cuenta que el vacio real esta en la entrega de la llave primaria de encripcion a cualquier persona de forma indiscriminada.
entonces, por esto, es necesario encriptar con llaves de tipo publico, alias, entidades como Entrust, Comodo o Digicert para el caso de las avaladas por Microsoft para Comunicaciones Unificadas.
entonces, primer punto:
cuales son las avaladas por microsoft para UC?
Unified Communications Certificate Partners for Exchange Server and for Communications Server: http://support.microsoft.com/kb/929395
Cuantos Certificados? 3 para los servicios basicos. 4 incluyendo CWA si asi lo quiere.
Cuales son los certificados o puntos certificables de mi plataforma OCS?
1. Access Edge: por lo general se debe llamar sip.midominiopublico.com o algo similar. Ubicado en la tarjeta externa o de DMZ, en su direccion asignada al trafico 5061 del servidor edge de OCS.
2. Web Conference: por lo general se debe llamar webconf.midominiopublico.com o algo similar. Ubicado en la tarjeta externa o de DMZ, en su direccion asignada al trafico 443 y que corresponde al tema de web conf del servidor edge de OCS.
estos dos estan claramente identificados en el poster de OCS 2007 R2:
pero y entonces de donde sale el requerimiento del tercer certificado?
la mayoria de las implementaciones deja funcionando el tema del OCS y Live Meeting con los certificados propios de le entidad interna. eso esta bien, si solamente y unicamente van a usarlo personas internas de la organizacion. en el mejor de los casos, hacen un ATP (Test Protocol) para entregar la solucion en produccion pero solo incluyen personas de la organizacion en la pruebas y certificacion.
pero los lios ocurren cuando quieren invitar a un externo o a un federado. alli pueden generar la invitacion de Live Meeting, enviarla por ejemplo a un usuario Hotmail, yahoo, aol, gmail o simplemente a otra empresa o inclusive a un usuario que esta federado en mi organizacion.
y la los ingenieros comienzan a dar vueltas a ver que fue lo que quedo mal de la implementacion e inclusive comienzan a modificar las ACL de recursos compartidos y a abrir la infraestructura.
los errores presentados y que son mas comunes pueden ser:
- Error message when you click the "Join the Meeting" link in the e-mail message that you receive from the Web Conference session presenter in Communications Server: "An error occurred verifying the server’s certificate" http://support.microsoft.com/kb/939802
- You cannot share your Whiteboard or documents when you join a conference in Live Meeting as a presenter http://support.microsoft.com/kb/939532/en-us
- Error message when you use Communicator to externally connect to the Communications Server Web Components by using ISA Server: "Cannot Synchronize Address Book" http://support.microsoft.com/kb/940779/en-us
- You cannot invite anonymous participants to a Web conference in Communications Server http://support.microsoft.com/kb/938298/en-us
y siguiendo cada uno de estos articulos, todos coinciden en que la infraestructura de Web Components interna en el Front end de OCS debe estar debidamente certificada por un ente externo.
Anonymous participants are individuals who are from outside your organization. These individuals do not have Active Directory directory service credentials.
This issue may occur when Communications Server does not use public certificates…
This issue may occur when Communications Server does not use public certificates. Public certificates are required for anonymous Web conferences in Communications Server.
por ejemplo, cuando usted invita a un tercero, por ejemplo a mi, un correo de hotmail y trata de compartirme video o de compartirme contenido para mi descarga, me sale un bello mensaje de no puede ser descargado el contenido.
esto ocurre por esto. porque usted no pone el certificado de tipo publico adicional para certificar los web components.
entonces vienen las preguntas de arquitectura: y donde debo ponerlo?
bueno, la respuesta es sencilla. si usted usa un reverse proxy para sus publicaciones y espero lo haga asi. siempre, siempre, siempre utilizar un reverse proxy para publicacion de paginas web ya bien sea de tipo Http y/o https. pues usted lo coloca alli.
si usted le gusta el terror y la adrenalina constante y no publica a traves de reverse proxy sino que le dice por ejemplo a su ASA de Cisco que haga una mera redireccion de trafico pues le es necesario colocar este certificado directamente en el front end a donde usted este entregando la publicacion de web components.
bueno, ya habiendo compartido un poco mas, me puedo ir tranquilo a dormir. 🙂
pero seguramente usted no va a dormir pensando como va a poner el certificado que le falta… jejejeje.
no olvide la guia de certificados de OCS:
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2. http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9f86f96-aa09-4dca-9088-f64b4f01c703
Enjoy!!!
Hans A.