Si ha configurado ADFS (servicios de federación de directorio activo) para autenticar a los usuarios de su dominio en Office365, sabrá que para mantener la comunicación entre su servicio adfs y office365 necesita un certificado que sea de confianza para ambos servidores / servicios. Obviamente, puede utilizar certificados generados por una CA pública, che tornano anche più comodi visto che sono di per se già trustati da entrambe le parti, ma è anche possibile utilizzare certificati self signed; il problema è che i certificati hanno una scadenza dopo la quale non sono più validi e quindi si rischia di interrompere la comunicazione tra i due siti.
Premisa: qualsiasi operazione di cui parlerò in questo articolo va eseguita sul server ADFS principale.
Cosa bisogna fare quando il certificato utilizzato sta per scadere? Rinnovarlo prima che scada ovviamente 🙂 e dato che ci si potrebbe dimenticare (office 365 comunque vi avvisa) la cosa più comoda è abilitare l’auto rinnovo.
En primer lugar, compruebe si la transferencia automática de certificados está habilitada, desde powershell da estos dos comandos:
PD C: Windows system32> Add-PSSnapin microsoft.adfs.powershell
PD C: Windows system32> Get-ADFSProperties
El comando debería devolver datos similares a este:
AutoCertificateRollover : Cierto
CertificateCriticalThreshold : 2
CertificadoDuración : 365
CertificateGenerationThreshold : 20
CertificadoPromotionThreshold : 5 5
CertificateRolloverInterval : 720
El primer elemento le dice si la renovación automática está habilitada o no, si no lo es, puedes habilitarlo:
Set-ADFSProperties -AutoCertificateRollover $ true
Los otros elementos indican otros parámetros interesantes:
CertificateGenerationThreshold: indica cuántos días antes de que caduque el certificado, su servidor adfs autogenerará un nuevo certificado
CertificadoPromotionThreshold: cuántos días antes de que expire el certificado se realiza la promoción del certificado secundario al certificado primario (sí, porque cuando la renovación automática genera un nuevo certificado, en realidad no reemplaza al principal, sino que crea uno secundario que acompaña al principal de tal manera que, antes de que caduque el principal, office365 reconoce el nuevo certificado a tiempo y luego lo promueve a principal)
CertificateRolloverInterval: indica cuántos minutos verifica el servicio adfs para ver si debe generar nuevos certificados
CertificateCriticalThreshold: indica cuántos días antes de la expiración adfs fuerza la generación de un nuevo certificado incluso si no hay tiempo para replicarlo en los servicios de office365 (caso extremo)
Aquí encontrarás la página oficial con todos los parámetros y propiedades de adfs: http://social.technet.microsoft.com/wiki/contents/articles/16156.ad-fs-2-0-understanding-autocertificaterollover-threshold-properties.aspx
Otro comando muy útil es actualizar si quieres forzar la creación de un nuevo certificado:
Actualización-ADFSCertificate
a lo que posiblemente pueda agregar el parámetro -Urgent pero con mucho cuidado porque coloca directamente el nuevo certificado como primario y si la información / metadatos / certificados no se comunican instantáneamente a office365, perdemos la autenticación, sigue leyendo…
Bueno, por ahora hemos visto cómo cambiar los parámetros y cómo generar nuevos certificados en el lado de adfs.…. pero si cambiamos el certificado primario y no lo comunicamos a office365 obviamente el certificado no se considerará válido y por lo tanto se bloqueará todo (o los usuarios ya no estarán autenticados). Entonces, ¿cómo transferir los metadatos a office365 quizás automáticamente?? Afortunadamente, Microsoft nos está ayudando con este script.:
https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
es un script de PowerShell, tienes que descargarlo y ejecutarlo, debe tener un usuario administrador del dominio local y un usuario administrador de office365, Te traigo todos los prerrequisitos, nada particularmente complejo, pero asegúrese de tenerlos todos:
Para ejecutar esta herramienta con éxito:
- Debe asegurarse de haber instalado la última versión del Módulo de servicios en línea de Microsoft para Windows PowerShell
- Necesita tener un AD FS 2 en funcionamiento.0 Servicio de Federación
- Debe tener acceso a las credenciales de administrador global para su inquilino de Office 365
- Debe tener al menos un dominio verificado en el inquilino de Office 365 debe ser del tipo "Federado’
- Esta herramienta debe ejecutarse en un servidor de federación grabable
- El usuario que ha iniciado sesión actualmente debe ser miembro del grupo de administradores locales
- El módulo de servicios en línea de Microsoft para Windows PowerShell debe estar instalado. Puede descargar el módulo desde http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx
De acuerdo, si estamos de acuerdo con los requisitos previos, podemos ejecutar el script que le pedirá las dos credenciales. (en el local e office365) y al final de la ejecución generará un script en C: Office365-Scripts y creará automáticamente una tarea programada que ejecutará el script todos los días. Este script se encargará de transferir a office365 todos los cambios de los metadatos incluidos los cambios en los certificados.; de esta manera estamos seguros de que todos los días habrá una sincronización entre lo que tenemos en el servidor de adfs y lo que tenemos en office365. De esta forma hemos cerrado el círculo en lo que respecta a la gestión del AutoCertificateRollover.
Para mayor claridad, resumiré brevemente cómo debería funcionar toda la vuelta con el auto rollover configurado:
1) Cuando llegue al término definido por el parámetro CertificateGenerationThreshold se genera un nuevo certificado que se configurará como secundario
2) Este nuevo certificado se comunicará / transferirá automáticamente a office365 gracias a la tarea programada que ejecuta el script contenido en C: Office365-Scripts todos los días y a partir de ese momento será aceptado como válido por office365
3) Al final definido por el parámetro CertificadoPromotionThreshold el certificado secundario se convertirá en el principal y, de hecho, se utilizará para la comunicación y autenticación entre adfs y office365 y Office 365 lo considerará válido porque “ya lo conoce”