CTT
2004-12-03 16:44:12 UTC
We have an ADAM application that makes use of basic LDAP security--we
create and delete users and set object permissions using calls into
the ntSecurityDescriptor. After we ported the AD code to ADAM things
worked fine, although, periodically we would see performance problems.
For instance, an attempt to validate a user by opening their user
user node with their credentials could take 20 ms or 4 seconds. We
haven't been able to determine with accuracy why the longer delay
occurs.
Then, this morning, I lost the network connectivity to my machine and
one of my more intensive application calls oscillated from 4 seconds
to 76 seconds. Tracing through the code, I determined that the call
time was being consumed in a retrieval of the ntSecurityDescriptor.
When the delay occurred, it was consistently at the retrieval of the
ntSecurityDescriptor. However, sometimes the call completed within a
normal timeframe. I then verified the trace logs from the last
several days and that same call was always in the 4 second range and
hasn't been over 5 seconds in the 3 days of logs that I have.
Hmmm...the difference seems to be the network connectivity, but why?
Everything is running locally on my machine (XPSP2), so there should
be no reason to go to the network. The accounts I'm using within the
program and ADAM are all ADAM accounts, not NT accounts. I know that
ADAM will use the domain for password policy, but why, outside of
setting a password, would ADAM need to access the network? Is this to
do with the ntSecurityDescriptor field or a general ADAM requirement?
Thanks for any clues you can provide,
Carol
P.S. The code isn't anything special:
// dirEntry created with an ADAM account. This is always a fast call.
dirEntry.RefreshCache(new string[]{"ntSecurityDescriptor"}) ;
// The next line normally takes a second-ish, but when the network was
down,
// about one call out of three took 10-70 seconds.
IADsSecurityDescriptor secDescriptor
= (IADsSecurityDescriptor)
dirEntry.Properties["ntSecurityDescriptor"].Value ;
create and delete users and set object permissions using calls into
the ntSecurityDescriptor. After we ported the AD code to ADAM things
worked fine, although, periodically we would see performance problems.
For instance, an attempt to validate a user by opening their user
user node with their credentials could take 20 ms or 4 seconds. We
haven't been able to determine with accuracy why the longer delay
occurs.
Then, this morning, I lost the network connectivity to my machine and
one of my more intensive application calls oscillated from 4 seconds
to 76 seconds. Tracing through the code, I determined that the call
time was being consumed in a retrieval of the ntSecurityDescriptor.
When the delay occurred, it was consistently at the retrieval of the
ntSecurityDescriptor. However, sometimes the call completed within a
normal timeframe. I then verified the trace logs from the last
several days and that same call was always in the 4 second range and
hasn't been over 5 seconds in the 3 days of logs that I have.
Hmmm...the difference seems to be the network connectivity, but why?
Everything is running locally on my machine (XPSP2), so there should
be no reason to go to the network. The accounts I'm using within the
program and ADAM are all ADAM accounts, not NT accounts. I know that
ADAM will use the domain for password policy, but why, outside of
setting a password, would ADAM need to access the network? Is this to
do with the ntSecurityDescriptor field or a general ADAM requirement?
Thanks for any clues you can provide,
Carol
P.S. The code isn't anything special:
// dirEntry created with an ADAM account. This is always a fast call.
dirEntry.RefreshCache(new string[]{"ntSecurityDescriptor"}) ;
// The next line normally takes a second-ish, but when the network was
down,
// about one call out of three took 10-70 seconds.
IADsSecurityDescriptor secDescriptor
= (IADsSecurityDescriptor)
dirEntry.Properties["ntSecurityDescriptor"].Value ;