kbannister Absent Member.
Absent Member.
1552 views

ndstrace LDAP

Working with eDirectory and LDAP for the first time in about six years. Siteminder, which I do not administer is showing several entries for users with a high processing time to authenticate via eDirectory LDAP. Looking at the ndstrace logs for a particular user that corresponds to the Siteminder times I see the following. Starting at 9:26:21 there are several entries in the ndstrace log for this user. Then at 9:26:30 I see a -669 for this user. I will also see -220, 222, 49 and 53 errors for other users which correspond to the Siteminder logs. What exactly am I seeing. It looks to me they are authentication errors, bad PW, account expired etc. Why are there so many entries for a user to authenticate. And why would it take Siteminder so long to receive a result, positive or negative. How do I know the -669 error is really for the v0984 user. What exactly does a successful bind look like. In other words I could use some assistance reading these logs. They appear different than what I saw in the past. By the way, it’s very good to be working with SLES and eDirectory after a six year hiatus!! Thanks in advance!

base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "mail"
attribute: "preferredlanguage"
attribute: "uid"
09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection 0x7ff20a80
09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending operation result 0:"":"" to connection 0x7ff20a80
09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) DoSearch on connection 0x804c6a80
09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) Search request:

base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "mail"

base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "mail"
09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Bind xxme:cn=VE051,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple
09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection 0x7ff20a80
09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending operation result 0:"":"" to connection 0x7ff20a80
09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Sending operation result 0:"":"" to connection 0x7dccd880
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) DoModify on connection 0x7dccc700
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) modify: dn (cn=VE051,ou=XXX,ou=XX,o=XXXX)
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) modifications:
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) replace: smPasswordData
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) Sending operation result 0:"":"" to connection 0x7dccc700
09:26:21 42355700 LDAP: (172.16.35.174:49810)(0xbd0e:0x63) DoSearch on connection 0x7d08ea80
09:26:21 42355700 LDAP: (172.16.35.174:49810)(0xbd0e:0x63) Search request:

base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "givenxxme"
attribute: "mail"
attribute: "sn"
attribute: "uid"
09:26:27 41E50700 LDAP: (172.16.254.87:55852)(0x0018:0x63) Sending search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection 0x7ff20a80
09:26:27 41E50700 LDAP: (172.16.254.87:55852)(0x0018:0x63) Sending operation result 0:"":"" to connection 0x7ff20a80
09:26:28 3BDF7700 LDAP: (172.16.254.83:50526)(0x58965:0x63) DoSearch on connection 0x7f774a80
09:26:28 3BDF7700 LDAP: (172.16.254.83:50526)(0x58965:0x63) Search request:
base: "ou=XX,o=XXXX"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(uID=yvg5602)(objectClass=user)(polExxbled=Y))"
no attributes

base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "givenxxme"
attribute: "sn"
attribute: "uid"
09:26:30 34781700 LDAP: (172.16.254.87:55852)(0x001d:0x63) Sending search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection 0x7ff20a80
09:26:30 34781700 LDAP: (172.16.254.87:55852)(0x001d:0x63) Sending operation result 0:"":"" to connection 0x7ff20a80
09:26:30 33771700 LDAP: (172.16.254.87:64511)(0x0001:0x60) Failed to authenticate local on connection 0x825a1c00, err = failed authentication (-669)
09:26:30 33771700 LDAP: (172.16.254.87:64511)(0x0001:0x60) Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x825a1c00
09:26:30 44779700 LDAP: (172.16.254.87:64511)(0x0002:0x42) DoUnbind on connection 0x825a1c00
09:26:30 44779700 LDAP: Connection 0x825a1c00 closed
09:26:30 57327700 LDAP: (172.16.254.87:51549)(0x00cb:0x63) DoSearch on connection 0x7fbb7880
09:26:30 57327700 LDAP: (172.16.254.87:51549)(0x00cb:0x63) Search request:
base: "ou=XXX,ou=XX,o=XXXX"
scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
filter: "(&(objectclass=inetOrgPerson)(cn=AGJ96))"
no attributes
Labels (1)
0 Likes
22 Replies
Micro Focus Expert
Micro Focus Expert

Re: ndstrace LDAP

On 2018-11-27 16:14, kbannister wrote:

You can use the TAG value (2nd column in your sample) to identify log
lines belonging to the same operation:

> 09:26:21 *2C701700* LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending
> operation result 0:"":"" to connection 0x7ff20a80
> 09:26:21 *3AAE4700* LDAP: (172.16.254.87:61153)(0x05f0:0x63) DoSearch on
> connection 0x804c6a80


See
https://www.netiq.com/communities/cool-solutions/cool_tools/elapsed-time-416/
for a tool to analyze ndstraces.

--
Norbert
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: ndstrace LDAP

Thank you. That helped. I’m also curious why so many different attributes are read within the 13:11:41, to 13:12:21 time frame. Also, what this means replace: smPasswordData (Last entry). Thank you. I’m just not finding good info on how to read these traces. You are a great help!


base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=5hakp)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:11:41 394CE700 LDAP: (172.16.35.172:49907)(0x36cbc:0x63) Sending search result entry "cn=5HAKP,ou=XXX,ou=XX,o=XXXX" to connection 0x7e7be000
13:11:41 394CE700 LDAP: (172.16.35.172:49907)(0x36cbc:0x63) Sending operation result 0:"":"" to connection 0x7e7be000

base: "cn=5HAKP,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"

13:11:41 30741700 LDAP: (172.16.35.172:49909)(0x130e:0x60) Bind xxme:cn=5HAKP,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple

base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=5hakp)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:11:41 43D6F700 LDAP: (172.16.35.172:49907)(0x36cc2:0x63) Sending search result entry "cn=5HAKP,ou=XXX,ou=XX,o=XXXX" to connection 0x7e7be000
13:11:41 43D6F700 LDAP: (172.16.35.172:49907)(0x36cc2:0x63) Sending operation result 0:"":"" to connection 0x7e7be000

base: "cn=5HAKP,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"
13:11:41 41B4D700 LDAP: (172.16.35.172:49907)(0x36cc3:0x63) Sending operation result 0:"":"" to connection 0x7e7be000
13:11:41 2FD37700 LDAP: (172.16.35.173:49821)(0x4f11a:0x63) DoSearch on connection 0x7fd1c700
13:11:41 2FD37700 LDAP: (172.16.35.173:49821)(0x4f11a:0x63) Search request:

base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=5hakp)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:11:41 3F029700 LDAP: (172.16.35.173:49821)(0x4f120:0x63) Sending search result entry "cn=5HAKP,ou=XXX,ou=XX,o=XXXX" to connection 0x7fd1c700
13:11:41 3F029700 LDAP: (172.16.35.173:49821)(0x4f120:0x63) Sending operation result 0:"":"" to connection 0x7fd1c700


13:12:27 30943700 LDAP: (172.16.35.174:49824)(0x597d1:0x66) modify: dn (cn=5HAKP,ou=PFA,ou=NA,o=INTL)
13:12:27 30943700 LDAP: (172.16.35.174:49824)(0x597d1:0x66) modifications:
13:12:27 30943700 LDAP: (172.16.35.174:49824)(0x597d1:0x66) replace: smPasswordData
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: ndstrace LDAP

On 2018-11-27 21:36, ka12312 wrote:
> Thank you. That helped. I�m also curious why so many different
> attributes are read within the 13:11:41, to 13:12:21 time frame. Also,
> what this means replace: smPasswordData (Last entry). Thank you. I�m
> just not finding good info on how to read these traces. You are a great
> help!


"smPasswordData" is not an eDirectory operational attribute. I'd guess
that the "sm" prefix stands for SiteMinder. Check SiteMinder doc about
its use of LDAP.


--
Norbert
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: ndstrace LDAP

Yes, just located as a Siteminder attribute. Why however would the bind request search in different base OUs. Is that written in the app wanting to authenticate? I am curious if this is what is taking so long according to the Siteminder admin.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

On 11/27/2018 02:24 PM, ka12312 wrote:
>
> Yes, just located as a Siteminder attribute. Why however would the bind
> request search in different base OUs. Is that written in the app


Good question for siteMinder; its configuration must have multiple base
DNs to search, and while that's fine, it is also completely up to the client.

By default eDirectory imposes a three (3) second delay on a failed login,
even if the reason for the failure is that you specified the wrong DN
rather than a wrong password (to prevent brute force finding a valid
username). Usually services using eDirectory as a backend can avoid the
slowness when finding a user by first finding the valid user using their
own authenticated user and doing a search based on the username, then
binding directly with a DN. If SiteMinder does not do that, then they
should probably be taught a few LDAP basics, but this would not be that
unusual.

> wanting to authenticate? I am curious if this is what is taking so long
> according to the Siteminder admin.


What is "so long" and how are they recording that? What does SiteMinder
do between the time the user starts their login attempt to the time that
"so long" has happened? We can guess from traces, but all we can see is
what it does, not why, and the why may be nestled in the minds of
SiteMinder programmers.

Whether the "why" makes sense in the real world is a common question since
the first thing programmers learn in college, and from many jobs, is how
to use a relational database, not a directory, even though the latter are
as common and far more practical for things like user logins and storing
user data. An experienced programmer is worth a lot, but an experienced
programmer probably won't be dealing with writing the login code (that's
ironic to me).

Note: please use the CODE tags (little '#' button in the web UI) in order
to avoid code and other things you post being interpreted by VBulletin and
subsequently messed up.


base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "mail"
attribute: "preferredlanguage"
attribute: "uid"
09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending
search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
0x7ff20a80
09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending
operation result 0:"":"" to connection 0x7ff20a80


In this block something is doing a search; there is some truncation before
it so I cannot tell who did it or whatever, but the serach was successful
(result 0) and sent back the one entry requested. This should have taken
a few milliseconds in total. The list of attributes requested was
requested by SiteMinder. There is no bind involved, as binds are
completely separate operations from searches and the two, in LDAP, cannot
be combined (nor should they be).

Another search:


09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) DoSearch on
connection 0x804c6a80
09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) Search
request:

base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "mail"


Another search, but I see no response, but perhaps that is because the
trace was truncated before/after again. It is the same object (assuming
the obfuscated stuff is not changed) as above, with the same attributes,
so this is redundant, but should still have been quick since it pointed
directly to the object in question.

Another search followed by a modify:


base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
attribute: "mail"
09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Bind
xxme:cn=VE051,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple
09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending
search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
0x7ff20a80
09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending
operation result 0:"":"" to connection 0x7ff20a80
09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Sending
operation result 0:"":"" to connection 0x7dccd880
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) DoModify on
connection 0x7dccc700
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) modify: dn
(cn=VE051,ou=XXX,ou=XX,o=XXXX)
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66)
modifications:
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) replace:
smPasswordData
09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) Sending
operation result 0:"":"" to connection 0x7dccc700


Searching for the same user again, asking for the same attributes again.
SiteMinder apparently has a problem remembering what it retrieved a
fraction of a second before, and that s only hurting their performance
(though barely considering the searches are very fast). After the search
we see a modify of the attribute you mentioned on some other object (VE051
instead of v0984) probably for something unrelated. Still, that also
finished in less than a second because it was a simple modify which always
has the DN to be modified, so no need to "search" and possibly have
slowness there.

Later in the trace we are getting multiple searches at the same time, so
the trace shows those interwoven and it's a pain to read, particularly as
I am guessing some lines were lost. It is also odd to me that we do not
have more-granular timestamps (only seconds, not milliseconds). Were
these from iMonitor rather than ndstrace? I could have sworn ndstrace
gave more granularity than that (dstrace on NetWare did not, but my bug
for that was never fixed as I recall).

There is another search in here that may be slow, and that is one
searching for a user by CN and Object Class. By default eDirectory does
NOT index Object Class, and my bug to fix that is probably not resolved
yet either, but many products do add this index (e.g. Identity Manager
(IDM)) so you may want to try adding a Value index to Object Class so
these searches can go faster. It would impact this search if you have a
non-tiny tree:


09:26:30 57327700 LDAP: (172.16.254.87:51549)(0x00cb:0x63) Search
request:
base: "ou=XXX,ou=XX,o=XXXX"
scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
filter: "(&(objectclass=inetOrgPerson)(cn=AGJ96))"
no attributes


Here is another that would also be impacted, though there is also a
polExxbled attribute which should be indexed with a Value index if it is
impacting performance:


09:26:28 3BDF7700 LDAP: (172.16.254.83:50526)(0x58965:0x63) Search
request:
base: "ou=XX,o=XXXX"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(uID=yvg5602)(objectClass=user)(polExxbled=Y))"
no attributes


It is odd to me that one of these uses objectclass=inetorgperson and the
other uses objectClass=user since, while they both mean the same thing,
that would normally tell me they are completely separate clients. If
those are both SiteMinder then that's sloppy. inetOrgPerson is the LDAP
standard attribute name, and User is the eDirectory name, and eDirectory's
LDAP interface maps the former to the latter automatically, thus they are
identical internally.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: ndstrace LDAP

Thank you ab!! I appreciate your assistance. I actually met you at Brainshare many years ago.

Siteminder Admin sent me what looks like a snip of a trace starting at 13:11:58 to 13:12:40.

It looks as if the replace: smPasswordData is being replaced in the eDirectory dstrace (iMonitor) log.

Siteminder Admin wants to know why it is taking 42 seconds (according to their trace) for LDAP to handle the password change and why LDAP i sperforming so many searches.

The errors I see in dstrace for what they consider long transactions have to do with bad passwords, expired accounts, grace logins etc. All other searches look fine to me.

According to the Siteminder admin they have had this issue long before I arrived. I am trying to assist them in solving this issue.

Thank you again!!





Dstrace of user HY983
13:11:49
base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=hy983)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:11:49 56519700 LDAP: (172.16.35.179:49798)(0x31a78:0x63) Sending search result entry "cn=HY983,ou=XXX,ou=XX,o=XXXX" to connection 0x805df880
13:11:49 56519700 LDAP: (172.16.35.179:49798)(0x31a78:0x63) Sending operation result 0:"":"" to connection 0x805df880
13:11:49 3F029700 LDAP: (172.16.35.179:49798)(0x31a79:0x63) DoSearch on connection 0x805df880
13:11:49 3F029700 LDAP: (172.16.35.179:49798)(0x31a79:0x63) Search request:
base: "cn=HY983,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"
13:11:49 3F029700 LDAP: (172.16.35.179:49798)(0x31a79:0x63) Sending operation result 0:"":"" to connection 0x805df880
13:11:49 44779700 LDAP: (172.16.35.179:49798)(0x31a7a:0x63) DoSearch on connection 0x805df880
13:11:49 44779700 LDAP: (172.16.35.179:49798)(0x31a7a:0x63) Search request:

13:11:58
base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=hy983)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:11:58 3FF38700 LDAP: (172.16.35.179:49798)(0x31a92:0x63) Sending search result entry "cn=HY983,ou=XXX,ou=XX,o=XXXX" to connection 0x805df880
13:11:58 3FF38700 LDAP: (172.16.35.179:49798)(0x31a92:0x63) Sending operation result 0:"":"" to connection 0x805df880
13:11:58 43062700 LDAP: (172.16.35.179:49798)(0x31a93:0x63) DoSearch on connection 0x805df880
13:11:58 43062700 LDAP: (172.16.35.179:49798)(0x31a93:0x63) Search request:
base: "cn=HY983,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"
13:11:58 43062700 LDAP: (172.16.35.179:49798)(0x31a93:0x63) Sending operation result 0:"":"" to connection 0x805df880

13:12:16
base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=hy983)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:12:16 3AEE8700 LDAP: (172.16.35.179:49798)(0x31ae2:0x63) Sending search result entry "cn=HY983,ou=XXX,ou=XX,o=XXXX" to connection 0x805df880
13:12:16 3AEE8700 LDAP: (172.16.35.179:49798)(0x31ae2:0x63) Sending operation result 0:"":"" to connection 0x805df880
13:12:16 3ABE5700 LDAP: (172.16.35.179:49798)(0x31ae3:0x63) DoSearch on connection 0x805df880
13:12:16 3ABE5700 LDAP: (172.16.35.179:49798)(0x31ae3:0x63) Search request:
base: "cn=HY983,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"
13:12:16 3ABE5700 LDAP: (172.16.35.179:49798)(0x31ae3:0x63) Sending operation result 0:"":"" to connection 0x805df880
13:12:17 34680700 LDAP: (172.16.254.83:64988)(0x5853:0x63) DoSearch on connection 0x9fbc6e00
13:12:17 34680700 LDAP: (172.16.254.83:64988)(0x5853:0x63) Search request:
base: "ou=XX,o=XXXX"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(uID=kkbj5)(objectClass=user)(polExxbled=Y))"
no attributes

13:12:22
base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=hy983)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:12:22 44577700 LDAP: (172.16.35.179:49798)(0x31aeb:0x63) Sending search result entry "cn=HY983,ou=XXX,ou=XX,o=XXXX" to connection 0x805df880
13:12:22 44577700 LDAP: (172.16.35.179:49798)(0x31aeb:0x63) Sending operation result 0:"":"" to connection 0x805df880
13:12:22 30943700 LDAP: (172.16.35.179:49798)(0x31aec:0x63) DoSearch on connection 0x805df880
13:12:22 30943700 LDAP: (172.16.35.179:49798)(0x31aec:0x63) Search request:
base: "cn=HY983,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"

13:12:25
13:12:25 394CE700 LDAP: (172.16.35.179:49805)(0x1281:0x60) DoBind on connection 0x7f064e00
13:12:25 394CE700 LDAP: (172.16.35.179:49805)(0x1281:0x60) Bind xxme:cn=HY983,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple

13:12:25 2E31D700 LDAP: (172.16.35.179:49798)(0x31aee:0x66) DoModify on connection 0x805df880
13:12:25 2E31D700 LDAP: (172.16.35.179:49798)(0x31aee:0x66) modify: dn (cn=HY983,ou=XXX,ou=XX,o=XXXX)
13:12:25 2E31D700 LDAP: (172.16.35.179:49798)(0x31aee:0x66) modifications:
13:12:25 2E31D700 LDAP: (172.16.35.179:49798)(0x31aee:0x66) replace: smPasswordData
13:12:25 2E31D700 LDAP: (172.16.35.179:49798)(0x31aee:0x66) Sending operation result 0:"":"" to connection 0x805df880

13:12:35
base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=hy983)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:12:35 43264700 LDAP: (172.16.35.172:49907)(0x36d7c:0x63) Sending search result entry "cn=HY983,ou=XXX,ou=XX,o=XXXX" to connection 0x7e7be000
13:12:35 43264700 LDAP: (172.16.35.172:49907)(0x36d7c:0x63) Sending operation result 0:"":"" to connection 0x7e7be000
13:12:35 3CA03700 LDAP: (172.16.35.172:49907)(0x36d7d:0x63) DoSearch on connection 0x7e7be000
13:12:35 3CA03700 LDAP: (172.16.35.172:49907)(0x36d7d:0x63) Search request:
base: "cn=HY983,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"
13:12:35 3CA03700 LDAP: (172.16.35.172:49907)(0x36d7d:0x63) Sending operation result 0:"":"" to connection 0x7e7be000
13:12:35 393CD700 LDAP: (172.16.254.83:63633)(0x5849:0x63) DoSearch on connection 0xbb911180
13:12:35 393CD700 LDAP: (172.16.254.83:63633)(0x5849:0x63) Search request:
base: "ou=XX,o=XXXX"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(uID=snyr1)(objectClass=user)(polExxbled=Y))"
no attributes

13:12:40
13:12:40 30943700 LDAP: (172.16.35.179:49805)(0x1287:0x60) Bind xxme:cn=HY983,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) DoModify on connection 0x805df880
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) modify: dn (cn=5HAKP,ou=XXX,ou=XX,o=XXXX)
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) modifications:
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) replace: smPasswordData
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) Sending operation result 0:"":"" to connection 0x805df880
13:12:40 30943700 LDAP: (172.16.35.179:49805)(0x1287:0x60) Sending operation result 0:"":"" to connection 0x7f064e00
13:12:40 3BDF7700 LDAP: (172.16.35.179:49805)(0x1288:0x60) DoBind on connection 0x7f064e00
13:12:40 3BDF7700 LDAP: (172.16.35.179:49805)(0x1288:0x60) Bind xxme:cn=LBEM7,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple
13:12:40 3D009700 LDAP: (172.16.35.179:49798)(0x31b43:0x66) DoModify on connection 0x805df880
13:12:40 3D009700 LDAP: (172.16.35.179:49798)(0x31b43:0x66) modify: dn (cn=HY983,ou=XXX,ou=XX,o=XXXX)
13:12:40 3D009700 LDAP: (172.16.35.179:49798)(0x31b43:0x66) modifications:
13:12:40 3D009700 LDAP: (172.16.35.179:49798)(0x31b43:0x66) replace: smPasswordData
13:12:40 3D009700 LDAP: (172.16.35.179:49798)(0x31b43:0x66) Sending operation result 0:"":"" to connection 0x805df880
13:12:40 43567700 LDAP: (172.16.35.179:50217)(0x3424:0x63) DoSearch on connection 0x7f42ae00
13:12:40 43567700 LDAP: (172.16.35.179:50217)(0x3424:0x63) Search request:

Continues similar entries until 13:13:31

And then I see this:
base: "cn=HY983,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass"
13:13:31 61511700 LDAP: (172.16.35.172:49907)(0x36f60:0x63) Sending operation result 0:"":"" to connection 0x7e7be000
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_IM_CLIENTSERVICES,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_34_MED_INDEX_ONLY,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_34_CLM_INDEX_ONLY,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_35_RC,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_POS,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_34_CLAIMS,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_36_RP,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_34_PCF,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_34_PAC,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_34_LIFE,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_34_APP,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_04_PCF,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_04_PAC,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_04_CLAIMS,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CM_DUL_04_APP,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CSN_LIFE_RVP_COMMUNICATIONS,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 3B6F0700 LDAP: (172.16.254.83:58807)(0x08e9:0x63) Sending search result entry "cn=XX_CSN_LIFE_CUSTOMER_COMMUNICATIONS,ou=Security,ou=XX,o=XXXX" to connection 0x82068700
13:13:31 2E01A700 LDAP: (172.16.35.172:49907)(0x36f61:0x63) DoSearch on connection 0x7e7be000
13:13:31 36FA9700 LDAP: (172.16.35.173:49821)(0x4f322:0x63) DoSearch on connection 0x7fd1c700
13:13:31 2E01A700 LDAP: (172.16.35.172:49907)(0x36f61:0x63) Search request:

At 13:13:55 again:
13:13:55 2FE38700 LDAP: (172.16.35.173:49821)(0x4f3b1:0x66) modify: dn (cn=HY983,ou=XXX,ou=XX,o=XXXX)
13:13:55 2FE38700 LDAP: (172.16.35.173:49821)(0x4f3b1:0x66) modifications:
13:13:55 2FE38700 LDAP: (172.16.35.173:49821)(0x4f3b1:0x66) replace: smPasswordData
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: ndstrace LDAP

FYI - Object Class is indexed with a value.

I will ask Siteminder what the polEXXbled attribute is. I do not see it in eDir or LDAP.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

On 11/28/2018 11:06 AM, ka12312 wrote:
>
> Siteminder Admin sent me what looks like a snip of a trace starting at
> 13:11:58 to 13:12:40.


The SiteMinder admin sent these? I presume from iMonitor? Let's get the
ndstrace output, either from ndstrace directly or from somebody who has
access to it. Hopefully that way we'll get better timestamps, fewer lost
lines, etc. ndstrace can be configured to write directly to a file, maybe
using these steps:


ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap
set dstrace=*m9999999
dstrace file on
set dstrace=*r
#perform your tests here
dstrace file off
quit


The file will, by default, be at
/var/opt/novell/eDirectory/log/ndstrace.log and you can compress and post
it wherever, or put its contents here if they fit, or somewhere like PasteBin.

> It looks as if the replace: smPasswordData is being replaced in the
> eDirectory dstrace (iMonitor) log.


Sure, but that part takes less than one second; if there is any perceived
delay, it is the stuff leading up to, or following, that. The trace
snippet showing that operation follows to prove it:


13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) DoModify on
connection 0x805df880
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) modify: dn
(cn=5HAKP,ou=XXX,ou=XX,o=XXXX)
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) modifications:
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) replace:
smPasswordData
13:12:40 371AB700 LDAP: (172.16.35.179:49798)(0x31b42:0x66) Sending
operation result 0:"":"" to connection 0x805df880


Without more timestamp granularity we cannot tell more about how long it
took, but at most 0.999 seconds.

> Siteminder Admin wants to know why it is taking 42 seconds (according to
> their trace) for LDAP to handle the password change and why LDAP i
> sperforming so many searches.


If their operation is taking that long, then the question to then ask is,
"Why are they performing so many searches?" The very first line of the
data they sent indicates they know the user's full DN (for user hy983) so
at that very moment, without any searches, they could potentially set
smPasswordData, which takes 0.999 seconds at most (more like 0.001, but no
way to prove it from here), and be done. Why are THEY doing all of those
searches? That's for them to tell us, as they are the ones doing the
searches they are asking about, assuming they are on IP address 172.16.35.179.

Also notice there is another IP address in there, 172.16.254.83, and it
may be related to their stuff or not, but it is doing queries on
polExxbled, though in these last traces I do not see the responses to
those, perhaps because they are running for a long period of time.

> The errors I see in dstrace for what they consider long transactions
> have to do with bad passwords, expired accounts, grace logins etc. All
> other searches look fine to me.
>
> According to the Siteminder admin they have had this issue long before I
> arrived. I am trying to assist them in solving this issue.


Simple enough; ask them why they are doing those queries, and then tell
them why they are doing those queries.

Also, while you are checking indexes, check for CN to have a value index.
As both Object Class ad CN are heavily used (on just about every object in
the tree normally) having indexes on them can help performance a lot.
Also please keep in mind that indexes are per-server, so while it is not
unusual for servers to all have the same indexes, that is because
something made them that way expliictly. iManager's index management
plugin lets you pretty-easily "copy" index configuration (one index at a
time) from one server to another, but that's as close as index consistency
gets, so just because one server has an Object Class or CN index does not
mean any other server will, so check them all, but especially the box that
is getting these queries (the box running iMonitor or ndstrace in this case).

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

On 2018-11-27 16:14, kbannister wrote:
>
> Working with eDirectory and LDAP for the first time in about six years.
> Siteminder, which I do not administer is showing several entries for
> users with a high processing time to authenticate via eDirectory LDAP.
> Looking at the ndstrace logs for a particular user that corresponds to
> the Siteminder times I see the following. Starting at 9:26:21 there
> are several entries in the ndstrace log for this user. Then at 9:26:30
> I see a -669 for this user. I will also see -220, 222, 49 and 53 errors
> for other users which correspond to the Siteminder logs. What exactly
> am I seeing. It looks to me they are authentication errors, bad PW,
> account expired etc. Why are there so many entries for a user to
> authenticate. And why would it take Siteminder so long to receive a
> result, positive or negative. How do I know the -669 error is really
> for the v0984 user. What exactly does a successful bind look like. In
> other words I could use some assistance reading these logs. They appear
> different than what I saw in the past. By the way, itÂ’s very good to be
> working with SLES and eDirectory after a six year hiatus!! Thanks in
> advance!
>
> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectclass=*)"
> attribute: "cn"
> attribute: "mail"
> attribute: "preferredlanguage"
> attribute: "uid"
> 09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending
> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
> 0x7ff20a80
> 09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending
> operation result 0:"":"" to connection 0x7ff20a80
> 09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) DoSearch on
> connection 0x804c6a80
> 09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) Search
> request:
>
> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectclass=*)"
> attribute: "cn"
> attribute: "mail"
>
> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectclass=*)"
> attribute: "cn"
> attribute: "mail"
> 09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Bind
> xxme:cn=VE051,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple
> 09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending
> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
> 0x7ff20a80
> 09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending
> operation result 0:"":"" to connection 0x7ff20a80
> 09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Sending
> operation result 0:"":"" to connection 0x7dccd880
> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) DoModify on
> connection 0x7dccc700
> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) modify: dn
> (cn=VE051,ou=XXX,ou=XX,o=XXXX)
> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66)
> modifications:
> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) replace:
> smPasswordData
> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) Sending
> operation result 0:"":"" to connection 0x7dccc700
> 09:26:21 42355700 LDAP: (172.16.35.174:49810)(0xbd0e:0x63) DoSearch on
> connection 0x7d08ea80
> 09:26:21 42355700 LDAP: (172.16.35.174:49810)(0xbd0e:0x63) Search
> request:
>
> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectclass=*)"
> attribute: "cn"
> attribute: "givenxxme"
> attribute: "mail"
> attribute: "sn"
> attribute: "uid"
> 09:26:27 41E50700 LDAP: (172.16.254.87:55852)(0x0018:0x63) Sending
> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
> 0x7ff20a80
> 09:26:27 41E50700 LDAP: (172.16.254.87:55852)(0x0018:0x63) Sending
> operation result 0:"":"" to connection 0x7ff20a80
> 09:26:28 3BDF7700 LDAP: (172.16.254.83:50526)(0x58965:0x63) DoSearch on
> connection 0x7f774a80
> 09:26:28 3BDF7700 LDAP: (172.16.254.83:50526)(0x58965:0x63) Search
> request:
> base: "ou=XX,o=XXXX"
> scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(&(uID=yvg5602)(objectClass=user)(polExxbled=Y))"
> no attributes
>
> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectclass=*)"
> attribute: "cn"
> attribute: "givenxxme"
> attribute: "sn"
> attribute: "uid"
> 09:26:30 34781700 LDAP: (172.16.254.87:55852)(0x001d:0x63) Sending
> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
> 0x7ff20a80
> 09:26:30 34781700 LDAP: (172.16.254.87:55852)(0x001d:0x63) Sending
> operation result 0:"":"" to connection 0x7ff20a80
> 09:26:30 33771700 LDAP: (172.16.254.87:64511)(0x0001:0x60) Failed to
> authenticate local on connection 0x825a1c00, err = failed authentication
> (-669)
> 09:26:30 33771700 LDAP: (172.16.254.87:64511)(0x0001:0x60) Sending
> operation result 49:"":"NDS error: failed authentication (-669)" to
> connection 0x825a1c00
> 09:26:30 44779700 LDAP: (172.16.254.87:64511)(0x0002:0x42) DoUnbind on
> connection 0x825a1c00
> 09:26:30 44779700 LDAP: Connection 0x825a1c00 closed
> 09:26:30 57327700 LDAP: (172.16.254.87:51549)(0x00cb:0x63) DoSearch on
> connection 0x7fbb7880
> 09:26:30 57327700 LDAP: (172.16.254.87:51549)(0x00cb:0x63) Search
> request:
> base: "ou=XXX,ou=XX,o=XXXX"
> scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
> filter: "(&(objectclass=inetOrgPerson)(cn=AGJ96))"
> no attributes
>
>

If I remember correctly there is a 3 second delay on failed
authentications by default (-669).


--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
0 Likes
Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

On 2018-11-28 09:28, alekz wrote:
> On 2018-11-27 16:14, kbannister wrote:
>>
>> Working with eDirectory and LDAP for the first time in about six years.
>> Siteminder, which I do not administer is showing several entries for
>> users with a high processing time to authenticate via eDirectory LDAP.
>> Looking at the ndstrace logs for a particular user that corresponds to
>> the Siteminder times I see the following.  Starting at 9:26:21  there
>> are several entries in the ndstrace log for this user.  Then at 9:26:30
>> I see a -669 for this user.  I will also see -220, 222, 49 and 53 errors
>> for other users which correspond to the Siteminder logs.  What exactly
>> am I seeing.  It looks to me they are authentication errors, bad PW,
>> account expired etc. Why are there so many entries for a user to
>> authenticate.  And why would it take Siteminder so long to receive a
>> result, positive or negative.  How do I know the -669 error is really
>> for the v0984 user.  What exactly does a successful bind look like.  In
>> other words I could use some assistance reading these logs.  They appear
>> different than what I saw in the past.  By the way, it’s very good to be
>> working with SLES and eDirectory after a six year hiatus!!  Thanks in
>> advance!
>>
>> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
>> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
>> filter: "(objectclass=*)"
>> attribute: "cn"
>> attribute: "mail"
>> attribute: "preferredlanguage"
>> attribute: "uid"
>> 09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending
>> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
>> 0x7ff20a80
>> 09:26:21 2C701700 LDAP: (172.16.254.87:55852)(0x000e:0x63) Sending
>> operation result 0:"":"" to connection 0x7ff20a80
>> 09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) DoSearch on
>> connection 0x804c6a80
>> 09:26:21 3AAE4700 LDAP: (172.16.254.87:61153)(0x05f0:0x63) Search
>> request:
>>
>> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
>> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
>> filter: "(objectclass=*)"
>> attribute: "cn"
>> attribute: "mail"
>>
>> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
>> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
>> filter: "(objectclass=*)"
>> attribute: "cn"
>> attribute: "mail"
>> 09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Bind
>> xxme:cn=VE051,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple
>> 09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending
>> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
>> 0x7ff20a80
>> 09:26:21 372AC700 LDAP: (172.16.254.87:55852)(0x0011:0x63) Sending
>> operation result 0:"":"" to connection 0x7ff20a80
>> 09:26:21 30A44700 LDAP: (172.16.35.173:49796)(0x04f0:0x60) Sending
>> operation result 0:"":"" to connection 0x7dccd880
>> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) DoModify on
>> connection 0x7dccc700
>> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) modify: dn
>> (cn=VE051,ou=XXX,ou=XX,o=XXXX)
>> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66)
>> modifications:
>> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66)    replace:
>> smPasswordData
>> 09:26:21 4063F700 LDAP: (172.16.35.173:49795)(0xb361:0x66) Sending
>> operation result 0:"":"" to connection 0x7dccc700
>> 09:26:21 42355700 LDAP: (172.16.35.174:49810)(0xbd0e:0x63) DoSearch on
>> connection 0x7d08ea80
>> 09:26:21 42355700 LDAP: (172.16.35.174:49810)(0xbd0e:0x63) Search
>> request:
>>
>> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
>> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
>> filter: "(objectclass=*)"
>> attribute: "cn"
>> attribute: "givenxxme"
>> attribute: "mail"
>> attribute: "sn"
>> attribute: "uid"
>> 09:26:27 41E50700 LDAP: (172.16.254.87:55852)(0x0018:0x63) Sending
>> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
>> 0x7ff20a80
>> 09:26:27 41E50700 LDAP: (172.16.254.87:55852)(0x0018:0x63) Sending
>> operation result 0:"":"" to connection 0x7ff20a80
>> 09:26:28 3BDF7700 LDAP: (172.16.254.83:50526)(0x58965:0x63) DoSearch on
>> connection 0x7f774a80
>> 09:26:28 3BDF7700 LDAP: (172.16.254.83:50526)(0x58965:0x63) Search
>> request:
>> base: "ou=XX,o=XXXX"
>> scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
>> filter: "(&(uID=yvg5602)(objectClass=user)(polExxbled=Y))"
>> no attributes
>>
>> base: "cn=v0984,ou=xxx,ou=xx,o=xxxx"
>> scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
>> filter: "(objectclass=*)"
>> attribute: "cn"
>> attribute: "givenxxme"
>> attribute: "sn"
>> attribute: "uid"
>> 09:26:30 34781700 LDAP: (172.16.254.87:55852)(0x001d:0x63) Sending
>> search result entry "cn=V0984,ou=XXX,ou=XX,o=XXXX" to connection
>> 0x7ff20a80
>> 09:26:30 34781700 LDAP: (172.16.254.87:55852)(0x001d:0x63) Sending
>> operation result 0:"":"" to connection 0x7ff20a80
>> 09:26:30 33771700 LDAP: (172.16.254.87:64511)(0x0001:0x60) Failed to
>> authenticate local on connection 0x825a1c00, err = failed authentication
>> (-669)
>> 09:26:30 33771700 LDAP: (172.16.254.87:64511)(0x0001:0x60) Sending
>> operation result 49:"":"NDS error: failed authentication (-669)" to
>> connection 0x825a1c00
>> 09:26:30 44779700 LDAP: (172.16.254.87:64511)(0x0002:0x42) DoUnbind on
>> connection 0x825a1c00
>> 09:26:30 44779700 LDAP: Connection 0x825a1c00 closed
>> 09:26:30 57327700 LDAP: (172.16.254.87:51549)(0x00cb:0x63) DoSearch on
>> connection 0x7fbb7880
>> 09:26:30 57327700 LDAP: (172.16.254.87:51549)(0x00cb:0x63) Search
>> request:
>> base: "ou=XXX,ou=XX,o=XXXX"
>> scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
>> filter: "(&(objectclass=inetOrgPerson)(cn=AGJ96))"
>> no attributes
>>
>>

> If I remember correctly there is a 3 second delay on failed
> authentications by default (-669).
>
>

Btw, the delay can be changed by editing the Login Policy.Security
object in iManager.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

On 11/29/2018 02:03 AM, alekz wrote:
>
> Btw, the delay can be changed by editing the Login Policy.Security object
> in iManager.


Yes, but it is generally a terrible idea, since it enables brute-force
attempts to work at a much faster rate. If something is slow because of
invalid credentials, fix the invalid credentials.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

On 2018-11-29 13:08, ab wrote:
> On 11/29/2018 02:03 AM, alekz wrote:
>>
>> Btw, the delay can be changed by editing the Login Policy.Security object
>> in iManager.

>
> Yes, but it is generally a terrible idea, since it enables brute-force
> attempts to work at a much faster rate. If something is slow because of
> invalid credentials, fix the invalid credentials.
>

Agree, but if you do something silly, like authenticate all users in a
single thread then the delay effectively blocks all authentication attempts.

It also depends on how exposed your LDAP server is, e.g. if only
SiteMinder can access the LDAP server and not the whole organization
then it might not be a big problem.

Of course you can always enable intruder lockout.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: ndstrace LDAP

Still parsing dstrace logs. What does this mean nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

Good question; it means work on the object itself if there is a referral,
I believe: https://ldapwiki.com/wiki/Manage%20DSA%20IT%20Control


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.