Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La característica Autenticación basada en certificados de Microsoft Entra ID para dispositivos iOS o Android permite el inicio de sesión único (SSO) mediante certificados X.509. Al habilitar esta característica, puede iniciar sesión en cuentas o servicios sin tener que escribir un nombre de usuario y una contraseña al conectarse a su cuenta de Exchange Online o a las aplicaciones móviles de Office.
En este artículo se proporciona información para ayudarle a solucionar problemas de autenticación basada en certificados.
Versión del producto original: Microsoft Entra ID
Número de KB original: 4032987
Requisitos generales
- La autenticación basada en certificados solo admite entornos federados mediante la autenticación moderna (ADAL). La única excepción es Exchange ActiveSync (EAS) para Exchange Online que pueden usar las cuentas administradas.
- El certificado de usuario emitido en el perfil del usuario requiere que la dirección de correo electrónico enrutable del usuario aparezca en nombre alternativo del firmante. Puede estar en el formato UserPrincipalName o RFC822. Microsoft Entra ID asigna el valor RFC822 al atributo Proxy Address del directorio.
Determinar si la autenticación basada en certificados funciona en Azure Portal
Vaya a Azure Portal desde el dispositivo para probar la autenticación basada en certificados.
Nota:
La memoria caché del explorador debe borrarse antes de probar la conexión para que el usuario vea el mensaje de aprobación del certificado.
Escriba la dirección de correo electrónico del usuario. Esto redirige a la página de autenticación de ADFS.
En lugar de escribir una contraseña (si el método de autenticación basado en formularios está habilitado en ADFS), seleccione Iniciar sesión con un certificado X.509 y apruebe el uso del certificado de cliente cuando se le solicite.
Si no se recibe ningún mensaje de aprobación de certificado después de borrar la memoria caché del explorador en un dispositivo, siga estos pasos:
- Compruebe que el certificado de usuario y los certificados raíz de la entidad de certificación emisora están instalados en el dispositivo.
- Compruebe que el puerto TCP 49443 está abierto en los servidores proxy de aplicación web/ADFS y que la cadena de certificados de la entidad de certificación emisora está instalada en todos los servidores proxy de aplicación web o ADFS.
Determinar si el identificador de Entra de Microsoft está configurado correctamente
Ejecute el siguiente comando de PowerShell para instalar el módulo de PowerShell de Azure Active Directory (versión preliminar):
Install-Module AzureAD
Para crear una entidad de certificación de confianza, use el cmdlet New-AzureADTrustedCertificateAuthority y establezca el atributo crlDistributionPoint en un valor correcto.
Nota:
Al crear los objetos TrustedRootCertificateAuthority en microsoft Entra ID, las direcciones URL de CRL definidas en . No se usa el archivo CER. Los valores crlDistributionPoint y DeltaCrlDistributionPoint deben rellenarse manualmente mediante una ubicación web donde microsoft Entra ID puede acceder a las CRL. Las rutas de acceso CRL dentro de los certificados emitidos no tienen que contener las direcciones URL a las que se puede acceder a Microsoft Entra ID. Además, las CRL de gran tamaño que tardan más de 15 segundos en descargarse deben colocarse en un vínculo más rápido, como Azure Storage, para evitar retrasos en el almacenamiento en caché que pueden provocar errores de autenticación intermedios.
$cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]" $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation $new_ca.AuthorityType=0 $new_ca.TrustedCertificate=$cert $new_ca.crlDistributionPoint="<CRL Distribution URL>" New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
Asegúrese de que los valores siguientes están definidos correctamente en los objetos TrustedCertificateAuthority según las instrucciones siguientes:
Todos los url de CrlDistributionPoint y DeltaCrlDistributionPoint deben ser accesibles desde Internet por los dispositivos cliente y los servidores proxy de aplicación web y ADFS.
El*. CER para la ENTIDAD de certificación raíz debe aparecer como AuthorityType = RootAuthority.
El*. Cer para la entidad de certificación intermedia debe aparecer de la siguiente manera:
AuthorityType = IntermediateAuthority
AuthorityType = 0 = RootAuthority
AuthorityType = 1 = IntermediateAuthority
Nota:
Para realizar cambios en estos objetos, consulte Configuración de las entidades de certificación.
Ejecute los siguientes comandos para asegurarse de que la configuración de ADFS no esté establecida en PromptLoginBehavior: true. De lo contrario, se pedirá a los usuarios que escriban su nombre de usuario y contraseña para algunas aplicaciones modernas.
Connect-msolService
Get-MSOLDomainFederationSettings -DomainName contoso.com
Nota:
Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lee la actualización de desuso. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.
Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulta las Preguntas más frecuentes sobre migración. Nota: versiones 1.0.x de MSOnline pueden experimentar interrupciones después del 30 de junio de 2024.
Nota:
Esto ocurre porque algunas aplicaciones modernas envían prompt=login a Microsoft Entra ID en su solicitud. Microsoft Entra ID lo traduce en la solicitud de ADFS a wauth=usernamepassworduri (esto indica a ADFS que realice la autenticación de nombre de usuario y contraseña) y wfresh=0 (indica a ADFS que omita el estado de SSO y realice una autenticación nueva). Si los usuarios tienen que usar la autenticación basada en certificados, PromptLoginBehavior debe establecerse en False.
Para deshabilitar PromptLoginBehavior en el dominio de Microsoft Entra, ejecute el siguiente comando:
Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled
Determinar si las configuraciones de ADFS y Proxy de aplicación web están configuradas correctamente
La autenticación basada en certificados requiere ADFS 2012R2 o una versión posterior, y debe usar el proxy de aplicación web.
Nota:
No se admite el uso de un proxy de aplicación web de terceros a menos que admita todos los MUST en el documento del protocolo MS-ADFSPIP.
El archivo raíz
*.CER
debe estar en el contenedor de certificación raíz de confianza\Certificados del equipo. Además, todos los archivos intermedios*.CER
deben estar en el contenedor entidad de certificación raíz intermedia del equipo\Certificados . Para comprobarlo, ejecutecertlm.msc
o ejecute los siguientescertutil.exe
comandos en un símbolo del sistema con privilegios elevados:certutil -verifystore root
certutil -verifystore CA**
Los dispositivos cliente, los servidores ADFS y el proxy de aplicación web deben poder resolver los puntos de conexión crL que existen en la ENTIDAD de certificación intermedia *. CER y en los certificados de usuario que se emitieron al perfil de usuario en los dispositivos.
Para comprobar que los servidores de ADFS y el proxy de aplicación web pueden resolverlos, siga estos pasos:
- Exporte la ENTIDAD de certificación intermedia *. CER:
- Vea el almacén de certificados del equipo. Para ello, ejecute certlm.msc, expanda \Entidades de certificación intermedias\Certificados y, a continuación, haga doble clic en el certificado de CA intermedio.
- Haga clic en la pestaña Detalles y, a continuación, haga clic en el botón Copiar al archivo .
- Haga clic en Siguiente dos veces y acepte todos los valores predeterminados del asistente.
- Especifique un nombre de archivo y una ubicación, haga clic en Siguiente y, a continuación, haga clic en Finalizar.
- En la entidad de certificación emisora, exporte uno de los certificados de usuario emitidos a un dispositivo. Para ello, realice los pasos siguientes:
Ejecute certsrv.msc y, a continuación, seleccione el nodo Certificados emitidos.
En la columna Nombre común emitido, busque el certificado emitido al usuario que no puede conectarse.
Haga doble clic en el certificado y, a continuación, haga clic en la pestaña Detalles para exportar el certificado a un *. Archivo CER.
Nota:
Si se emite más de un certificado al usuario, busque el número de serie del certificado en la pestaña Detalles y compruebe que coincide con el certificado en el dispositivo.
Descargue PSEXEC.EXE y, a continuación, copie psexec.exe junto con *. Archivos CER de la ENTIDAD de certificación intermedia y del usuario a todos los servidores de ADFS y proxy de aplicación web.
Abra un nuevo símbolo del sistema en el contexto de seguridad del sistema. Para ello, abra un símbolo del sistema con privilegios elevados para cada servidor y ejecute el siguiente comando:
psexec -s -i -d cmd.exe
En el nuevo símbolo del sistema, ejecute los siguientes comandos para determinar si se puede acceder a la CRL:
certutil.exe -verify -urlfetch SubCA.cer > %computername%_%username%_SubCA.txt
certutil.exe -verify -urlfetch usercert.cer > %computername%_%username%_usercert.txt
En la salida, compruebe la sección ---------------- ---------------- Certificado CDP y determine si se pueden resolver todos los puntos de conexión.
Si los servidores de ADFS no pueden resolver la dirección URL HTTP, asegúrese de que las cuentas de servicio administradas de grupo en las que se ejecuta ADFS tienen acceso a través del firewall y el proxy. El servicio proxy de aplicación web se ejecuta en Servicio de red, por lo que la cuenta ComputerName$ requiere acceso a través del firewall y el proxy.
- Exporte la ENTIDAD de certificación intermedia *. CER:
Las notificaciones de paso a través para serialNumber y emisor deben configurarse para la confianza del proveedor de notificaciones de Active Directory y para la confianza de usuario autenticado de la Plataforma de identidad de Microsoft Office 365. Estos se pueden recuperar de los servidores ADFS mediante la ejecución de los siguientes comandos de PowerShell en un símbolo del sistema con privilegios elevados:
Get-AdfsClaimsProviderTrust -Name "Active Directory" @RuleTemplate = "PassThroughClaims" @RuleName = "<serialnumber AD for cert based auth>" c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "<Issuer AD for cert based auth>" c:[Type == http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer] => issue(claim = c);
Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform" @RuleTemplate = "PassThroughClaims" @RuleName = "<serialnumber RP for cert based auth>" c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "<Issuer RP for cert based auth>" c:[Type == http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer] => issue(claim = c);
Dado que es probable que la mayoría de los dispositivos que usan la autenticación de certificados se encuentren en la extranet (fuera de la red corporativa), puede habilitar la autenticación basada en certificados solo para la extranet o también para la intranet, según sea necesario. Para determinar si el método "Autenticación de certificados" está habilitado para o ambas opciones, ejecute el siguiente cmdlet desde un símbolo del sistema de PowerShell con privilegios elevados:
Get-AdfsAuthenticationProvider: ----------Output sample---------- AdminName : Certificate Authentication AllowedForPrimaryExtranet : True AllowedForPrimaryIntranet : True AllowedForAdditionalAuthentication : True AuthenticationMethods : {urn:ietf:rfc:2246, urn:oasis:names:tc:SAML:1.0:am:X509-PKI, urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient, urn:oasis:names:tc:SAML:2.0:ac:classes:X509...} Descriptions : {} DisplayNames : {} Name : CertificateAuthentication IdentityClaims : {} IsCustom : False RequiresIdentity : False
- Busque la entrada AdminName denominada Autenticación de certificados.
- Compruebe que AllowedForPrimaryExtranet está establecido en True.
- Opcionalmente, también puede establecer AllowedForPrimaryIntranet en True si quiere autenticación basada en certificados de usuarios de intranet.
- Haga clic en la pestaña Detalles y, a continuación, haga clic en el botón Copiar al archivo .
El puerto TCP 49443 debe ser accesible entre el dispositivo cliente y ADFS, también entre el dispositivo cliente y los servidores proxy de aplicación web. Para comprobar que TCP 49443 está escuchando y enlazado a ADFS en los servidores de ADFS y el proxy de aplicación web, ejecute el siguiente comando:
netsh http show urlacl > %computername%_49443.txt
Si el puerto TCP 49443 es accesible, debería ver la salida como la siguiente:
Reserved URL: https://<URL>:49443/adfs/ User: NT SERVICE\adfssrv Listen: Yes Delegate: Yes SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-975697593)
En un dispositivo cliente, intente conectarse al punto de conexión certificateTransport. Por ejemplo, use la siguiente dirección URL para
Contoso.com
:https://sts.contoso.com:49443/adfs/services/trust/2005/certificatetransport
Nota:
Si el punto de conexión es accesible y escucha, el intento de conexión debe girar indefinidamente mientras espera una respuesta.
Más información
- Microsoft Entra ID: autenticación basada en certificados para iOS y Android ahora en versión preliminar.
- Introducción a la autenticación basada en certificados en iOS: versión preliminar pública
- ADFS: Autenticación de certificados con microsoft Entra ID y Office 365
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.