Crea y edita tus propiedades personalizadas en el Directorio Activo.
En este artículo aprenderás cosas acerca del esquema y de algunos aspectos del funcionamiento interno del AD, crearemos una nueva propiedad para los usuarios y aprenderemos como extender la administración para poder utilizarla.
Introducción
Cada objeto que almacenamos en el directorio activo ya sea por ejemplo un usuario o un ordenador tiene una serie de propiedades que son las que nos permiten a nosotros y al Directorio Activo almacenar información relativa al objeto en cuestión, como por ejemplo los grupos a los que pertenece un usuario, la fecha en la que expira la cuenta o en que servidor de Exchange tiene su buzón un usuario.
Las propiedades que tiene un objeto están definidas en la “Clase”, a las propiedades se las llama atributos.
Cuando creamos un nuevo usuario en el Directorio Activo, en realidad estamos creando una instancia de la clase “User”, la clase contiene información relativa a todos los atributos que son necesarios para guardar toda la información de un usuarios en el AD, como la contraseña, el nombre, etc, la clase también define que atributos son obligatorios y cuáles no.
Las clases pueden heredar unas de otras, por ejemplo aunque nos parezca increíble, la clase “Computer” que es la que define a los objetos de los ordenadores que estén en el AD hereda de la clase “User”, cuando una clase hereda automáticamente contiene los mismos atributos y con la misma configuración que la clase de la que hereda, además se pueden añadir nuevos atributos.
Toda la información sobre las clases y los atributos se encuentra en el esquema que está almacenado en una partición especial del directorio activo.
Esta partición se replica a todos los controladores de dominio, pero solo puede ser modificada por el controlador de dominio que sostiene el rol de Maestro de esquema o Schema Master.
Para poder modificar el esquema es necesario pertenecer al grupo de usuarios Enterprise Admins o Schema Admins.
Modificar el esquema es una operación muy seria y delicada, antes de realizar una modificación en el esquema hay que probarla bien en un entorno de pruebas, yo recomiendo siempre hacer estos cambios con un script ya que podemos ejecutar el mismo script en una maquina de desarrollo y luego en producción si todo va bien.
Los cambios que hagamos en el esquema no se pueden borrar del todo, aunque es posible deshabilitar clases o borrar atributos.
Encuentro muy práctico realizar las pruebas con una maquina virtual, ya que se puede configurar esta para que no guarde los cambios cuando se reinicia, de forma que si tienes que repetir algo no tengas que hacer un DC de nuevo o copiar otra máquina virtual.
Explorando el Esquema.
Para poder ver la definición de las clases necesitamos acceder a la consola de administración del esquema, para hacer esto tenemos que registrar la DLL “schmmgmt.dll”.
Imagen 1, registrando la DLL.
Imagen 2, Mensaje de confirmación del registro de la DLL.
Una vez registrada la DLL lo siguiente será ejecutar la consola, para ello accederemos a la MMC y añadiremos la consola de
Imagen 3, Ejecutando la MMC.
Imagen 4, Añadiendo la consola.
Imagen 5, Añadiendo la consola.
Imagen 6, Añadiendo la consola.
Imagen 7, Atributos y clases.
Imagen 8, Clases.
Imagen 9, Atributos.
Imagen 10, Definición de la clase User (Ficha General).
Veis que la clase tiene un atributo llamado OID, por simplificar diré que este OID es un número único que se usa para identificar las clases, este número se genera con una utilidad llamada oidgen que podéis encontrar en el resource kit de Windows 2000.
Imagen 11, Definición de la clase User (atributos)
En el tab de Attributes podéis ver todas las propiedades que tiene la clase User.
En el Tab de Relationships veréis que clases pueden contener instancias de este objeto.
Imagen 12, Definición de la clase User (atributos).
Imagen 13, Propiedades de un atributo.
A parte del OID del que ya hemos hablado en explicación sobre las clases y que funciona igual en los atributos, nos podemos encontrar con alguna información muy interesante, tal como el tipo de atributo que es este caso es “Unicode String”, cadena de caracteres Unicode y el largo mínimo y máximo que puede tener.
Como sabéis el catalogo global no contiene todos los atributos de los objetos, solo contiene los atributos más usados, a este grupo de atributos se le llama PAS (partial attribute set), el catalogo global contiene estos atributos pero de todos los dominios, por esa razón en las empresas en las que hay varios dominios, es común que se realicen búsquedas sobre los GC, si queremos que un atributo especifico este replicado en los GC, tendremos que activar el check “Replicate tis attribute to the Global Catalog”
Hay que ser conservador a la hora de añadir atributos a la PAS pues si añadimos muchos afectaremos a la replicación, aunque esta consideración solo tiene sentido si tenemos grandes volúmenes de usuarios y también hay que analizar la capacidad de las líneas de comunicaciones, el numero de cambios que se hagan al día, las ventanas de replicación, etc.
Alguno de los otros checks como por ejemplo el de búsquedas ANR nos permiten modificar la forma en la que se indexara este atributo en las diferentes tipos de búsquedas.
¿Quién es el Schema Master?
Podemos saber quién es el schema master de varias maneras.
La primera es desde la consola de administración del esquema.
Imagen 14, Averiguando quien es el Schema Master.
Imagen 15, Viendo el Schema Master.
Fijaros que desde aquí también es posible especificar que servidor es el schama master, pudiéndolo cambiar en cualquier momento.
También podemos modificar quien es el Schema Master desde el comando NTDSutil.
Imagen 16, NTDSutil.
Modificando el esquema del AD.
Como ejemplo vamos a añadir una nueva propiedad a la clase user, esta nueva propiedad la usaremos para almacenar el Nº del documento nacional de identidad del usuario.
Es importante que antes de modificar el esquema para añadir un atributo a una clase, investiguéis bien la clase por si hay algún atributo que os valga, por ejemplo los objetos de tipo user tienen un atributo denominado EmployeeID que vale para poner el numero de empleado en recursos humanos de la empresa, si no usáis este campo para esa función, os puede valer para guardar el DNI.
El primer paso será generar un OID valido con la herramienta OIDGen del Resource Kit, en nuestro caso será: 1.2.840.113556.1.4.7000.233.28688.28684.8.416449.1243815.479696.960415
Imagen 17, Creando el nuevo atributo.
Imagen 18, Aviso.
Imagen 19, Creando el atributo.
Los atributos marcados como multivalue son en realidad Arrays unidimensionales, por ejemplo el campo de direcciones de correo de un usuario es multivalue.
Imagen 20, Atributo DNI ya creado.
El paso siguiente será modificar la clase User para que contenga este atributo.
Imagen 21, Añadiendo el DNI a la clase User.
Imagen 22, Añadiendo el DNI a la clase User.
Imagen 23, Añadiendo el DNI a la clase User.
Comprobando que hemos añadido la propiedad correctamente.
Desgraciadamente cuando añadimos un atributo a una clase, este atributo no está disponible desde la administración común de estos objetos.
Por lo tanto aunque hemos añadido el DNI a la clase user, si editamos un usuario desde la consola de usuarios y computadoras, no veremos dicho atributo, al final de este artículo os mostrare una sencilla solución a este problema.
Lo que sí es posible es usar la consola de edición del Directorio Activo (adsiedit.msc) para ver y editar las propiedades de un usuario, para poder usar esta consola tendréis que instalar las support tools de Windows 2003.
Yo siempre recomiendo que las support tools y el resource kit vayan instaladas en todos los servidores, pero eso es parte de otro artículo que algún día hare, podeis bajar las support tools de:
http://www.microsoft.com/downloads/details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en
Imagen 24, Añadiremos la consola como hemos aprendido antes.
Imagen 25, Conectándonos al AD desde el ADSI Edit.
Imagen 26, Conectándonos al AD desde el ADSI Edit.
Imagen 27, Refrescando el cache del esquema tras conectarnos.
Imagen 28, Viendo las propiedades de un usuario.
Imagen 29, Editando el DNI del usuario.
Imagen 30, Editando el DNI del usuario.
El secreto de los Display Specifiers.
Bien, por supuesto, este proceso de edición no es demasiado rápido y no sería muy práctico que los operadores tuvieran que usar ADSIEdit para mantener el directorio por esa razón, vamos a usar un pequeño truco del Directorio Activo para facilitar el proceso de edición.
Vamos a modificar el menú contextual del objeto user dentro de la consola de usuarios y computadoras para que incluya una opción que nos permita editar el DNI del usuario.
El primer paso será crear un script que nos permita editar el DNI.
Si tuviéramos más atributos o quisiéramos poner combos para elegir los valores o un interfaz más rico podríamos usar un script HTA.
Los scripts HTA son scripts normales VBS pero que exponen un interfaz Windows, este interfaz se diseña usando HTML, otro día pondré un articulo enseñando como se haría este mismo script pero con PowerShell, pero es más complicado porque en vez de usar HTML hay que poner los controles a mano usando el espacio de nombres de Windows Forms de .Net.
El script que usaremos será muy sencillo:
‘***************************************************************************************
On Error resume next
Dim oemployeeID
Dim oUser
Dim temp
Set StrArgs = Wscript.Arguments
Set oUser = GetObject(StrArgs(0))
temp = InputBox(«DNI: » & oUser.DNI & vbCRLF & vbCRLF & «Si quieres introducir un nuevo DNI o modificar el existente, introduce el nuevo número en la caja de texto.»)
if temp <> «» then oUser.Put «DNI»,temp
oUser.SetInfo
Set oUser = Nothing
Set StrArgs = Nothing
Set temp = Nothing
WScript.Quit
‘***************************************************************************************
En este ejemplo guardare el script con el nombre DS_DNI.vbs en una carpeta llamada c:scripts.
El siguiente paso será conectarnos con AdsiEdit pero esta vez en vez de a la partición de Dominio nos conectaremos a la partición de configuración.
Imagen 31, Conectando AdsiEdit a la partición de configuración.
Una vez conectados a la partición de configuración veremos una unidad organizativa llamada “Display Specifiers”, entraremos en ella y veremos una OU por cada idioma, tenemos que modificar los Display Specifiers del idioma en el que este la consola de Usuarios y Computadoras que vallamos a usar, como normalmente todos instalamos los sistemas en ingles, usare la 409 que es la de este idioma.
Dentro de la OU 409 editaremos las propiedades del objeto User-Display
Imagen 32, Editando el objeto User-Display.
El objeto User-Display controla los menús contextuales y otras comportamientos gráficos de las instancias de la clase User a lo largo de todo Windows, la propiedad “adminContextMenu” se encarga del menú contextual de administración que es el que nos aparece en la cosa de usuarios y computadaros.
Tendremos que editar esa propiedad “adminContextMenu“y añadir una nueva línea que apunte a nuestro script.
Imagen 33, Editando la propiedad “adminContextMenu“.
Cada línea tiene que tener un numero identificador, luego pondremos el nombre que queremos que salga en el menú precedido de “&” y finalmente la ruta del script.
Imagen 34, Viendo el menú contextual de cualquier usuario.
Imagen 35, Script corriendo tras pulsar en DNI.
Imagen 36, Script corriendo por segunda vez.
Conclusión
En este articulo habéis visto como extender el schema y crear un Display Specifier para ayudaros a resolver una necesidad de administración, algo tan simple como guardar el DNI de los usuarios es un aspecto clave dentro de toda administración evolucionada.
Pensar que un usuario del que no sabéis su DNI no es nadie, es solo un nombre, mientras que con el DNI es posible una integración con el sistema de nominas, lo cual tras varias iteraciones de automatización puede llegar a sinergias tan importantes como las bajas y altas automáticas o el control de errores, pero eso otro artículo.
