Active Directory

Descripción de autenticación de proxy en AD LDS

Ken St. Cyr

En resumen:

• Definición de autenticación proxy
• ¿Por qué es útil autenticación proxy
• En el objeto de proxy
• Lo que sucede durante authenticationItem

Contenido

¿Qué es la autenticación de proxy?
Ventajas de autenticación proxy
Dentro del objeto de proxy
Cómo se realizan la autenticación estrictamente
Configurar un laboratorio de autenticación proxy
Conclusión

Como con cualquier servicio de directorio LDAP-habilitado, servicios de directorio de compacto de Microsoft Active Directory (AD LDS, antiguamente llamada ADAM) requiere un usuario enlazar antes de ejecutar las operaciones LDAP en el directorio. Este enlace puede realizarse a través de unos pocos métodos diferentes, incluidos un enlace LDAP sencillo, una autenticación simple y enlace de seguridad (SASL) o incluso la redirección del enlace. El enlace también podría ser anónimo, en cuyo caso el usuario presenta una contraseña nula. En este artículo, voy a explicar y analizar un método concreto, enlace redirección, en caso contrario, conocido como autenticación proxy.

¿Qué es la autenticación de proxy?

Autenticación proxy permite a un usuario realice un enlace sencillo a una instancia de AD LDS, manteniendo una asociación a una cuenta de Active Directory. Dos cuentas participan en la transacción. El primero es un objeto especial en AD LDS como un objeto de userProxy. El segundo es la cuenta del usuario en Active Directory.

El objeto de userProxy AD LDS es una representación de la cuenta de Active Directory. El objeto de proxy está vinculado a la cuenta Active Directory a través del identificador de seguridad (SID) que cuenta. No hay ninguna contraseña almacenada en el propio objeto de proxy real.

Cuando un usuario realiza un enlace sencillo a una instancia LDS con un objeto de proxy, el enlace se redirige a Active Directory pasando el SID y una contraseña a un controlador de dominio. El servidor AD LDS realiza la autenticación y todo el proceso es invisible para el usuario final. Esto se muestra en la figura 1 , donde en que Lucy es conectar a una instancia de AD LDS denominada " CN = AppDir,DC = contoso, DC = com " con su cuenta de usuario AD LDS.

La figura 1 la conexión con AD LDS (haga clic en la imagen de una vista más grande)

Para la autenticación, Lucy está utilizando un enlace sencillo y proporciona su nombre distintivo (DN) y la contraseña como que haría en un enlace LDAP normal. Aunque Lucy aparentemente se conecta con su cuenta de usuario LDS típica, mediante realmente un objeto de proxy. La autenticación en Active Directory está ocurriendo en segundo plano y Lucy tiene pistas que realmente del usando su cuenta de Active Directory que se va a enlazar.

Ventajas de autenticación proxy

El poder de autenticación proxy reside en dar a los desarrolladores de aplicaciones acceso a un objeto de usuario sin que se les da acceso a la cuenta de Active Directory. Considere qué pasa cuando se está generando una nueva aplicación habilitadas para directorios y la aplicación necesita almacenar algunos datos en Active Directory. La aplicación puede utilizar un atributo existente o crear uno nuevo.

El peligro mediante un atributo existente sin utilizar es que el atributo es probable que no existe para otro propósito. Incluso si es sin utilizar ahora, podría utilizarse en el futuro; si se utiliza para algunos propósito diferente, los administradores tendrían para realizar un seguimiento de cómo se se utiliza Active Directory. Y ¿qué ocurre si el desarrollador de aplicación necesita más de un atributo?

Con la autenticación de proxy, una representación del objeto de usuario de Active Directory existe en el directorio de AD LDS. Un directorio específico de la aplicación permite al desarrollador aplicación modificar el esquema de alguna manera que desea en el contexto de AD LDS. Los atributos pueden agregarse, cambiar o reutilizar en cualquier forma que el programador elige y el administrador no tiene que preocuparse realicen varios cambios de esquema o realizar el seguimiento de cómo se utilizan los atributos de Active Directory. Si otra aplicación procede en línea y desea utilizar el mismo atributo, no es un problema porque puede ser una instancia de AD LDS independiente y no tendrá conflictos de atributo.

Autenticación proxy también puede ser útil en situaciones que requieren el formato X.500. Active Directory no utiliza nomenclatura X.500 típica de nombres. Por ejemplo, un objeto de usuario en Active Directory tiene el nombre COMPLETO " CN = Lucy D. Smith, CN = Users, DC = contoso, DC = com ". Sin embargo, en AD LDS, nombre COMPLETO del usuario podría ser " CN = Lucy D. Smith, CN = Users, O = contoso, C = US ", que es compatible con X.500.

Esto resulta útil cuando estás utilizando un cliente LDAP de otros fabricantes o intenta integrar con un directorio de terceros que requiere el formato X.500. De este modo, LDS puede ser un directorio intermediario entre un directorio de terceros y Active Directory. Utilizar la autenticación proxy, la cuenta de servicio que debe usar para enlazar a la instancia LDS el directorio de otros fabricantes se puede almacenar en Active Directory en lugar de LDS propio.

Dentro del objeto de proxy

Hasta ahora ha proporcionado una breve descripción de la forma en que el objeto de proxy LDS está vinculado a la cuenta de usuario de Active Directory. Ahora VOY mirar esto con más detalle y examinar lo que sucede realmente en segundo plano, comenzando con la clase de objeto.

En Windows Server 2008, el directorio %SYSTEMROOT%\ADAM contiene dos archivos LDF que representa un objeto proxy:

• MS-UserProxy.LDF
• MS-UserProxyFull.LDF

MS-UserProxy.LDF contiene la definición de la clase userProxy simple, que tiene atributos básicos y contiene la clase auxiliar msDS-BindProxy. MS-UserProxyFull.LDF contiene la msDS-BindProxy clase auxiliar así, pero también pre-populates atributos de usuario adicionales en el atributo mayContain de la clase. A causa de ello, las clases de atributo tiene que existir con antelación. Por lo que al importar la clase userProxyFull, el usuario o inetOrgPerson clase es necesario que se va a importar en primer lugar. Usuario y inetOrgPerson contienen el atributo definiciones de clase para los atributos que userProxyFull utiliza. la figura 2 muestra las diferencias entre la clase userProxy y la clase de userProxyFull.

La Figura 2 las clases userProxy y userProxyFull (haga clic en la imagen de una vista más grande)

El hecho de que ambas clases contienen msDS-BindProxy como una clase auxiliar es importante. Una clase auxiliar es un tipo de clase que puede proporcionar datos adicionales a una clase estructural. En LDS, por ejemplo, la clase de usuario es una clase estructural que se hereda de la clase de persona, organización, lo que significa que la clase de usuario tiene todo lo que la clase de persona de la organización tiene. Pero la clase de usuario también tiene una clase auxiliar llamada msDS-BindableObject, lo que significa usuario contiene todos los atributos obligatorios y opcionales de msDS-BindableObject junto con los atributos de la clase de persona de la organización. En este caso, uso msDS-Bindable­Object como una clase auxiliar hace la clase de usuario enlazable.

Puesto que la clase userProxy tiene msDS-BindProxy como una clase auxiliar (vea figura 3 ), ahora también contiene los atributos obligatorios y opcionales todo conjunto de msDS-BindProxy. La clase auxiliar de msDS-BindProxy es lo que convierte un objeto en un objeto proxy. Por lo que incluso si tiene una clase personalizada, puede agregar la clase auxiliar msDS-BindProxy y utilizar los objetos personalizados para autenticación de proxy.

La figura 3 crear una proxyobject (haga clic en la imagen de una vista más grande)

Si desea examinar la clase msDS-BindProxy, se Observe que hay sólo un atributo obligatorio definido, objectSID. Éste es el atributo que el SID de la cuenta de usuario de Active Directory se situarán en para crear la asociación entre el objeto de proxy en LDS y el objeto de usuario en Active Directory. Este atributo sólo puede rellenarse cuando se crea el objeto. No se puede cambiar sin eliminar el objeto y volver a crear.

Cómo se realizan la autenticación estrictamente

Para entender realmente lo que sucede en segundo plano, necesitaremos entra un poco más profunda en cómo se realiza la autenticación. Le guiará por dos trazas de red que ayudarán a mostrar cómo funciona la autenticación proxy. La primera traza es una captura de red de enlace simple un usuario proxy en una estación de trabajo de Windows XP a una instancia de Windows Server 2008 LDS. En esta captura, Lucy enlaza con el objeto de usuario de proxy utilizando LDP.EXE desde su estación de trabajo.

Figura 4 muestra los tres paquetes en la captura que se debe examinar. Paquete 1 es la solicitud de enlace desde la estación de trabajo (10.0.0.107) para el servidor LDS de Active Directory (10.0.0.201). La solicitud de enlace contiene nombre COMPLETO de Lucy, " cn = lucy, cn = usuarios, cn = appdir, dc = contoso, dc = com ". Paquete 2 es la respuesta del servidor LDS de Active Directory en la estación de trabajo, que indica un enlace correctamente. Y paquete 3 es la confirmación en la estación de trabajo al servidor LDS de Active Directory, que indica la confirmación de la respuesta de enlace.

La figura 4 enlazar solicitud y respuesta (haga clic en la imagen de una vista más grande)

Si cavar en los detalles del paquete 1 (consulte figura 5 ), verá algo sorprendente. La contraseña que Lucy suministrada (P@ssw0rd) se muestra en texto no cifrado en la captura. Esto es, en realidad, uno de los problemas de utilizar un enlace LDAP simple para la autenticación. A menos que el enlace se ajusta en el cifrado SSL, la contraseña del usuario se se anuncian a cualquier persona a la escucha en la red.

La figura 5 enlace simple con SSL desactivado (haga clic en la imagen de una vista más grande)

LDS de Active Directory habilitar SSL de forma predeterminada, sin embargo. Tendrá que salga de la forma de desactivarla, que es exactamente lo que hizo para este ejercicio para realizar la traza de red puede leer. Y me no tendría que molestar para asignar un certificado al servidor LDS de Active Directory, pero en una implementación real, absolutamente desea asegurarse de que el servidor LDS de Active Directory tiene un certificado válido que puede utilizarse para SSL.

El seguimiento de la segundo es una captura de red desde el servidor LDS de Active Directory en el controlador de dominio (DC). Este seguimiento es un poco mayor que el primero, por lo que va dividir hacia arriba en fragmentos. Los paquetes en primer lugar 9 de este seguimiento se muestran en la figura 6 .

Figura 6 AD LDS conectar con el controlador de dominio (haga clic en la imagen de una vista más grande)

El primer paquete debe resultarle familiar para usted. Se trata de la solicitud enlace entrante desde la estación de trabajo. De nuevo, este paquete contiene nombre COMPLETO del Lucy y una contraseña en texto sin cifrar. Paquetes de 2 a 9 muestran el servidor AD LDS (10.0.0.201) que se conecta al controlador de dominio (10.0.0.200). Esto se compone de algunos mensajes de protocolo (ARP) de resolución de dirección seguidas de una conexión de la llamada a (RPC) de procedimiento remoto en el controlador de dominio.

En la figura 7 , paquetes 10 y 11 llamar a un método denominado LsarLookupSids3, una llamada RPC que indica el controlador de dominio para hacer un lote de los SID y devolver sus correspondientes nombres. El servidor de AD LDS realiza la solicitud en el paquete 10 y recibe la respuesta desde el controlador de dominio en el paquete 11.

La figura 7 intento de autenticación Kerberos (haga clic en la imagen de una vista más grande)

A continuación, después de un enlace TCP breve para iniciar la sesión de Kerberos (12–14 paquetes), en paquete 15 el AD LDS servidor intenta obtener el vale de servicio de autenticación (AS REQ) desde el Centro de distribución de claves (KDC). En el paquete 16, se deniega la solicitud de vale de servicio de autenticación porque el controlador de dominio está esperando algunos autenticación previa datos que no proporcionan el servidor AD LDS. En este caso, el controlador de dominio desea la marca de tiempo para que pueda utilizarse para la comprobación de identidades. La sesión de Kerberos extremos y un restablecimiento se solicita (17–19 paquetes).

la figura 8 muestra el resto de la captura. Los paquetes 20–22 establecer una nueva sesión de Kerberos y una nueva solicitud de servicio de autenticación se envía desde el servidor AD LDS al controlador de dominio en el paquete 23. Esta nueva solicitud contiene los datos necesarios de autenticación previa, indicados por la respuesta correcta desde el controlador de dominio en el paquete 25. El servidor AD LDS ahora tiene el vale de servicio de autenticación y puede colocar una solicitud para el vale de concesión de servicio para autenticar las credenciales de Lucy.

Figura 8 autenticación correcta (haga clic en la imagen de una vista más grande)

El vale de concesión de solicitud de servicio y la respuesta se capturan en paquetes 33 y 34. La recepción de la KRB_TGS_REP en paquete 34 indica que Lucy está autenticada correctamente. Por último, en paquete 38 el servidor AD LDS pasa la respuesta de enlace vuelve a la estación de trabajo, permitiendo que Lucy saber que ella correctamente ha enlazado a la instancia AD LDS. Aunque este proceso implica varios pasos, el tiempo total para esta transacción completa sólo es aproximadamente 1 y 10 de un segundo.

¿Qué ocurriría si Lucy introduce la contraseña incorrecta? En nuestro ejemplo, la solicitud de servicio de autenticación podría fallar en paquetes 25. El error de la solicitud de servicio de autenticación podría indicar al servidor AD LDS que las credenciales de Lucy eran incorrectas. En lugar de emitir una solicitud al vale de concesión de servicio, el servidor AD LDS podría emitir una respuesta de enlace vuelve a la estación de trabajo, que indica que las credenciales no eran válidas.

Éste es un recap de ¿qué ha ocurrido en el intercambio correcto:

1. La estación de trabajo envía una solicitud y enlazarlo al servidor AD LDS.
2. El servidor AD LDS establece una conexión con el controlador de dominio.
3. El servidor AD LDS solicita el controlador de dominio para traducir de Lucy SID en un identificador que puede utilizar para la autenticación.
4. El controlador de dominio proporciona Id. de AD LDS servidor Lucy
5. El servidor AD LDS obtiene un vale de concesión de vales (TGT) desde el controlador de dominio con Id. de Lucy
6. El servidor AD LDS obtiene un vale de sesión a sí mismo con etiqueta TGT. de Lucy
7. El servidor AD LDS envía una respuesta de enlazar correctamente volver a la estación de trabajo.

Este proceso muestra que la conexión desde la estación de trabajo con el servidor AD LDS es una transacción de enlace LDAP estándar. A continuación, desde el servidor AD LDS al controlador de dominio, se utiliza Kerberos para autenticar de forma segura al usuario.

Configurar un laboratorio de autenticación proxy

Ahora que sabe cómo funciona la autenticación proxy, veamos cómo puede configurar esto en un entorno de laboratorio. Tenga en cuenta que para este ejercicio, le va deshabilitar el requisito de SSL en la autenticación de proxy. Como mencioné anteriormente, sin embargo, recuerde que no debe deshabilitar este requisito en una implementación de la vida real.

Antes de empezar, necesitará un dominio completamente funcional con un servidor de miembro de Windows Server 2008 y una estación de trabajo unirse a él. El servidor miembro Windows Server 2008 ejecutará AD LDS, y la estación de trabajo será el extremo del cliente. La ventaja de separación de estos equipos es que puede realizar capturas de red de la interacción entre ellos. Para configurar el laboratorio, le recorrer los siguientes pasos:

• Instalar AD LDS en el servidor miembro.
• Deshabilitar el requisito de SSL para autenticación proxy.
• Importar la clase userProxy en el esquema de AD LDS.
• Crear el objeto de proxy y asignar permisos a ella.
• Enlazar con el directorio de AD LDS con el objeto proxy.

El primer paso es instalar AD LDS en el servidor de miembro de Windows Server 2008. En el administrador de servidor, encontrará la opción de instalar LDS en el Asistente de "agregar funciones". Una vez instalada la función, una opción nueva aparecerá en el menú Herramientas administrativas que se llama al Asistente para de Active Directory ligero Active servicios de instalación. Utilice este asistente para crear una nueva instancia LDS.

Cuando se le solicite el nombre de la partición de aplicación, escriba cualquier nombre COMPLETO le gustaría. Recuerde que LDS admite nombres de X.500, por lo que no está limitado a usar un " controlador de dominio = " nombre del estilo. En mis ejemplos, utiliza " cn = appdir, dc = contoso, dc = com ", pero ha puede utilizar también " cn = appdir, o = contoso, c = us ".

Una vez instalada la instancia AD LDS, el paso siguiente es deshabilitar el requisito de SSL para autenticación proxy. En el Edición de ADSI complemento (adsiedit.msc), debe conectarse a la partición de configuración de la instancia de AD LDS utilizando la cuenta de administrador que especificó durante la instalación. Si desconoce el DN de la partición de configuración, puede elegir "configuración" en la lista "Seleccione un contexto de nomenclatura conocido" desplegable en el cuadro de diálogo Configuración de conexión de edición de ADSI.

Busque el contenedor " CN = Directory Service, CN = Windows NT, CN = Services, CN = Configuration, CN = {guid} " y abrir el cuadro de diálogo Propiedades de la " CN = Directory Service " contenedor. Hay un atributo de cadena de valor múltiple en la lista atributo denominado msDS-otros-configuración que muestra varias cadenas, cada uno que indica una configuración diferente de la instancia AD LDS. Edite este atributo y cambie la cadena "RequireSecureProxyBind" a un valor de 0.

El siguiente paso consiste en importar la definición de clase de esquema de la clase userProxy. Es posible que ha ya importado, cuando se le pida que hacerlo en el Asistente de AD LDS. Si es así, puede omitir este paso. Si se ha no ya importarlo, hacerlo con el siguiente comando LDIFDE.exe. Asegúrese de que especifica el nombre del servidor AD LDS y el puerto correcto en el comando:

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

Ahora que la clase de objeto se importan, puede crearse el objeto proxy. Va usar LDP.EXE, pero podría usar otra herramienta o algún método mediante programación. Mediante LDP, se conectarse a la instancia AD LDS y se enlaza con tus credenciales de administrador. Busque el DN de la instancia AD LDS y a continuación, seleccione el contenedor en el que desea crear el objeto de proxy. Haga clic con el botón secundario del mouse en el contenedor y elija Agregar elemento secundario en la lista desplegable. En el cuadro de diálogo Agregar, deberá especificar el DN del nuevo objeto de proxy en el campo Nombre COMPLETO. Por ejemplo, se puede utilizar " cn = lucy, cn = appdir, o = contoso, c = us ".

También tendrá que crear dos atributos con este objeto. El primero es objectClass, que indica el tipo de objeto que se va a crear. El valor para este ejemplo debe ser userProxy. Colocar esta información en la sección Editar entrada de cuadro de diálogo y haga clic en el botón ENTRAR.

El atributo segundo para agregar es objectSID, que contiene el SID de la cuenta de usuario de Active Directory con el que está asociado este objeto de proxy. Este SID se puede obtener con una variedad de métodos, pero PUEDO sólo está conectado a Active Directory en una instancia LDP independiente y copia el atributo objectSID de la cuenta de usuario no existe. Después de escribir esta información, el cuadro de diálogo Agregar debe ser similar a figura 9 . Por último, haga clic en el botón de ejecución para confirmar el cambio.

Figura 9 crear un objeto de proxy

Para poder utilizar el objeto proxy que acaba de crear, necesitará para darle algunos permisos. Puede hacerlo fácilmente mediante la selección el " CN = lectores " objeto en el " CN = funciones " contenedor en LDP. Haga clic con el botón secundario del mouse y elija Modificar en la lista desplegable. Agregar un atributo denominado miembro y para el valor, escriba el DN del objeto userProxy que ha creado. No se olvide de clic en el botón de entrar antes de hacer clic en Ejecutar. Ahora el objeto userProxy debe ser miembro del grupo lectores en la instancia LDS.

Todo lo que debe configurarse, por lo que ahora puede probar la autenticación de proxy. Abra una nueva instancia de LDP y conéctese al servidor AD LDS. Esta vez, sin embargo, cuando se enlaza a la instancia, seleccione el enlace simple y escriba el DN del objeto proxy en el campo de nombre de usuario. La contraseña, escriba la contraseña de cuenta vinculado este proxy objeto a Active Directory. Haga clic en ACEPTAR y ahora se debe enlazado a la instancia en modo de sólo lectura.

Dedicar algún tiempo a tomar trazas de red y probar los métodos de enlace diferentes. Podría ser un ejercicio activar SSL y tomar una captura del proceso de enlace LDAP, a continuación. Puede incluso deliberadamente escriba un nombre de usuario o la contraseña y vea qué sucede al proceso de autenticación.

Conclusión

No se alarmed a través de la dificultad del uso de autenticación proxy. Tardó el enfoque de demostrar este proceso con LDP y edición de ADSI ya que proporciona un mejor aspecto en segundo plano. Causa de eso, el ejemplo recorre mediante aquí ilustra autenticación proxy desde una perspectiva muy práctica.

En la práctica, el largo proceso de creación objetos userProxy y manipularlos es codificado normalmente a través de un sistema de administración de identidades o un desarrollado personalizado-cliente para la creación de cuentas. LO animo a crear su propio laboratorio LDS y ver para usted mismo cómo puede usar la autenticación de servidor proxy para integrar los directorios de otros fabricantes y aplicaciones.

Ken ST. Cyr es un consultor de Microsoft y ha diseñado e implementado soluciones de directorio basadas en Active Directory desde sus inicios. Recientemente se uno de los primeros para lograr la certificación Microsoft Certified principal para servicios de directorio. Póngase en contacto con él en Ken.stcyr@Microsoft.com.