Configurar S-MIME para Windows 10 y Windows 10 Mobile (Windows 10)

Contents
Administración de identidades y acceso

Introducción a Access Control
Introducción al Control de acceso dinámico
Identificadores de seguridad
Entidades de seguridad
Cuentas locales
Cuentas de Active Directory
Cuentas de Microsoft
Cuentas de servicio
Grupos de seguridad de Active Directory
Identidades especiales
Configurar S/MIME para Windows 10 y Windows 10 Mobile
Asignación de certificados de empresa
Instalar certificados digitales en Windows 10 Mobile
Protección del sistema de Windows Defender
Proteger las credenciales de dominio derivadas con Credential Guard
Cómo funciona Credential Guard
Requisitos de Credential Guard
Administrar Credential Guard
Límites de protección de Credential Guard
Consideraciones sobre el uso de Credential Guard
Credential Guard: mitigaciones adicionales
Credential Guard: problemas conocidos
Proteger las credenciales de Escritorio remoto con Credential Guard remoto
Tarjetas inteligentes
Funcionamiento del inicio de sesión mediante tarjetas inteligentes en Windows
Arquitectura de tarjeta inteligente
Enumeración y requisitos de certificados
Tarjeta inteligente y Servicios de Escritorio remoto
Tarjetas inteligentes para el servicio de Windows
Servicio de propagación de certificados
Servicio Directiva de extracción de tarjetas inteligentes
Herramientas y configuración de Tarjeta inteligente
Información de depuración de tarjetas inteligentes
Directiva de grupo de tarjeta inteligente y configuración de registros
Eventos de tarjeta inteligente
Control de cuentas de usuario
Cómo funciona el Control de cuentas de usuario
Configuración de directiva de seguridad de Control de cuentas de usuario
Configuración de las claves del Registro y directiva de grupo de Control de
cuentas de usuario
Tarjetas inteligentes virtuales
Comprender y evaluar las tarjetas inteligentes virtuales
Introducción a las tarjetas inteligentes virtuales: guía paso a paso
Usar tarjetas inteligentes virtuales
Implementar tarjetas inteligentes virtuales
Evaluar la seguridad de las tarjetas inteligentes virtuales
Tpmvscmgr
Guía técnica de VPN
Tipos de conexión de VPN
Decisiones de enrutamiento de VPN
Opciones de autenticación de VPN
VPN y acceso condicional
Resolución de nombres de VPN
Opciones desencadenadas automáticamente de perfil de VPN
Características de seguridad de VPN
Opciones de perfil de VPN
Cómo configurar el Protocolo Diffie Hellman sobre conexiones VPN IKEv2
Cómo usar el inicio de sesión único (SSO) a través de conexiones VPN y Wi-Fi
Resumen de la guía de mitigación de robos de credenciales de Windows 10
Windows Hello para empresas
Configurar S/MIME para Windows 10 y Windows 10
Mobile
16/07/2018 • 3 minutes to read
Se aplica a:
Windows 10
Windows 10 Mobile
S/MIME significa Extensiones seguras multipropósito al correo de Internet y proporciona una capa de seguridad
adicional para correos electrónicos enviados a una cuenta de Exchange ActiveSync (EAS ) y desde ella. En Windows
10, S/MIME permite a los usuarios cifrar los datos adjuntos y los mensajes salientes para que puedan leerlos solo
los destinatarios previstos que tienen una identificación digital (Id.), también conocida como certificado. Los
usuarios pueden firmar digitalmente un mensaje, lo que proporciona a los destinatarios una manera de comprobar
la identidad del remitente y que el mensaje no ha sido alterado.
Acerca del cifrado de mensajes

Los usuarios pueden enviar un mensaje cifrado a personas de su organización y a personas fuera de su
organización si tienen sus certificados de cifrado. Sin embargo, los usuarios que usan la aplicación Correo de
Windows 10 solo pueden leer los mensajes cifrados si los reciben en su cuenta de Exchange y tienen las claves de
descifrado correspondientes.
Solo los destinatarios que tengan un certificado pueden leer los mensajes cifrados. Si intentas enviar un mensaje
cifrado a destinatarios cuyo certificado de cifrado no está disponible, la aplicación te pedirá que quites estos
destinatarios antes de enviar el correo electrónico.
Acerca de firmas digitales

Un mensaje firmado digitalmente asegura al destinatario que el mensaje no ha sido alterado y comprueba la
identidad del remitente. Los destinatarios solo pueden comprobar la firma digital si usan un cliente de correo
electrónico compatible con S/MIME.
Requisitos previos
S/MIME está habilitado para las cuentas de Exchange (local y Office 365). Los usuarios no pueden usar la firma
y el cifrado de S/MIME con una cuenta personal como Outlook.com.
Se han instalado en el dispositivo certificados de intercambio de información personal (PFX) válidos.
Cómo crear perfiles de certificado PFX en el Administrador de configuración
Habilitar el acceso a recursos de la compañía mediante perfiles de certificado con Microsoft Intune
Elegir la configuración de S/MIME

En el dispositivo, sigue estos pasos: (agregar seleccionar certificado)
1. Abre la aplicación de correo. (En Windows 10 Mobile, la aplicación es Correo de Outlook).
2. Abre Configuración pulsando en el icono de engranaje en un equipo o en los puntos suspensivos (...) y, a
continuación, en el icono del engranaje en un teléfono.
3. Pulsa en Seguridad del correo electrónico.
4. En Seleccionar una cuenta, selecciona la cuenta para la que quieras configurar las opciones de S/MIME.
5. Selecciona un certificado para la firma digital y cifrado.
Selecciona Automáticamente para permitir que la aplicación elija el certificado.
Selecciona Manualmente para especificar un certificado de la lista de certificados válidos en el
dispositivo.
6. (Opcional) Selecciona Firmar siempre con S/MIME, Cifrar siempre con S/MIME, o ambas opciones,
para firmar digitalmente o cifrar de forma automática todos los mensajes salientes.
Nota: La opción para firmar o cifrar puede cambiarse para mensajes individuales, a menos que las
directivas EAS lo impidan.
7. Pulsa en la flecha atrás.
Cifrar o firmar mensajes individuales

1. Al redactar un mensaje, elige Opciones en la cinta. En el teléfono, se puede tener acceso a las opciones ,
puntee en el botón de puntos suspensivos (...).
2. Usa los iconos Firmar y Cifrar para activar la firma digital y el cifrado para este mensaje.
Leer mensajes firmados o cifrados

Cuando recibas un mensaje cifrado, la aplicación correo comprobará si hay un certificado disponible en el equipo.
Si hay un certificado disponible, el mensaje se descifrará cuando lo abras. Si el certificado está almacenado en una
tarjeta inteligente, se te pedirá que insertes la tarjeta inteligente para leer el mensaje. La tarjeta inteligente también
puede necesitar un PIN para acceder al certificado.
Instalar certificados de un mensaje recibido

Al recibir un correo electrónico con firma, la aplicación proporciona la característica para instalar el certificado de
cifrado correspondiente en el dispositivo si está disponible el certificado. Este certificado puede usarse después
para enviar correos electrónicos cifrados a esta persona.
1. Abre un correo electrónico con firma.
2. Pulsa o haz clic en el icono de firma digital del panel de lectura.
3. Pulsa en Instalar.
Asignación de certificados de empresa
Se aplica a
Windows 10
La asignación de certificados de empresa es una característica de Windows para recordar o "asignar" una entidad
emisora de certificados raíz o certificado de entidad final a un nombre de dominio dado. La asignación de
certificados de ayuda a reducir los ataques de tipo "Man in the middle" al permitirte proteger los nombres de
dominio internos contra certificados de encadenamiento o no deseados o contra certificados emitidos de forma
fraudulenta.
NOTE
Los nombres de dominio externo, donde entidad de certificación pública emite el certificado emitido para estos dominios, no
son ideales para la asignación de certificados de empresa.
Las API de certificado de Windows (CertVerifyCertificateChainPolicy y WinVerifyTrust) se actualizan para

comprobar si la cadena de certificados de autenticación de servidores del sitio coincide con un conjunto restringido
de certificados. Estas restricciones se encapsulan en una lista de certificado de confianza (CTL ) de reglas de
asignación, que está configurada e implementada en equipos con Windows10. El certificado de cualquier sitio que
desencadene un error de coincidencia de nombre hace que Windows escriba un evento en el registro de eventos
CAPI2 e impide que el usuario navegue al sitio web con Microsoft Edge o Internet Explorer.
Implementación
Para implementar la asignación de certificados de empresa, debes:
Crear un archivo XML de reglas de asignación de certificados con formato correcto.
Crear un archivo de lista de certificados de confianza de reglas de asignación a partir del archivo XML.
Aplicar el archivo de lista de certificados de confianza de reglas de asignación a un equipo administrador de
referencia.
Implementar la configuración del registro en el equipo de referencia mediante la Consola de administración de
directivas de grupo (GPMC ), que se incluye en las Herramientas de administración remota del servidor (RSAT) .
Crear un archivo XML de las reglas de asignación
El archivo de reglas de asignación basado en XML consta de una secuencia de elementos PinRule. Cada elemento
PinRule contiene una secuencia de uno o más elementos Site y una secuencia de cero o más elementos Certificate.
<PinRules ListIdentifier="PinRulesExample" Duration="P28D">
<PinRule Name="AllCertificateAttributes" Error="None" Log="true">

<Certificate File="Single.cer"/>
<Certificate File="Multiple.p7b"/>
<Certificate File="Multiple.sst"/>
<Certificate Directory="Multiple"/>
<Certificate Base64="MIIBy … QFzuM"/>
<Certificate File="WillExpire.cer" EndDate="2015-05-12T00:00:00Z"/>
<Site Domain="xyz.com"/>
</PinRule>
<PinRule Name="MultipleSites" Log="false">

<Certificate File="Root.cer"/>
<Site Domain="xyz.com"/>
<Site Domain=".xyz.com"/>
<Site Domain="*.abc.xyz.com" AllSubdomains="true"/>
<Site Domain="WillNormalize.com"/>
</PinRule>
</PinRules>
Elemento PinRules
El elemento PinRules puede tener los atributos siguientes. Para obtener ayuda con el formato de las reglas de
asignación, consulta Representar una fecha en XML o Representar una duración en XML.
ATRIBUTO DESCRIPCIÓN REQUERIDO
Duration o NextUpdate Especifica cuándo expirarán las reglas de ¿Es obligatorio? Sí. Al menos uno es
asignación. Uno es obligatoria. obligatorio.
NextUpdate tiene prioridad si se
especifican ambos.
Duración, declarado como un tipo de
datos XML TimeSpan, no admite años y
meses. El atributo NextUpdate se
declara como un tipo de datos XML
DateTime en hora UTC.
LogDuration o LogEndDate Configura que la auditoría solo se No.

extenderá más allá de la expiración del
cumplimiento de las reglas de
asignación.
LogEndDate, declarado como una tipo
de datos XML DateTime en hora UTC,
tiene precedencia si se especifican
ambos.
LogDuration se declara como un tipo
de datos XML TimeSpan, que no admite
años y meses.
Si no se especifica ninguno de los
atributos, la expiración de la auditoría
usará los atributos Duration o
NextUpdate.
ListIdentifier Proporciona un nombre descriptivo No.

para la lista de reglas de asignación.
Windows no usa este atributo para la
aplicación de la asignación de
certificados; sin embargo, se incluye
cuando las reglas de asignación se
convierten en una lista de certificados
de confianza (CTL).
Elemento PinRule
El elemento PinRule puede tener los atributos siguientes:
Name Identifica la PinRule de manera Sí.

exclusiva. Windows usa este atributo
para identificar el elemento en caso de
un error de análisis o de una salida
detallada. El atributo no está incluido en
la lista de certificados de confianza (CTL)
generada.
Error Describe la acción que realiza Windows No.

cuando encuentra un error de
coincidencia de PIN. Puede elegir entre
los siguientes valores de cadena:
- Revoked: Windows denuncia el
certificado que protege el sitio como si
estuviera revocado. Normalmente esto
impide que el usuario acceda al sitio.
- InvalidName: Windows denuncia el
certificado que protege el sitio como si
el nombre en el certificado no
coincidiera con el nombre en el sitio.
Normalmente esto hace que se
pregunte al usuario antes de acceder al
sitio.
- None: el valor predeterminado. No se
devuelve ningún error. Puedes usar esta
configuración para auditar las reglas de
asignación sin introducir ninguna
fricción con el usuario.
Log Un valor booleano que se representa No.

como cadena y es igual a true o false.
De manera predeterminada, el registro
está habilitado (true).
Elemento Certificate
El elemento Certificate puede tener los atributos siguientes:

Archivo Ruta de acceso a un archivo que Sí (debe estar presente File, Directory o
contiene uno o más certificados. Donde Base64).
los certificados pueden codificarse
como:
-.Certificado único
- p7b
- sst
Estos archivos también pueden tener el
formato Base64. Todos los elementos
Site que se incluyen en el mismo
elemento PinRule pueden coincidir con
cualquiera de estos certificados.
Directory Ruta de acceso a un directorio que Sí (debe estar presente File, Directory o
contiene uno o varios de los archivos de Base64).
certificado anteriores. Omite los
archivos que no contienen ningún
certificado.
Base64 Certificados codificados con Base64. Sí (debe estar presente File, Directory o
Donde los certificados pueden Base64).
codificarse como:
-.Certificado único
- p7b
- sst
Esto permite incluir los certificados en el
archivo XML sin una dependencia del
directorio de archivos.
Nota:
Puedes usar certutil-encode para
convertir un archivo .cer en base64. A
continuación, puedes usar el Bloc de
notas para copiar el certificado
codificado en base64 y pegarlo en la
regla de asignación.
EndDate Te permite configurar una fecha de No.

expiración para cuando el certificado ya
no sea válido en la regla de asignación.
Si estás en el proceso de cambiar a una
nueva entidad de certificación raíz,
puedes establecer EndDate para
permitir la coincidencia de certificados
de este elemento.
Si la hora actual es posterior a EndDate,
luego, al crear la lista de certificados de
confianza (CTL), el analizador envía un
mensaje de advertencia y excluye los
certificados de la regla de asignación de
la CTL generada.
Para obtener ayuda con el formato de
las reglas de asignación, consulta
Representar una fecha en XML.
Elemento Site
El elemento Site puede tener los atributos siguientes:
Domain Contiene el nombre DNS que debe Sí.

coincidir para esta regla de asignación.
Al crear la lista de certificados de
confianza, el analizador normaliza el
valor de cadena de nombre de entrada
como sigue:
- Si el nombre DNS tiene un "*" inicial,
se quita.
- El nombre DNS que no sea ASCII se
convierte en ASCII Punycode.
- Los caracteres ASCII en mayúsculas se
convierten en minúsculas.
Si el nombre normalizado tiene un "."
inicial, se habilita la coincidencia de
etiqueta izquierda comodín. Por
ejemplo, ".xyz.com" coincidirá con
"abc.xyz.com".
AllSubdomains De manera predeterminada, la No.

coincidencia de etiqueta izquierda
comodín está restringida a una única
etiqueta izquierda. Este atributo se
puede establecer en "true" para habilitar
comodines que coincidan con todas las
etiquetas izquierdas.
Por ejemplo, al establecer este atributo
también se hará que "123.abc.xyz.com"
coincida con el valor de dominio
".xyz.com".
Crear una lista de certificados de confianza de reglas de asignación

La utilidad de línea de comandos, Certutil.exe, incluye el argumento generatePinRulesCTL para analizar el
archivo XML y generar la lista de certificados de confianza (CTL ) codificada que agregas al equipo de referencia
con Windows10, versión1703 e implementaciones posteriores. La sintaxis de uso es:
CertUtil [Options] -generatePinRulesCTL XMLFile CTLFile [SSTFile]

Generate Pin Rules CTL
XMLFile -- input XML file to be parsed.
CTLFile -- output CTL file to be generated.
SSTFile -- optional .sst file to be created.
The .sst file contains all of the certificates
used for pinning.
Options:
-f -- Force overwrite
-v -- Verbose operation
Los mismos certificados pueden presentarse en varios elementos PinRule. El mismo dominio puede presentarse
en varios elementos PinRule. Certutil fusiona estos en la lista de certificados de confianza de reglas de asignación
resultante.
Certutil.exe no aplica estrictamente la definición de esquema XML. Lleva a cabo lo siguiente para permitir que otras
herramientas agreguen o consuman sus propios elementos y atributos específicos:
Omite los elementos antes y después del elemento PinRules.
Omite cualquier elemento que no coincida con Certificate o Site dentro del elemento PinRules.
Omite los atributos que no coinciden con los nombres anteriores para cada tipo de elemento.
Usa el comando certutil con el argumento generatePinRulesCTL junto con el archivo XML que contiene tus
reglas de asignación de certificados. Por último, proporciona el nombre de un archivo de salida que incluya las
reglas de asignación de certificados en forma de una lista de certificados de confianza.
certutil -generatePinRulesCTL certPinRules.xml pinrules.stl
Aplicar reglas de asignación de certificados a un equipo de referencia

Ahora que las reglas de asignación de certificados tienen el formato de lista de certificados de confianza, debes
aplicar la configuración a un equipo de referencia como requisito previo para implementar la configuración en la
empresa. Para simplificar la configuración de implementación, es mejor aplicar las reglas de asignación de
certificados en un equipo que tenga la Consola de administración de directivas de grupo (GPMC ) que se incluye en
las Herramientas de administración remota del servidor (RSAT).
Usa certutil.exe para aplicar las reglas de asignación de certificados en el equipo de referencia con el argumento
setreg. El argumento setreg toma un argumento secundario que determina la ubicación de dónde certutil escribe
las reglas de asignación de certificados. Este argumento secundario es chain\PinRules. El último argumento que
proporcionas es el nombre de archivo que contiene tus reglas de asignación de certificados en el formato de lista
de certificados de confianza (.stl). El nombre del archivo se pasa como último argumento; sin embargo, tienes que
agregar un prefijo al nombre de archivo con el símbolo "@", tal como se muestra en el siguiente ejemplo. Debes
ejecutar este comando desde un símbolo del sistema con privilegios elevados.
Certutil -setreg chain\PinRules @pinrules.stl
Certutil escribe la información binaria en la ubicación del Registro siguiente:
NOMBRE VALOR
Clave HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingTyp
e0\CertDllCreateCertificateChainEngine\Config
Nombre PinRules
Valor Contenido binario del archivo de lista de certificados de

confianza de las reglas de asignación de certificados
Tipo de datos REG_BINARY

Implementar la configuración de regla de asignación de empresa mediante directiva de grupo
Has creado correctamente un archivo XML de reglas de asignación de certificados. A partir el archivo XML, has
creado un archivo de lista de confianza de asignación de certificados, y has aplicado el contenido de ese archivo al
equipo de referencia desde el que puedes ejecutar la Consola de administración de directivas de grupo. Ahora
tienes que configurar un objeto de directiva de grupo para incluir la configuración de reglas de asignación de
certificados aplicada e implementarla en tu entorno.
Inicia sesión en el equipo de referencia con credenciales equivalente a la de administrador de dominio.
1. Inicia la Consola de administración de directivas de grupo (gpmc.msc).
2. En el panel de navegación, expande el nodo del bosque y luego expande el nodo de dominio.
3. Expande el nodo que tiene contiene el nombre de dominio de Active Directory.
4. Selecciona el nodo Objetos de directiva de grupo. Haz clic con el botón derecho en el nodo Objetos de
directiva de grupo y luego en Nuevo.
5. En el cuadro de diálogo Nuevo GPO, escribe Enterprise Certificate Pinning Rules en el cuadro de texto
Nombre y haz clic en Aceptar.
6. En el panel de contenido, haz clic en el objeto de directiva de grupo Enterprise Certificate Pinning Rules y
haz clic en Editar.
7. En el Editor de administración de directivas de grupo, en el panel de navegación, expande el nodo
Preferencias bajo Configuración del equipo. Expande Configuración de Windows.
8. Haz clic con el botón derecho en el nodo Registro y haz clic en Nuevo.
9. En el cuadro de diálogo Nuevas propiedades de Registro, selecciona Actualizar de la lista Acción.
Selecciona HKEY_LOCAL_MACHINE de la lista Subárbol.
10. Para la Ruta de la clave, haz clic en … para iniciar Explorador de elementos del Registro. Navega a la
siguiente clave de registro y selecciona el nombre del valor de registro PinRules:
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType0\CertDllCreateCertificateChainEngine\C
onfig
Haz clic en Seleccionar para cerrar el Explorador de elementos del Registro.
11. La Ruta de la clave debe contener la clave del Registro seleccionada. La configuración del Nombre del
valor debe contener el nombre del valor del registro PinRules. El Tipo de valor debe ser REG_BINARY y
los Datos del valor deben contener una serie larga de números del 0 al 9 y letras que van de la A a la F
(hexadecimal). Haz clic en Aceptar para guardar la configuración y cerrar el cuadro de diálogo.
12. Cierra el Editor de administración de directivas de grupo para guardar la configuración.

13. Vincula el objeto de directiva de grupo Enterprise Certificate Pinning Rules para aplicar en los equipos que
ejecutan Windows10, versión1703 en tu empresa. Cuando estos equipos unidos a un dominio aplican la
directiva de grupo, la información del Registro configurada en el objeto de directiva de grupo se aplica al
equipo.
Registro de reglas de asignación adicionales

Para ayudar en la creación de reglas de asignación de certificados, puedes configurar la opción PinRulesLogDir
debajo de la clave del Registro de configuración de la cadena de certificados para incluir un directorio principal
para registrar las reglas de asignación.
NOMBRE VALOR
Clave HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingTyp
e0\CertDllCreateCertificateChainEngine\Config
Nombre PinRulesLogDir
Valor El directorio principal donde Windows debe escribir los

registros de reglas de asignación adicionales
Tipo de datos REG_SZ
Permiso para la carpeta del registro de reglas de asignación

La carpeta en la que Windows escribe los registros de reglas de asignación adicionales debe tener permisos para
que todos los usuarios y aplicaciones tengan acceso completo. Puedes ejecutar los siguientes comandos desde un
símbolo del sistema con privilegios elevados para obtener los permisos adecuados.
set PinRulesLogDir=c:\PinRulesLog
mkdir %PinRulesLogDir%
icacls %PinRulesLogDir% /grant *S-1-15-2-1:(OI)(CI)(F)
icacls %PinRulesLogDir% /grant *S-1-1-0:(OI)(CI)(F)
icacls %PinRulesLogDir% /grant *S-1-5-12:(OI)(CI)(F)
icacls %PinRulesLogDir% /inheritance:e /setintegritylevel (OI)(CI)L
Siempre que una aplicación comprueba una cadena de certificados TLS/SSL que contiene un nombre de servidor
que coinciden con un nombre DNS en el certificado del servidor, Windows escribe un archivo. p7b, que consta de
todos los certificados de cadena del servidor, en una de tres carpetas secundarias:
AdminPinRules: coincide con un sitio en las reglas de asignación de certificados de la empresa.
AutoUpdatePinRules: coincide con un sitio en las reglas de asignación de certificados administradas por
Microsoft.
NoPinRules: no coincide con ningún sitio en las reglas de asignación de certificados.
El nombre de archivo de salida consta de 8 dígitos hexadecimales ASCII a la izquierda, correspondientes a la huella
digital de SHA1 de la raíz, seguidos por el nombre del servidor. Por ejemplo:
D4DE20D0_xsi.outlook.com.p7b
DE28F4A4_www.yammer.com.p7b
Si hay una falta de coincidencia con la regla de asignación de certificados de la empresa o la regla de asignación de
certificados de Microsoft, Windows escribe el archivo. p7b en la carpeta secundaria MismatchPinRules. Si
expiraron las reglas de asignación, Windows escribe el archivo. p7b en la carpeta secundaria ExpiredPinRules.
Representar una fecha en XML

Muchos atributos dentro del archivo XML de las reglas de asignación son fechas.
Estas fechas deben tener el formato correcto y estar representadas en hora UTC.
Puedes usar Windows PowerShell para dar formato a estas fechas.
Luego puedes copiar la salida del cmdlet y pegarla en el archivo XML.
Por cuestiones de simplicidad, puedes truncar el punto decimal (.) y los números de después de él. Sin embargo,
asegúrate de anexar la "Z" mayúscula al final de la cadena de fecha XML.
2015-05-11T07:00:00.2655691Z
2015-05-11T07:00:00Z
Convertir una fecha XML

También puedes usar Windows PowerShell para convertir una fecha XML en una fecha legible para las personas
para validar que es la fecha correcta.
Representar una duración en XML
Algunos elementos pueden configurarse para usar una duración, en lugar de una fecha. Debes representar la
duración como un tipo de datos TimeSpan XML. Puedes usar Windows PowerShell para dar formato y validar
correctamente las duraciones (TimeSpan), copiarlas y pegarlas en el archivo XML.
Convertir una duración XML

Puedes convertir un objeto TimeSpan con formato XML en una variable de duración que puedes leer.
Definición de esquema XML (XSD) de lista de certificados de confianza
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="PinRules">
<xs:complexType>
<xs:sequence>
<xs:element name="PinRule" maxOccurs="unbounded" minOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="Certificate" maxOccurs="unbounded" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute type="xs:dateTime" name="EndDate" use="optional"/>
<xs:attribute type="xs:string" name="File" use="optional"/>
<xs:attribute type="xs:string" name="Directory" use="optional"/>
<xs:attribute type="xs:base64Binary" name="Base64" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Site" maxOccurs="unbounded" minOccurs="1">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute type="xs:string" name="Domain"/>
<xs:attribute type="xs:boolean" name="AllSubdomains" use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute type="xs:string" name="Name"/>
<xs:attribute name="Error" use="optional" default="None">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value ="Revoked"/>
<xs:enumeration value ="InvalidName"/>
<xs:enumeration value ="None"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute type="xs:boolean" name="Log" use="optional" default="true"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute type="xs:duration" name="Duration" use="optional"/>
<xs:attribute type="xs:duration" name="LogDuration" use="optional"/>
<xs:attribute type="xs:dateTime" name="NextUpdate" use="optional"/>
<xs:attribute type="xs:dateTime" name="LogEndDate" use="optional"/>
<xs:attribute type="xs:string" name="ListIdentifier" use="optional"/>
</xs:complexType>
</xs:element>
</xs:schema>
Se aplica a:
Windows 10 Mobile
Los certificados digitales enlazan la identidad de un usuario o equipo a un par de claves que pueden usarse para
cifrar y firmar la información digital. Los certificados se emiten por una entidad de certificación (CA) que garantiza
la identidad del titular del certificado, y permiten comunicaciones de cliente seguras con sitios y servicios web.
Los certificados en Windows 10 Mobile se usan principalmente para los fines siguientes:
Para crear un canal seguro mediante una capa de sockets seguros (SSL ) entre un teléfono y un servidor o
servicio web.
Para autenticar un usuario en un servidor proxy inverso que se usa para habilitar Microsoft Exchange
ActiveSync (EAS ) para el correo electrónico.
Para la instalación y las licencias de aplicaciones (de la Tienda de Windows Phone o un sitio de distribución
personalizado de la empresa).
WARNING
En Windows10, versión1607, si tienes varios certificados aprovisionados en el dispositivo y el perfil de Wi-Fi aprovisionado no
tiene ningún criterio de filtrado estricto, pueden producirse errores de conexión al conectarte a la red Wi-Fi. Más información
sobre este problema conocido en la versión 1607
Instalar certificados mediante Microsoft Edge

Un certificado puede publicarse en un sitio web y estar disponible para los usuarios a través de una dirección URL
accesible para dispositivo, que pueden usar para descargar el certificado. Cuando un usuario accede a la página y
pulsa en el certificado, se abre en el dispositivo. El usuario puede inspeccionar el certificado y, si decide continuar,
el certificado se instala en el dispositivo de Windows 10 Mobile.
Instalar certificados mediante correo electrónico

El programa de instalación del certificado de Windows10Mobile admite archivos .cer, .p7b, .pem y .pfx. Algunos
programas de correo electrónico bloquean los archivos .cer por motivos de seguridad. Si ocurre esto en tu
organización, usa un método alternativo para implementar el certificado. Los certificados que se envían a través de
correo electrónico aparecen como datos adjuntos del mensaje. Cuando se recibe un certificado, un usuario puede
pulsar para revisar el contenido y, a continuación, pulsar para instalar el certificado. Por lo general, cuando se
instala un certificado de identidad, se pide al usuario la contraseña (o frase de contraseña) que lo protege.
Instalar certificados mediante la administración de dispositivos móviles

(MDM)
Windows 10 Mobile admite que los certificados raíz, de entidad de certificación y de cliente se configuren a través
de MDM. Con MDM, un administrador puede agregar, eliminar o consultar directamente certificados raíz y de
entidad de certificación, así como configurar el dispositivo para inscribir un certificado de cliente con un servidor
de inscripción de certificados que admita el Protocolo de inscripción de certificados simple (SCEP ). Wi-Fi, VPN, el
correo electrónico y el explorador usan los certificados de cliente SCEP inscritos. Un servidor MDM también
puede consultar y eliminar los certificados de cliente SCEP inscritos (incluidos los certificados instalados por el
usuario) o desencadenar una nueva solicitud de inscripción antes de que el certificado actual expire.
WARNING
No uses SCEP para certificados de cifrado de S/MIME. Debes usar un perfil de certificado PFX para admitir S/MIME en
Windows 10 Mobile. Para obtener instrucciones sobre cómo crear un perfil de certificado PFX en Microsoft Intune, consulta
Habilitar el acceso a los recursos de empresa mediante perfiles de certificados con Microsoft Intune.
Proceso de instalación de certificados mediante MDM

1. El servidor MDM genera la solicitud inicial de inscripción de certificado incluida la contraseña de
comprobación, la dirección URL del servidor SCEP y otros parámetros relacionados con la inscripción.
2. La directiva se convierte en la solicitud de OMA DM y se envía al dispositivo.
3. El certificado de la entidad de certificación de confianza se instala directamente durante la solicitud MDM.
4. El dispositivo acepta la solicitud de inscripción del certificado.
5. El dispositivo genera el par de claves pública y privada.
6. El dispositivo se conecta al punto con conexión a Internet expuesto por el servidor MDM.
7. El servidor MDM crea un certificado firmado con el certificado de entidad de certificación adecuado y lo
devuelve al dispositivo.
NOTE
El dispositivo admite la función pendiente para permitir que el lado del servidor realice una comprobación adicional
antes de emitir el certificado. En este caso, se enviará un estado pendiente al dispositivo. El dispositivo se pondrá en
contacto periódicamente con el servidor, en función de los parámetros preconfigurados de número de reintentos y de
período de reintento. El reintento termina cuando:
Se ha recibido correctamente un certificado del servidor.
El servidor devuelve un error.
El número de reintentos alcanza el límite preconfigurado.
8. El certificado se instala en el dispositivo. El explorador, la red Wi-Fi, la VPN, el correo electrónico y otras
aplicaciones propias tienen acceso a este certificado.
NOTE
Si MDM solicita la clave privada que se almacena en el Módulo de proceso de confianza (TPM) (configurado durante
la solicitud de inscripción), la clave privada se guardará en el TPM. Ten en cuenta que certificado SCEP inscrito
protegido por TPM no está protegido por un PIN. Sin embargo, si el certificado se importa al proveedor de
almacenamiento de claves (KSP) de Windows Hello para empresas, está protegido por el PIN de Hello.
Temas relacionados
Configurar S/MIME
2 minutes to read
Proteger las credenciales de dominio derivadas con
Credential Guard de Windows Defender
Se aplica a:
Windows 10
WindowsServer2016
¿Prefieres el vídeo? Consulta Credential Theft and Lateral Traversal (Robo de credenciales y cruce seguro lateral)
en la serie de vídeos Deep Dive into Windows Defender Credential Guard.
Credential Guard de Windows Defender, que se introdujo en Windows 10 Enterprise y en Windows Server 2016,
usa seguridad basada en la virtualización para aislar secretos, de manera que solo el software del sistema con
privilegios puede acceder a ellos. El acceso no autorizado a estos secretos puede derivar en ataques de robo de
credenciales, como ataques pass-the-hash o pass-the-ticket. Credential Guard de Windows Defender impide estos
ataques mediante la protección de los hash de contraseña NTLM, los vales de concesión de vales de Kerberos y las
credenciales que almacenan las aplicaciones como credenciales de dominio.
Al habilitar Credential Guard de Windows Defender, se proporcionan las siguientes características y soluciones:
Seguridad de hardware NTLM, Kerberos y el Administrador de credenciales usan las características de
seguridad de plataforma, como el arranque seguro y la virtualización, para proteger las credenciales.
Seguridad basada en la virtualización Windows NTLM, las credenciales derivadas de Kerberos y otros
secretos se ejecutan en un entorno protegido que está aislado del sistema operativo en ejecución.
Mejor protección contra las amenazas persistentes avanzadas Cuando se protegen las credenciales de
dominio del Administrador de credenciales, NTLM y las credenciales derivadas de Kerberos mediante seguridad
basada en virtualización, las herramientas y técnicas de ataque de robo de credenciales que se usan en muchos
ataques dirigidos se bloquean. Con la ejecución de malware en el sistema operativo con privilegios
administrativos no se pueden extraer secretos que están protegidos con la seguridad basada en la virtualización.
Aunque Credential Guard de Windows Defender es una mitigación eficaz, los ataques de amenazas
persistentes, probablemente, cambiarán por nuevas técnicas de ataque y también deberías incorporar Device
Guard de Windows Defender y otras arquitecturas y estrategias de seguridad.
Temas relacionados
Modo de usuario aislado de Windows 10 con David Probert (Channel 9)
Características y procesos de modo de usuario aislado de Windows 10 con Logan Gabriel (Channel 9)
Más en Procesos y características en modo de usuario aislado de Windows 10 con David Probert (Channel 9)
Mitigación de los robos de credenciales mediante el modo de usuario aislado de Windows 10 (Channel 9)
Protección de contraseñas de red con Credential Guard de Windows Defender
Habilitación de la validación KDC estricta en Windows Kerberos
Novedades en la autenticación Kerberos para Windows Server 2012
Comprobación del mecanismo de autenticación de AD DS en la Guía paso a paso de Windows Server 2008 R2
Módulo de plataforma segura
Consulta también
Deep Dive into Windows Defender Credential Guard: vídeos relacionados
Credentials Protected by Windows Defender Credential Guard (Credenciales protegidas con Credential Guard de
Windows Defender).
Cómo funciona Credential Guard de Windows
Defender
Se aplica a:
Windows10
WindowsServer2016
¿Prefieres el vídeo? Consulta Windows Defender Credential Guard Design (Diseño de Credential Guard de
Windows Defender) en la serie de vídeos Deep Dive into Windows Defender Credential Guard.
Kerberos, NTLM y el Administrador de credenciales aíslan secretos mediante la seguridad basada en virtualización.
Las versiones anteriores de Windows almacenaban secretos en la Autoridad de seguridad local (LSA). Antes de
Windows 10, la LSA almacenaba los secretos que usaba el sistema operativo en la memoria del proceso. Con
Credential Guard de Windows Defender habilitado, el proceso de LSA en el sistema operativo se comunica con un
nuevo componente denominado proceso LSA aislado que almacena y protege estos secretos. Los datos
almacenados mediante el proceso LSA aislado se protegen con la seguridad basada en la virtualización y no son
accesibles para el resto del sistema operativo. LSA usa llamadas a procedimiento remoto para comunicarse con el
proceso LSA aislado.
Por motivos de seguridad, el proceso LSA aislado no hospeda ningún controlador de dispositivo. En su lugar, solo
hospeda un pequeño subconjunto de binarios del sistema operativo que solo son necesarios para la seguridad.
Todos estos binarios se firman con un certificado de confianza de la seguridad basada en la virtualización y estas
firmas se validan antes de iniciar el archivo en el entorno protegido.
Cuando se habilita Credential Guard de Windows Defender, NTLMv1, MS -CHAPv2, Digest y CredSSP no pueden
usar las credenciales de inicio de sesión. Por lo tanto, el inicio de sesión único no funciona con estos protocolos. Sin
embargo, las aplicaciones pueden pedir credenciales o usar credenciales almacenadas en el almacén de
credenciales de Windows que no estén protegidas con Credential Guard de Windows Defender con cualquiera de
estos protocolos. Se recomienda encarecidamente que las credenciales importantes, como las de inicio de sesión,
no se usen con ninguno de estos protocolos. Si los usuarios del dominio o Azure AD deben usar estos protocolos,
se deben proporcionar credenciales secundarias para estos casos.
Cuando se habilita Credential Guard de Windows Defender, Kerberos no permite la delegación Kerberos sin
restricciones ni el cifrado DES, no solo para las credenciales de inicio de sesión, sino también para las credenciales
solicitadas o guardadas.
Aquí encontrarás una descripción general de cómo se aísla la LSA mediante la seguridad basada en virtualización:
Consulta también
Robo de credenciales y cruce seguro lateral
Seguridad de virtualización
Credentials Protected by Windows Defender Credential Guard (Credenciales protegidas con Credential Guard de
Windows Defender).
Requisitos de Credential Guard de Windows
Defender
Se aplica a:
Windows 10
WindowsServer2016
¿Prefieres el vídeo? Consulta Windows Defender Credential Guard Deployment (Implementación de Credential
Guard de Windows Defender) en la serie de vídeos Deep Dive into Windows Defender Credential Guard.
Para que Windows Defender credenciales Guard proporcionar protección, los equipos que va a proteger deben
cumplir determinados requisitos de hardware, firmware y software de línea de base que nos referiremos a como
los requisitos de Hardware y software. Además, Credential Guard de Windows Defender bloquea determinadas
funcionalidades de autenticación, así que las aplicaciones que requieran funcionalidades bloqueadas no
funcionarán. Nos referiremos a esto como Requisitos de aplicación. Además, los equipos pueden cumplir
calificaciones adicionales de firmware y hardware, y recibir protecciones adicionales. Los equipos estarán más
reforzados frente a determinadas amenazas. Para obtener información detallada sobre las protecciones de línea
base, además de protecciones para mejorar la seguridad que están asociadas a las opciones de hardware y
firmware disponibles en 2015, 2016 y 2017, consulta las tablas de Consideraciones de seguridad.
Requisitos de hardware y software

Para proporcionar protección básica contra intentos de nivel de sistema operativo para leer credenciales de
dominio de Credential Manager, NTLM y credenciales derivadas de Kerberos, Credential Guard de Windows
Defender usa:
Compatibilidad con seguridad basada en virtualización (obligatoria)
Arranque seguro (obligatorio)
TPM 1.2 o 2.0, ya sea discreto o firmware (preferido - proporciona el enlace de hardware)
Bloqueo UEFI (preferido: impide que el atacante deshabilite opciones con un sencillo cambio de clave del
Registro)
La seguridad basada en virtualización requiere:
CPU de 64 bits
Extensiones de virtualización de CPU, además de tablas de páginas extendidas
Hipervisor de Windows
Implementación de Credential Guard de Windows Defender en máquinas virtuales
Credential Guard puede proteger información confidencial en una máquina virtual de Hyper-V, tal como lo haría
en una máquina física. Cuando se implemente Credential Guard en una máquina virtual, los secretos protegen de
ataques dentro de la máquina virtual. Credential Guard no proporciona protección adicional contra ataques de
sistema con privilegios originados desde el host.
Requisitos para ejecutar Credential Guard de Windows Defender en máquinas virtuales Hyper-V
El host de Hyper-V debe tener una IOMMU y ejecutar al menos Windows Server 2016 o Windows 10 versión
1607.
La máquina virtual Hyper-V debe ser de generación 2, tener un TPM virtual habilitado y ejecutar Windows
Server 2016 o Windows 10 como mínimo.
Para obtener información acerca de otras plataformas de host, consulta Enabling Windows Server 2016 and
Hyper-V virtualization based security features on other platforms (Habilitar las características de seguridad
basadas en virtualización de Windows Server 2016 y Hyper-V en otras plataformas).
Para obtener más información sobre los requisitos de hardware y software de Remote Credential Guard de
Windows Defender, consulta Windows Defender Remote Credential Guard requirements (Requisitos de Remote
Credential Guard de Windows Defender).
Requisitos de aplicaciones
Cuando se habilita Credential Guard de Windows Defender, se bloquean las funcionalidades de autenticación
específicas, así que las aplicaciones que requieran funcionalidades bloqueadas no funcionarán. Las aplicaciones
deben probarse antes de la implementación para garantizar que son compatibles con la funcionalidad reducida.
WARNING
No se admite la habilitación de Credential Guard de Windows Defender en controladores de dominio.
El controlador de dominio hospeda los servicios de autenticación que se integran con procesos aislados cuando se habilita
Credential Guard de Windows Defender, lo que provoca bloqueos.
NOTE
Credential Guard de Windows Defender no proporciona protección para la base de datos de Active Directory ni el
Administrador de cuentas de seguridad (SAM). Las credenciales protegidas por Kerberos y NTLM cuando se habilita
Credential Guard de Windows Defender también están en la base de datos de Active Directory (en los controladores de
dominio) y en SAM (para las cuentas locales).
Las aplicaciones se interrumpirán si necesitan:

Compatibilidad con el cifrado DES de Kerberos
Delegación de Kerberos sin restricciones
Extraer TGT de Kerberos
NTLMv1
Las aplicaciones pedirán credenciales y las expondrán a riesgos si requieren:
Autenticación implícita
Delegación de credenciales
MS -CHAPv2
Las aplicaciones pueden provocar problemas de rendimiento al intentar enlazar el proceso de Credential Guard de
Windows Defender aislado.
Los servicios o protocolos que dependen de Kerberos, tales como recursos compartidos de archivos, escritorio
remoto o BranchCache, siguen funcionando y no se han visto afectados por Credential Guard de Windows
Defender.
Consulta este vídeo: Credenciales protegidas con Credential Guard de Windows Defender
Consideraciones sobre seguridad

Todos los equipos que cumplen las protecciones de línea base para el hardware, el firmware y el software pueden
usar Credential Guard de Windows Defender. Los equipos que cumplen las calificaciones adicionales pueden
proporcionar protección adicional para reducir aún más la superficie de ataque. En las siguientes tablas se
describen las protecciones de línea base, además de protecciones para mejorar la seguridad asociadas con
opciones de hardware y firmware disponibles en 2015, 2016 y 2017.
NOTE
A partir de Windows10, versión1607, el Módulo de plataforma segura (TPM2.0) debe estar habilitado de manera
predeterminada en equipos nuevos.
Si eres un OEM, consulta la información sobre requisitos en Requisitos de OEM de PC para Device Guard de Windows
Defender y Credential Guard de Windows Defender.
Protecciones básicas
PROTECCIONES DE LÍNEA DE BASE DESCRIPCIÓN BENEFICIOS DE SEGURIDAD
Hardware: CPU de 64 bits Es necesario un equipo de 64 bits para

que el hipervisor de Windows pueda
proporcionar VBS.
Hardware: extensiones de Requisitos: estas características de VBS proporciona aislamiento del kernel
virtualización de CPU, hardware son obligatorias para VBS. seguro desde el sistema operativo
y tablas de página extendidas. Una de las extensiones de virtualización normal. Gracias a este aislamiento, no
siguientes: es posible aprovechar las
• VT-x (Intel) o vulnerabilidades de día 0 ni otras
• AMD-V vulnerabilidades en el sistema operativo
Además: normal.
• Tablas de página extendidas, también
denominadas Traducción de direcciones
de segundo nivel (SLAT).
Hardware: módulo de plataforma Requisito: TPM 1.2 o TPM 2.0, discreto Un TPM proporciona protección para
segura (TPM) o firmware. las claves de cifrado de VBS que se
Recomendaciones para el TPM almacenan en el firmware. De esta
manera, se establece una protección
frente a ataques que involucran a un
usuario físicamente presente con acceso
al BIOS.
Firmware: firmware de UEFI versión Requisitos: consulta los requisitos del El arranque seguro de UEFI garantiza
2.3.1.c o posteriores con arranque programa de compatibilidad de que el dispositivo solo arranque código
seguro de UEFI. hardware con Windows en autorizado. Así se evita que se instalen
System.Fundamentals.Firmware.UEFISec kits de arranque y rootkits y que estos
ureBoot persistan entre reinicios.
Firmware: proceso de actualización Requisitos: el firmware de UEFI debe El firmware de UEFI, como el software,
de firmware seguro ser compatible con la actualización de puede tener vulnerabilidades de
firmware seguro disponible en los seguridad a las que se debe aplicar
requisitos del programa de parches mediante actualizaciones de
compatibilidad de hardware de firmware. La aplicación de revisiones
Windows de ayuda a impedir la instalación de
System.Fundamentals.Firmware.UEFISec rootkits.
ureBoot.
PROTECCIONES DE LÍNEA DE BASE DESCRIPCIÓN BENEFICIOS DE SEGURIDAD
Software: sistema operativo Windows Requisitos: Windows 10 Enterprise, Compatibilidad con VBS y con las
calificado Windows 10 Education, Windows Server características de administración que
2016 o Windows 10 IoT Enterprise simplifican la configuración de
Credential Guard de Windows Defender.
Importante:
Cuando Windows Server 2016
se ejecuta como controlador de
dominio, no es compatible con
Credential Guard de Windows
Defender. Solo Device Guard de
Windows Defender es
compatible con esta
configuración.
IMPORTANT
En las tablas siguientes se enumeran calificaciones adicionales para mejorar la seguridad. Sin embargo, te recomendamos
encarecidamente cumplir los requisitos para mejorar la seguridad y reforzar significativamente el nivel de seguridad que
Credential Guard de Windows Defender puede ofrecerte.
Calificaciones de seguridad adicionales de 2015 a partir de Windows 10, versión 1507 y Windows Server 2016
Technical Preview 4
PROTECCIONES PARA UNA SEGURIDAD MEJORADA DESCRIPCIÓN
Hardware: IOMMU (unidad de administración de memoria de Requisito: VT-D o AMD Vi IOMMU Ventajas de seguridad:
entrada y salida) una IOMMU puede mejorar la resistencia del sistema frente a
ataques de memoria. Para obtener más información, consulta
las tablas de descripción de ACPI.
Firmware: administración y configuración del arranque Requisitos:

seguro • Debe admitirse una contraseña del BIOS o una autenticación
más sólida.
• Debe establecerse la autenticación del BIOS en la
configuración del BIOS.
• La opción de BIOS protegida debe ser compatible para
configurar la lista de dispositivos de arranque permitidos (por
ejemplo, "Arranque solo desde el disco duro interno") y el
orden de dispositivos de arranque, reemplazando la
modificación BOOTORDER realizada por el sistema operativo.
• En la configuración del BIOS, las opciones de BIOS
relacionadas con el arranque y la seguridad (lista de
dispositivos de arranque permitidos, orden de arranque)
deben estar protegidas para impedir que se inicien otros
sistemas operativos y para evitar cambios en la configuración
del BIOS.
Firmware: Secure MOR, implementación de revisión 2 Requisito: Secure MOR, implementación de revisión 2
Calificaciones de seguridad adicionales de 2016 a partir de Windows 10, versión 1607 y Windows Server 2016
IMPORTANT
En las tablas siguientes se enumeran calificaciones adicionales para mejorar la seguridad. Los sistemas que cumplan estas
calificaciones adicionales pueden proporcionar más protecciones.
PROTECCIONES PARA UNA SEGURIDAD

MEJORADA DESCRIPCIÓN VENTAJAS DE SEGURIDAD
Firmware: arranque seguro de la Requisitos: La integridad del arranque (arranque

plataforma de confianza de raíz de La integridad de arranque (arranque seguro de plataforma) desde el
hardware seguro de plataforma) debe ser encendido proporciona protección
compatible. Consulta los requisitos del contra los atacantes físicamente
programa de compatibilidad de presentes y una defensa exhaustiva
hardware de Windows en contra el malware.
System.Fundamentals.Firmware.CS.UEFI • HSTI proporciona una garantía de
SecureBoot.ConnectedStandby. seguridad adicional para plataformas y
• Es necesario implementar la interfaz placas correctamente protegidas.
de prueba de seguridad de hardware
(HSTI). Consulta Hardware Security
Testability Specification (Especificación
de prueba de seguridad de hardware).
Firmware: actualización de firmware Requisitos: el firmware debe ser Ayuda a garantizar que las
mediante Windows Update compatible con las actualizaciones de actualizaciones de firmware sean
campo a través de Windows Update y la rápidas, seguras y de confianza.
actualización de encapsulación de UEFI.
Firmware: administración y Requisitos: • Las empresas pueden permitir que se

configuración del arranque seguro • Funcionalidades de BIOS obligatorias: ejecuten controladores o aplicaciones
capacidad de OEM para agregar ISV, propietarios de EFI.
OEM o el certificado de empresa en la • Al quitar Microsoft UEFI CA de la base
base de datos de arranque seguro en el de datos de arranque seguro, las
momento de la fabricación. empresas tienen el control total sobre el
• Configuraciones necesarias: es software que se ejecuta antes de
necesario quitar Microsoft UEFI CA de la arrancar el sistema operativo.
base de datos de arranque seguro. Se
permite la compatibilidad con módulos
UEFI de terceros, pero debe aprovechar
los certificados proporcionados por ISV
o un certificado de OEM para el
software específico de UEFI.
Calificaciones de seguridad adicionales de 2017 a partir de Windows 10, versión 1703

En la siguiente tabla se enumeran las calificaciones para Windows10, versión1703, que son complementarios a
todas las calificaciones anteriores.

Firmware: habilitación de VBS de Requisitos: • Las vulnerabilidades en tiempo de

protección NX para servicios en • VBS permitirá la protección No- ejecución de UEFI, si las hay, se
tiempo de ejecución de UEFI Execute (NX) en el código del servicio en bloquearán de poner en peligro VBS
tiempo de ejecución de UEFI y las (por ejemplo, en funciones como
regiones de memoria de datos. El UpdateCapsule y SetVariable).
código de servicio en tiempo de • Reduce la superficie expuesta a
ejecución de UEFI debe admitir la ataques de VBS desde el firmware del
protección de páginas de solo lectura, y sistema.
los datos del servicio en tiempo de
ejecución de UEFI no deben ser
ejecutables.
• El servicio en tiempo de ejecución de
UEFI debe cumplir los requisitos
siguientes:
- Implementar UEFI 2.6
EFI_MEMORY_ATTRIBUTES_TABLE. En
esta tabla se debe describir toda la
memoria del servicio en tiempo de
ejecución de UEFI (código y datos).
- Las secciones de PE deben estar
alineadas por página en la memoria (no
es necesario en un almacenamiento no
volátil).
- La tabla de atributos de memoria
debe marcar correctamente el código y
los datos como RO/NX para la
configuración por parte del sistema
operativo:
- Todas las entradas tienen que
incluir atributos EFI_MEMORY_RO o
EFI_MEMORY_XP, o ambos.
- No se puede dejar ninguna
entrada sin al menos uno de los
atributos anteriores, que indican que la
memoria es ejecutable y grabable. La
memoria debe ser legible y ejecutable o
grabable y no ejecutable.
Notas:
• Esto solo se aplica a la
memoria del servicio en tiempo
de ejecución de UEFI, y no a la
memoria del servicio de
arranque de UEFI.
• VBS aplica esta protección en
las tablas de la página del
sistema operativo.
Además, tenga en cuenta lo siguiente:

• No uses secciones que sean grabables
y ejecutables.
• No intentes modificar directamente la
memoria del sistema ejecutable.
• No uses código dinámico.
Firmware: compatibilidad de Requisitos: la especificación Windows • Protege frente a las posibles

firmware para la protección de SMM Security Mitigations Table (WSMT) vulnerabilidades en los servicios en
SMM (tabla de mitigaciones de seguridad de tiempo de ejecución de UEFI, si las hay,
Windows SMM) contiene detalles de que se bloquearán de poner en peligro
una tabla de interfaz avanzada de VBS (por ejemplo, en funciones como
configuración y energía (ACPI), que se UpdateCapsule y SetVariable).
creó para usarla con sistemas • Reduce la superficie expuesta a
operativos Windows compatibles con ataques de VBS desde el firmware del
las características de seguridad basada sistema.
en virtualización (VBS) de Windows. • Bloquea ataques de seguridad
adicionales contra SMM.
Administrar Credential Guard de Windows Defender
Se aplica a:
Windows 10
WindowsServer2016
¿Prefieres el vídeo? Consulta Windows Defender Credential Guard Deployment (Implementación de Credential
Guard de Windows Defender) en la serie de vídeos Deep Dive into Windows Defender Credential Guard.
Habilitar Credential Guard de Windows Defender

Se puede habilitar Credential Guard de Windows Defender mediante directivas de grupo, el registro o la
herramienta de preparación de hardware de Device Guard de Windows Defender y Credential Guard de Windows
Defender. Credential Guard de Windows Defender puede proteger información confidencial en una máquina
virtual de Hyper-V, tal como lo haría en una máquina física. El mismo conjunto de procedimientos que se utilizan
para habilitar Credential Guard de Windows Defender en máquinas físicas también se aplica a máquinas virtuales.
Habilitar Credential Guard de Windows Defender con una directiva de grupo
Puedes usar directivas de grupo para habilitar Credential Guard de Windows Defender. Esto agregará y habilitará
las características de seguridad basadas en virtualización si es necesario.
1. Desde la Consola de administración de directivas de grupo, ve a Configuración del equipo -> Plantillas
administrativas -> Sistema -> Device Guard.
2. Haz doble clic en Activar la seguridad basada en la virtualización y, a continuación, haz clic en la opción
Habilitado.
3. En el cuadro Selecciona el nivel de seguridad de la plataforma, elige Arranque seguro o Protección de
DMA y arranque seguro.
4. En el cuadro Credential Guard Configuration, haz clic en Enabled with UEFI lock y, a continuación,
haga clic en Aceptar. Si quieres poder desactivar Credential Guard de Windows Defender de forma remota,
elige Habilitar sin bloqueo.
5. Cierra la Consola de administración de directivas de grupo.
Para aplicar el procesamiento de la directiva de grupo, puedes ejecutar gpupdate /force .
Habilitar Credential Guard de Windows Defender mediante el registro
Si no usas una directiva de grupo, puedes habilitar Credential Guard de Windows Defender mediante el Registro.
Credential Guard de Windows Defender usa características de seguridad basadas en virtualización que deben estar
habilitadas primero en algunos sistemas operativos.
Agregar las características de seguridad basada en la virtualización
A partir de Windows 10 versión 1607 y Windows Server 2016, la habilitación de las características de Windows
para usar la seguridad basada en virtualización no es necesaria y se puede omitir este paso.
Si usas Windows 10 versión 1507 (RTM ) o Windows 10 versión 1511, las características de Windows deben estar
habilitadas para usar la seguridad basada en virtualización. Para ello, usa el Panel de control o la herramienta
Administración y mantenimiento de imágenes de implementación (DISM ).
NOTE
Si habilitas Credential Guard de Windows Defender mediante la directiva de grupo, no se requieren los pasos para habilitar las
características de Windows a través del Panel de Control o DISM. La directiva de grupo instalará para ti las características de
Windows.
Agregar las características de seguridad basada en la virtualización mediante Programas y

características
1. Abre el panel de control Programas y características.
2. Haz clic en Activar o desactivar la característica de Windows.
3. Ve a Hyper-V -> Plataforma Hyper-V y, después, selecciona la casilla Hipervisor Hyper-V.
4. Selecciona la casilla Modo de usuario aislado en el nivel superior de la selección de características.
5. Haz clic en Aceptar.
Agregar las características de seguridad basada en la virtualización a una imagen sin conexión mediante
DISM
1. Abre un símbolo del sistema con privilegios elevados.
2. Agrega el hipervisor Hyper-V ejecutando el siguiente comando:
dism /image:<WIM file name> /Enable-Feature /FeatureName:Microsoft-Hyper-V-Hypervisor /all
3. Para agregar la característica Modo de usuario aislado, ejecuta el siguiente comando:
dism /image:<WIM file name> /Enable-Feature /FeatureName:IsolatedUserMode
NOTE
También puedes agregar estas características a una imagen en línea con DISM o Configuration Manager.
Habilitar la seguridad basada en virtualización y Credential Guard de Windows Defender

1. Abre el Editor del Registro.
2. Habilitar la seguridad basada en la virtualización:
Ve a HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard.
Agrega un nuevo valor DWORD denominado EnableVirtualizationBasedSecurity. Establece el valor
de esta configuración del registro en 1 para habilitar la seguridad basada en la virtualización y
establécelo en 0 para deshabilitarla.
Agrega un nuevo valor DWORD denominado RequirePlatformSecurityFeatures. Establece el valor de
esta configuración del Registro en 1 para que solo use la opción Arranque seguro o establécelo en 3
para que use Protección de DMA y arranque seguro.
3. Habilitar Credential Guard de Windows Defender:
Ve a HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA.
Agrega un nuevo valor DWORD denominado LsaCfgFlags. Establece el valor de esta configuración de
registro en 1 para habilitar Credential Guard de Windows Defender con el bloqueo UEFI, establécelo en
2 para habilitar Credential Guard de Windows Defender sin el bloqueo y establécelo en 0 para
deshabilitarlo.
4. Cierra el Editor del registro.
NOTE
También puedes habilitar Credential Guard de Windows Defender configurando las entradas del Registro en la configuración
desatendida FirstLogonCommands.
Habilita Credential Guard de Windows Defender mediante la herramienta de preparación de hardware de

Device Guard de Windows Defender y Credential Guard de Windows Defender.
También puedes habilitar Credential Guard de Windows Defender mediante la herramienta de preparación de
hardware de Device Guard de Windows Defender y Credential Guard de Windows Defender.
DG_Readiness_Tool_v3.5.ps1 -Enable -AutoReboot
Revisar el rendimiento de Credential Guard de Windows Defender

¿Se está ejecutando Credential Guard de Windows Defender?
Puedes usar la opción Información del sistema para comprobar que Credential Guard de Windows Defender se
está ejecutando en un equipo.
1. Haz clic en Inicio, escribe msinfo32.exe y, a continuación, haz clic en Información del sistema.
2. Haz clic en Resumen del sistema.
3. Comprueba que Credential Guard se muestra junto a Virtualization-based security Services
Configured.
A continuación te mostramos un ejemplo:
También puedes comprobar que Credential Guard de Windows Defender se está ejecutando mediante la
herramienta de preparación de hardware de Device Guard de Windows Defender y Credential Guard de Windows
Defender.
DG_Readiness_Tool_v3.5.ps1 -Ready
NOTE
En el caso de equipos cliente que ejecutan Windows 10 1703, LsaIso.exe se ejecuta cada vez que la seguridad
basada en virtualización se habilita para otras características.
Te recomendamos habilitar Credential Guard de Windows Defender antes de que un dispositivo se una a un
dominio. Si Credential Guard de Windows Defender se habilita después de unirse a un dominio, los secretos
de usuario y del dispositivo podrían estar ya en riesgo. En otras palabras, habilitar Credential Guard no
ayudará a proteger un dispositivo o identidad que ya se ha puesto en peligro, por lo que recomendamos
activar Credential Guard lo antes posible.
Debes realizar revisiones periódicas de los equipos que tienen Credential Guard de Windows Defender
habilitada. Esto puede hacerse con directivas de auditoría de seguridad o consultas de WMI. Esta es una lista
de identificadores de evento de WinInit que buscar:
Identificador de evento 13 Credential Guard de Windows Defender (LsaIso.exe) se ha iniciado y
protegerá las credenciales de LSA.
Identificador de evento 14 Configuración de Credential Guard de Windows Defender (LsaIso.exe):
0x1, 0
La primera variable: 0x1 significa que Credential Guard de Windows Defender está configurado
para ejecutarse. 0x0 significa que no está configurado para ejecutarse.
La segunda variable: 0 significa que está configurado para ejecutarse en el modo de protección. 1
significa que está configurado para ejecutarse en modo de prueba. Esta variable debe ser siempre
0.
Identificador de evento 15 Credential Guard de Windows Defender se ha configurado (LsaIso.exe),
pero el kernel seguro no se está ejecutando y continúa sin Credential Guard de Windows Defender.
Identificador de evento 16 Credential Guard de Windows Defender (LsaIso.exe) no se pudo iniciar:
[código de error]
Identificador de evento 17 Error al leer la configuración UEFI de Credential Guard de Windows
Defender (LsaIso.exe): [código de error] También puedes comprobar si el TPM se está usando para la
protección de claves consultando el evento con identificador 51 en el origen de eventos Microsoft ->
Windows -> Kernel-Arranque. Si ejecutas el sistema con un TPM, el valor de máscara de TPM PCR
será distinto de 0.
Identificador de evento 51 Aprovisionamiento de la clave de cifrado maestro de VSM. Estado
de la eliminación de la copia en caché: 0x0. Estado de la generación de la clave nueva: 0x1. Estado
de la generación de la clave nueva: 0x1. Estado del sello: 0x1. Máscara de TPM PCR: 0x0.
Deshabilitar Credential Guard de Windows Defender

Para deshabilitar a Credential Guard de Windows Defender, puedes usar el siguiente conjunto de procedimientos o
el Device Guard y Credential Guard herramienta de preparación de hardware. Si se habilita Credential Guard con
el bloqueo UEFI, a continuación, debes usar el siguiente procedimiento como la configuración se guarda en
variables EFI (firmware) y requerirá la presencia física en la máquina que presionar una tecla de función para
aceptar el cambio. Si se habilita Credential Guard sin bloqueo UEFI, a continuación, puedes desactivar él mediante
el uso de la directiva de grupo.
1. Si has usado una directiva de grupo, deshabilita la configuración de directiva de grupo que usaste para habilitar
Credential Guard de Windows Defender (Configuración del equipo -> Plantillas administrativas ->
Sistema -> Device Guard -> Activar la seguridad basada en la virtualización).
2. Elimina la configuración del Registro siguiente:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LsaCfgFlags
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard\EnableVirtualizationBasedSecurity
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard\RequirePlatformSecurityFeatures
IMPORTANT
Si quitas manualmente estas opciones de configuración del Registro, asegúrate de eliminarlas todas. Si no las quitas
todas, el dispositivo podría ejecutar la recuperación de BitLocker.
3. Elimina las variables EFI de Credential Guard de Windows Defender mediante bcdedit. En un símbolo del
sistema con privilegios elevados, escribe los siguientes comandos:
mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d
4. Reinicia el equipo.
5. Acepta la solicitud para deshabilitar Credential Guard de Windows Defender.
6. Como alternativa, puedes deshabilitar las características de seguridad basada en la virtualización para
desactivar Credential Guard de Windows Defender.
NOTE
El equipo debe tener acceso de un solo uso a un controlador de dominio para descifrar contenido, como archivos cifrados con
EFS. Si quieres desactivar Credential Guard de Windows Defender y la seguridad basada en la virtualización, ejecuta el
siguiente comando de bcdedit después de desactivar todas las opciones de configuración del Registro y de la directiva de
grupo de seguridad basada en la virtualización: bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions
DISABLE-LSA-ISO,DISABLE-VBS
Para obtener más información sobre la seguridad basada en la virtualización y Device Guard de Windows
Defender, consulta el tema Guía de implementación de Device Guard de Windows Defender.
Deshabilitar Credential Guard de Windows Defender mediante la herramienta de preparación de hardware de Device Guard de
Windows Defender y Credential Guard de Windows Defender.
También puedes deshabilitar Credential Guard de Windows Defender mediante la herramienta de preparación de
hardware de Device Guard de Windows Defender y Credential Guard de Windows Defender.
DG_Readiness_Tool_v3.5.ps1 -Disable -AutoReboot
Deshabilitar Credential Guard de Windows Defender para una máquina virtual

Desde el host, puedes deshabilitar Credential Guard de Windows Defender para una máquina virtual:
Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true

Límites de protección de Credential Guard de
Windows Defender
Se aplica a:
Windows10
WindowsServer2016
¿Prefieres el vídeo? Consulta Credentials protected by Windows Defender Credential Guard (Credenciales
protegidas por Credential Guard de Windows Defender) en la serie de vídeos Deep Dive into Windows Defender
Credential Guard.
Algunas maneras de almacenar las credenciales no están protegidas por Credential Guard de Windows Defender,
como:
Software que administra credenciales fuera de la protección de la característica de Windows
Cuentas locales y cuentas de Microsoft
Credential Guard de Windows Defender no protege la base de datos de Active Directory que se ejecuta en los
controladores de dominio de Windows Server 2016. Tampoco protege las canalizaciones de entrada de
credenciales, como los servidores de Windows Server 2016 que ejecutan Puerta de enlace de Escritorio remoto.
Si usas un servidor de Windows Server 2016 como un equipo cliente, obtendrá la misma protección que la que
dispondría al ejecutar Windows 10 Enterprise.
Registradores de pulsaciones de teclas
Ataques físicos
No impide que un atacante con malware en el equipo use los privilegios asociados con cualquier credencial. Se
recomienda usar equipos dedicados para las cuentas de gran valor, como los profesionales de TI y los usuarios
con acceso a activos de gran valor de la organización.
Paquetes de seguridad de terceros
Credenciales de Digest y CredSSP
Cuando Credential Guard de Windows Defender está habilitado, ni Digest ni CredSSP tienen acceso a
las credenciales de inicio de sesión de los usuarios. Esto implica que no se usa el inicio de sesión único
para estos protocolos.
Las credenciales proporcionadas para la autenticación NTLM no están protegidas. Si se pide a usuario que
escriba las credenciales para la autenticación NTLM y obedece a esta solicitud, dichas credenciales se podrán
leer desde la memoria LSASS. Ten en cuenta que estas mismas credenciales también son vulnerables a los
registradores de pulsaciones de teclas.
Vales de servicio Kerberos no están protegidos por el guardián de credenciales, pero es el vale de concesión de
vales (TGT) de Kerberos.
Cuando se implementa Credential Guard de Windows Defender en una máquina virtual, Credential Guard de
Windows Defender protege los secretos frente a los ataques dentro de la máquina virtual. Sin embargo, no
proporciona protección adicional contra ataques de sistema con privilegios originados desde el host.
Los comprobadores de contraseñas almacenadas en caché de inicio de sesión de Windows (comúnmente
denominadas "credenciales almacenadas en caché") no se califican como credenciales porque no se pueden
presentar a otro equipo para autenticación y solo se pueden usar localmente para comprobar las credenciales.
Se almacenan en el Registro del equipo local y proporcionan la validación de credenciales cuando un equipo
unido al dominio no se puede conectar a AD DS durante el inicio de sesión del usuario. Estos “inicios de sesión
en caché” o, en concreto, la información de la cuenta de dominio almacenada en caché, se pueden administrar
mediante la configuración de directiva de seguridad Inicio de sesión interactivo: número de inicios de
sesión anteriores que se almacenarán en caché (si el controlador de dominio no está disponible).
Consulta también
Proteger a los usuarios con privilegios con Credential Guard de Windows Defender
Consideraciones sobre el uso de Credential Guard de
Windows Defender
Se aplica a:
Windows 10
WindowsServer2016
¿Prefieres el vídeo? Consulta Credentials protected by Windows Defender Credential Guard (Credenciales
protegidas por Credential Guard de Windows Defender) en la serie de vídeos Deep Dive into Windows
Defender Credential Guard.
Las contraseñas siguen siendo poco seguras. Recomendamos que además de implementar Credential Guard de
Windows Defender, las organizaciones deben evitar las contraseñas y usar otros métodos de autenticación, como
tarjetas inteligentes físicas, tarjetas inteligentes virtuales o Windows Hello para empresas.
Credential Guard de Windows Defender usa seguridad de hardware, por lo que algunas características, como
Windows To Go, no son compatibles.
Consideraciones sobre Wi-Fi y VPN

Cuando se habilita Windows Defender credenciales Guard, ya no se puede usar la autenticación NTLM clásica para
el inicio de sesión único. Se forzará a escribir sus credenciales para usar estos protocolos y no se puede guardar las
credenciales para un uso futuro. Si usas puntos de conexión Wi-Fi y VPN que se basan en MS -CHAPv2, están
sujetos a ataques similares como NTLMv1. Para las conexiones Wi-Fi y VPN, Microsoft recomienda que las
organizaciones cambien las conexiones basadas en MSCHAPv2, como PEAP -MSCHAPv2 y EAP -MSCHAPv2, a la
autenticación basada en certificados, como PEAP -TLS o EAP -TLS.
Consideraciones de Kerberos
Al habilitar Credential Guard de Windows Defender, ya no se puede usar la delegación de Kerberos sin
restricciones ni el cifrado DES. La delegación sin restricciones podría permitir a los atacantes extraer claves de
Kerberos del proceso de LSA aislado. Usa la delegación de Kerberos restringida o basada en recursos en su lugar.
Consideraciones acerca de los proveedores de soporte técnico de

seguridad de otros fabricantes
Algunos proveedores de compatibilidad con seguridad externos (SSP y puntos de acceso personalizados) podrían
no ser compatibles con Credential Guard de Windows Defender, ya que este no permite que SSP externos pidan
hashes de contraseña a LSA. Sin embargo, los SSP y puntos de acceso personalizados siguen recibiendo la
notificación de la contraseña cuando un usuario inicia sesión o cambia su contraseña. No se admite el uso de API
no documentadas dentro de los SSP y puntos de acceso personalizados. Te recomendamos que las
implementaciones personalizadas de SSP/puntos de acceso se prueben con Credential Guard de Windows
Defender. Los SSP y puntos de acceso que dependen de cualquier error de comportamiento no documentado o no
compatible. Por ejemplo, no se admite el uso de la API KerbQuerySupplementalCredentialsMessage. Reemplazar
SSP de Kerberos o NTLM con SSP y puntos de acceso personalizados. Para obtener más información, consulta
Restrictions around Registering and Installing a Security Package (Restricciones en torno al registro y la instalación
de paquetes de seguridad) en MSDN.
Consideraciones acerca de la actualización
Dado que la amplitud y profundidad de las protecciones que ofrece Credential Guard de Windows Defender
aumentan, las versiones posteriores de Windows 10 que ejecuten Credential Guard de Windows Defender podrían
influir en los escenarios que estaban funcionando en el pasado. Por ejemplo, Credential Guard de Windows
Defender puede bloquear el uso de un tipo particular de credencial o de un componente concreto para impedir que
el malware saque provecho de las vulnerabilidades. Prueba los escenarios necesarios para las operaciones de una
organización antes de actualizar un dispositivo con Credential Guard de Windows Defender.
Credenciales protegidas con Windows guardadas
A partir de Windows10, versión 1511, las credenciales de dominio que se almacenan con el Administrador de
credenciales están protegidas con Credential Guard de Windows Defender. El Administrador de credenciales te
permite almacenar tres tipos de credenciales: credenciales de Windows, credenciales basadas en certificados y
credenciales genéricas. Las credenciales genéricas, como nombres de usuario y contraseñas, que usas para iniciar
sesión en sitios web no están protegidas, ya que las aplicaciones requieren una contraseña de texto no cifrado. Si la
aplicación no tiene una copia de la contraseña, puede guardar las credenciales de dominio como credenciales de
Windows que están protegidas. Las credenciales de Windows se usan para conectarse a otros equipos en una red.
Las consideraciones siguientes se aplican a las protecciones de Credential Guard de Windows Defender para el
Administrador de credenciales:
Las credenciales de Windows guardadas por el Cliente de escritorio remoto no se pueden enviar a un host
remoto. Cualquier intento de usar credenciales de Windows guardadas fallará y se mostrará el mensaje de error
"No se puede iniciar sesión".
Se produce un error en las aplicaciones que extraigan credenciales de Windows.
Cuando las credenciales son una copia de seguridad de un PC que tiene Credential Guard de Windows
Defender habilitado, las credenciales de Windows no pueden restablecerse. Si necesitas hacer una copia de
seguridad de tus credenciales, debes hacerlo antes de habilitar Credential Guard de Windows Defender. De lo
contrario, no puedes restaurar dichas credenciales.
Consideraciones acerca del borrado del TPM

La seguridad basada en la virtualización (VBS ) usa el TPM para proteger su clave. Por lo tanto, cuando se borra el
TPM, la clave protegida del TPM que se usa para cifrar secretos de VBS se pierde.
WARNING
Al borrar el TPM, se pierden los datos protegidos de todas las características que usan VBS para proteger los datos.
Cuando un TPM se borra, TODAS las características, que usan VBS para proteger los datos, ya no pueden descifrar sus datos
protegidos.
Como resultado, Credential Guard ya no puede descifrar los datos protegidos. VBS crea una nueva clave TPM
protegido para Credential Guard. Credential Guard usa la nueva clave para proteger los datos nuevos. Sin
embargo, los datos protegidos anteriormente se pierden para siempre.
NOTE
Credential Guard obtiene la clave durante la inicialización. De modo que la pérdida de datos únicamente afectará a los datos
persistentes y se producirá después del próximo inicio del sistema.
Credenciales de Windows guardadas en el Administrador de credenciales

Dado que el Administrador de credenciales no puede descifrar las credenciales de Windows guardadas, estas se
eliminan. Las aplicaciones deben solicitar credenciales que se guardaron anteriormente. Si se guardan de nuevo,
las credenciales de Windows están protegidas por Credential Guard.
Clave pública aprovisionada automáticamente por el dispositivo unido a un dominio
A partir de Windows10 y WindowsServer2016, los dispositivos de dominio automáticamente aprovisionan una
clave pública vinculada. Para obtener más información sobre el aprovisionamiento de claves públicas automáticas,
consulta Autenticación de clave pública de dispositivo unido al dominio.
Dado que Credential Guard no puede descifrar la clave privada protegida, Windows usa la contraseña del equipo
unido al dominio para la autenticación para el dominio. A menos que se implementen directivas adicionales, no
debe haber una pérdida de funcionalidad. Si un dispositivo se configura para usar únicamente una clave pública, no
se puede autenticar con contraseña hasta que se deshabilite la directiva. Para obtener más información sobre cómo
configurar dispositivos para usar únicamente una clave pública, consulta Autenticación de clave pública de
dispositivo unido al dominio.
Además, si las comprobaciones de control de acceso, incluidas las directivas de autenticación, requieren que los
dispositivos tengan los SID conocidos KEY TRUST IDENTITY (S -1-18-4) o FRESH PUBLIC KEY IDENTITY (S -1-
18-3), se producirá un error en dichas comprobaciones. Para obtener más información acerca de las directivas de
autenticación, consulta Directivas de autenticación y silos de directivas de autenticación. Para obtener más
información acerca de los SID conocidos, consulta [MS -DTYP ] sección 2.4.2.4 Well-known SID Structures
(Estructuras de SID conocido).
Dividir la DPAPI en dispositivos unidos a un dominio
En los dispositivos unidos a un dominio, la DPAPI puede recuperar las claves de usuario con un controlador de
dominio desde el dominio del usuario. Si un dispositivo unido al dominio no tiene conectividad a un controlador de
dominio, no es posible la recuperación.
IMPORTANT
La práctica recomendada al borrar un TPM en un dispositivo unido a un dominio es estar en una red con conectividad a los
controladores de dominio. Esto garantiza que la DPAPI funcione y el usuario no experimente un comportamiento extraño.
La configuración de VPN automática está protegida con la DPAPI del usuario. Es posible que el usuario no pueda usar VPN
para conectarse a los controladores de dominio, dado que las configuraciones de VPN se pierden.
Si debes borrar el TPM en un dispositivo unido al dominio sin conectividad a los controladores de dominio, debes
tener en cuenta lo siguiente.
Inicio de sesión de un usuario de dominio en un dispositivo unido a un dominio tras borrar un TPM siempre que
no haya conectividad a un controlador de dominio:
TIPO DE CREDENCIAL VERSIÓN DE WINDOWS10 COMPORTAMIENTO
Certificado (tarjeta inteligente o Todos Todos los datos protegidos con la

Windows Hello para empresas) DPAPI de usuario es inutilizable y la
DPAPI de usuario no funciona en
absoluto.
Contraseña Windows10 v1709 o versiones Si el usuario inició sesión con un

posteriores certificado o contraseña antes de borrar
el TPM, puede iniciar sesión con una
contraseña y la DPAPI de usuario no se
verá afectada.
Contraseña Windows10 v1703 Si el usuario inició sesión con una

contraseña antes de borrar el TPM,
puede iniciar sesión con dicha
contraseña y no se verá afectado.
TIPO DE CREDENCIAL VERSIÓN DE WINDOWS10 COMPORTAMIENTO
Contraseña Windows10 v1607 o versiones Los datos protegidos por la DPAPI del
anteriores usuario existente son inutilizables. La
DPAPI de usuario es capaz de proteger
nuevos datos.
Una vez que el dispositivo tiene conectividad a los controladores de dominio, la DPAPI recupera la clave del
usuario y los datos protegidos antes de borrar el TPM pueden descifrarse.
Efecto de los errores de la DPAPI en WindowsInformationProtection
Cuando los datos protegidos con la DPAPI de usuario son inutilizables, el usuario pierde el acceso a todos los datos
de trabajo protegidos por WindowsInformationProtection. El efecto incluye: no se ha podido iniciar Outlook2016 y
no se han podido abrir documentos protegidos de trabajo. Si la DPAPI está funcionando, los datos de trabajo
creados recientemente están protegidos y se puede tener acceso a ellos.
Solución alternativa: los usuarios pueden resolver el problema conectando su dispositivo al dominio y
reiniciando o usando el certificado de Agente de recuperación de datos del Sistema de cifrado de archivos. Para
obtener más información sobre el certificado de Agente de recuperación de datos del Sistema de cifrado de
archivos, consulta Crear y comprobar un certificado del Agente de recuperación de datos (DRA) del Sistema de
cifrado de archivos (EFS ).
Consulta también
Seguridad de virtualización
Mitigaciones adicionales
Credential Guard de Windows Defender puede proporcionar mitigaciones frente a los ataques de credenciales
derivadas y evitar el uso de credenciales robadas en otro lugar. Sin embargo, los equipos pueden seguir siendo
vulnerables a determinados ataques, aunque las credenciales derivadas estén protegidas por Credential Guard de
Windows Defender. Estos ataques pueden incluir el mal uso de privilegios y el uso de credenciales derivadas
directamente desde un dispositivo en peligro, al reutilizar credenciales robadas anteriormente antes de instalar
Device Guard de Windows Defender, y el abuso de herramientas de administración y configuraciones de
aplicaciones no seguras. Por este motivo, las mitigaciones adicionales también deben implementarse para hacer
que el entorno de dominio sea más sólido.
Restringir los usuarios del dominio a dispositivos específicos unidos a un dominio
Los ataques de robo de credenciales permiten al atacante robar secretos de un dispositivo y usarlos en otro
dispositivo. Si un usuario puede iniciar sesión en varios dispositivos, podría usarse cualquier dispositivo para robar
las credenciales. ¿Cómo garantizar que los usuarios solo inicien sesión al usar dispositivos que tengan Credential
Guard de Windows Defender habilitado? Esto se consigue implementando directivas de autenticación que les
permite iniciar sesión únicamente en un dispositivo unido a un dominio y que se ha configurado con Credential
Guard de Windows Defender. Para que el controlador de dominio sepa desde qué dispositivo está iniciando sesión
un usuario, se debe utilizar la protección de Kerberos.
Protección de Kerberos
La protección de Kerberos forma parte de RFC 6113. Cuando un dispositivo admite la protección de Kerberos, su
TGT se usa para proteger la prueba de posesión del usuario que puede mitigar los ataques de diccionario sin
conexión. La protección de Kerberos también proporciona la ventaja adicional de los errores de KDC firmados. Esto
mitiga la manipulación que puede ayudar a degradar los ataques.
Habilitar la protección de Kerberos para restringir los usuarios del dominio a dispositivos específicos
unidos a un dominio.
Los usuarios tienen que estar en dominios que ejecuten Windows Server 2012 R2 o superior.
Todos los controladores de dominio de estos dominios deben estar configurados para admitir la protección de
Kerberos. Establece la configuración de la directiva de grupo Compatibilidad de KDC con notificaciones,
autenticación compuesta y protección de Kerberos en Admitida o Siempre proporcionar
notificaciones.
Todos los dispositivos con Credential Guard de Windows Defender que estarán restringidos únicamente a los
usuarios deben configurarse para admitir la protección de Kerberos. Habilita las opciones de configuración de
directiva de grupo El cliente Kerberos admite notificaciones, autenticación compuesta y protección de
Kerberos **** Enviar siempre autenticación compuesta primero -> en Configuración del equipo ->
Plantillas administrativas -> Sistema Kerberos.
Proteger secretos de un dispositivo unido a un dominio
Dado que los dispositivos unidos a un dominio también usan secretos compartidos para la autenticación, los
atacantes también pueden robar esos secretos. Al implementar los certificados de dispositivo con Credential Guard
de Windows Defender, se puede proteger la clave privada. A continuación, las directivas de autenticación pueden
requerir que los usuarios inicien sesión en dispositivos que autentican con dichos certificados. Esto impide que los
secretos compartidos robados en los dispositivos se usen con las credenciales de usuario para iniciar sesión como
tal.
La autenticación de certificado de dispositivos unidos a un dominio tiene los siguientes requisitos:
Las cuentas de los dispositivos están ejecutando el nivel funcional de dominio de Windows Server 2012 o un
nivel superior.
Todos los controladores en esos dominios tienen certificados KDC que cumplen con los estrictos requisitos de
certificación de validación KDC.
EKU de KDC presente
El nombre de dominio DNS coincide con el campo DNSName de la extensión SubjectAltName (SAN ).
Los dispositivos de Windows 10 cuentan con los certificados de controlador de dominio que emite la entidad de
certificación en el almacén de la empresa.
Se establece un proceso para garantizar la identidad y la confiabilidad del dispositivo de una manera similar a la
que establecerías la identidad y la confiabilidad de un usuario antes de emitirle una tarjeta inteligente.
I m p l e m e n t a c i ó n d e c e r t i fi c a d o s d e u n d i sp o si t i v o u n i d o a u n d o m i n i o
Para garantizar que los certificados con la directiva de emisión necesaria se instalen únicamente en los dispositivos
que los usuarios deben utilizar, deberán implementarse de forma manual en cada dispositivo. Para los certificados
del dispositivo, deben aplicarse los mismos procedimientos de seguridad que se usan para emitir tarjetas
inteligentes a los usuarios.
Por ejemplo, supongamos que desea usar la directiva de seguridad alta solamente en estos dispositivos. Con una
entidad de certificación de Windows Server Enterprise puedes crear una nueva plantilla.
Crear una nueva plantilla de certificado
1. Desde la consola del Administrador de certificados, haz clic con el botón secundario en Plantillas de
certificado y, a continuación, haz clic en Administrar.
2. Haz clic con el botón secundario en Autenticación de estación de trabajo y, a continuación, haz clic en
Duplicar plantilla.
3. Haz clic en la nueva plantilla y, a continuación, haz clic en Propiedades.
4. En la pestaña Extensiones , haz clic en Directivas de aplicación y, a continuación, haz clic en Editar.
5. Haz clic en Autenticación de cliente y, a continuación, haz clic en Quitar.
6. Agrega el EKU ID -PKInit-KPClientAuth. Haz clic en Agregar, haz clic en Nuevo y, a continuación, especifica los
siguientes valores:
Nombre: Autenticación de cliente Kerberos
Identificador de objeto: 1.3.6.1.5.2.3.4
7. En la pestaña Extensiones , haz clic en Directivas de emisión y, a continuación, haz clic en Editar.
8. En Directivas de emisión, haz clic en Seguridad alta.
9. En la pestaña Nombre del sujeto, desactiva la casilla Nombre DNS y, a continuación, selecciona la casilla
Nombre principal de usuario (UPN ).
A continuación, inscribe los dispositivos que usan el certificado que acabas de crear en los dispositivos que
ejecutan Credential Guard de Windows Defender.
Inscripción de dispositivos en un certificado
Ejecuta el siguiente comando:
CertReq -EnrollCredGuardCert MachineAuthentication
NOTE
Debes reiniciar el dispositivo después de realizar la inscripción del certificado de autenticación de equipo.
C ó m o u n a d i r e c t i v a d e e m i si ó n d e c e r t i fi c a d o s p u e d e u sa r se p a r a e l c o n t r o l d e a c c e so
A partir del nivel funcional de dominio de Windows Server 2008 R2, la compatibilidad de los controladores de
dominio para la seguridad del mecanismo de autenticación proporciona una manera de asignar los OID de la
directiva de emisión de certificados a grupos de seguridad universal. Los controladores de dominio de Windows
Server 2012 con soporte de notificación pueden asignarles estas notificaciones. Para obtener más información
sobre el mecanismo de autenticación, consulta Comprobación del mecanismo de autenticación de AD DS en la
Guía paso a paso de Windows Server 2008 R2 en TechNet.
Ver las directivas de emisión disponibles
get-IssuancePolicy.ps1 muestra todas las directivas de emisión que están disponibles en la entidad de
certificación. En el símbolo del sistema de Windows PowerShell, ejecuta el siguiente comando:
.\get-IssuancePolicy.ps1 –LinkedToGroup:All
Vincular una directiva de emisión a un grupo de seguridad universal

set-IssuancePolicyToGroupLink.ps1 crea un grupo de seguridad universal, crea una unidad organizativa y
vincula la directiva de emisión a ese grupo de seguridad universal. En el símbolo del sistema de Windows
PowerShell, ejecuta el siguiente comando:
.\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName:"<name of issuance policy>" –groupOU:"<Name of

OU to create>" –groupName:”<name of Universal security group to create>"
Inicio de sesión de usuario restringido

Por ahora hemos completado lo siguiente:
Se ha creado una directiva de emisión de certificados especial para identificar aquello que reúne los criterios de
implementación necesarios para que el usuario pueda iniciar sesión.
Se ha asignado esa directiva a un grupo o notificación de seguridad universal.
Se ha proporcionado una manera de que los controladores de dominio consigan los datos de autorización del
dispositivo durante el inicio de sesión del usuario mientras usa la protección de Kerberos. Ahora lo que falta aún
por hacer es configurar la comprobación de acceso en los controladores de dominio. Esto se hace con las
directivas de autenticación.
Las directivas de autenticación deben cumplir los siguientes requisitos:
Las cuentas de los usuarios están ejecutando el nivel funcional de dominio de Windows Server 2012 o un nivel
superior.
Crear una directiva de autenticación que restrinja los usuarios al grupo de seguridad universal específico
1. Abre el Centro de administración de Active Directory.
2. Haz clic en Autenticación, haz clic en Nueva y, a continuación, haz clic en Directiva de autenticación.
3. En el cuadro Nombre para mostrar, escribe un nombre para esta directiva de autenticación.
4. En el encabezado Cuentas, haz clic en Agregar.
5. En la casilla Seleccionar usuarios, equipos o cuentas de servicio, escribe el nombre de la cuenta de usuario
que quieras restringir y, a continuación, haz clic en Aceptar.
6. En la sección Inicio de sesión de usuario haz clic en el botón Editar.
7. Haz clic en Agregar una condición.
8. En el cuadro Editar condiciones del control de acceso, asegúrate de que se muestra Usuario > Grupo >
Miembro de cada > Valor y, a continuación, haz clic en Agregar elementos.
9. En el cuadro de diálogo Seleccionar usuarios, equipos o cuentas de servicio, escribe el nombre del grupo
de seguridad universal que creaste con el script set-IssuancePolicyToGroupLink y, a continuación, haz clic en
Aceptar.
10. Haz clic en Aceptar para cerrar el cuadro Editar las condiciones de control de acceso.
11. Haz clic en Aceptar para crear la directiva de autenticación.
12. Cierra el Centro de administración de Active Directory.
NOTE
Cuando la directiva de autenticación aplica las restricciones de la directiva, los usuarios no podrán iniciar sesión en
dispositivos que no tengan un certificado con la directiva de emisión implementada correcta. Esto se aplica en escenarios de
inicio de sesión local y remoto. Por lo tanto, se recomienda encarecidamente auditar en primer lugar solo las restricciones de
directiva para que no ocurran errores inesperados.
Det ec c i ó n de er r o r es de au t en t i c ac i ó n debi do a di r ec t i vas de au t en t i c ac i ó n
Para realizar un seguimiento más fácil de los errores de autenticación debido a directivas de autenticación, existe
un registro operativo únicamente con esos eventos. Para habilitar los registros en los controladores de dominio, en
el Visor de eventos, ve a Registros de aplicaciones y servicios\Microsoft\Windows\Autenticación, haz clic
con el botón derecho en AuthenticationPolicyFailures-DomainController y, después, haz clic en Habilitar
registro.
Para obtener más información sobre los eventos de la directiva de autenticación, consulta Directivas de
autenticación y silos de directivas de autenticación.
Apéndice: scripts
A continuación, presentamos una lista de los scripts mencionados en este tema.
Obtener las directivas de emisión disponibles en la entidad de certificación
Guarda este archivo de script como get-IssuancePolicy.ps1.
#######################################
## Parameters to be defined ##
## by the user ##
#######################################
Param (
$Identity,
$LinkedToGroup
)
#######################################
## Strings definitions ##
#######################################
Data getIP_strings {
# culture="en-US"
ConvertFrom-StringData -stringdata @'
help1 = This command can be used to retrieve all available Issuance Policies in a forest. The forest of the
currently logged on user is targeted.
help2 = Usage:
help3 = The following parameter is mandatory:
help4 = -LinkedToGroup:<yes|no|all>
help5 = "yes" will return only Issuance Policies that are linked to groups. Checks that the linked Issuance
Policies are linked to valid groups.
help6 = "no" will return only Issuance Policies that are not currently linked to any group.
help7 = "all" will return all Issuance Policies defined in the forest. Checks that the linked Issuance policies
are linked to valid groups.
help8 = The following parameter is optional:
help9 = -Identity:<Name, Distinguished Name or Display Name of the Issuance Policy that you want to retrieve>.
If you specify an identity, the option specified in the "-LinkedToGroup" parameter is ignored.
help10 = Output: This script returns the Issuance Policy objects meeting the criteria defined by the above
parameters.
help11 = Examples:
errorIPNotFound = Error: no Issuance Policy could be found with Identity "{0}"
ErrorNotSecurity = Error: Issuance Policy "{0}" is linked to group "{1}" which is not of type "Security".
ErrorNotUniversal = Error: Issuance Policy "{0}" is linked to group "{1}" whose scope is not "Universal".
ErrorHasMembers = Error: Issuance Policy "{0}" is linked to group "{1}" which has a non-empty membership. The
group has the following members:
group has the following members:
LinkedIPs = The following Issuance Policies are linked to groups:
displayName = displayName : {0}
Name = Name : {0}
dn = distinguishedName : {0}
InfoName = Linked Group Name: {0}
InfoDN = Linked Group DN: {0}
NonLinkedIPs = The following Issuance Policies are NOT linked to groups:
'@
}
##Import-LocalizedData getIP_strings
import-module ActiveDirectory
#######################################
## Help ##
#######################################
function Display-Help {
""
$getIP_strings.help1
""
""
" " + $getIP_strings.help4
""
""
""
""
" " + '$' + "myIPs = .\get-IssuancePolicy.ps1 -LinkedToGroup:All"
" " + '$' + "myLinkedIPs = .\get-IssuancePolicy.ps1 -LinkedToGroup:yes"
" " + '$' + "myIP = .\get-IssuancePolicy.ps1 -Identity:""Medium Assurance"""
""
}
$root = get-adrootdse
$domain = get-addomain -current loggedonuser
$configNCDN = [String]$root.configurationNamingContext
if ( !($Identity) -and !($LinkedToGroup) ) {
display-Help
break
}
if ($Identity) {
$OIDs = get-adobject -Filter {(objectclass -eq "msPKI-Enterprise-Oid") -and ((name -eq $Identity) -or
(displayname -eq $Identity) -or (distinguishedName -like $Identity)) } -searchBase $configNCDN -properties *
if ($OIDs -eq $null) {
$errormsg = $getIP_strings.ErrorIPNotFound -f $Identity
write-host $errormsg -ForegroundColor Red
}
foreach ($OID in $OIDs) {
if ($OID."msDS-OIDToGroupLink") {
# In case the Issuance Policy is linked to a group, it is good to check whether there is any problem with the
mapping.
$groupDN = $OID."msDS-OIDToGroupLink"
$group = get-adgroup -Identity $groupDN
$groupName = $group.Name
# Analyze the group
if ($group.groupCategory -ne "Security") {
$errormsg = $getIP_strings.ErrorNotSecurity -f $Identity, $groupName
}
if ($group.groupScope -ne "Universal") {
$errormsg = $getIP_strings.ErrorNotUniversal -f $Identity, $groupName
}
$members = Get-ADGroupMember -Identity $group
if ($members) {
$errormsg = $getIP_strings.ErrorHasMembers -f $Identity, $groupName
foreach ($member in $members) {
write-host " " $member -ForeGroundColor Red
}
}
}
}
return $OIDs
break
}
if (($LinkedToGroup -eq "yes") -or ($LinkedToGroup -eq "all")) {
$LDAPFilter = "(&(objectClass=msPKI-Enterprise-Oid)(msDS-OIDToGroupLink=*)(flags=2))"
$LinkedOIDs = get-adobject -searchBase $configNCDN -LDAPFilter $LDAPFilter -properties *
write-host ""
write-host "*****************************************************"
write-host $getIP_strings.LinkedIPs
write-host "*****************************************************"
write-host ""
if ($LinkedOIDs -ne $null){
foreach ($OID in $LinkedOIDs) {
# Display basic information about the Issuance Policies
""
$getIP_strings.displayName -f $OID.displayName
$getIP_strings.Name -f $OID.Name
$getIP_strings.dn -f $OID.distinguishedName
# Get the linked group.
$groupDN = $OID."msDS-OIDToGroupLink"
$group = get-adgroup -Identity $groupDN
$getIP_strings.InfoName -f $group.Name
$getIP_strings.InfoDN -f $groupDN
# Analyze the group
$OIDName = $OID.displayName
$groupName = $group.Name
if ($group.groupCategory -ne "Security") {
$errormsg = $getIP_strings.ErrorNotSecurity -f $OIDName, $groupName
}
if ($group.groupScope -ne "Universal") {
$errormsg = $getIP_strings.ErrorNotUniversal -f $OIDName, $groupName
}
if ($members) {
$errormsg = $getIP_strings.ErrorHasMembers -f $OIDName, $groupName
foreach ($member in $members) {
write-host " " $member -ForeGroundColor Red
}
}
write-host ""
}
}else{
write-host "There are no issuance policies that are mapped to a group"
}
if ($LinkedToGroup -eq "yes") {
return $LinkedOIDs
break
}
}
if (($LinkedToGroup -eq "no") -or ($LinkedToGroup -eq "all")) {
$LDAPFilter = "(&(objectClass=msPKI-Enterprise-Oid)(!(msDS-OIDToGroupLink=*))(flags=2))"
$NonLinkedOIDs = get-adobject -searchBase $configNCDN -LDAPFilter $LDAPFilter -properties *
write-host ""
write-host "*********************************************************"
write-host $getIP_strings.NonLinkedIPs
write-host "*********************************************************"
write-host ""
write-host ""
if ($NonLinkedOIDs -ne $null) {
foreach ($OID in $NonLinkedOIDs) {
# Display basic information about the Issuance Policies
write-host ""
$getIP_strings.displayName -f $OID.displayName
$getIP_strings.Name -f $OID.Name
$getIP_strings.dn -f $OID.distinguishedName
write-host ""
}
}else{
write-host "There are no issuance policies which are not mapped to groups"
}
if ($LinkedToGroup -eq "no") {
return $NonLinkedOIDs
break
}
}
NOTE
Si tienes problemas para ejecutar este script, prueba a reemplazar la comilla simple después del parámetro ConvertFrom-
StringData.
Vincular una directiva de emisión a un grupo

Guarda el archivo de script como set-IssuancePolicyToGroupLink.ps1.
#######################################
## Parameters to be defined ##
## by the user ##
#######################################
Param (
$IssuancePolicyName,
$groupOU,
$groupName
)
#######################################
## Strings definitions ##
#######################################
Data ErrorMsg {
# culture="en-US"
ConvertFrom-StringData -stringdata @'
help1 = This command can be used to set the link between a certificate issuance policy and a universal security
group.
help2 = Usage:
help3 = The following parameters are required:
help4 = -IssuancePolicyName:<name or display name of the issuance policy that you want to link to a group>
help5 = -groupName:<name of the group you want to link the issuance policy to>. If no name is specified, any
existing link to a group is removed from the Issuance Policy.
help6 = The following parameter is optional:
help7 = -groupOU:<Name of the Organizational Unit dedicated to the groups which are linked to issuance
policies>. If this parameter is not specified, the group is looked for or created in the Users container.
help8 = Examples:
help9 = This command will link the issuance policy whose display name is "High Assurance" to the group
"HighAssuranceGroup" in the Organizational Unit "OU_FOR_IPol_linked_groups". If the group or the Organizational
Unit do not exist, you will be prompted to create them.
help10 = This command will unlink the issuance policy whose name is "402.164959C40F4A5C12C6302E31D5476062" from
any group.
MultipleIPs = Error: Multiple Issuance Policies with name or display name "{0}" were found in the subtree of "
{1}"
NoIP = Error: no issuance policy with name or display name "{0}" could be found in the subtree of "{1}".
IPFound = An Issuance Policy with name or display name "{0}" was successfully found: {1}
MultipleOUs = Error: more than 1 Organizational Unit with name "{0}" could be found in the subtree of "{1}".
confirmOUcreation = Warning: The Organizational Unit that you specified does not exist. Do you want to create
it?
OUCreationSuccess = Organizational Unit "{0}" successfully created.
OUcreationError = Error: Organizational Unit "{0}" could not be created.
OUFoundSuccess = Organizational Unit "{0}" was successfully found.
multipleGroups = Error: More than one group with name "{0}" was found in Organizational Unit "{1}".
confirmGroupCreation = Warning: The group that you specified does not exist. Do you want to create it?
groupCreationSuccess = Univeral Security group "{0}" successfully created.
groupCreationError = Error: Univeral Security group "{0}" could not be created.
GroupFound = Group "{0}" was successfully found.
confirmLinkDeletion = Warning: The Issuance Policy "{0}" is currently linked to group "{1}". Do you really want
to remove the link?
UnlinkSuccess = Certificate issuance policy successfully unlinked from any group.
UnlinkError = Removing the link failed.
UnlinkExit = Exiting without removing the link from the issuance policy to the group.
IPNotLinked = The Certificate issuance policy is not currently linked to any group. If you want to link it to a
group, you should specify the -groupName option when starting this script.
ErrorNotSecurity = Error: You cannot link issuance Policy "{0}" to group "{1}" because this group is not of
type "Security".
ErrorNotUniversal = Error: You cannot link issuance Policy "{0}" to group "{1}" because the scope of this group
is not "Universal".
ErrorHasMembers = Error: You cannot link issuance Policy "{0}" to group "{1}" because it has a non-empty
membership. The group has the following members:
ConfirmLinkReplacement = Warning: The Issuance Policy "{0}" is currently linked to group "{1}". Do you really
want to update the link to point to group "{2}"?
LinkSuccess = The certificate issuance policy was successfully linked to the specified group.
LinkError = The certificate issuance policy could not be linked to the specified group.
ExitNoLinkReplacement = Exiting without setting the new link.
'@
}
# import-localizeddata ErrorMsg
function Display-Help {
""
write-host $ErrorMsg.help1
""
""
write-host "`t" $ErrorMsg.help4
""
""
""
""
".\Set-IssuancePolicyToGroupMapping.ps1 -IssuancePolicyName ""High Assurance"" -groupOU
""OU_FOR_IPol_linked_groups"" -groupName ""HighAssuranceGroup"" "
""
'.\Set-IssuancePolicyToGroupMapping.ps1 -IssuancePolicyName "402.164959C40F4A5C12C6302E31D5476062" -groupName
$null '
""
}
# Assumption: The group to which the Issuance Policy is going
# to be linked is (or is going to be created) in
# the domain the user running this script is a member of.
import-module ActiveDirectory
$root = get-adrootdse
$domain = get-addomain -current loggedonuser
if ( !($IssuancePolicyName) ) {
display-Help
break
}
#######################################
## Find the OID object ##
## (aka Issuance Policy) ##
#######################################
$searchBase = [String]$root.configurationnamingcontext
$searchBase = [String]$root.configurationnamingcontext
$OID = get-adobject -searchBase $searchBase -Filter { ((displayname -eq $IssuancePolicyName) -or (name -eq
$IssuancePolicyName)) -and (objectClass -eq "msPKI-Enterprise-Oid")} -properties *
if ($OID -eq $null) {
$tmp = $ErrorMsg.NoIP -f $IssuancePolicyName, $searchBase
write-host $tmp -ForeGroundColor Red
break;
}
elseif ($OID.GetType().IsArray) {
$tmp = $ErrorMsg.MultipleIPs -f $IssuancePolicyName, $searchBase
break;
}
else {
$tmp = $ErrorMsg.IPFound -f $IssuancePolicyName, $OID.distinguishedName
write-host $tmp -ForeGroundColor Green
}
#######################################
## Find the container of the group ##
#######################################
if ($groupOU -eq $null) {
# default to the Users container
$groupContainer = $domain.UsersContainer
}
else {
$searchBase = [string]$domain.DistinguishedName
$groupContainer = get-adobject -searchBase $searchBase -Filter { (Name -eq $groupOU) -and (objectClass -eq
"organizationalUnit")}
if ($groupContainer.count -gt 1) {
$tmp = $ErrorMsg.MultipleOUs -f $groupOU, $searchBase
write-host $tmp -ForegroundColor Red
break;
}
elseif ($groupContainer -eq $null) {
$tmp = $ErrorMsg.confirmOUcreation
write-host $tmp " ( (y)es / (n)o )" -ForegroundColor Yellow -nonewline
$userChoice = read-host
if ( ($userChoice -eq "y") -or ($userChoice -eq "yes") ) {
new-adobject -Name $groupOU -displayName $groupOU -Type "organizationalUnit" -ProtectedFromAccidentalDeletion
$true -path $domain.distinguishedName
if ($?){
$tmp = $ErrorMsg.OUCreationSuccess -f $groupOU
write-host $tmp -ForegroundColor Green
}
else{
$tmp = $ErrorMsg.OUCreationError -f $groupOU
break;
}
$groupContainer = get-adobject -searchBase $searchBase -Filter { (Name -eq $groupOU) -and (objectClass -eq
"organizationalUnit")}
}
else {
break;
}
}
else {
$tmp = $ErrorMsg.OUFoundSuccess -f $groupContainer.name
}
}
#######################################
## Find the group ##
#######################################
if (($groupName -ne $null) -and ($groupName -ne "")){
##$searchBase = [String]$groupContainer.DistinguishedName
$searchBase = $groupContainer
$group = get-adgroup -Filter { (Name -eq $groupName) -and (objectClass -eq "group") } -searchBase $searchBase
if ($group -ne $null -and $group.gettype().isarray) {
$tmp = $ErrorMsg.multipleGroups -f $groupName, $searchBase
$tmp = $ErrorMsg.multipleGroups -f $groupName, $searchBase
break;
}
elseif ($group -eq $null) {
$tmp = $ErrorMsg.confirmGroupCreation
new-adgroup -samAccountName $groupName -path $groupContainer.distinguishedName -GroupScope "Universal" -
GroupCategory "Security"
if ($?){
$tmp = $ErrorMsg.GroupCreationSuccess -f $groupName
}else{
$tmp = $ErrorMsg.groupCreationError -f $groupName
break
}
$group = get-adgroup -Filter { (Name -eq $groupName) -and (objectClass -eq "group") } -searchBase $searchBase
}
else {
break;
}
}
else {
$tmp = $ErrorMsg.GroupFound -f $group.Name
}
}
else {
#####
## If the group is not specified, we should remove the link if any exists
#####
if ($OID."msDS-OIDToGroupLink" -ne $null) {
$tmp = $ErrorMsg.confirmLinkDeletion -f $IssuancePolicyName, $OID."msDS-OIDToGroupLink"
set-adobject -Identity $OID -Clear "msDS-OIDToGroupLink"
if ($?) {
$tmp = $ErrorMsg.UnlinkSuccess
write-host $tmp -ForeGroundColor Green
}else{
$tmp = $ErrorMsg.UnlinkError
}
}
else {
$tmp = $ErrorMsg.UnlinkExit
write-host $tmp
break
}
}
else {
$tmp = $ErrorMsg.IPNotLinked
write-host $tmp -ForeGroundColor Yellow
}
break;
}
#######################################
## Verify that the group is ##
## Universal, Security, and ##
## has no members ##
#######################################
if ($group.GroupScope -ne "Universal") {
$tmp = $ErrorMsg.ErrorNotUniversal -f $IssuancePolicyName, $groupName
break;
}
}
if ($group.GroupCategory -ne "Security") {
$tmp = $ErrorMsg.ErrorNotSecurity -f $IssuancePolicyName, $groupName
break;
}
if ($members -ne $null) {
$tmp = $ErrorMsg.ErrorHasMembers -f $IssuancePolicyName, $groupName
foreach ($member in $members) {write-host " $member.name" -ForeGroundColor Red}
break;
}
#######################################
## We have verified everything. We ##
## can create the link from the ##
## Issuance Policy to the group. ##
#######################################
if ($OID."msDS-OIDToGroupLink" -ne $null) {
$tmp = $ErrorMsg.ConfirmLinkReplacement -f $IssuancePolicyName, $OID."msDS-OIDToGroupLink",
$group.distinguishedName
write-host $tmp "( (y)es / (n)o )" -ForegroundColor Yellow -nonewline
$tmp = @{'msDS-OIDToGroupLink'= $group.DistinguishedName}
set-adobject -Identity $OID -Replace $tmp
if ($?) {
$tmp = $Errormsg.LinkSuccess
write-host $tmp -Foreground Green
}else{
$tmp = $ErrorMsg.LinkError
write-host $tmp -Foreground Red
}
} else {
$tmp = $Errormsg.ExitNoLinkReplacement
write-host $tmp
break
}
}
else {
$tmp = @{'msDS-OIDToGroupLink'= $group.DistinguishedName}
set-adobject -Identity $OID -Add $tmp
if ($?) {
$tmp = $Errormsg.LinkSuccess
write-host $tmp -Foreground Green
}else{
$tmp = $ErrorMsg.LinkError
write-host $tmp -Foreground Red
}
}
NOTE
Si tienes problemas para ejecutar este script, prueba a reemplazar la comilla simple después del parámetro ConvertFrom-
StringData.
Consulta también
Proteger a los usuarios con privilegios con Credential Guard de Windows Defender
Credential Guard de Windows Defender: problemas
conocidos
Se aplica a:
Windows10
WindowsServer2016
Credential Guard de Windows Defender tiene determinados requisitos de aplicación. Credential Guard de
Windows Defender bloquea las funcionalidades de autenticación específicas. Por lo tanto, las aplicaciones que
requieren estas funcionalidades no funcionarán al habilitarlo. Para obtener más información, consulta Requisitos de
aplicaciones.
Se ha solucionado el siguiente problema conocido en la Actualización de seguridad acumulativa de noviembre de
2017:
Error al ejecutar tareas programadas con credenciales almacenadas cuando Credential Guard está habilitado. La
tarea produce un error y notifica el identificador de evento 104 con el siguiente mensaje:
"Task Scheduler failed to log on ‘\Test’ .
Error en "LogonUserExEx".
Acción del usuario: Asegúrate de que las credenciales de la tarea se especifican correctamente.
Datos adicionales: Valor de error: 2147943726. 2147943726 : ERROR_LOGON_FAILURE (El nombre de
usuario o la contraseña no son correctos)".
Los siguientes problemas conocidos se han solucionado con versiones puestas a disposición en las actualizaciones
de seguridad acumulativa de abril de 2017:
KB4015217: Credential Guard de Windows Defender genera el recuento doble de contraseña incorrecta en
equipos con Windows 10 unidos a un dominio de Active Directory
Este problema puede provocar bloqueos de cuenta inesperados. Consulta también artículos de Microsoft®
Knowledge Base KB4015219 y KB4015221
KB4033236: Dos intentos incorrectos de inicio de sesión se envían a Active Directory tras instalar Credential
Guard de Windows Defender en Windows 10
Este problema puede provocar bloqueos de cuenta inesperados. El problema se solucionó en actualizaciones
de mantenimiento para cada uno de los siguientes sistemas operativos:
Windows 10 versión 1607 y Windows Server 2016: KB4015217 (compilaciones del SO 14393.1066 y
14393.1083)
Windows 10 versión 1511: KB4015219 (compilación del SO 10586.873)
Windows 10 versión 1507: KB4015221 (compilación del SO 10240.17354)
Problemas conocidos relacionados con aplicaciones de terceros

El siguiente problema afecta a la GSS API de Java. Consulta el siguiente artículo de la base de datos de errores de
Oracle:
JDK-8161921: Credential Guard de Windows Defender en Windows 10 no admite el uso compartido de TGT
con Java
Cuando se habilita Credential Guard de Windows Defender en Windows 10, la GSS API de Java no se autentica.
Este es el comportamiento esperado, ya que Credential Guard de Windows Defender bloquea las funcionalidades
de autenticación específicas a la aplicación y no proporciona la clave de sesión TGT a aplicaciones,
independientemente de la configuración de las claves de registro. Para obtener más información, consulta
Requisitos de aplicaciones.
El siguiente problema afecta a Cisco AnyConnect Secure Mobility Client:
Pantalla azul en equipos con Windows 10 que ejecutan Device Guard de Windows Defender y Credential Guard
de Windows Defender con Cisco Anyconnect 4.3.04027 *
*Registro necesario para obtener acceso a este artículo.
El siguiente problema afecta a McAfee Application and Change Control (MACC ):
KB88869: Los equipos con Windows 10 muestran un uso elevado de la CPU con McAfee Application and
Change Control (MACC ) instalado cuando Credential Guard de Windows Defender está habilitado [1]
El siguiente problema afecta a AppSense Environment Manager. Para obtener más información, consulta el
siguiente artículo de Microsoft Knowledge Base:
La instalación de AppSense Environment Manager en máquinas de Windows 10 hace que LSAISO.exe muestre
un uso elevado de la CPU cuando Credential Guard de Windows Defender está habilitado [1] **
El siguiente problema afecta a las aplicaciones de Citrix:
Las máquinas con Windows 10 muestran un uso elevado de la CPU con aplicaciones instaladas cuando
Credential Guard de Windows Defender está habilitado. [1]
[1]
Los productos que se conectan a los procesos protegidos con la seguridad basada en virtualización (VBS )
pueden hacer que los clientes que usan Windows 10 habilitado con Credential Guard de Windows Defender o
equipos con Windows Server 2016 muestren un uso elevado de la CPU. Para obtener más información técnica y
para solucionar problemas, consulta el siguiente artículo de Microsoft Knowledge Base:
KB4032786: Alto uso de la CPU por parte del proceso LSAISO en Windows 10 o Windows Server 2016
Para obtener más información técnica sobre LSAISO.exe, consulta el artículo de MSDN: Isolated User Mode (IUM )
Processes (Procesos de modo de usuario aislado (IUM ))
** Registro necesario para obtener acceso a este artículo.
Compatibilidad del proveedor

Consulta el siguiente artículo sobre la compatibilidad con Citrix para el arranque seguro:
Compatibilidad de Citrix para el arranque seguro
Credential Guard de Windows Defender no es compatible con estos productos, versiones de productos, sistemas
informáticos o versiones de Windows 10:
Para Credential Guard de Windows Defender en Windows 10 con productos de cifrado de McAfee,
consulta: Compatibilidad de Device Guard de Windows Defender y Credential Guard de Windows Defender
en Windows 10 con los productos de cifrado de McAfee
Para Credential Guard de Windows Defender en Windows 10 con el Check Point Endpoint Security Client,
consulta: Compatibilidad de Check Point Endpoint Security Client con las características de Credential
Guard de Windows Defender y Device Guard de Windows Defender de Microsoft Windows 10
Para Credential Guard de Windows Defender en Windows 10 con VMWare Workstation Se produce un
error del host de Windows 10 al ejecutar VMWare Workstation cuando Credential Guard de Windows
Defender está habilitado
Para Credential Guard de Windows Defender en Windows 10 con versiones específicas de Lenovo
ThinkPad Compatibilidad de ThinkPad con Device Guard de Windows Defender y Credential Guard de
Windows Defender en Microsoft Windows 10: ThinkPad
Para Credential Guard de Windows Defender en Windows 10 con Symantec Endpoint Protection Windows
10 con Credential Guard de Windows Defender y Symantec Endpoint Protection 12.1
Esta no es una lista completa. Comprueba si tu proveedor del producto, la versión del producto o el sistema
del equipo, admiten Credential Guard de Windows Defender en sistemas que ejecutan Windows 10 o
versiones específicas de Windows 10. Los modelos de sistema de equipo específico pueden ser compatibles
con Credential Guard de Windows Defender.
Microsoft recomienda a los proveedores de terceros contribuir a esta página proporcionando información
de soporte técnico de producto relevante y agregando vínculos a sus propias declaraciones de soporte
técnico del producto.
Control de cuentas de usuario
Se aplica a
Windows10
Windows Server 2016
Control de cuentas de usuario (UAC ) ayuda a prevenir que el malware dañe un equipo y ayuda a las organizaciones
a implementar un escritorio mejor administrado. Con UAC, las aplicaciones y las tareas siempre se ejecutan en el
contexto de seguridad de una cuenta de administrador, a menos que un administrador autorice específicamente el
acceso de nivel de administrador al sistema. UAC puede bloquear la instalación automática de aplicaciones no
autorizadas y evitar cambios inadvertidos en la configuración del sistema.
UAC permite a los usuarios iniciar sesión en sus equipos con una cuenta de usuario estándar. Los procesos que se
inician con un token de usuario estándar pueden realizar tareas usando los derechos de acceso concedidos a un
usuario estándar. Por ejemplo, el Explorador de Windows hereda automáticamente los permisos de nivel de
usuario estándar. Además, las aplicaciones que se inician mediante el Explorador de Windows (por ejemplo,
haciendo doble clic en un acceso directo) también se ejecutan con el conjunto de permisos de usuario estándar.
Muchas aplicaciones, como las que se incluyen en el propio sistema operativo, están diseñadas para funcionar
correctamente de este modo.
Otras aplicaciones, en especial, aquellas que no se diseñaron específicamente teniendo en cuenta la configuración
de seguridad, requieren a menudo permisos adicionales para ejecutarse correctamente. Estos tipos de aplicaciones
se conocen como aplicaciones heredadas. Además, las acciones como instalar software nuevo y realizar cambios de
configuración en el Firewall de Windows, requieren más permisos de los que hay disponibles para una cuenta de
usuario estándar.
Cuando una aplicación necesita ejecutarse con más que derechos de usuario estándar, UAC puede restaurar grupos
de usuarios adicionales en el token. Esto permite que el usuario tenga control explícito de las aplicaciones que
están realizando cambios en el nivel del sistema en su equipo o dispositivo.
Aplicaciones prácticas
El Modo de aprobación de administración de UAC ayuda a prevenir que el malware se instale de forma silenciosa
sin conocimiento del administrador. También ayuda a prevenir cambios inadvertidos de todo el sistema. Por último,
se puede usar para aplicar un mayor nivel de cumplimiento donde los administradores deben consentir
activamente cada proceso administrativo o proporcionar credenciales para ellos.
En esta sección
TEMA DESCRIPCIÓN
Cómo funciona el Control de cuentas de usuario El Control de cuentas de usuario (UAC) es un componente
fundamental de la visión global de seguridad de Microsoft.
UAC te ayuda a mitigar el impacto de malware.
TEMA DESCRIPCIÓN
Configuración de directiva de seguridad de Control de cuentas Puedes usar directivas de seguridad para configurar cómo
de usuario funciona el Control de cuentas de usuario de la organización.
Pueden configurarse localmente mediante el complemento de
directiva de seguridad local (secpol.msc) o para el dominio,
unidad organizativa o grupos específicos mediante la directiva
de grupo.
Configuración de las claves del Registro y directiva de grupo Aquí tienes una lista de las opciones de configuración de
de Control de cuentas de usuario claves del registro y la directiva de grupo de UAC que tu
organización puede usar para gestionar el UAC.
Guía técnica de VPN para Windows 10
Se aplica a
Windows10
Windows 10 Mobile
En esta guía se explican las decisiones que tomarás para los clientes de Windows 10 en la solución VPN
empresarial y cómo configurar la implementación. Esta guía hace referencia al Proveedor de servicios de
configuración (CSP ) VPNv2 y proporciona instrucciones de configuración de la administración de dispositivos
móviles (MDM ) mediante Microsoft Intune y la plantilla de perfil de VPN para Windows 10.
NOTE
En esta guía no se explica la implementación del servidor.
En esta guía
TEMA DESCRIPCIÓN
Tipos de conexión de VPN Selecciona un cliente VPN y un protocolo de túnel
Decisiones de enrutamiento de VPN Elige entre una configuración de túnel dividido y túnel forzado
Opciones de autenticación de VPN Selecciona un método para la autenticación del protocolo de

autenticación extensible (EAP).
VPN y acceso condicional Usa la evaluación de la directiva de Azure Active Directory

para establecer las directivas de acceso para las conexiones
VPN.
Resolución de nombres de VPN Decidir cómo debe funcionar la resolución de nombres
Opciones desencadenadas automáticamente de perfil de VPN Configurar un perfil de VPN para conectarte automáticamente
por aplicación o por nombre, para estar "siempre activado" y
para que no active VPN en redes de confianza
Características de seguridad de VPN Establecer un perfil de Bloquear VPN, configurar el filtrado de

tráfico y conectar el perfil de VPN a Windows Information
Protection (WIP)
TEMA DESCRIPCIÓN
Opciones de perfil de VPN Combinar la configuración en un único perfil de VPN

mediante XML
Más información
Conexiones VPN en Microsoft Intune
Se aplica a
Windows10
Windows 10 Mobile
Las redes privadas virtuales (VPN ) son conexiones de punto a punto en una red pública o privada, como Internet.
Un cliente VPN usa protocolos especiales TCP/IP o basados en UDP, denominados protocolos de túnel, para
realizar una llamada virtual a un puerto virtual en un servidor VPN. En una implementación típica de VPN, un
cliente inicia una conexión virtual de punto a punto en un servidor de acceso remoto a través de Internet. El
servidor de acceso remoto responde a la llamada, autentica al autor de la llamada y transfiere datos entre el
cliente VPN y de red privada de la organización.
Hay muchas opciones para los clientes VPN. En Windows 10, los complementos integrados y la plataforma de
complementos de VPN de la Plataforma universal de Windows (UWP ) se basan en la plataforma de VPN de
Windows. Esta guía se centra en los clientes de la plataforma de VPN de Windows y en las características que
pueden configurarse.
Cliente VPN integrado

Protocolos de túnel
Intercambio de claves por red versión 2 (IKEv2)
Configura las propiedades criptográficas de túnel de IPsec/IKE mediante la opción Conjunto de
aplicaciones criptográficas en el Proveedor de servicios de configuración (CSP ) VPNv2.
L2TP
L2TP con la autenticación de clave precompartida (PSK) puede configurarse mediante la opción
L2tpPsk en el VPNv2 CSP.
PPTP
SSTP
SSTP es compatible con las ediciones de escritorio de Windows únicamente. No se puede
configurar SSTP mediante la administración de dispositivos móviles (MDM ), pero es uno de los
protocolos que se intenta en la opción Automático.
Automático
La opción Automático significa que el dispositivo intentará cada uno de los protocolos de túnel
integrados hasta que se establezca la conexión. Intentará desde el más seguro al menos seguro.
Configura Automático para la opción NativeProtocolType en el VPNv2 CSP.
Complemento de VPN de la Plataforma universal de Windows

Los complementos de VPN de la Plataforma universal de Windows (UWP ) se introdujeron en Windows 10,
aunque originalmente había disponibles versiones independientes para las plataformas Windows 8.1 Mobile y
Windows 8.1 para equipos de escritorio. Con la plataforma UWP, los proveedores de VPN externos pueden crear
complementos de contenedores de aplicaciones mediante API de WinRT, lo que elimina la complejidad y los
problemas a menudo asociados con la escritura en controladores de nivel del sistema.
Hay un número de aplicaciones de VPN de la Plataforma universal de Windows, como Pulse Secure, Cisco
AnyConnect, F5 Access, Sonicwall Mobile Connect y Check Point Capsule. Si quieres usar un complemento de
VPN de UWP, trabaja con tu proveedor para conocer las opciones personalizadas necesarias para configurar la
solución VPN.
Configurar el tipo de conexión

Consulta Opciones de perfil de VPN y VPNv2 CSP para conocer la configuración de XML.
La siguiente imagen muestra las opciones de conexión en una directiva de configuración de perfil de VPN con
Microsoft Intune.
En Intune, también puedes incluir XML personalizado para los perfiles de complementos de terceros.
Temas relacionados
Se aplica a
Windows10
Windows 10 Mobile
Las rutas de red son necesarias para que la pila comprenda qué interfaz usar para el tráfico saliente. Una de las
decisiones más importantes para la configuración de VPN es si quieres enviar todos los datos a través de VPN
(túnel forzado) o solo algunos datos a través de la VPN (túnel dividido). Esta decisión afecta a la configuración y
el planeamiento de capacidad, así como las expectativas de seguridad de la conexión.
Configuración de túnel dividido

En una configuración de túnel dividido, se pueden especificar las rutas para ir por VPN y todo el tráfico restante
pasará por la interfaz física.
Las rutas pueden configurarse mediante la opción VPNv2/ProfileName/RouteList en el proveedor de servicios
de configuración (CSP ) VPNv2.
Para cada elemento de la ruta en la lista, puede especificarse lo siguiente:
Dirección: VPNv2/NombreDePerfil/ListaDeRuta/IdDeFilaDeRuta/Dirección
Tamaño de prefijo: VPNv2/NombreDePerfil/ListaDeRuta/IdDeFilaDeRuta/Prefijo
Ruta de exclusión: VPNv2/NombreDePerfil/ListaDeRuta/IdDeFilaDeRita/RutaDeExclusión
La plataforma de VPN de Windows ahora admite la capacidad de especificar las rutas de exclusión que en
concreto no deben incluirse en la interfaz física.
También pueden agregarse rutas en tiempo de conexión a través del servidor para aplicaciones VPN para UWP.
Configuración de túnel forzado

En una configuración de túnel forzado, todo el tráfico pasará por VPN. Esta es la configuración predeterminada y
surte efecto si no se especifica ninguna ruta.
La única implicación de esta configuración es la manipulación de las entradas de enrutamiento. En el caso de un
túnel forzado, las rutas VPN v4 y v6 predeterminadas (por ejemplo, 0.0.0.0/0) se agregan a la tabla de
enrutamiento con una métrica inferior a las de otras interfaces. Esto envía el tráfico a través de la VPN, siempre y
cuando no haya una ruta específica en la interfaz física misma.
Para una VPN integrada, esta decisión se controla mediante la opción de MDM
VPNv2/ProfileName/NativeProfile/RoutingPolicyType.
Para un complemento de VPN para UWP, la aplicación controla esta propiedad directamente. Si el complemento
VPN indica la ruta predeterminada para IPv4 e IPv6 como las dos únicas rutas de inclusión, la plataforma VPN
marca la conexión como Túnel forzado.
Configurar el enrutamiento
Cuando configuras un perfil de VPN en Microsoft Intune, seleccionas una casilla para habilitar la configuración de
túnel dividido.
Luego, en Límites corporativos, agregas las rutas que deben usar la conexión VPN.
Temas relacionados
Se aplica a
Windows10
Windows 10 Mobile
Además de los métodos de autenticación basados en contraseña antiguos y menos seguros (que deben evitarse),
la solución VPN integrada usa el protocolo de autenticación extensible (EAP ) para proporcionar una autenticación
segura con el nombre de usuario y la contraseña, y métodos basados en certificados. Solo puedes configurar la
autenticación basada en EAP si seleccionas un tipo VPN integrado (IKEv2, L2TP, PPTP o automático).
Windows admite una serie de métodos de autenticación de EAP.
MÉTODO DETALLES
EAP con protocolo de autenticación por desafío mutuo de Autenticación por nombre de usuario y contraseña
Microsoft, versión 2 (EAP-MSCHAPv2) Credenciales de Winlogon: puedes especificar la
autenticación con credenciales de inicio de sesión del
equipo
EAP con seguridad de la capa de transporte (EAP-TLS) Admite los siguientes tipos de autenticación de
certificados
Certificado con claves en el proveedor de
almacenamiento de claves (KSP) de software
Certificado con claves en módulo de
plataforma segura (TPM) KSP
Certificados de tarjeta inteligente
Certificado de Windows Hello para empresas
Filtrado de certificados
El filtrado de certificados puede habilitarse para
buscar un determinado certificado que se
usará para autenticarse
El filtrado puede basarse en el emisor o
basarse en el uso mejorado de claves (EKU)
Validación del servidor: con TLS, la validación del
servidor se puede activar o desactivar
Nombre de servidor: especifica el servidor para
validar
Certificado de servidor: certificado raíz de
confianza para validar el servidor
Notificación: especifica si el usuario debe recibir
una notificación que le pregunte si confiar en el
servidor o no
MÉTODO DETALLES
Protocolo de autenticación extensible protegido (PEAP) Validación del servidor: con PEAP, la validación del
servidor se puede activar o desactivar
Nombre de servidor: especifica el servidor para
validar
Certificado de servidor: certificado raíz de
confianza para validar el servidor
Notificación: especifica si el usuario debe recibir
una notificación que le pregunte si confiar en el
servidor o no
Método interno: el método externo crea un túnel
seguro en el interior, mientras que el método interno
se usa para completar la autenticación
EAP-MSCHAPv2
EAP-TLS
Reconexión rápida: reduce el retraso entre un la
solicitud de autenticación de un cliente y la respuesta
del servidor de directivas de redes (NPS) u otro
servidor de Servicio de autenticación remota telefónica
de usuario (RADIUS). Esto reduce los requisitos de
recursos del cliente y el servidor, a la vez que minimiza
el número de veces que se le piden las credenciales a
los usuarios.
Cryptobinding: al derivar e intercambiar valores desde
el material de clave PEAP de fase 1 (clave de túnel) y
el material de clave del método EAP interno PEAP de
fase 2 (Clave de sesión interna), es posible
demostrar que las dos autenticaciones terminan en las
mismas dos entidades (mismo nivel PEAP y servidor
PEAP). Este proceso, que se conoce como
"cryptobinding", se usa para proteger la negociación
de PEAP contra los ataques "Man in the Middle".
Seguridad de capa de transporte de túnel (TTLS) Método interno

Sin EAP
Protocolo de autenticación de
contraseña (PAP)
CHAP
MSCHAP
MSCHAPv2
EAP
MSCHAPv2
TLS
Validación del servidor: en TTLS, el servidor debe
validarse. Puede configurarse lo siguiente:
Nombre del servidor
Certificado raíz de confianza para el certificado
de servidor
Si debe haber una notificación de validación de
servidor
Para un complemento VPN de UWP, el proveedor de la aplicación controla el método de autenticación que se
usará. Pueden usarse los siguientes tipos de credenciales:
Tarjeta inteligente
Certificado
Nombre de usuario y contraseña
Contraseña de un solo uso
Tipo de credencial personalizada
Configurar la autenticación
Consulta Configuración de EAP para conocer la configuración de EAP XML.
NOTE
Para configurar la autenticación de Windows Hello para empresas, sigue los pasos de configuración de EAP para crear un
certificado de tarjeta inteligente. Más información sobre Windows Hello para empresas.
La siguiente imagen muestra el campo para EAP XML en un perfil de VPN de Microsoft Intune. El campo de EAP
XML solo aparece cuando seleccionas un tipo de conexión integrada (automático, IKEv2, L2TP, PPTP ).
Temas relacionados
Se aplica a: Windows 10 y 10 de Windows Mobile
El cliente VPN ahora es capaz de integrarse con la plataforma de acceso condicional basado en la nube para
proporcionar una opción de cumplimiento del dispositivo para los clientes remotos. Acceso condicional es un
motor de evaluación basado en directivas que te permite crear reglas de acceso para cualquier aplicación
conectada de Azure Active Directory (Azure AD ).
NOTE
Acceso condicional es una característica de Azure AD Premium.
Los componentes de la plataforma de acceso condicional usados para el cumplimiento del dispositivo incluyen
los siguientes servicios basados en la nube:
Marco de acceso condicional
Azure AD Connect Health
Servicio de atestación de estado de Windows (opcional)
Entidad de certificación de Azure AD: es obligatorio que el certificado de cliente usado para la solución de
cumplimiento del dispositivo basado en la nube sea emitido por una entidad de certificación (CA) basada
en Azure Active Directory. Una entidad de certificación de Azure AD es, básicamente, un inquilino de nube
miniCA en Azure. No puede configurarse la entidad de certificación de Azure AD como parte de una CA
empresarial local.
Certificados emitidos por Azure AD de corta duración: cuando se realiza un intento de conexión a VPN, el
agente de tokens de Azure AD en el dispositivo local se comunica con Azure Active Directory, que, a
continuación, comprueba el estado en función de reglas de cumplimiento. Si cumple, Azure AD devuelve
un certificado de corta duración que se usa para autenticar la VPN. Ten en cuenta que pueden usarse
métodos de autenticación de certificados como EAP -TLS.
Detalles adicionales relativos a certificados emitidos por Azure AD de corta duración:
La duración predeterminada es de 60 minutos y se puede configurar
Cuando expira el certificado, el cliente volverá a comprobar con Azure AD para que se pueda validar el
estado continuo antes de emitir un nuevo certificado, lo que permite la continuación de la conexión
Directivas de cumplimiento de dispositivo de Microsoft Intune: el cumplimiento de dispositivos basado en
la nube aprovecha las directivas de cumplimiento de Microsoft Intune, que son capaces de consultar el
estado del dispositivo y definir reglas de cumplimiento para lo siguiente, entre otras cosas.
Estado del antivirus
Estado de actualización automática y cumplimiento de actualización
Cumplimiento de la directiva de contraseñas
Cumplimiento de cifrado
Estado de atestación de estado de dispositivo (que se validan con el servicio de atestación después de la
consulta)
Los siguientes componentes del lado cliente también son obligatorios:
Proveedor de servicio de configuración (CSP ) de HealthAttestation
Configuración del nodo VPNv2 CSP DeviceCompliance
Módulo de plataforma segura (TPM )
Cumplimiento del dispositivo VPN

Según el CSP VPNv2, estas opciones de configuración son opcional. Si desea que los usuarios tener acceso a
recursos locales, como los archivos en un recurso compartido de red, en función de la credencial de un certificado
emitido por una entidad emisora de certificados local y no el certificado de entidad emisora de certificados en la
nube, agregue estas opciones de configuración para el perfil de VPNv2. Como alternativa, si agrega los
certificados raíz de la nube en el almacén NTAuth en prem AD, se encadenamiento de certificado de la nube de
su usuario y KDC emitirá vales TGT y TGS a ellos.
Los requisitos de infraestructura del lado servidor para admitir el cumplimiento del dispositivo VPN incluyen:
El servidor VPN debe configurarse para la autenticación de certificado.
El servidor VPN debe confiar en la entidad de certificación de Azure AD específica del inquilino
Cualquiera de las condiciones siguientes debe ser verdadera para el SSO de Kerberos/NTLM:
Los servidores de dominio confían en la CA de Azure AD
Un certificado de dominio de confianza se implementa en el dispositivo cliente y está configurado para
usarse para el inicio de sesión único (SSO )
Después de configurar el lado del servidor, los administradores de la VPN pueden agregar la configuración de
directiva para el acceso condicional en el perfil de VPN mediante el nodo VPNv2 DeviceCompliance.
Se aprovechan dos proveedores de servicios de configuración del lado cliente para el cumplimiento del
dispositivo VPN.
Configuración de VPNv2 CSP DeviceCompliance
Habilitado: habilita el flujo de cumplimiento del dispositivo para el cliente. Si se marcó como true, el
cliente VPN intenta comunicarse con Azure AD para obtener un certificado que se va a usar para la
autenticación. La VPN debe configurarse para usar autenticación de certificado, y el servidor VPN debe
confiar en el servidor devuelto por Azure AD.
SSO: nodos de SSO se pueden usar para elegir un certificado diferente desde el certificado de
autenticación de VPN para la autenticación Kerberos en el caso de cumplimiento del dispositivo.
Sso/Enabled: si este campo se establece en true, el cliente VPN busca un certificado distinto para la
autenticación Kerberos.
Sso/IssuerHash: aplica una función hash para que el cliente VPN busque el certificado correcto para la
autenticación Kerberos.
Sso/Eku: lista separada por comas de extensiones de uso mejorado de clave (EKU ) para que el cliente
VPN busque el certificado correcto para la autenticación Kerberos.
HealthAttestation CSP (no es un requisito): las funciones realizadas por el HealthAttestation CSP incluyen:
Recopila datos TPM que se usan para comprobar estados de mantenimiento
Reenvía los datos al servicio de atestación de estado (HAS )
Aprovisiona el certificado de atestación de estado recibido del HAS
Cuando se solicita, reenvía el certificado de atestación de estado (recibido del HAS ) y la información en
tiempo de ejecución relacionada al servidor MDM para su comprobación.
NOTE
Habilitar SSO no es necesario realizar a menos que desea que los usuarios VPN que ser emitidos vales Kerberos para tener
acceso a los recursos locales con un certificado emitido por la entidad emisora de certificados local; no en la nube certificado
emitido por AAD.
Flujo de conexión de cliente

El flujo de conexión del lado de cliente VPN funciona de la siguiente manera:
Cuando se configura un perfil de VPNv2 con \ < DeviceCompliance > \ < habilitada > true < /Enabled > el
cliente VPN usa este flujo de conexión:
1. El cliente VPN llama al agente de tokens de AAD de Windows 10 y se identifica como un cliente VPN.
2. El agente de tokens de Azure AD se autentica en Azure AD y le proporciona información acerca del dispositivo
que intenta conectarse. El servidor de AD Azure comprueba si el dispositivo cumple con las directivas.
3. Si cumple, Azure AD solicita un certificado de corta duración
4. Azure AD inserta un certificado de corta duración en el almacén de certificados mediante el agente de tokens.
El agente de tokens luego devuelve el control al cliente VPN para el procesamiento posterior de conexión.
5. El cliente VPN usa el certificado emitido por AD Azure para autenticarse en el servidor VPN.
Configurar el acceso condicional

Obtén más información sobre el acceso condicional y el estado de

Azure AD
Acceso condicional de Azure Active Directory
Introducción al acceso condicional de Azure Active Directory
Controlar el estado de los dispositivos basados en Windows 10
Sugerencia: el marco de acceso condicional y cumplimiento del dispositivo para VPN (parte 1)
Temas relacionados
Se aplica a
Windows10
Windows 10 Mobile
Cuando el cliente VPN se conecta al servidor VPN, el cliente VPN recibe la dirección IP del cliente. El cliente
también puede recibir la dirección IP del servidor de sistema de nombres de dominio (DNS ) y la dirección IP del
servidor del Servicio de nombres Internet de Windows (WINS ).
La configuración de resolución de nombre en el perfil de VPN configura cómo debe funcionar la resolución de
nombres en el sistema cuando se conecta la VPN. La pila de red primero busca las coincidencias en la tabla de
directivas de resolución de nombre (NRPT) e intenta una resolución en caso de hallar una coincidencia. Si no se
encuentra ninguna coincidencia, el sufijo DNS en la interfaz preferida en función de la métrica de interfaz se
anexa al nombre (en el caso de un nombre corto) y se envía una consulta DNS en la interfaz preferida. Si se agota
el tiempo de espera de la consulta, se usa la lista de búsqueda de sufijos DNS en orden y se envían consultas
DNS en todas las interfaces.
Tabla de directivas de resolución de nombres (NRPT)

La tabla NRPT es una tabla de espacios de nombres que determina el comportamiento del cliente DNS al emitir
las consultas de resolución de nombres y las respuestas de procesamiento. Es el primer lugar donde la pila
buscará DNSCache.
Hay 3 tipos de coincidencias de nombre que se pueden configurar para NRPT:
Nombre de dominio completo (FQDN ) que puede usarse para una coincidencia directa con un nombre
La coincidencia de sufijos provoca una comparación de sufijos (para la resolución FQDN ) o el anexado del
sufijo (en caso de un nombre corto)
Toda resolución debe intentar primero resolverse con el servidor proxy/servidor DNS con esta entrada
NRPT se establece mediante el nodo VPNv2/ProfileName/DomainNameInformationList del VPNv2 CSP.
Este nodo configura también el servidor proxy web o servidores de nombres de dominio.
Obtén más información sobre NRPT
Sufijo DNS
Esta opción se usa para configurar el sufijo DNS principal de la interfaz VPN y la lista de búsqueda sufijos una
vez que se establece la conexión VPN.
El sufijo DNS principal se establece mediante el nodo VPNv2/ProfileName/DnsSuffix.
Averigua más sobre el sufijo DNS principal
Persistente
También puedes configurar reglas de resolución de nombres persistente. La resolución de nombres para los
elementos especificados se realizará únicamente por VPN.
La resolución de nombres persistente se establece mediante el nodo
VPNv2/ProfileName/DomainNameInformationList//dniRowId/Persistent.
Configurar la resolución de nombres

La siguiente imagen muestra las opciones de resolución de nombres en una directiva de configuración de perfil
de VPN con Microsoft Intune.
Los campos en Agregar o editar regla de DNS en el perfil de Intune correspondiente a la configuración de
XML que se muestra en la siguiente tabla.
CAMPO XML
Nombre VPNv2/ProfileName/DomainNameInformationList/dniRo
wId/DomainName
Servidores (separados por comas) VPNv2/ProfileName/DomainNameInformationList/dniRo

wId/DnsServers
Servidor proxy VPNv2/ProfileName/DomainNameInformationList/dniRo

wId/WebServers
Temas relacionados
Opciones desencadenadas automáticamente de
perfil de VPN
Se aplica a
Windows 10
Windows 10 Mobile
En Windows 10, se agregó una serie de características para el desencadenamiento automático de VPN para que
los usuarios no tengan que conectarse manualmente cuando se necesita una VPN para acceder a recursos.
Existen tres tipos diferentes de reglas de desencadenamiento automático:
Desencadenador de aplicaciones
Desencadenador basado en nombre
Siempre activado
Desencadenador de aplicaciones
Los perfiles de VPN en Windows 10 pueden configurarse para conectarse automáticamente en el inicio de un
conjunto de aplicaciones especificado. Puedes configurar aplicaciones de escritorio o para Plataforma universal
de Windows (UWP ) para desencadenar una conexión VPN. También puedes configurar VPN por aplicación y
especificar las reglas de tráfico para cada aplicación. Consulta Filtros de tráfico para obtener más detalles.
El identificador de la aplicación para una aplicación de escritorio es una ruta de acceso de archivo. El identificador
de la aplicación para una aplicación para UWP es un nombre de familia de paquete.
Buscar un nombre de familia de paquete (PFN ) para la configuración de VPN por aplicación
Desencadenador basado en nombre

Puedes configurar una regla basada en el nombre de dominio para que un nombre de dominio específico
desencadene la conexión VPN.
El desencadenador automático basado en nombre puede configurarse mediante la opción
VPNv2/ProfileName/DomainNameInformationList/dniRowId/AutoTrigger en el proveedor de servicios de
configuración (CSP ) VPNv2.
Existen cuatro tipos de desencadenadores basados en nombre:
Nombre corto: por ejemplo, si HRweb está configurado como desencadenador y la pila ve una solicitud de
resolución DNS para HRweb, se activará la VPN.
Nombre de dominio completo (FQDN ): por ejemplo, si HRweb.corp.contoso.com está configurado como
un desencadenador y la pila ve una solicitud de resolución DNS para HRweb.corp.contoso.com, se activará
la VPN.
Sufijo: por ejemplo, si .corp.contoso.com está configurado como desencadenador y la pila ve una solicitud
de resolución DNS con un sufijo coincidente (como HRweb.corp.contoso.com ), se activará la VPN. Para las
resoluciones de nombre corto, se activará la VPN y se consultará al servidor DNS por
NombreCorto.corp.contoso.com.
Todo: si se usa, todas las resoluciones de DNS deberían activar la VPN.
Siempre activado
Siempre activado es una característica de Windows 10 que permite que el perfil de VPN activo se conecte
automáticamente en los siguientes desencadenadores:
Inicio de sesión de usuario
Cambio de red
Encendido de la pantalla del dispositivo
Cuando se produce el desencadenador, la VPN intenta conectarse. Si se produce un error o se necesita la entrada
de cualquier usuario, al usuario le aparece una notificación del sistema para que interactúe.
Cuando un dispositivo tiene varios perfiles con desencadenadores Siempre activado, el usuario puede especificar
el perfil activo en Configuración > Red e Internet > VPN > Perfil de VPN si selecciona la casilla Permitir que
las aplicaciones usen automáticamente esta conexión VPN. De manera predeterminada, el primer perfil
configurado por MDM está marcado como Activo.
La conservación de usuario siempre en preferencia
Windows tiene una característica para conservar la preferencia de AlwaysOn de un usuario. En caso de que un
usuario manualmente desactiva la casilla de verificación "Conectar automáticamente", Windows recordará esta
preferencia de usuario para este nombre de perfil agregando el nombre del perfil en el valor
AutoTriggerDisabledProfilesList.
Una administración herramienta quitar o agregar el mismo perfil nombre back y establezca AlwaysOn en true,
será de Windows no deben comprobar el cuadro si ya existe el nombre del perfil en el por debajo del valor del
registro con el fin de conservar la preferencia de usuario. Clave: Valor
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Config: tipo de
AutoTriggerDisabledProfilesList: REG_MULTI_SZ
Detección de redes de confianza

Esta característica configura la VPN de modo que no se active si un usuario está en una red corporativa de
confianza. El valor de esta opción es una lista de sufijos DNS. La pila VPN examinará el sufijo DNS en la interfaz
física y, si coincide con cualquiera en la lista configurada y la red es privada o está aprovisionada mediante MDM,
no se activará la VPN.
La detección de redes de confianza puede configurarse mediante la opción
VPNv2/ProfileName/TrustedNetworkDetection en VPNv2 CSP.
Configurar VPN activadas por aplicaciones

La siguiente imagen muestra la asociación de una aplicación a una conexión VPN en una directiva de
configuración de perfil de VPN mediante Microsoft Intune.
Después de agregar una aplicación asociada, si seleccionas la casilla Solo estas aplicaciones pueden usar esta
conexión VPN (VPN por aplicación), la aplicación pasa a estar disponible en Límites corporativos, donde
puedes configurar las reglas de la aplicación. Consulta Filtros de tráfico para obtener más detalles.
Temas relacionados
Se aplica a
Windows10
Windows 10 Mobile
VPN de bloqueo
Un perfil de VPN configurado con bloqueo protege el dispositivo para permitir solamente el tráfico de red a
través de la interfaz de VPN. Tiene las siguientes características:
El sistema intenta mantener la VPN conectada en todo momento.
El usuario no puede desconectar la conexión VPN.
El usuario no puede eliminar o modificar el perfil de VPN.
El perfil de bloqueo de VPN usa la conexión de túnel forzada.
Si la conexión VPN no está disponible, se bloquea el tráfico de red saliente.
Solo se permite un perfil de bloqueo de VPN en un dispositivo.
NOTE
Para la VPN integrada, Bloquear VPN solo está disponible para el tipo de conexión de la versión 2 del intercambio de claves
por red (IKEv2).
Implementa esta característica con precaución, ya que la conexión resultante no podrá enviar ni recibir tráfico de
red sin que la VPN esté conectada.
Integración de Windows Information Protection (WIP) con VPN

Windows Information Protection ofrece capacidades que permiten la separación y la protección de datos
empresariales frente a la divulgación en dispositivos empresariales y personales, sin necesidad de cambios
adicionales en los entornos ni en las aplicaciones mismas. Además, cuando se usa con Rights Management
Services (RMS ), WIP puede ayudar a proteger los datos empresariales localmente.
El nodo EdpModeId en el proveedor de servicios de configuración (CSP ) VPNv2 permite que un cliente VPN
de Windows 10 se integre con WIP, lo que amplía su funcionalidad a dispositivos remotos. Entre las situaciones
de uso para WIP se incluyen:
Funcionalidad principal: cifrado de archivos y bloqueo de acceso a archivos
Aplicación de directivas de la experiencia del usuario: restringir las operaciones de copiar y pegar, arrastrar y
colocar, y uso compartido
Aplicación de directivas de red de WIP: proteger los recursos de intranet a través de la red corporativa y VPN
Aplicación de directivas de red: proteger los recursos de nube en Internet y SMB a través de la red corporativa
y VPN
El valor de EdpModeId es un identificador de empresa. La pila de red buscará este identificador en el token de
la aplicación para determinar si debe activarse la VPN para esa aplicación en particular.
Además, al conectarse con WIP, el administrador no tiene que especificar reglas AppTriggerList y TrafficFilterList
por separado en este perfil (a menos que se necesite una configuración más avanzada) porque las directivas de
WIP y las listas de aplicaciones surten efecto automáticamente.
Más información sobre Windows Information Protection
Filtros de tráfico
Los filtros de tráfico permiten a las empresas decidir qué tráfico se permite en la red corporativa según las
directivas. Los administradores de redes deben agregar de manera eficaz reglas de firewall específicas para la
interfaz en la interfaz de VPN. Hay dos tipos de reglas de filtros de tráfico:
Reglas basadas en aplicaciones. Con las reglas basadas en aplicaciones, se puede marcar una lista de
aplicaciones para permitir en la interfaz VPN solo el tráfico procedente de dichas aplicaciones.
Reglas basadas en el tráfico. Las reglas basadas en el tráfico son directivas de 5 tuplas (puertos, direcciones,
protocolo) que se pueden especificar para permitir solo el tráfico que coincida con dichas reglas en la interfaz
VPN.
Puede haber varios conjuntos de reglas vinculados con el operador OR. En cada conjunto, puede haber reglas
basadas en aplicaciones y en el tráfico. Todas las propiedades del conjunto se vincularán mediante el operador
AND. Además, estas reglas pueden aplicarse en un nivel por aplicación o por dispositivo.
Por ejemplo, un administrador puede definir las reglas que especifican:
La aplicación de Recursos Humanos de Contoso debe tener permitido pasar por la VPN y acceder
únicamente al puerto 4545.
Las aplicaciones de finanzas de Contoso pueden pasar por la VPN y acceder únicamente a los intervalos IP
remota de 10.10.0.40 a 10.10.0.201 en el puerto 5889.
Todas las demás aplicaciones en el dispositivo deben poder acceder únicamente a los puertos 80 o 443.
Configurar los filtros de tráfico

La siguiente imagen muestra la interfaz para configurar las reglas de tráfico en una directiva de configuración de
perfil de VPN con Microsoft Intune.
Temas relacionados
Se aplica a
Windows10
Windows 10 Mobile
La mayoría de las opciones de VPN en Windows 10 puede configurarse en los perfiles de VPN con Microsoft
Intune o System Center Configuration Manager. Todas las opciones de VPN en Windows 10 pueden
configurarse mediante el nodo ProfileXML en el proveedor de servicios de configuración (CSP ) VPNv2.
NOTE
Si no estás familiarizado con los CSP, consulta antes Introducción a los proveedores de servicios de configuración (CSP) .
En la siguiente tabla se enumeran las opciones de VPN y si las opciones pueden configurarse en Intune y
Configuration Manager, o solo se pueden configurarse mediante ProfileXML.
SE PUEDE CONFIGURAR EN INTUNE Y CONFIGURATION

CONFIGURACIÓN DEL PERFIL MANAGER
Tipo de conexión sí
Enrutamiento: rutas de túnel dividido sí, excepto las rutas de exclusión
Enrutamiento: túnel forzado sí
Autenticación (EAP) sí, si el tipo de conexión está integrado
Acceso condicional sí
Configuración de proxy sí, en un archivo WPAD/PAC o servidor y puerto
Resolución de nombres: NRPT sí
Resolución de nombres: sufijo DNS no
Resolución de nombres: persistente no
Desencadenador automático: desencadenador de sí

aplicaciones
Desencadenador automático: desencadenador de nombres sí
Desencadenador automático: Siempre activado sí
Desencadenador automático: detección de redes de no

confianza
SE PUEDE CONFIGURAR EN INTUNE Y CONFIGURATION
CONFIGURACIÓN DEL PERFIL MANAGER
LockDown no
Windows Information Protection (WIP) sí
Filtros de tráfico sí
El nodo ProfileXML se agregó al VPNv2 CSP para permitir que los usuarios implementen un perfil de VPN
como un blob único. Esto es especialmente útil para la implementación de perfiles con características que las
MDM aún no admiten. Puedes obtener otros ejemplos en el tema ProfileXML XSD.
Perfil de VPN nativo de muestra

El siguiente es un perfil de VPN nativo de muestra. Este blob estaría incluido en el nodo ProfileXML.
<VPNProfile>
<ProfileName>TestVpnProfile</ProfileName>
<NativeProfile>
<Servers>testServer.VPN.com</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>


<Authentication>
<UserMethod>Eap</UserMethod>
<MachineMethod>Eap</MachineMethod>
<Eap>
<Configuration>
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<EapMethod>
<Type xmlns="http://www.microsoft.com/provisioning/EapCommon">25</Type>
<VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
<VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
<AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>
</EapMethod>
<Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
<Type>25</Type>
<EapType xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV1">
<ServerValidation>
<DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
<ServerNames></ServerNames>
<TrustedRootCA>d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2
</TrustedRootCA>
<TrustedRootCA>d1 76 97 cc 20 6e d2 6e 1a 51 f5 bb 96 e9 35 6d 6d 61 0b 74
</TrustedRootCA>
</ServerValidation>
<FastReconnect>true</FastReconnect>
<InnerEapOptional>false</InnerEapOptional>
<Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
<Type>13</Type>
<EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1">
<CredentialsSource>
<CertificateStore>
<SimpleCertSelection>true</SimpleCertSelection>
</CertificateStore>
</CredentialsSource>
<ServerValidation>
<DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
<ServerNames></ServerNames>
<TrustedRootCA>d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2
</TrustedRootCA>
</TrustedRootCA>
</ServerValidation>
<DifferentUsername>false</DifferentUsername>
<PerformServerValidation
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</PerformServerValidation>
<AcceptServerName
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
<TLSExtensions
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">
<FilteringInfo
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3">
<EKUMapping>
<EKUMap>
<EKUName>AAD Conditional Access</EKUName>
<EKUOID>1.3.6.1.4.1.311.87</EKUOID>
</EKUMap>
</EKUMapping>
<ClientAuthEKUList Enabled="true">
<EKUMapInList>
<EKUName>AAD Conditional Access</EKUName>
</EKUMapInList>
</ClientAuthEKUList>
</FilteringInfo>
</TLSExtensions>
</EapType>
</Eap>
<EnableQuarantineChecks>false</EnableQuarantineChecks>
<RequireCryptoBinding>true</RequireCryptoBinding>
<PeapExtensions>
<PerformServerValidation
xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">true</PerformServerValidation>
<AcceptServerName
xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">false</AcceptServerName>
</PeapExtensions>
</EapType>
</Eap>
</Config>
</EapHostConfig>
</Configuration>
</Eap>
</Authentication>

<RoutingPolicyType>SplitTunnel</RoutingPolicyType>
<DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
</NativeProfile>
<Route>
<Address>192.168.0.0</Address>
<PrefixSize>24</PrefixSize>
</Route>
<Route>
</Route>


<AppTrigger>
<App>
<Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
</App>
</AppTrigger>
<AppTrigger>
<App>
<Id>C:\windows\system32\ping.exe</Id>
</App>
</AppTrigger>

<TrafficFilter>
<App>
<Id>%ProgramFiles%\Internet Explorer\iexplore.exe</Id>
</App>
<Protocol>6</Protocol>
<LocalPortRanges>10,20-50,100-200</LocalPortRanges>
<RemotePortRanges>20-50,100-200,300</RemotePortRanges>
<RemoteAddressRanges>30.30.0.0/16,10.10.10.10-20.20.20.20</RemoteAddressRanges>
<RoutingPolicyType>ForceTunnel</RoutingPolicyType>
</TrafficFilter>
<TrafficFilter>
<App>
</App>
<LocalAddressRanges>3.3.3.3/32,1.1.1.1-2.2.2.2</LocalAddressRanges>
</TrafficFilter>

<DomainNameInformation>
<DomainName>hrsite.corporate.contoso.com</DomainName>
<DnsServers>1.2.3.4,5.6.7.8</DnsServers>
<WebProxyServers>5.5.5.5</WebProxyServers>
<AutoTrigger>true</AutoTrigger>
</DomainNameInformation>
<DomainName>.corp.contoso.com</DomainName>

<EdpModeId>corp.contoso.com</EdpModeId>
<RememberCredentials>true</RememberCredentials>

<AlwaysOn>false</AlwaysOn>
<DnsSuffix>corp.contoso.com</DnsSuffix>
<TrustedNetworkDetection>contoso.com</TrustedNetworkDetection>
<Proxy>
<Manual>
<Server>HelloServer</Server>
</Manual>
<AutoConfigUrl>Helloworld.Com</AutoConfigUrl>
</Proxy>

<DeviceCompliance>
<Enabled>true</Enabled>
<Sso>
<Enabled>true</Enabled>
<Eku>This is my Eku</Eku>
<IssuerHash>This is my issuer hash</IssuerHash>
</Sso>
</DeviceCompliance>
</VPNProfile>
Perfil de VPN de complemento de muestra

El siguiente es un perfil de VPN de complemento de muestra. Este blob estaría incluido en el nodo ProfileXML.
<VPNProfile>
<ProfileName>TestVpnProfile</ProfileName>
<PluginProfile>
<ServerUrlList>testserver1.contoso.com;testserver2.contoso..com</ServerUrlList>
<PluginPackageFamilyName>JuniperNetworks.JunosPulseVpn_cw5n1h2txyewy</PluginPackageFamilyName>
<CustomConfiguration><pulse-
schema><isSingleSignOnCredential>true</isSingleSignOnCredential></pulse-schema>
</CustomConfiguration>
</PluginProfile>
<Route>
</Route>
<Route>
</Route>
<AppTrigger>
<App>
</App>
</AppTrigger>
<AppTrigger>
<App>
</App>
</AppTrigger>
<TrafficFilter>
<App>
</App>
<Protocol>6</Protocol>
<LocalPortRanges>10,20-50,100-200</LocalPortRanges>
<RemotePortRanges>20-50,100-200,300</RemotePortRanges>
<RemoteAddressRanges>30.30.0.0/16,10.10.10.10-20.20.20.20</RemoteAddressRanges>

</TrafficFilter>
<TrafficFilter>
<App>
</App>
<LocalAddressRanges>3.3.3.3/32,1.1.1.1-2.2.2.2</LocalAddressRanges>
</TrafficFilter>
<TrafficFilter>
<App>
</App>
<Claims>O:SYG:SYD:(A;;CC;;;AU)</Claims>

</TrafficFilter>
<DomainName>corp.contoso.com</DomainName>
<AutoTrigger>false</AutoTrigger>
<DomainName>corp.contoso.com</DomainName>

<RememberCredentials>true</RememberCredentials>
<AlwaysOn>false</AlwaysOn>
<DnsSuffix>corp.contoso.com</DnsSuffix>
<TrustedNetworkDetection>contoso.com,test.corp.contoso.com</TrustedNetworkDetection>
<Proxy>
<Manual>
<Manual>
<Server>HelloServer</Server>
</Manual>
<AutoConfigUrl>Helloworld.Com</AutoConfigUrl>
</Proxy>
</VPNProfile>
Aplicar ProfileXML con Intune

Después de configurar las opciones que quieras mediante ProfileXML, puedes aplicarlas mediante Intune y una
directiva Configuración personalizada (Windows 10 para equipos de escritorio y Windows 10 Mobile
y posterior).
1. Inicie sesión en el portal de Azure.
2. Vaya a Intune > configuración de dispositivo > Propiedades.
3. Haga clic en Crear perfil.
4. Escriba un nombre y (opcionalmente) una descripción.
5. Elija 10 y versiones posteriores de Windows como la plataforma.
6. Elija personalizado como el tipo de perfil y haga clic en Agregar.
7. Escriba un nombre y (opcionalmente) una descripción.
8. Escriba el URI de OMA ./user/vendor/MSFT/VPNv2/ /ProfileXML de_nombre de perfil VPN_.
9. Establezca el tipo de datos en String (archivo XML ).
10. Cargar el archivo XML del perfil.
11. Haz clic en Aceptar.
12. Haga clic en Aceptar, a continuación, crear.

13. Asigne el perfil.
Más información
Aprende a configurar conexiones VPN con Microsoft Intune.
Referencia del proveedor de servicio de configuración (CSP ) VPNv2
Cómo crear perfiles de VPN en Configuration Manager
Temas relacionados
Cómo configurar el Protocolo Diffie Hellman sobre
conexiones VPN IKEv2
Se aplica a: Windows Server (canal semianual), Windows Server 2016 y Windows 10
En conexiones VPN IKEv2, la configuración predeterminada del grupo Diffie Hellman es Grupo 2, que no es segura
para intercambios IKE. Para proteger las conexiones, actualiza la configuración de los clientes y servidores de la
VPN mediante la ejecución de los cmdlets de VPN.
Servidor VPN
Para los servidores VPN que ejecuten Windows Server 2012 R2 o posterior, debes ejecutar Set-
VpnServerConfiguration para configurar el tipo de túnel. Esto hace que todos los intercambios IKE en el túnel
IKEv2 usen la configuración segura.
Set-VpnServerConfiguration -TunnelType IKEv2 -CustomPolicy
En versiones anteriores de Windows Server, ejecuta Set-VpnServerIPsecConfiguration. Dado que

Set-VpnServerIPsecConfiguration no tiene -TunnelType , la configuración se aplica a todos los tipos de túnel del
servidor.
Set-VpnServerIPsecConfiguration -CustomPolicy
Cliente VPN
Para el cliente VPN, deberás configurar cada conexión VPN. Por ejemplo, ejecuta Set-
VpnConnectionIPsecConfiguration (versión 4.0) y especifica el nombre de la conexión:
Set-VpnConnectionIPsecConfiguration -ConnectionName <String>

En Windows 10, Windows Hello para empresas reemplaza las contraseñas por la autenticación segura en dos
fases, tanto en equipos como en dispositivos móviles. Esta autenticación consiste en un nuevo tipo de credenciales
de usuario vinculadas a un dispositivo y usa un PIN o datos biométricos.
Windows Hello para empresas permite al usuario autenticarse en una cuenta de Active Directory o Azure Active
Directory.
Windows Hello soluciona estos problemas de las contraseñas:
Las contraseñas seguras resultan difíciles de recordar, por lo que los usuarios suelen reutilizarlas en varios sitios.
Las infracciones en el servidor pueden dejar expuestas las credenciales de red simétricas (contraseñas).
Las contraseñas están sujetas a ataques de reproducción.
Los usuarios pueden exponer sus contraseñas de forma involuntaria debido a ataques de suplantación de
identidad (phishing).
Información general Por qué un PIN es mejor que una Administrar Windows Hello en tu
contraseña organización
Requisitos previos.
Implementación solo en la nube
Windows10, versión 1511 o posterior
Cuenta de Microsoft Azure
Azure Active Directory
Multifactor authentication de Azure
Administración moderno (Intune o MDM de terceros compatible), opcional
Suscripción a Azure AD Premium - opcional, necesario para la inscripción de MDM automática cuando el
dispositivo se une a Azure Active Directory
Implementaciones híbridas
La tabla muestra los requisitos mínimos para cada implementación.
CLAVE DE CONFIANZA
DIRECTIVA DE GRUPO CERTIFICADO DE CONFIANZA CLAVE DE CONFIANZA CERTIFICADO DE CONFIANZA
ADMINISTRADA ADMINISTRADO MIX TO ADMINISTRADO MODERNO ADMINISTRADO MODERNO
CLAVE DE CONFIANZA
DIRECTIVA DE GRUPO CERTIFICADO DE CONFIANZA CLAVE DE CONFIANZA CERTIFICADO DE CONFIANZA
ADMINISTRADA ADMINISTRADO MIX TO ADMINISTRADO MODERNO ADMINISTRADO MODERNO
Windows10, versión 1511 o Unido a Azure AD híbrido: Windows10, versión 1511 o Windows10, versión 1511 o
posterior Mínimo: Windows 10, posterior posterior
version 1703
Mejor experiencia: Windows
10, versión 1709 o posterior
(admite inscripción
sincrónica de certificados).
Unido a Azure AD:
Windows10, versión 1511 o
posterior
Esquema Windows Server Esquema de Windows Server Esquema de Windows Server Esquema de Windows Server
2016 2016 2016 2016
Nivel funcional del Nivel funcional del Nivel funcional del Nivel funcional del
dominio/bosque de dominio/bosque de dominio/bosque de dominio/bosque de
Windows Server 2008 R2 Windows Server 2008 R2 Windows Server 2008 R2 Windows Server 2008 R2
Controladores de dominio Controladores de dominio Controladores de dominio Controladores de dominio

de Windows Server 2016 de Windows Server 2008 R2 de Windows Server 2016 de Windows Server 2008 R2
o posterior o posterior
Entidad de certificación de Entidad de certificación de Entidad de certificación de Entidad de certificación de

Windows Server 2012 o Windows Server 2012 o Windows Server 2012 o Windows Server 2012 o
posterior posterior posterior posterior
N/A Windows Server 2016 AD FS N/C Servicio de inscripción de

con actualización dispositivos de red de
KB4088889 (clientes unidos Windows Server 2012 o
a Azure AD híbrido), posterior
y
Servicio de inscripción de
dispositivos de red (unido a
Azure AD) de Windows
Server 2012
Inquilino de MFA de Azure, Inquilino de MFA de Azure, Inquilino de MFA de Azure, o Inquilino de MFA de Azure, o
o o AD FS con adaptador de AD FS con adaptador de
AD FS con adaptador de AD FS con adaptador de MFA de Azure, o MFA de Azure, o
MFA de Azure, o MFA de Azure, o AD FS con adaptador del AD FS con adaptador del
AD FS con adaptador del AD FS con adaptador del servidor de MFA de Azure, o servidor de MFA de Azure, o
servidor de MFA de Azure, o servidor de MFA de Azure, o AD FS con adaptador de AD FS con adaptador de
AD FS con adaptador de AD FS con adaptador de MFA de terceros MFA de terceros
MFA de terceros MFA de terceros
Cuenta de Azure Cuenta de Azure Cuenta de Azure Cuenta de Azure
Azure Active Directory Azure Active Directory Azure Active Directory Azure Active Directory
Azure AD Connect Azure AD Connect Azure AD Connect Azure AD Connect
Azure AD Premium, opcional Azure AD Premium, Azure AD Premium, opcional Azure AD Premium, opcional
necesario para la reescritura para la inscripción para la inscripción
de dispositivos automática de MDM automática de MDM
Implementaciones locales
La tabla muestra los requisitos mínimos para cada implementación.
CLAVE DE CONFIANZA CERTIFICADO DE CONFIANZA

DIRECTIVA DE GRUPO ADMINISTRADA DIRECTIVA DE GRUPO ADMINISTRADA
Windows10, versión 1703 o posterior Windows10, versión 1703 o posterior
Esquema de Windows Server 2016 Esquema de Windows Server 2016
Nivel funcional del dominio/bosque de Windows Server 2008 Nivel funcional del dominio/bosque de Windows Server 2008
R2 R2
Controladores de dominio de Windows Server 2016 Controladores de dominio de Windows Server 2008 R2 o
posterior
Entidad de certificación de Windows Server 2012 o posterior Entidad de certificación de Windows Server 2012 o posterior
Windows Server 2016 AD FS con actualización KB4088889 Windows Server 2016 AD FS con actualización KB4088889
AD FS con servidor de MFA de Azure, o AD FS con adaptador del servidor de MFA de Azure, o
AD FS con adaptador de MFA de terceros AD FS con adaptador de MFA de terceros
Cuenta de Azure, opcional para la facturación de MFA de Cuenta de Azure, opcional para la facturación de MFA de
Azure Azure
Preguntas frecuentes
¿Puedo implementar Windows Hello para empresas usando System Center Configuration Manager?
Windows Hello para implementaciones empresariales con System Center Configuration Manager tenga que
mover para el modelo de implementación híbrida que usa los servicios de federación de Active Directory. Las
implementaciones con System Center Configuration Manager no durante cuánto tiempo se admitirá después de
2018 de noviembre.
¿Qué es la estrategia sin contraseña?
Ver la presentación de Ignite 2017 del Director sénior de programa Karanbir Singh Guía de Microsoft para no
utilizar contraseña
¿Qué es la experiencia del usuario para Windows Hello para empresas?

La experiencia del usuario para Windows Hello para empresas se produce después del inicio de sesión del usuario,
después de implementar la configuración de directiva de Windows Hello en su entorno.
¿Qué sucede cuando el usuario olvida su PIN?

Si el usuario puede iniciar sesión con una contraseña, puede restablecer su PIN haciendo clic en el vínculo "Olvidé
mi PIN" en la configuración. A partir de Fall Creators Update, los usuarios pueden restablecer su PIN por encima
de la pantalla de bloqueo, haz clic en el vínculo "Olvidé mi PIN" en el proveedor de credenciales PIN.
Para las implementaciones locales, los dispositivos deben estar bien conectados a su red local (controladores de
dominio y entidad de certificación) para poder restablecer el PIN. Los clientes híbridos pueden incorporar su
inquilino de Azure para que usen el servicio de restablecimiento de PIN de Windows Hello para restablecer el PIN
sin acceder a su red corporativa.
¿Necesito controladores de dominio de Windows Server 2016?
Existen varias opciones de implementación entre las que elegir. Algunas de estas opciones requieren un número
suficiente de controladores de dominio de Windows Server 2016 en el sitio donde se ha implementado Windows
Hello para empresas. Hay otras opciones de implementación que usan controladores de dominio existentes de
Windows Server 2008 R2 o posterior. Elige la opción de implementación que mejor se adapte a tu entorno
¿Windows Hello para empresas es autenticación multifactor?
Windows Hello para empresas es autenticación en dos fases basada en los factores de autenticación observados
de: algo que tengas, algo que conozcas y algo que forme parte de ti. Windows Hello para empresas incorpora dos
de estos factores: algo que tienes (la clave privada del usuario protegida por el módulo de seguridad del
dispositivo) y algo que sabes (el PIN ). Con el hardware adecuado, puedes mejorar la experiencia del usuario
mediante la introducción de la biométrica. Al usar biométrica, puedes reemplazar el factor de autenticación "algo
que sabes" con el factor "algo que forma parte de ti", con las garantías de que los usuarios pueden volver al factor
"algo que sabes".
¿Puedo usar el PIN y biométrica para desbloquear mi dispositivo?
A partir de Windows 10, versión 1709, puedes usar el desbloqueo multifactor para exigir al usuario que
proporcione un factor adicional para desbloquear el dispositivo. La autenticación permanece en dos fases, pero se
requiere otro factor antes de que Windows permita al usuario llegar al escritorio. Lee más sobre desbloqueo
multifactor en Características de Windows Hello para empresas
La diferencia entre Windows Hello y Windows Hello para empresas
Windows Hello representa el marco biométrico proporcionado en Windows10. Windows Hello permite a los
usuarios usar biométrica para iniciar sesión en sus dispositivos almacenando de forma segura su nombre de
usuario y contraseña y liberándola para la autenticación cuando el usuario se identifica correctamente mediante
biométrica. Windows Hello para empresas usa claves asimétricas protegidas por el módulo de seguridad del
dispositivo, que requiere de un gesto del usuario (PIN o biométrica) para la autenticación.
He extendido Active Directory a Azure Active Directory. ¿Puedo usar el modelo de implementación local?
No. Si tu organización está federada o usa servicios en línea, como Office 365 o OneDrive, entonces, debes usar un
modelo de implementación híbrida. Las implementaciones locales son exclusivas de organizaciones que necesitan
más tiempo antes de pasar a la nube y exclusivamente usan Active Directory.
¿Windows Hello para empresas evita el uso de PIN sencillos?
Sí. Nuestro algoritmo de PIN sencillo busca e impide que cualquier PIN que tenga un delta constante de un dígito
al siguiente. Esto impide números repetitivos, números secuenciales y patrones sencillos. Por ejemplo:
1111 tiene un delta constante de 0, de modo que no está permitido
9630 tiene un delta constante de -3, de modo que no está permitido
1231 no tiene un delta constante, por lo que es correcto
1593 no tiene un delta constante, por lo que es correcto
Este algoritmo no se aplica a PIN alfanuméricos.
¿Cómo el almacenamiento en la memoria caché de PIN funciona con Windows Hello para empresas?
Windows Hello para empresas ofrece una experiencia de usuario de almacenamiento en la memoria caché de PIN
con un sistema de vales. En lugar de almacenamiento en la memoria caché de un PIN, los procesos almacenan en
la memoria caché un vale que pueden usar para solicitar operaciones de clave privada. Las claves de inicio de
sesión de Azure AD y Active Directory se almacenan en la memoria caché con la pantalla bloqueada. Esto significa
que las claves siguen estando disponibles para su uso sin preguntar siempre que sea el usuario inicie sesión de
forma interactiva. Las claves de inicio de sesión de la cuenta de Microsoft se consideran claves transaccionales, lo
que significa que siempre se les pide a los usuarios cuando tienen acceso a la cuenta.
A partir de Windows 10, Fall Creators Update, Windows Hello para empresas usado como tarjeta inteligente
(emulación de tarjeta inteligente habilitada de forma predeterminada) ofrece la misma experiencia de usuario del
almacenamiento predeterminado en la memoria caché de PIN de tarjeta inteligente. Cada proceso que solicita una
operación de clave privada solicitará al usuario el PIN la primera vez que se use. Las operaciones de clave privada
posteriores no pedirán al usuario el PIN.
La característica de emulación de tarjeta inteligente de Windows Hello para empresas comprueba el PIN y luego
descarta el PIN a cambio de un vale. El proceso no recibe el PIN, pero, en su lugar, el vale le concede operaciones
de clave privada. Windows 10 no proporciona ninguna configuración de directiva de grupo para ajustar este
almacenamiento en caché.
¿Se puede deshabilitar el PIN mientras se usa Windows Hello para empresas?
No. El movimiento de extracción de contraseñas se logra gradualmente mediante la reducción del uso de la
contraseña. En el caso de que no puedas realizar una autenticación con biometría, necesitas un mecanismo
alternativo que no sea una contraseña. El PIN es el mecanismo alternativo. Deshabilitar u ocultar el proveedor de
credenciales PIN deshabilitó el uso de la biometría.
¿Windows Hello para empresas funciona con servidores de federación de terceros?
Windows Hello para empresas puede trabajar con servidores de federación de terceros que admitan los protocolos
utilizados durante la experiencia de aprovisionamiento. Terceros interesados pueden consultar en
whfbfeedback@microsoft.com
PROTOCOLO DESCRIPCIÓN
[MS-KPP]: Protocolo de aprovisionamiento de clave Especifica el protocolo de aprovisionamiento de clave, que

define un mecanismo para que un cliente registre un conjunto
de claves criptográficas en una pareja de usuarios y
dispositivos.
[MS-OAPX]: OAuth 2.0 Extensiones del protocolo Especifica las extensiones de protocolo OAuth 2.0, que se usan
para ampliar el marco de autorización de OAuth 2.0. Estas
extensiones habilitan características de autorización, tales
como la especificación de recursos, los identificadores de
solicitud y sugerencias de inicio de sesión.
[MS-OAPXBC]: extensiones del protocolo OAuth 2.0 para Especifica las extensiones de protocolo OAuth 2.0 para clientes
clientes de agente de agente, extensiones para RFC6749 (el marco de
autorización de OAuth 2.0) que permiten que un cliente de
agente obtenga tokens de acceso en nombre de clientes de
llamada.
[MS-OIDCE]: Extensiones del protocolo de OpenID Connect Especifica las extensiones de protocolo de OpenID Connect
1.0 1.0. Estas extensiones definen notificaciones adicionales para
transmitir información sobre el usuario final, incluidos el
nombre principal de usuario, un identificador único local, un
tiempo de expiración de la contraseña y una dirección URL
para cambiar la contraseña. Estas extensiones también definen
metadatos de proveedor adicionales que permiten descubrir el
emisor de tokens de acceso y proporcionar información
adicional sobre las funcionalidades de proveedor.
¿Windows Hello para empresas funciona con clientes de Mac y Linux?
Windows Hello para empresas es una funcionalidad de Windows 10 En este momento, Microsoft no está
implementando clientes para otras plataformas. Sin embargo, Microsoft está abierto a terceros que estén
interesados en mover estas plataformas lejos de las contraseñas. Terceros interesados pueden consultar en
whfbfeedback@microsoft.com

Configurar S-MIME para Windows 10 y Windows 10 Mobile (Windows 10)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Configurar S-MIME para Windows 10 y Windows 10 Mobile (Windows 10)

Încărcat de

Drepturi de autor:

Formate disponibile

Contents

Administración de identidades y acceso

Acerca del cifrado de mensajes

Acerca de firmas digitales

Elegir la configuración de S/MIME

Cifrar o firmar mensajes individuales

Leer mensajes firmados o cifrados

Instalar certificados de un mensaje recibido

Las API de certificado de Windows (CertVerifyCertificateChainPolicy y WinVerifyTrust) se actualizan para

<PinRule Name="AllCertificateAttributes" Error="None" Log="true">

<PinRule Name="MultipleSites" Log="false">

ATRIBUTO DESCRIPCIÓN REQUERIDO

LogDuration o LogEndDate Configura que la auditoría solo se No.

ListIdentifier Proporciona un nombre descriptivo No.

ATRIBUTO DESCRIPCIÓN REQUERIDO

Name Identifica la PinRule de manera Sí.

Error Describe la acción que realiza Windows No.

Log Un valor booleano que se representa No.

ATRIBUTO DESCRIPCIÓN REQUERIDO

EndDate Te permite configurar una fecha de No.

Domain Contiene el nombre DNS que debe Sí.

AllSubdomains De manera predeterminada, la No.

Crear una lista de certificados de confianza de reglas de asignación

CertUtil [Options] -generatePinRulesCTL XMLFile CTLFile [SSTFile]

certutil -generatePinRulesCTL certPinRules.xml pinrules.stl

Aplicar reglas de asignación de certificados a un equipo de referencia

Certutil -setreg chain\PinRules @pinrules.stl

Certutil escribe la información binaria en la ubicación del Registro siguiente:

Valor Contenido binario del archivo de lista de certificados de

Tipo de datos REG_BINARY

12. Cierra el Editor de administración de directivas de grupo para guardar la configuración.

Registro de reglas de asignación adicionales

Valor El directorio principal donde Windows debe escribir los

Tipo de datos REG_SZ

Permiso para la carpeta del registro de reglas de asignación

Representar una fecha en XML

Convertir una fecha XML

Convertir una duración XML

Instalar certificados mediante Microsoft Edge

Instalar certificados mediante correo electrónico

Instalar certificados mediante la administración de dispositivos móviles

Proceso de instalación de certificados mediante MDM

Requisitos de hardware y software

Las aplicaciones se interrumpirán si necesitan:

Consideraciones sobre seguridad

Hardware: CPU de 64 bits Es necesario un equipo de 64 bits para

Firmware: administración y configuración del arranque Requisitos:

PROTECCIONES PARA UNA SEGURIDAD

Firmware: arranque seguro de la Requisitos: La integridad del arranque (arranque

Firmware: administración y Requisitos: • Las empresas pueden permitir que se

Calificaciones de seguridad adicionales de 2017 a partir de Windows 10, versión 1703

PROTECCIONES PARA UNA SEGURIDAD

Firmware: habilitación de VBS de Requisitos: • Las vulnerabilidades en tiempo de

Además, tenga en cuenta lo siguiente:

Firmware: compatibilidad de Requisitos: la especificación Windows • Protege frente a las posibles

Habilitar Credential Guard de Windows Defender

Agregar las características de seguridad basada en la virtualización mediante Programas y

Habilitar la seguridad basada en virtualización y Credential Guard de Windows Defender

Habilita Credential Guard de Windows Defender mediante la herramienta de preparación de hardware de

DG_Readiness_Tool_v3.5.ps1 -Enable -AutoReboot

Revisar el rendimiento de Credential Guard de Windows Defender

Deshabilitar Credential Guard de Windows Defender

copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y