Inicio > .NET Framework, C++/CLI, Resolución de problemas > Acceso denegado al actualizar propiedades del directorio activo

Acceso denegado al actualizar propiedades del directorio activo


Hace poco publiqué una entrada sobre un pequeño código para leer un usuario en un directorio activo. También comentaba que estuve apoyando a un colega con esto. Continuando con la historia, resulta que estuvimos trabajando para no solo leer el código, sino para modificarlo. Para hacer eso, utilizamos un código similar al siguiente.

try
{
    auto searcher = gcnew DirectorySearcher();            
    searcher->Filter = String::Format(L"(SAMAccountName={0})", account);
    searcher->PropertiesToLoad->Add(L"displayName");
    searcher->PropertiesToLoad->Add(L"givenname");
    searcher->PropertiesToLoad->Add(L"sn");
    searcher->PropertiesToLoad->Add(L"company");
            
    auto result = searcher->FindOne();
    if (result == nullptr)
        throw gcnew Exception(L"Usuario no encontrado.");

    auto entry = result->GetDirectoryEntry();
    entry->Properties[L"displayName"]->Value = L"Arthur Dent";
    entry->Properties[L"givenname"]->Value = L"Arthur";
    entry->Properties[L"sn"]->Value = L"Dent";
    entry->Properties[L"company"]->Value = L"Heart of Gold";
    entry->CommitChanges();
}
catch (Exception^ ex)
{
    Console::WriteLine(ex->Message);
}

En este código buscamos un usuario por su SAM AccountName, cargamos algunas propiedades y luego las modificamos. Queremos buscar a un usuario y asignarle sus nombres y la compañía en la que trabaja. Cualquiera que haya leído la documentación de MSDN puede llegar a un código como el anterior: la colección “Properties” contiene las propiedades en el directorio activo. Y el método CommitChanges hace la actualización hacia el AD.

Bien. Hasta aquí pensábamos que la vida era rosa. Ejecutamos el código y ¡BOOM! excepción: SecurityException, Access Denied. Que no panda el cúnico, nos dijimos. Seguramente es de esperar que no cualquier fulano pueda modificar al AD. Entonces probamos ejecutar la anterior aplicación con permisos de administrador.

Nada. Bueno, quizás el administrador que utilizábamos no tiene permisos de modificar el AD. Le hablamos a nuestro cliente y le pedimos que nos generara un usuario con permisos para modificar el dichoso AD.

 

try
{
    auto searcher = gcnew DirectorySearcher();            
    searcher->Filter = String::Format(L"(SAMAccountName={0})", account);
    searcher->PropertiesToLoad->Add(L"displayName");
    searcher->PropertiesToLoad->Add(L"givenname");
    searcher->PropertiesToLoad->Add(L"sn");
    searcher->PropertiesToLoad->Add(L"company");
            
    auto result = searcher->FindOne();
    if (result == nullptr)
        throw gcnew Exception(L"Usuario no encontrado.");

    auto entry = result->GetDirectoryEntry();
    entry->Username = L"my.admin";
    entry->Password = L"42";
    entry->Properties[L"displayName"]->Value = L"Arthur Dent";
    entry->Properties[L"givenname"]->Value = L"Arthur";
    entry->Properties[L"sn"]->Value = L"Dent";
    entry->Properties[L"company"]->Value = L"Heart of Gold";
    entry->CommitChanges();
}
catch (Exception^ ex)
{
    Console::WriteLine(ex->Message);
}

Como puedes ver, el código cambió un poco. Las líneas resaltadas muestran cómo pusimos el nombre de usuario y la contrasña del usuario que nos generó el cliente, con permisos para modificar el AD. Corremos el programa, y… ¡tan tan taaan! Acceso denegado.

Estuvimos explorando varias posibilidades. Hablamos con el cliente, le dijimos que seguía dando el error. Le solicitamos que pusiera al usuario que nos generó dentro del grupo de Enterprise Administratos. A lo que se negó, por supuesto. Nos explicó que lo que hizo fue delegar los permisos para que pudiera modificar propiedades, y que ya se había propagado el cambio en todo el bosque.

Frustrados, intentamos buscar más explicaciones. Hasta que en una reunión con la gente de AD del cliente, se pusieron a revisar y se dieron cuenta de que los usuarios que intentábamos modificar tenían la opción marcada para que no se replicara la delegación de permisos. Jope: eran las cuentas destino las que no podían modificarse. Bastó unos cuantos minutos para que cambiaran en el AD a esas cuentas, y todo funcionó a la perfección.

Así que, en resumen, si obtienes un acceso denegado, revisa:

1.- Impersonar con una cuenta que sí tenga permisos para modificar el AD.

2.- Que las cuentas destino tengan permisos para ser modificadas.

3.- En caso de que deleguen permisos, que las cuentas destino acepten la propagación de delegación.

4.- Si no funciona lo anterior, que el usuario ingrese al grupo de Enterprise Administrators y búscale a partir de ahí.

¡Saludos!

Anuncios
  1. Aún no hay comentarios.
  1. abril 17, 2012 en 5:07 pm
  2. abril 23, 2012 en 12:14 pm
  3. abril 25, 2012 en 12:18 am

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s