|
|
|
date: Tue, 6 Sep 2005 16:28:25 -0400,
group: microsoft.public.platformsdk.active.directory
back
Re: LDAP query causes 99% LSASS.EXE spike
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)" 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.
>>
>
>
date: Wed, 14 Sep 2005 12:33:23 -0400
author: -
Re: LDAP query causes 99% LSASS.EXE spike
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)" 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.
>>>
>>
>>
>
>
date: Wed, 14 Sep 2005 14:51:28 -0700
author: Joe Kaplan \(MVP - ADSI\)
Re: LDAP query causes 99% LSASS.EXE spike
Hi Joe,
Would you know how I could enable inefficient query auditing on my DC's? I
can't find it in Google.
Thanks
"Joe Kaplan (MVP - ADSI)" wrote
in message news:%23IntuZXuFHA.3424@tk2msftngp13.phx.gbl...
> 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)"
>> 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.
>>>>
>>>
>>>
>>
>>
>
>
date: Thu, 27 Oct 2005 21:37:13 -0400
author: -
|
|
