Un certificado es una estructura de datos firmada que vincula una clave pública a una persona, computadora u organización. X.509 es un estándar UIT-T para infraestructuras de clave pública (PKI), donde X509 específica, entre otras cosas, formatos estándar para certificados de claves públicas y un algoritmo de validación de la ruta de certificación. Su sintaxis, se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One), y los formatos de codificación más comunes son DER (Distinguish Encoding Rules) o PEM (Privacy Enhanced Mail).
Si nuestra organización ha implementado la autenticación con una tarjeta de verificación de identidad personal (PIV), veremos que cuando iniciamos sesión en Office 365 a través del portal web, nos dará la posibilidad de realizar autenticación moderna. La solicitud de inicio de sesión del usuario se redirigirá a ADFS, sin embargo este tipo de inicio de sesión que incrementa enormemente la seguridad, no es compatible con para sesiones por PowerShell.
Los requisitos de seguridad de la red generalmente generan una arquitectura de identidad compleja. ADFS, autenticación moderna, identidad alternativa y el uso de smartcards como sistema de verificación de identidad personal (PIV), coexisten perfectamente, como se puede ver en la siguiente imagen:
De manera predeterminada, ADFS muestra “iniciar sesión con un certificado X.509” o “Iniciar sesión con PIN o smartcard”, sin embargo, la autenticación de certificados no es compatible con PowerShell en Azure AD…
Esta es la explicación que nos dan desde el equipo de producto:
“I was thinking about the PowerShell idea, which is useful for people to run scheduled jobs. The gap is that the current CBA support from AAD revolved around mobile devices (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-certificate-based-authentication-ios)”
Esto pone en el roadmap de AzureAD la inclusión de CBA para PowerShell, y nos alegra ver que ya están trabajando en ello.
Solución
Puede que esperar no esté en tus planes, de modo que te explicaré brevemente una solución alternativa con userClass object sincronizado a través de AD Connect y con inicio de sesión interactivo deshabilitado.
Esta cuenta aprovechará AD FS con autenticación integrada de Windows. De manera predeterminada, la autenticación integrada de Windows está habilitada en ADFS en Windows Server 2012 R2 para las solicitudes de autenticación que se producen dentro de la red interna (Local intranet). Para mayor seguridad, podemos habilitar MFA para Office 365 o Azure, y funciona. También podemos evaluar el uso de una cuenta de Office 365 con el rol de GlobalAdmin, es algo que muchas empresas hacen, pero yo personalmente lo desaconsejo completamente.
Para más información:
Autenticación SmartCard:
https://technet.microsoft.com/en-us/library/dd277362.aspx
Autenticación integrada de Windows (WIA) con AD FS:
