|
Nueva característica
|
Descripción
|
|
No es necesaria una cuenta de equipo para iniciar sesión
en un cliente Windows XP
|
Normalmente, se necesita una cuenta de equipo para la autenticación Kerberos. Un usuario debe obtener un
ticket de servicios para el equipo para tener acceso a los recursos de éste.
Sin esta autenticación de usuario a host, el equipo
host debe realizar el control de acceso
basándose en el mapeo del nombre de usuario a un nombre que él mantiene en su
base de datos de cuentas locales. El usuario debe ejecutar KSETUP para
establecer un mapeo local.
|
|
Los Nombres de Entidades Principales de Servicios (Service Principal Names,
SPNs) ya no están normalizados.
|
Antes, los SPNs se generaban
automáticamente a partir del nombre de cuenta del Administrador de Cuentas de
Seguridad (Security Accounts Manager , SAM), por ejemplo mycomputer$.
Esto causaba problemas cuando un usuario requería un servicio con un nombre distinto,
no normalizado, ya que el sistema era incapaz de detectar que tenía un ticket
cacheado para el servicio, y por lo tanto requería un nuevo ticket de
servicio. Ahora la solución consiste en usar sencillamente el SPN que se
solicite, y no utilizar la normalización de nombres.
|
|
SPN debe configurarse como Principal de Seguridad
actuando como servicio para el Centro de Distribución de Claves (Key Distribution Center, KDC) para que pueda emitir un ticket de
servicio
|
Esto significa que el KDC no emitirá un ticket de
servicio para una cuenta que no tenga un SPN (tal como una cuenta de
usuario). El motivo de esto es que facilitaría montar un ataque mediante
diccionario de claves sin conexión contra un servicio, si dicho servicio
consistiera tan solo en una cuenta de usuario con una password
de generación humana. Para una cuenta que no tenga un SPN, el KDC devolverá
un error indicando que se requiere “Usuario-a-Usuario”.
|
|
Mejoras en la Verificación de Direcciones Cliente
|
El KDC de Windows 2000 comprobará las direcciones en los tickets, en caso de que existan. Sin embargo, el KDC de
Windows 2000 no pondrá direcciones requeridas dentro del ticket.
Por defecto, el KDC de Windows Server 2003 es compatible con los clientes
Windows 2000. El KDC de Windows Server 2003 no propagará las direcciones en
el campo AS-REQ del ticket a menos que se haga una nueva entrada de registro
(HKLM/System/CCS/Services/Kdc/KdcUseClientAddresses con
el valor de DWORD igual a 1). Cuando se presenta un ticket al Servicio de
Concesión de Tickets (ticket-granting service, TGS), se comprobará la dirección, en
caso de que exista. En Windows Server 2003 esto puede deshabilitarse
añadiendo una entrada de registro (HKLM/System/CCS/Services/Kdc/KdcDontCheckAddresses con el valor de DWORD igual a 0).
Por defecto, las direcciones se comprueban, en caso de que existan, para ser
compatible con Windows 2000.
Los administradores pueden configurar las dos nuevas características del
KDC de Windows Server 2003 añadiendo las siguientes entradas en el registro:
HKLM/System/CCS/Services/Kdc/KdcUseClientAddresses
Controla si el KDC propagará direcciones de cliente a los tickets.
|
• |
Si no existen o DWORD = 0, las direcciones cliente no
se propagarán
|
|
• |
Si DWORD = 1, las direcciones cliente se propagarán.
|
HKLM/System/CCS/Services/Kdc/KdcDontCheckAddresses
Controla si el KDC comprobará las direcciones cliente.
|
• |
Si no existen o DWORD = 0, las direcciones cliente se
comprobarán.
|
|
• |
Si DWORD = 1, las direcciones cliente no se
comprobarán
|
|
|
Soporte de la Opción Números de Versión de Claves
|
Los números de versión de claves son una parte opcional de la especificación
Kerberos. Se pueden incluir como parte de los datos cifrados de Kerberos,
cuando dichos datos están cifrados con una clave de larga vida. Windows
Server 2003 introduce el uso de números de versión de claves.
|
|
Selección del tipo de cifrado
|
En Windows 2000, el KDC selecciona el primer tipo de
cifrado. En Windows Server 2003, el KDC selecciona el tipo de cifrado más
potente soportado por el cliente.
|
|
Renovación del Ticket de concesión de tickets
(Ticket Granting Ticket, TGT) con
Windows XP y Windows 2000 con SP2 o posterior
|
El TGT tiene un tiempo de vida por defecto de 10 horas,
pero se puede renovar hasta siete días (por defecto). La renovación no
requiere credenciales. La renovación sólo se producirá si se utiliza el TGT
en los 5 últimos minutos antes de su caducidad. De lo contrario, el TGT
caducará y tendrá que ser refrescado (lo que requiere credenciales).
|
|
Renovación del TGT con Windows Server 2003
|
El TGT tiene un tiempo de vida por defecto de 10 horas,
pero se puede renovar hasta siete días (por defecto). La renovación no
requiere credenciales. La renovación se producirá a través de un proceso de
eliminación de registros obsoletos (scavenging)
en la máquina. Si
por alguna razón el TGT no pudo renovarse, caducará y tendrá que ser
refrescado (lo que requiere credenciales).
En Windows XP y Windows 2000 con SP2 o posterior, la renovación
del TGT se lanzará si se utiliza el TGT en los 5 últimos minutos antes de su
caducidad.
En Windows Server 2003, el sistema renovará de forma periódica y
automáticamente las TGTs que estén expirando.
|
|
Delegación restringida
|
Kerberos ha proporcionado
siempre el mecanismo para permitir a un cliente delegar su ticket de
concesión de tickets a un servidor intermediario.
Esto debería permitir al intermediario obtener tickets
de servicio para otros servicios en nombre del cliente. Por ejemplo, tal
delegación permite a un intermediario en un escenario de tres niveles asumir
el papel del cliente en una aplicación final. Sin embargo, este mecanismo
permite al intermediario obtener tickets para
cualquier servicio de la misma forma que el cliente. La delegación
restringida es una característica de Windows Server 2003 a través de la cual
el controlador de dominios emitirá tickets a un
intermediario sólo para aquellos servicios de los que el intermediario esté
autorizado a obtener tickets delegados (tal y como
lo determine la política administrativa). Por lo tanto, la capacidad de
delegación de un intermediario está restringida por la política
administrativa.
|
|
Delegación restringida con transición de protocolos
|
La transición de protocolos es una característica que
permite a un intermediario solicitar un ticket sin necesidad de que el
cliente se autentique inicialmente con la autenticación Kerberos. Por lo tanto, un cliente
podría usar la Capa
Segura de Sockets (Secure Sockets Layer, SSL) para autenticar a un intermediario y el
intermediario usaría autenticación Kerberos para
finalizar la aplicación.
Para más detalles consulte
Transición de Protocolos Kerberos y Delegación Restringida (en inglés).
|
|
Relaciones de confianza entre bosques
|
Muchas organizaciones implantan múltiples bosques pero
necesitan colaboración con bosques de diferentes organizaciones. Cuando esto
ocurre, el establecimiento de una relación de confianza externa requiere una
enorme cantidad de administración y no utiliza los últimos avances
tecnológicos. Windows Server 2003 introduce el concepto de confianza entre
bosques para facilitar las implantaciones de múltiples bosques. La confianza
entre bosques permite a los administradores federar dos bosques del
Directorio Activo con una única relación de confianza para proporcionar una
sensación de autenticación y autorización entre bosques completamente
integrada.
Para más detalles, consulte
Planificación
e Implantación de bosques federados en Windows Server 2003.
|
