LDAP query causes 99% LSASS.EXE spike

[user]

Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.platformsdk.active.directory,microsoft.public.win2000.active_directory,microsoft.public.windows.activedirectory.dsml,microsoft.public.windows.server.active_directory (More info?)

Hello all,

Our developers are utilizing AD to provide authentication for a product
called COGNOS. It has been configured to point to one of our Global Catalog
servers. When a user logs in through the COGNOS reporting interface, the
LSASS.EXE on the GC spikes to 99% and will either remain for a few seconds
for some accounts, or will hang indefinitely at 99% CPU. It has caused me
on two occasions to have to reboot the server. Is there a way I can prevent
this from happening while still allowing COGNOS to perform its LDAP
functions against the Global Catalog? Specifically, can I find out via any
of the logs (security didn't provide much of anything) who is doing the
querying, how to determine why the LDAP response time is slow, and why the
query/login methodology is causing LSASS.EXE to spike? Is it how the query
is coded? Should I turn of the logging on the GC?

Thanks.

 

[Guest]

Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.platformsdk.active.directory,microsoft.public.win2000.active_directory,microsoft.public.windows.activedirectory.dsml,microsoft.public.windows.server.active_directory (More info?)

I would suggest trying to figure out what the LDAP query is that COGNOS is
doing. It sounds like it is very inefficient and might be an issue that
needs to be taken up with the vendor.

There are a bunch of ways you could accomplish this. You might try sniffing
the wire traffic for the raw LDAP calls (unless they are SSL encrypted) or
you might try enabling inefficient query auditing on the DC.

Joe K.

<-> wrote in message news:%23cYuJGysFHA.2968@TK2MSFTNGP10.phx.gbl...
> Hello all,
>
> Our developers are utilizing AD to provide authentication for a product
> called COGNOS. It has been configured to point to one of our Global
> Catalog servers. When a user logs in through the COGNOS reporting
> interface, the LSASS.EXE on the GC spikes to 99% and will either remain
> for a few seconds for some accounts, or will hang indefinitely at 99% CPU.
> It has caused me on two occasions to have to reboot the server. Is there
> a way I can prevent this from happening while still allowing COGNOS to
> perform its LDAP functions against the Global Catalog? Specifically, can
> I find out via any of the logs (security didn't provide much of anything)
> who is doing the querying, how to determine why the LDAP response time is
> slow, and why the query/login methodology is causing LSASS.EXE to spike?
> Is it how the query is coded? Should I turn of the logging on the GC?
>
> Thanks.
>

 

[user]

Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.platformsdk.active.directory,microsoft.public.win2000.active_directory,microsoft.public.windows.activedirectory.dsml,microsoft.public.windows.server.active_directory (More info?)

Hello,

Thank you for your response. I am still at a loss as to why AD doesn't have
some kind of protection against rogue LDAP queries. Could you indicate how
I can enable query auditing on the domain controller, as there seems to be
no mention of it from Google. I think sniffing the wire is a good idea,
perhaps we can limit the LDAP calls through CISCO.

"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:eUTqdZ7sFHA.3404@TK2MSFTNGP09.phx.gbl...
>I would suggest trying to figure out what the LDAP query is that COGNOS is
>doing. It sounds like it is very inefficient and might be an issue that
>needs to be taken up with the vendor.
>
> There are a bunch of ways you could accomplish this. You might try
> sniffing the wire traffic for the raw LDAP calls (unless they are SSL
> encrypted) or you might try enabling inefficient query auditing on the DC.
>
> Joe K.
>
> <-> wrote in message news:%23cYuJGysFHA.2968@TK2MSFTNGP10.phx.gbl...
>> Hello all,
>>
>> Our developers are utilizing AD to provide authentication for a product
>> called COGNOS. It has been configured to point to one of our Global
>> Catalog servers. When a user logs in through the COGNOS reporting
>> interface, the LSASS.EXE on the GC spikes to 99% and will either remain
>> for a few seconds for some accounts, or will hang indefinitely at 99%
>> CPU. It has caused me on two occasions to have to reboot the server. Is
>> there a way I can prevent this from happening while still allowing COGNOS
>> to perform its LDAP functions against the Global Catalog? Specifically,
>> can I find out via any of the logs (security didn't provide much of
>> anything) who is doing the querying, how to determine why the LDAP
>> response time is slow, and why the query/login methodology is causing
>> LSASS.EXE to spike? Is it how the query is coded? Should I turn of the
>> logging on the GC?
>>
>> Thanks.
>>
>
>

 

[Guest]

Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.platformsdk.active.directory,microsoft.public.win2000.active_directory,microsoft.public.windows.activedirectory.dsml,microsoft.public.windows.server.active_directory (More info?)

Actually, AD does have some protections against rogue queries such as
maxPageSize and the various query timeouts. These can also be tightened by
the domain admin if desired.

The fact that a single query can consume all the CPU is a bit alarming and
might indicate a bug of some sort that needs to be fixed. It really all
depends.

Perhaps if you are able to determine the query in question that is
problematic, you can approach MS with the info to see if there is an actual
problem that needs fixing or to see if they have additional guidance.

Joe K.

<-> wrote in message news:OUNXIoUuFHA.2160@TK2MSFTNGP09.phx.gbl...
> Hello,
>
> Thank you for your response. I am still at a loss as to why AD doesn't
> have some kind of protection against rogue LDAP queries. Could you
> indicate how I can enable query auditing on the domain controller, as
> there seems to be no mention of it from Google. I think sniffing the wire
> is a good idea, perhaps we can limit the LDAP calls through CISCO.
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
> in message news:eUTqdZ7sFHA.3404@TK2MSFTNGP09.phx.gbl...
>>I would suggest trying to figure out what the LDAP query is that COGNOS is
>>doing. It sounds like it is very inefficient and might be an issue that
>>needs to be taken up with the vendor.
>>
>> There are a bunch of ways you could accomplish this. You might try
>> sniffing the wire traffic for the raw LDAP calls (unless they are SSL
>> encrypted) or you might try enabling inefficient query auditing on the
>> DC.
>>
>> Joe K.
>>
>> <-> wrote in message news:%23cYuJGysFHA.2968@TK2MSFTNGP10.phx.gbl...
>>> Hello all,
>>>
>>> Our developers are utilizing AD to provide authentication for a product
>>> called COGNOS. It has been configured to point to one of our Global
>>> Catalog servers. When a user logs in through the COGNOS reporting
>>> interface, the LSASS.EXE on the GC spikes to 99% and will either remain
>>> for a few seconds for some accounts, or will hang indefinitely at 99%
>>> CPU. It has caused me on two occasions to have to reboot the server. Is
>>> there a way I can prevent this from happening while still allowing
>>> COGNOS to perform its LDAP functions against the Global Catalog?
>>> Specifically, can I find out via any of the logs (security didn't
>>> provide much of anything) who is doing the querying, how to determine
>>> why the LDAP response time is slow, and why the query/login methodology
>>> is causing LSASS.EXE to spike? Is it how the query is coded? Should I
>>> turn of the logging on the GC?
>>>
>>> Thanks.
>>>
>>
>>
>
>