Las aplicaciones que usan NetUserGetInfo y las API similares dependen del acceso de lectura a determinados objetos de AD.
En este artículo se describe un problema en el que las aplicaciones que usan API de nivel descendente de la clase NetUser o NetGroup como NetUserGetInfo
o NetGroupGetInfo
producen un error con el error ACCESS DENIED.
Número de KB original: 2281774
Resumen
Tiene una aplicación que usa las API de nivel descendente de la clase NetUser o NetGroup, como NetUserGetInfo
, NetUserSetInfo
, , NetUserEnum
NetGroupGetInfo
, NetGroupSetInfo
, NetGroupEnum
, NetLocalGroupGetInfo
, NetLocalGroupSetInfo
y NetLocalGroupEnum
. En este esquema, las API de clase NetUser también se usan para administrar la cuenta de equipo.
Las mismas API se usan al invocar el proveedor WINNT ADSI.
Estas API pueden producir un error con ACCESS DENIED, aunque la cuenta de llamada tiene permisos suficientes en las cuentas de destino. La razón de esto es que la implementación de api del lado cliente no tiene una relación 1:1 con las API RPC del Administrador de cuentas de seguridad (SAM). El lado cliente realiza comprobaciones adicionales y preparación para estas llamadas que requieren permisos adicionales en Active Directory.
Una aplicación que usa estas API es el servicio de clúster y, en el registro del servicio de clúster, verá:
00000a78.000021b8::2010/06/15-00:00:47.911 WARN [RES] Nombre <de red cluster-resource1: No se pudo determinar si la cuenta de equipo cluster-resource1> ya está deshabilitada. estado 5
Otro síntoma de este efecto podría ser registros de auditoría excesivos en el registro de eventos de seguridad de los controladores de dominio para estas llamadas API y los objetos citados a continuación, si la auditoría de acceso correcta o con errores para la cuenta de llamada está habilitada.
Más información
La implementación de las API usa varias llamadas RPC dirigidas al controlador de dominio para configurar la sesión y comprobar el dominio. Tiene acceso a los siguientes objetos con acceso de lectura:
Objeto raíz de dominio: busca el dominio principal del controlador de dominio y abre el dominio para leer, que a su vez abre el objeto de AD para el dominio, como DC=contoso,dc=com.
Contenedor integrado: este es el objeto raíz del dominio integrado. Se abre cuando el autor de la llamada quiere comprobar su existencia. Por lo tanto, el autor de la llamada necesita acceso de lectura al contenedor CN=Builtin,DC=contoso,dc=com.
Objeto de servidor SAM: este objeto almacena permisos generales sobre el acceso y la enumeración generales de la cuenta SAM. Solo se usará en determinadas llamadas. El nombre del objeto es cn=server,cn=system,DC=contoso,dc=com.
En la mayoría de los dominios de Active Directory, se conceden permisos para estos objetos en función de la pertenencia a grupos genéricos, como Usuarios autenticados, Todos o el grupo de acceso compatible con Versiones anteriores a Windows 2000. El cambio para desencadenar el problema puede haber sido que el usuario se quitó del último grupo (quizás junto con Todos o los permisos de los objetos enumerados se quitaron en un movimiento para proteger los permisos de Active Directory.
Los enfoques para resolver el problema son conceder los permisos de lectura necesarios o cambiar la aplicación para usar LDAP en lugar de las API anteriores o el proveedor WINNT adsI. LDAP no tocará los objetos anteriores y también admitirá los permisos granulares que puede haber establecido en el objeto de destino.
Auditoría excesiva
Cuando tenga habilitada la auditoría en estos objetos, verá hasta tres registros de auditoría para los objetos anteriores para abrir y cerrar los objetos, además del acceso real al objeto de destino. Si los eventos se registran excesivamente, tiene sentido quitar las entradas de la ACL de auditoría para que estos tipos de acceso genéricos ya no se registren. El problema es que el objeto Raíz del dominio y el contenedor builtin heredan a muchos objetos subordinados.
Para resolver esto, debe interrumpir la herencia en el contenedor integrado y redefinir los AEC que heredan para que solo se apliquen a este objeto. También debe tocar los ACE en el objeto raíz del dominio para que los SAC del problema ya no se apliquen al objeto raíz del dominio. Los pasos exactos dependen de la configuración de SACL real que está en vigor en su entorno.