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
Highlighted
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
kab12312 Respected Contributor.
Respected Contributor.

Re: ndstrace LDAP

I think I can attribute the slow transaction in Siteminder to the Siteminder attributes, smDisabledFlag and or smPasswordData. In addition to searching on CN I will also see a search on smDisabledFlag and or smPasswordData. The only error, sort of, I see in the Siteminder log is, Execution time exceeded threshold. I don't know what this means. Siteminder reports the transaction taking 39 seconds. While the Siteminder Policy Server Trace file starts at 13:12:04 and ends at 13:13:43 I looked at the dstrace files from 13:12:04 to 13:13:49. These logs are very long as we have over 125k users using this LDAP server. (Yes, we have additional servers.) I have snipped the searches for the user MKM85. I'm thinking, I'll ask the Siteminder Admin, the different IP addresses are perhaps different Apps. That may be all the different searches logged. I'm also curious if the -669 refers to the user MKM85. What is the sequence of numbers before LDAP, i,e; 2FE38700 LDAP, 3F029700 LDAP. Does 2FE38700 belong to MKM85. What about 3F029700 that references the -669. Slowly I am getting there. I appreciate your help everyone!! To sum I believe the users password is either incorrect, expired, no PW at all or locked out, grace logins used etc and Siteminder is referncing all the various Apps that require authentication. Make sense maybe?

Siteminder snip if this can help:
13:12:04 – 	Pre processing new password – Authenticating user
13:12:43 - Execution time exceeded threshold
Have 1 Password Policies to apply SmPasswordCheck.cpp:97 CSmPasswordCheck::
Execution time exceeded threshold SmAuthUser::Authenticate
Execution time exceeded threshold. (CSmAuthUser::VerifyUserCredentials,
Execution time exceeded threshold. (CSmAuthUser::AuthenticateUserDir,
Processing Attribute [Property = cn
Sessioxxssurance is not exxbled
Evaluating 'OxxuthAccept' policy
SmSamlDataContext::~SmSamlDataContext: Cleaning up
Status: Authenticated.


Dstrace snip:
 base: "ou=XX,o=XXXX"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=mkm85)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:12:04 3AFE9700 LDAP: (172.16.35.179:49798)(0x31aa9:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x805df880
13:12:04 3AFE9700 LDAP: (172.16.35.179:49798)(0x31aa9:0x63) Sending operation result 0:"":"" to connection 0x805df880
13:12:04 40A43700 LDAP: (172.16.35.179:49798)(0x31aaa:0x63) DoSearch on connection 0x805df880
13:12:04 40A43700 LDAP: (172.16.35.179:49798)(0x31aaa:0x63) Search request:
base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
filter: "(generationQualifier=Fun)"
attribute: "objectclass

13:12:43 3053F700 LDAP: (172.16.35.179:49805)(0x1289:0x60) DoBind on connection 0x7f064e00
13:12:43 3053F700 LDAP: (172.16.35.179:49805)(0x1289:0x60) Bind xxme:cn=MKM85,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple

33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) DoModify on connection 0x805df880
13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) modify: dn (cn=MKM85,ou=XXX,ou=XX,o=XXXX)
13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) modifications:
13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) replace: smPasswordData
13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) Sending operation result 0:"":"" to connection 0x805df880

base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(objectclass=*)"
attribute: "cn"
13:13:21 34781700 LDAP: (172.16.35.174:49824)(0x5989c:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x7f994e00
13:13:21 34781700 LDAP: (172.16.35.174:49824)(0x5989c:0x63) Sending operation result 0:"":"" to connection 0x7f994e00

base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(objectclass=*)"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:13:49 392CC700 LDAP: (172.16.35.173:49821)(0x4f36a:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x7fd1c700
13:13:49 392CC700 LDAP: (172.16.35.173:49821)(0x4f36a:0x63) Sending operation result 0:"":"" to connection 0x7fd1c700

base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "objectClass"
attribute: "guid"
13:13:49 3CE07700 LDAP: (172.16.254.83:50555)(0x0c55:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
13:13:49 3CE07700 LDAP: (172.16.254.83:50555)(0x0c55:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x80666700
13:13:49 3CE07700 LDAP: (172.16.254.83:50555)(0x0c55:0x63) Sending operation result 0:"":"" to connection 0x80666700

13:13:49 383BD700 LDAP: (172.16.254.83:50555)(0x0c56:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x80666700
13:13:49 383BD700 LDAP: (172.16.254.83:50555)(0x0c56:0x63) Sending operation result 0:"":"" to connection 0x80666700

base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
scope:0 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "cn"
13:13:49 2F933700 LDAP: (172.16.254.83:50555)(0x0c57:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
13:13:49 2F933700 LDAP: (172.16.254.83:50555)(0x0c57:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x80666700

base: "o=XXXX"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(objectClass=groupofxxmes)(member=cn=MKM85,ou=XXX,ou=XX,o=XXXX))"
attribute: "objectClass"
attribute: "guid"
13:13:49 4053E700 LDAP: (172.16.254.83:50555)(0x0c58:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2

base: "ou=XXX,ou=XX,o=XXXX"
scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
filter: "(&(objectclass=inetOrgPerson)(cn=MKM85))"
no attributes
13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) Empty attribute list implies all user attributes
13:13:49 3F029700 LDAP: (172.16.254.87:54050)(0x0001:0x60) Failed to authenticate local on connection 0x7ee3f500, err = failed authentication (-669)
13:13:49 3F029700 LDAP: (172.16.254.87:54050)(0x0001:0x60) Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x7ee3f500
13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x804d6a80
13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) Sending operation result 0:"":"" to connection 0x804d6a80

base: "ou=XXX,ou=XX,o=xxxx"
scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
filter: "(&(objectclass=inetOrgPerson)(cn=MKM85))"
no attributes
13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) Empty attribute list implies all user attributes
13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x804d6a80
13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) Sending operation result 0:"":"" to connection 0x804d6a80
0 Likes
Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

Get us full logs and maybe we can tell if these are related to something
else, but I doubt it since I assume you sent us everything having to do
with MKM85, and nothing else that you sent us happened over this socket
(172.16.254.87 port 54050) meaning this is something else you happened to
catch but was somebody else's bad login.

On 11/30/2018 12:14 PM, ka12312 wrote:
> 13:13:49 3F029700 LDAP: (172.16.254.87:54050)(0x0001:0x60) Failed to authenticate local on connection 0x7ee3f500, err = failed authentication (-669)
> 13:13:49 3F029700 LDAP: (172.16.254.87:54050)(0x0001:0x60) Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x7ee3f500


--
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 11/30/2018 2:14 PM, ka12312 wrote:
>
> I think I can attribute the slow transaction in Siteminder to the
> Siteminder attributes, smDisabledFlag and or smPasswordData. In
> addition to searching on CN I will also see a search on smDisabledFlag
> and or smPasswordData. The only error, sort of, I see in the Siteminder


You know, you can have some fun with this... In an eDirectory LDAP
server you can re-map external to internal attribute names.

So you could on the LDAP Server or Group (I honestly never remember
which but I am right 50% of the time) there is an Attribute map option
in iManager.

Make Login Disabled map to smDisabledFlag and maybe something else that
always exists on the user to smPasswordData so that it finds a result
every time.

> log is, Execution time exceeded threshold. I don't know what this
> means. Siteminder reports the transaction taking 39 seconds. While the
> Siteminder Policy Server Trace file starts at 13:12:04 and ends at
> 13:13:43 I looked at the dstrace files from 13:12:04 to 13:13:49. These
> logs are very long as we have over 125k users using this LDAP server.
> (Yes, we have additional servers.) I have snipped the searches for the
> user MKM85. I'm thinking, I'll ask the Siteminder Admin, the different
> IP addresses are perhaps different Apps. That may be all the different
> searches logged. I'm also curious if the -669 refers to the user MKM85.
> What is the sequence of numbers before LDAP, i,e; 2FE38700 LDAP,
> 3F029700 LDAP. Does 2FE38700 belong to MKM85. What about 3F029700 that
> references the -669. Slowly I am getting there. I appreciate your help
> everyone!! To sum I believe the users password is either incorrect,
> expired, no PW at all or locked out, grace logins used etc and
> Siteminder is referncing all the various Apps that require
> authentication. Make sense maybe?
>
> Siteminder snip if this can help:
> Code:
> --------------------
> 13:12:04 � Pre processing new password � Authenticating user
> 13:12:43 - Execution time exceeded threshold
> Have 1 Password Policies to apply SmPasswordCheck.cpp:97 CSmPasswordCheck::
> Execution time exceeded threshold SmAuthUser::Authenticate
> Execution time exceeded threshold. (CSmAuthUser::VerifyUserCredentials,
> Execution time exceeded threshold. (CSmAuthUser::AuthenticateUserDir,
> Processing Attribute [Property = cn
> Sessioxxssurance is not exxbled
> Evaluating 'OxxuthAccept' policy
> SmSamlDataContext::~SmSamlDataContext: Cleaning up
> Status: Authenticated.
>
> --------------------
>
>
> Dstrace snip:
> Code:
> --------------------
> base: "ou=XX,o=XXXX"
> scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
> filter: "(&(cn=mkm85)(objectclass=inetOrgPerson))"
> attribute: "smPasswordData"
> attribute: "cn"
> attribute: "smDisabledFlag"
> attribute: "objectclass"
> 13:12:04 3AFE9700 LDAP: (172.16.35.179:49798)(0x31aa9:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x805df880
> 13:12:04 3AFE9700 LDAP: (172.16.35.179:49798)(0x31aa9:0x63) Sending operation result 0:"":"" to connection 0x805df880
> 13:12:04 40A43700 LDAP: (172.16.35.179:49798)(0x31aaa:0x63) DoSearch on connection 0x805df880
> 13:12:04 40A43700 LDAP: (172.16.35.179:49798)(0x31aaa:0x63) Search request:
> base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
> scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:1
> filter: "(generationQualifier=Fun)"
> attribute: "objectclass
>
> 13:12:43 3053F700 LDAP: (172.16.35.179:49805)(0x1289:0x60) DoBind on connection 0x7f064e00
> 13:12:43 3053F700 LDAP: (172.16.35.179:49805)(0x1289:0x60) Bind xxme:cn=MKM85,ou=XXX,ou=XX,o=XXXX, version:3, authentication:simple
>
> 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) DoModify on connection 0x805df880
> 13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) modify: dn (cn=MKM85,ou=XXX,ou=XX,o=XXXX)
> 13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) modifications:
> 13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) replace: smPasswordData
> 13:12:43 33D77700 LDAP: (172.16.35.179:49798)(0x31b56:0x66) Sending operation result 0:"":"" to connection 0x805df880
>
> base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
> scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
> filter: "(objectclass=*)"
> attribute: "cn"
> 13:13:21 34781700 LDAP: (172.16.35.174:49824)(0x5989c:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x7f994e00
> 13:13:21 34781700 LDAP: (172.16.35.174:49824)(0x5989c:0x63) Sending operation result 0:"":"" to connection 0x7f994e00
>
> base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
> scope:0 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
> filter: "(objectclass=*)"
> attribute: "smDisabledFlag"
> attribute: "objectclass"
> 13:13:49 392CC700 LDAP: (172.16.35.173:49821)(0x4f36a:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x7fd1c700
> 13:13:49 392CC700 LDAP: (172.16.35.173:49821)(0x4f36a:0x63) Sending operation result 0:"":"" to connection 0x7fd1c700
>
> base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
> scope:0 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectClass=*)"
> attribute: "objectClass"
> attribute: "guid"
> 13:13:49 3CE07700 LDAP: (172.16.254.83:50555)(0x0c55:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
> 13:13:49 3CE07700 LDAP: (172.16.254.83:50555)(0x0c55:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x80666700
> 13:13:49 3CE07700 LDAP: (172.16.254.83:50555)(0x0c55:0x63) Sending operation result 0:"":"" to connection 0x80666700
>
> 13:13:49 383BD700 LDAP: (172.16.254.83:50555)(0x0c56:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x80666700
> 13:13:49 383BD700 LDAP: (172.16.254.83:50555)(0x0c56:0x63) Sending operation result 0:"":"" to connection 0x80666700
>
> base: "cn=MKM85,ou=XXX,ou=XX,o=XXXX"
> scope:0 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectClass=*)"
> attribute: "cn"
> 13:13:49 2F933700 LDAP: (172.16.254.83:50555)(0x0c57:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
> 13:13:49 2F933700 LDAP: (172.16.254.83:50555)(0x0c57:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x80666700
>
> base: "o=XXXX"
> scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(&(objectClass=groupofxxmes)(member=cn=MKM85,ou=XXX,ou=XX,o=XXXX))"
> attribute: "objectClass"
> attribute: "guid"
> 13:13:49 4053E700 LDAP: (172.16.254.83:50555)(0x0c58:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
>
> base: "ou=XXX,ou=XX,o=XXXX"
> scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
> filter: "(&(objectclass=inetOrgPerson)(cn=MKM85))"
> no attributes
> 13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
> 13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) Empty attribute list implies all user attributes
> 13:13:49 3F029700 LDAP: (172.16.254.87:54050)(0x0001:0x60) Failed to authenticate local on connection 0x7ee3f500, err = failed authentication (-669)
> 13:13:49 3F029700 LDAP: (172.16.254.87:54050)(0x0001:0x60) Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x7ee3f500
> 13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x804d6a80
> 13:13:49 2FE38700 LDAP: (172.16.254.83:53696)(0x15a7:0x63) Sending operation result 0:"":"" to connection 0x804d6a80
>
> base: "ou=XXX,ou=XX,o=xxxx"
> scope:2 dereference:3 sizelimit:999 timelimit:0 attrsonly:0
> filter: "(&(objectclass=inetOrgPerson)(cn=MKM85))"
> no attributes
> 13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
> 13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) Empty attribute list implies all user attributes
> 13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) Sending search result entry "cn=MKM85,ou=XXX,ou=XX,o=XXXX" to connection 0x804d6a80
> 13:13:49 2C600700 LDAP: (172.16.254.83:53696)(0x15a8:0x63) Sending operation result 0:"":"" to connection 0x804d6a80
>
> --------------------
>
>


0 Likes
Knowledge Partner
Knowledge Partner

Re: ndstrace LDAP

On 12/01/2018 04:03 PM, Geoffrey Carman wrote:
> On 11/30/2018 2:14 PM, ka12312 wrote:
>>
>> I think I can attribute the slow transaction in Siteminder to the
>> Siteminder attributes, smDisabledFlag and or smPasswordData. In
>> addition to searching on CN I will also see a search on smDisabledFlag
>> and or smPasswordData. The only error, sort of, I see in the Siteminder

>
> So you could on the LDAP Server or Group (I honestly never remember which


It's the group. The way I remember it is that this is generally something
you want applied to many servers at once so you have a consistent LDAP
interface for applications querying eDirectory, and having a single group
with all of these attribute (and class) mappings setup means you can link
all LDAP servers (one per NCP/eDirectory servers) linked, so they are all
consistent whenever you change this kind of thing. Things handled on the
per-server side include TLS/SSL certificates (different Subject values
make it prudent to have different certificates in place), trace/screen
settings (though I wish they were all consistent, that's not always
desirable), etc.

> but I am right 50% of the time) there is an Attribute map option in iManager.


Canadian math and humor are doing well. 🙂

> Make Login Disabled map to smDisabledFlag and maybe something else that


Assuming smDisabledFlag isn't some kind of way to disable ONLY SiteMinder.
Considering there is clearly custom schema involved, it seems likely that
eDirectory SHOULD have this actual attribute present, and it si expected
to be managed separately from the user object's main login option.

> always exists on the user to smPasswordData so that it finds a result
> every time.


These may actually hurt performance, as going for just any old attribute
(populated or not) means that eDirectory must look for objects with that
attribute. I would recommend at least testing the performance difference
from an LDAP perspective (not via SiteMinder but via something like
'ldapsearch' or Apache Directory Studio) to see if it is faster to find
results for things which are not in schema at all or for things which are
in schema but merely unpopulated. There could easily be optimizations in
eDirectory to automatically return properly if an attribute is not present
in schema is part of a required LDAP filter, but doing a search on
anything possible per the class means actually checking the data, and
without an index defined that may hurt performance.

Doing a test just now in a tree with 100,000 objects or so a search on
bogusAttr=asdf returned immediately, though the attribute does not exist
anywhere in schema, thus has no index. A similar search on
description=asdf took three (3) seconds to return zero (0) objects. Doing
a second search on each of those yielded the same results, so the
description search was still slow, but then searching for both at the same
time came back immediately, so I think my understanding (described above)
is correct, meaning if the attribute really is not in schema then
eDirectory should do a good job of returning nothing quickly.


(bogusAttr=asdf) #immediate return
(description=asdf) #few seconds to return nothing
(&(bogusAttr=asdf)(description=asdf)) #immediate return
(|(bogusAttr=asdf)(description=asdf)) #few seconds to return nothing


--
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

I met with the Siteminder Admin today. He will investigate the smPasswordData modifications since it is a Siteminder attribute and causes the slowness. I will let you know the outcome. Thank you again!! I so appreciate it!!

One more question if I may. I see most entries in dstrace as this and I assume it means a successful search and authentication:

13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) DoSearch on connection 0x805df880
13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Search request:
base: "ou=xx,o=xxxx"
scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
filter: "(&(cn=a4408)(objectclass=inetOrgPerson))"
attribute: "smPasswordData"
attribute: "cn"
attribute: "smDisabledFlag"
attribute: "objectclass"
13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Sending search result entry "cn=A4408,ou=xx,ou=xx,o=xxxx" to connection 0x805df880
13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Sending operation result 0:"":"" to connection 0x805df880


Then I will see this, only on the cns which have the smPasswordData modification. Why is that the only Bind I see in a zillion dstrace entries. It is for the same cn=A4408 which had an earlier smPasswordData modification Thank you!!

13:12:43 50830700 LDAP: (172.16.35.179:49805)(0x128c:0x60) DoBind on connection 0x7f064e00
13:12:43 50830700 LDAP: (172.16.35.179:49805)(0x128c:0x60) Bind name:cn=A4408,ou=xx,ou=xx,o=xxxx, version:3, authentication:simple



ab;2491784 wrote:
On 12/01/2018 04:03 PM, Geoffrey Carman wrote:
> On 11/30/2018 2:14 PM, ka12312 wrote:
>>
>> I think I can attribute the slow transaction in Siteminder to the
>> Siteminder attributes, smDisabledFlag and or smPasswordData. In
>> addition to searching on CN I will also see a search on smDisabledFlag
>> and or smPasswordData. The only error, sort of, I see in the Siteminder

>
> So you could on the LDAP Server or Group (I honestly never remember which


It's the group. The way I remember it is that this is generally something
you want applied to many servers at once so you have a consistent LDAP
interface for applications querying eDirectory, and having a single group
with all of these attribute (and class) mappings setup means you can link
all LDAP servers (one per NCP/eDirectory servers) linked, so they are all
consistent whenever you change this kind of thing. Things handled on the
per-server side include TLS/SSL certificates (different Subject values
make it prudent to have different certificates in place), trace/screen
settings (though I wish they were all consistent, that's not always
desirable), etc.

> but I am right 50% of the time) there is an Attribute map option in iManager.


Canadian math and humor are doing well. 🙂

> Make Login Disabled map to smDisabledFlag and maybe something else that


Assuming smDisabledFlag isn't some kind of way to disable ONLY SiteMinder.
Considering there is clearly custom schema involved, it seems likely that
eDirectory SHOULD have this actual attribute present, and it si expected
to be managed separately from the user object's main login option.

> always exists on the user to smPasswordData so that it finds a result
> every time.


These may actually hurt performance, as going for just any old attribute
(populated or not) means that eDirectory must look for objects with that
attribute. I would recommend at least testing the performance difference
from an LDAP perspective (not via SiteMinder but via something like
'ldapsearch' or Apache Directory Studio) to see if it is faster to find
results for things which are not in schema at all or for things which are
in schema but merely unpopulated. There could easily be optimizations in
eDirectory to automatically return properly if an attribute is not present
in schema is part of a required LDAP filter, but doing a search on
anything possible per the class means actually checking the data, and
without an index defined that may hurt performance.

Doing a test just now in a tree with 100,000 objects or so a search on
bogusAttr=asdf returned immediately, though the attribute does not exist
anywhere in schema, thus has no index. A similar search on
description=asdf took three (3) seconds to return zero (0) objects. Doing
a second search on each of those yielded the same results, so the
description search was still slow, but then searching for both at the same
time came back immediately, so I think my understanding (described above)
is correct, meaning if the attribute really is not in schema then
eDirectory should do a good job of returning nothing quickly.


(bogusAttr=asdf) #immediate return
(description=asdf) #few seconds to return nothing
(&(bogusAttr=asdf)(description=asdf)) #immediate return
(|(bogusAttr=asdf)(description=asdf)) #few seconds to return nothing


--
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-12-04 21:04, ka12312 wrote:
>
> I met with the Siteminder Admin today. He will investigate the
> smPasswordData modifications since it is a Siteminder attribute and
> causes the slowness. I will let you know the outcome. Thank you
> again!! I so appreciate it!!
>
> One more question if I may. I see most entries in dstrace as this and I
> assume it means a successful search and authentication:
>
>
> Code:
> --------------------
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) DoSearch on connection 0x805df880
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Search request:
> base: "ou=xx,o=xxxx"
> scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
> filter: "(&(cn=a4408)(objectclass=inetOrgPerson))"
> attribute: "smPasswordData"
> attribute: "cn"
> attribute: "smDisabledFlag"
> attribute: "objectclass"
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Sending search result entry "cn=A4408,ou=xx,ou=xx,o=xxxx" to connection 0x805df880
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Sending operation result 0:"":"" to connection 0x805df880
>
> --------------------
>
>
> Then I will see this, only on the cns which have the smPasswordData
> modification. Why is that the only Bind I see in a zillion dstrace
> entries. It is for the same cn=A4408 which had an earlier
> smPasswordData modification Thank you!!
>
>
> Code:
> --------------------
> 13:12:43 50830700 LDAP: (172.16.35.179:49805)(0x128c:0x60) DoBind on connection 0x7f064e00
> 13:12:43 50830700 LDAP: (172.16.35.179:49805)(0x128c:0x60) Bind name:cn=A4408,ou=xx,ou=xx,o=xxxx, version:3, authentication:simple
>
> --------------------
>
>
>
> ab;2491784 Wrote:
>> On 12/01/2018 04:03 PM, Geoffrey Carman wrote:
>>> On 11/30/2018 2:14 PM, ka12312 wrote:
>>>>
>>>> I think I can attribute the slow transaction in Siteminder to the
>>>> Siteminder attributes, smDisabledFlag and or smPasswordData. In
>>>> addition to searching on CN I will also see a search on

>> smDisabledFlag
>>>> and or smPasswordData. The only error, sort of, I see in the

>> Siteminder
>>>
>>> So you could on the LDAP Server or Group (I honestly never remember

>> which
>>
>> It's the group. The way I remember it is that this is generally
>> something
>> you want applied to many servers at once so you have a consistent LDAP
>> interface for applications querying eDirectory, and having a single
>> group
>> with all of these attribute (and class) mappings setup means you can
>> link
>> all LDAP servers (one per NCP/eDirectory servers) linked, so they are
>> all
>> consistent whenever you change this kind of thing. Things handled on
>> the
>> per-server side include TLS/SSL certificates (different Subject values
>> make it prudent to have different certificates in place), trace/screen
>> settings (though I wish they were all consistent, that's not always
>> desirable), etc.
>>
>>> but I am right 50% of the time) there is an Attribute map option in

>> iManager.
>>
>> Canadian math and humor are doing well. 🙂
>>
>>> Make Login Disabled map to smDisabledFlag and maybe something else

>> that
>>
>> Assuming smDisabledFlag isn't some kind of way to disable ONLY
>> SiteMinder.
>> Considering there is clearly custom schema involved, it seems likely
>> that
>> eDirectory SHOULD have this actual attribute present, and it si
>> expected
>> to be managed separately from the user object's main login option.
>>
>>> always exists on the user to smPasswordData so that it finds a result
>>> every time.

>>
>> These may actually hurt performance, as going for just any old
>> attribute
>> (populated or not) means that eDirectory must look for objects with
>> that
>> attribute. I would recommend at least testing the performance
>> difference
>> from an LDAP perspective (not via SiteMinder but via something like
>> 'ldapsearch' or Apache Directory Studio) to see if it is faster to find
>> results for things which are not in schema at all or for things which
>> are
>> in schema but merely unpopulated. There could easily be optimizations
>> in
>> eDirectory to automatically return properly if an attribute is not
>> present
>> in schema is part of a required LDAP filter, but doing a search on
>> anything possible per the class means actually checking the data, and
>> without an index defined that may hurt performance.
>>
>> Doing a test just now in a tree with 100,000 objects or so a search on
>> bogusAttr=asdf returned immediately, though the attribute does not
>> exist
>> anywhere in schema, thus has no index. A similar search on
>> description=asdf took three (3) seconds to return zero (0) objects.
>> Doing
>> a second search on each of those yielded the same results, so the
>> description search was still slow, but then searching for both at the
>> same
>> time came back immediately, so I think my understanding (described
>> above)
>> is correct, meaning if the attribute really is not in schema then
>> eDirectory should do a good job of returning nothing quickly.
>>
>>>

> Code:
> --------------------
> > >

> > (bogusAttr=asdf) #immediate return
> > (description=asdf) #few seconds to return nothing
> > (&(bogusAttr=asdf)(description=asdf)) #immediate return
> > (|(bogusAttr=asdf)(description=asdf)) #few seconds to return nothing
> >

> --------------------
>>>

>>
>> --
>> 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.

>
>

I guess what you are seeing is SM first searching for the user and
retrieving some attributes.
Then it tries to bind as that user to verify if the user is allowed to
login to the LDAP directory.

--
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 12/04/2018 01:04 PM, ka12312 wrote:
>
> I met with the Siteminder Admin today. He will investigate the
> smPasswordData modifications since it is a Siteminder attribute and
> causes the slowness.


Just to be sure we all understand, the modification doesn't cause any
slowness, as mentioned before; it happens in something less than one (1)
second, probably less than 1/100 of a second. If this is used in a
search, and is not indexed, then that matters to the time taken, but the
actual modification clearly does not.

> One more question if I may. I see most entries in dstrace as this and I
> assume it means a successful search and authentication:
>
>
> Code:
> --------------------
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) DoSearch on connection 0x805df880
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Search request:
> base: "ou=xx,o=xxxx"
> scope:2 dereference:0 sizelimit:0 timelimit:30 attrsonly:0
> filter: "(&(cn=a4408)(objectclass=inetOrgPerson))"
> attribute: "smPasswordData"
> attribute: "cn"
> attribute: "smDisabledFlag"
> attribute: "objectclass"
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Sending search result entry "cn=A4408,ou=xx,ou=xx,o=xxxx" to connection 0x805df880
> 13:12:13 3A9E3700 LDAP: (172.16.35.179:49798)(0x31ac8:0x63) Sending operation result 0:"":"" to connection 0x805df880
>
> --------------------
>
> Then I will see this, only on the cns which have the smPasswordData
> modification. Why is that the only Bind I see in a zillion dstrace
> entries. It is for the same cn=A4408 which had an earlier
> smPasswordData modification Thank you!!
>
> Code:
> --------------------
> 13:12:43 50830700 LDAP: (172.16.35.179:49805)(0x128c:0x60) DoBind on connection 0x7f064e00
> 13:12:43 50830700 LDAP: (172.16.35.179:49805)(0x128c:0x60) Bind name:cn=A4408,ou=xx,ou=xx,o=xxxx, version:3, authentication:simple
>
> --------------------


Good question; why does SiteMinder do that? Hopefully that too can be
answered by them since this has nothing to do with general LDAP stuff. A
bind is a single operation, those last two lines, and may only have a few
(as in single-digits few) lines before or after to setup the connection,
even with TLS/SSL involved, so everything else is not part of the bind.
All of the searches, modifications, etc. are not part of the bind. They
may be related to the bind inasmuch as SiteMinder does other stuff before
or after the bind, but that's not the bind, that is other stuff SiteMinder
has decided to do and is now doing. Those things may impact overall login
times, of course, but eDirectory cannot tell you the why as much as the what.

--
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 11/30/2018 02:28 AM, alekz wrote:
> Agree, but if you do something silly, like authenticate all users in a
> single thread then the delay effectively blocks all authentication attempts.


Good point, but some software I would hope yo would assume is not "silly"
(where "silly" must be a synonym for grotesquely designed), and something
like SiteMinder is big enough surely they have a connection pool for this
kind of thing. If not, it should be tossed out like the high school
learning exercise it would be.

> 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.


Possibly, though I think too often people read this and think, "If the box
is not exposed to the Internet" then it's okay to soften it up, but really
being exposed to humans or their computers at all, even behind corporate
firewalls, is just as big a problem. If it is ONLY SiteMinder accessing
it due to firewalls and such, perhaps that's an option, but if this is an
option being considered to work around a horrible design in SiteMInder
(single thread for all binds) then it would be better if SiteMinder was
tossed out as mentioned above. Again, I doubt that is the case at all
here; it is much more likely that SiteMinder is doing a lot of things
along with the password change attempt and those other things are slow,
perhaps due to a missing index.

> Of course you can always enable intruder lockout.


That might help, but I still think it would be better to fix the problem
than to try to work around new problems when working around the original
problem. None of this matters if something other than the bind is slow,
and I think the report is lots of slowness, not just three seconds, on a
password change, not on a login.

--
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.