query - sql select active directory users

Consulta del servidor vinculado SQL 2005 que falla periódicamente

Question

Tenemos una base de datos que se ejecuta en SQL 2005. Uno de los procedimientos de la tienda busca la dirección de correo electrónico de un usuario desde Active Directory utilizando un servidor vinculado. La llamada al servidor vinculado se produce en una función de base de datos.

Pude llamar desde mi aplicación Asp.Net con éxito desde la primera vez, pero periódicamente después de eso, falla con el siguiente error:

{"La operación solicitada no se pudo realizar porque el proveedor OLE DB /" ADsDSOObject / "para el servidor vinculado /" ADSI / "no es compatible con la interfaz de transacción requerida."}

Parece que la cantidad de tiempo entre llamar a la función afecta si la consulta del servidor vinculado funcionará correctamente. No estoy usando ninguna transacción. Cuando intento llamar a la función en una secuencia de comandos SQL make-shift rápida, funciona bien cada vez (incluso cuando se prueba en sucesión rápida).

¿Hay algún tipo de transacción abierta que naturalmente muere si no intento volver a llamar al procedimiento? Estoy perdido aquí.

Aquí está la llamada simple en el procedimiento de la tienda:

DECLARE @email varchar(50)
SELECT @email = LEFT(mail, 50)
FROM OPENQUERY (
ADSI,
''SELECT mail, sAMAccountName FROM ''''LDAP://DC=Katz,DC=COM'''' WHERE objectCategory = ''''Person'''' AND objectClass = ''''User''''''
)
WHERE sAMAccountName = CAST(@LoginName AS varchar(35))
RETURN @email

Answer 1

He trabajado con servidores de enlaces de SQL Server a menudo, aunque rara vez consultas LDAP ... pero me entró curiosidad y leí la página de soporte técnico de Microsoft enlazada en la publicación previa de Ric Tokyo. Hacia la parte inferior se lee:

Es típico que un servidor de directorio imponga una limitación de servidor en la cantidad de objetos que se devolverán para una consulta determinada. Esto es para prevenir ataques de denegación de servicio y sobrecarga de red. Para consultar correctamente el servidor de directorio, las consultas grandes deben dividirse en muchas más pequeñas. Una forma de hacerlo es a través de un proceso llamado paginación. Mientras que la paginación está disponible a través del proveedor OLEDB de ADSI, actualmente no hay forma de realizarla desde una consulta SQL distribuida. Esto significa que la cantidad total de objetos que se pueden devolver para una consulta es el límite del servidor. En el Directorio Activo de Windows 2000, el límite del servidor predeterminado es de 1,000 objetos.

Estoy pensando que la razón por la cual falla en usted (o no) dependiendo de si lo llama desde la aplicación o desde un "script SQL de cambio rápido" (como usted dice) podría estar relacionado con el contexto de seguridad bajo el cual el la operación se está ejecutando. Dependiendo de cómo se haya configurado la conexión del servidor de enlace, la operación se podría ejecutar bajo una variedad de credenciales posibles según cómo inicie la consulta.

No lo sé, pero esa es mi mejor suposición. Me gustaría ver la configuración del servidor de enlaces, en particular las configuraciones del servidor de enlaces para qué conjunto de credenciales se usan como el contexto de seguridad bajo el cual se ejecutan las operaciones ejecutadas en el servidor de enlaces.

Answer 2

por favor lea la página de soporte de Microsoft

Answer 3

En lugar de consultar Active Directory a través de un servidor vinculado, sería mejor almacenar en caché sus datos AD en una base de datos SQL y luego consultarlos. Puede usar Integration Services creando una conexión OLE DB utilizando "OLE DB PRovider para Microsoft Directory Services" y teniendo un origen de DataReader con una consulta como:

 SELECT physicalDeliveryOfficeName, department, company, title, displayName, SN,
givenName, sAMAccountName, manager, mail, telephoneNumber, mobile
FROM ''LDAP://DC=SOMECO,DC=COM''
WHERE objectClass=''User'' and objectCategory = ''Person''
order by mail 

Al utilizar este método, aún se encontrará con el límite de 1000 filas para obtener resultados de una consulta de AD (tenga en cuenta que NO es aconsejable intentar aumentar este límite en AD, está ahí para evitar que el controlador de dominio se sobrecargue). A veces es posible usar una combinación de consultas para devolver el conjunto completo de datos, por ejemplo, nombres A - L y M - Z

Alternativamente, puede usar la utilidad de línea de comandos CSVDE en Windows Server para exportar su información de directorio a un archivo CSV y luego importarla en una base de datos SQL (consulte http://computerperformance.co.uk/Logon/Logon_CSVDE_Export.htm para obtener más información sobre exportar datos AD con CSVDE).

Answer 4

Sospecho que podría ser el plan de consulta en caché debido a su afirmación de que "cuando intento llamar a la función en una secuencia de comandos SQL make-shift rápida, se ejecuta correctamente cada vez (incluso cuando se prueba en sucesión rápida)".

¿Podría intentar ejecutar su procedimiento almacenado de la siguiente manera:

EXEC usp_MyProcedure WITH RECOMPILE

Answer 5

Esta pregunta aparece en la parte superior de la primera página de google cuando busca la cadena de error pero no tiene una respuesta válida.

Este error ocurre intermitentemente cuando el nivel de aislamiento no se especifica en el código .NET ni en el Procedimiento de almacenamiento.

Este error también ocurre en SQL Server 2008.

El arreglo es forzado SET TRANSACTION ISOLATION LEVEL READ (UN)COMMITTED porque un nivel de aislamiento superior no es compatible con Active Directory y SQL Server intenta usar SERIALIZABLE .

Ahora, como este error está intermitente. ¿Por qué ADO.NET o SQLServer cambian su aislamiento predeterminado a SERIALIZABLE algunas veces y otras no? ¿Qué desencadena este cambio?