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.
Accede a los mapas desde tus aplicaciones, conecta tus soluciones con el messenger, accede a blogs programaticamente, todo esto y mucho mas con el Windows Live SDK
Windows Live SDK
The Windows Live™ Platform puts a deeper level of control into developers' hands by offering access to the core services and data through open, easily accessible APIs. Now you can build applications and mashups that combine your innovation with the power of Windows Live services and social relationships.
Visit http://dev.live.com to learn more about other services and developer offerings from Windows Live.
Windows Live Services
The following software development kits and application programming interfaces are available to Windows Live developers:
Microsoft adCenter API - The Microsoft adCenter application programming interface (API) enables you to create applications that create and manage adCenter campaigns, orders, keywords, and ads; obtain the status on orders, keywords and ads; pause and resume orders; generate keyword estimates; generate reports about campaign performance; and perform order targeting.
Windows Live™ Search Web Service API - The Windows Live™ Search Web Service is an Extensible Markup Language (XML) Web service with a SOAP API. The Search Web Service enables you to submit queries to and return results from the Windows Live Search Engine. The Search section also features articles that cover a variety of technical topics and coding techniques for the Windows Live Search developer.
Messenger Activity SDK - The Messenger Activity software development kit (SDK) contains technical information about how to develop and test single-user and multi-user applications by using the Activity object model. The SDK also provides detailed information about development and testing requirements that your Activity must meet and how to increase the usage of your Messenger Activity application.
Windows Live™ Messenger Add-In API - By creating add-ins for the Windows Live™ Messenger 8.0 client, you can add new abilities to the client. This document explains how you can create add-ins and make them available to customers. This release of the Messenger Add-in API relies on the Microsoft .NET Framework as the hosting platform. Using the Code Access Security feature of the .NET Framework, you can isolate add-ins from the system on which they run.
Windows Live™ Spaces MetaWeblog API - The MetaWeblog API programming interface enables external programs to get and set the text and attributes of Weblog posts. The API uses the XML-RPC protocol for communication between client applications and the Weblog server.
Virtual Earth Map Control SDK, Version 4.0 - Virtual Earth provides the power behind Live Maps, an online mapping service that enables users to search, discover, explore, plan, and share information about specific locations. By using traditional road maps, labeled aerial photo views, low-angle high-resolution aerial photos, and proximity searching capabilities, Virtual Earth provides unique opportunities for developers to incorporate both location and local search features into their Web applications. The Virtual Earth map control software development kit (SDK) consists of a set of conceptual topics about Virtual Earth and a complete set of reference topics that cover the Virtual Earth map control application programming interface (API). Version 3.2 of the Virtual Earth Map Control SDK is also provided to support those developers who are using the earlier version of the map control and have not yet migrated to version 4.0. In addition, the Virtual Earth section features articles that cover a wide variety of technical topics and coding techniques for the Virtual Earth developer.
Windows Live™ Alerts SDK - The Windows Live™ Alerts SDK, version 2.5, enables developers familiar with Simple Object Access Protocol (SOAP) to programmatically integrate with the Alerts notification service and perform administrative tasks that are not available using the Windows Live Alerts web site.
Windows Live™ Custom Domains SDK - The Windows Live™ Custom Domains software development kit (SDK), version 1.2, enables developers to programmatically manage their Windows Live Custom Domains user base by means of a Web service. This SDK is intended for customers and partners who want to programmatically accomplish many of the administration tasks that are available on the Windows Live Custom Domains Web site in addition to tasks that are not available on the Web site, such as importing and exporting user lists.
Windows Live™ Expo (Beta) API - The Expo API defines a set of Web services enabling customers to programmatically access the Expo classifieds listings database, a collection of location-tagged classifieds listings in categories like merchandise, real estate, autos, jobs and commercial services.
Windows Live™ ID Service - Read all about the evolution of Microsoft Passport into Windows Live™ ID and how it helps make life online better for both users and developers in this white paper, which describes the technology behind an upcoming release of a new service offering for Windows Live developers.
Windows Live™ Toolbar Custom Button SDK - The Windows Live™ Toolbar Custom Button Software Development Kit (SDK) shows how you can extend Toolbar with custom buttons. This SDK provides a quick overview of how users can install publicly available buttons and create their own simple buttons. Most of this SDK, however, shows how you can use XML to create more sophisticated custom buttons, and how you can distribute those buttons to users.
Windows Live™ Writer SDK - Two sets of APIs are provided in this beta version of the SDK: The Application API, for launching Writer to create new posts or "Blog This" items for links, snippets, images, and feed items; and the Content Source Plugin API, for extending the capabilities of Writer to insert, edit, and publish new types of content. The SDK documentation contained in this beta version of the SDK is preliminary. The documentation will be extended and improved in a subsequent release of the SDK.
Hoy en cosas interesantes: Asp.Net Ajax 1.0 y mas, Microsoft y Novell, System Center, SQL 2005 SP2, Herramienta para hacer informes de reporting services, BPMN en Visio, RSS e IE7
ASP.NET AJAX 1.0 y ASP.NET 2.0 AJAX Futures CTP de Enero de 2007
Pues al fin salio la 1.0 y como es logico toda los blogs lo cuentan, pero tambien anuncian cosas para la 2.0, Jorge Serrano añade algunas explicaciones a este pequeño lio.
Lo podeis leer en: http://geeks.ms/blogs/jorge/archive/2007/01/23/asp-net-ajax-1-0-y-asp-net-2-0-ajax-futures-ctp-de-enero-de-2007.aspx
Sitio oficial de asp.net ajax y descarga
Wal-Mart, otro cliente del acuerdo Microsoft-Novell.
Segun microsoft ya han vendido mas de 35.000 servers subscription certificates.
Leer Articulo
System Center
Nuevas noticias, se confirma que MOM 2007 saldra para finales de Marzo y que al poco saldra el Capacity Planner 2007.
El Virtual Machine Manager se retrasa hasta Q3.
Service Desk estara en beta para finales de este "quarter"
SQL 2005 SP2
Se confirma su salida para el Q12007
Y traera el SQL Server 2005 best practice analyzer que es una herramienta que nos ayudara a ver si tenemos bien configurado el SQL de acuerdo a las "buenas practicas"
Herramienta para hacer informes de Reporting Services.
En este articulo hablan bien de ella, sobre todo veo interesante que se integra con TFS y que permite reutilizar partes de informes incluso las que hayan hecho otros developers.
No es que me guste mucho usar herramientas de terceros pero la tendre que probar.
BPMN en visio.
Leer mas.
RSS en IE7
Add-In para agregar feeds y notificar los nuevos posts.
Leer mas.