danb1 Absent Member.
Absent Member.
2585 views

login password not honoring caps

We have a weird issue with Self Service Password Reset portal.

We are running the latest version 4.1.0.4 on a Windows 2012R2 server.
It is connected to our Edirectory.

Here is the issue we just discovered. I don't know if it's always been there or something new with version 4.1.0.4

In Edirectory my password has capital letters in it. When I log into Edirectory for a PC or even log into Imanager i have to make sure I have my password correct with the capital letters in it.

We have noticed when logging into Self Service Password Reset portal it uses the Edirectory password but doesn't seem to care if you use caps in your password or not.
So for example....

Bob has a password of TestMyPassword.12345! When logging into Edirectory Bob has to enter the password just like this in order to login.

But....when logging into the Self Service Password Reset portal Bob can login with password testmypassword.12345!

Is there something I am missing? Does this happen for other users running version 4.1.0.4 on a Windows server?

Thanks for any help.
0 Likes
26 Replies
Knowledge Partner
Knowledge Partner

Re: login password not honoring caps

On 8/2/2017 2:34 PM, danb1 wrote:
>
> We have a weird issue with Self Service Password Reset portal.
>
> We are running the latest version 4.1.0.4 on a Windows 2012R2 server.
> It is connected to our Edirectory.
>
> Here is the issue we just discovered. I don't know if it's always been
> there or something new with version 4.1.0.4
>
> In Edirectory my password has capital letters in it. When I log into
> Edirectory for a PC or even log into Imanager i have to make sure I have
> my password correct with the capital letters in it.
>
> We have noticed when logging into Self Service Password Reset portal it
> uses the Edirectory password but doesn't seem to care if you use caps in
> your password or not.
> So for example....
>
> Bob has a password of TestMyPassword.12345! When logging into
> Edirectory Bob has to enter the password just like this in order to
> login.
>
> But....when logging into the Self Service Password Reset portal Bob can
> login with password testmypassword.12345!
>
> Is there something I am missing? Does this happen for other users
> running version 4.1.0.4 on a Windows server?


Are you pointing SSPR against your eDirectory? Sounds like it. Are you
syncing your UP to NDS password? NDS password is NOT case sensitive,
but UP can be if you set it thusly.

So looks like you are logging in with NDS password first, somehow.
Perhaps it is trying UP and falling back to NDS if that fails?



0 Likes
Knowledge Partner
Knowledge Partner

Re: login password not honoring caps

There is also a setting to make UPs case-insensitive, but I would expect
that to apply everywhere. Still, your best bet is probably to get
ndstrace output from the box where you authenticate (where SSPR is
pointed) using something like the following from the shell:


ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap +nmas +auth
set dstrace=*m9999999
dstrace file on
set dstrace=*r
#perform test here
dstrace file off
quit


Post the ndstrace.log file located (by default) at
/var/opt/novell/eDirectory/log/ndstrace.log and we'll see what shows up.

--
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
danb1 Absent Member.
Absent Member.

Re: login password not honoring caps

ab;2463315 wrote:
There is also a setting to make UPs case-insensitive, but I would expect
that to apply everywhere. Still, your best bet is probably to get
ndstrace output from the box where you authenticate (where SSPR is
pointed) using something like the following from the shell:


ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap +nmas +auth
set dstrace=*m9999999
dstrace file on
set dstrace=*r
#perform test here
dstrace file off
quit


Post the ndstrace.log file located (by default) at
/var/opt/novell/eDirectory/log/ndstrace.log and we'll see what shows up.

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


Thank you.
I will run a ndstrace and get it posted.
0 Likes
danb1 Absent Member.
Absent Member.

Re: login password not honoring caps

danb1;2463319 wrote:
Thank you.
I will run a ndstrace and get it posted.


Here is a ldap trace from SSPR and an NDS trace from the OES server.
The user I am using to test is dayp

Let me know if you see anything.
Thanks for everyone's help!
0 Likes
Knowledge Partner
Knowledge Partner

Re: login password not honoring caps

On 8/3/2017 8:34 AM, danb1 wrote:
>
> danb1;2463319 Wrote:
>> Thank you.
>> I will run a ndstrace and get it posted.58995900

>
> Here is a ldap trace from SSPR and an NDS trace from the OES server.
> The user I am using to test is dayp


In iManager, LDAP Options (I always forget if it is server or group, I
think LDAP Server) there is a tracing option. Tick everything on and
try again.

Also enable +NMAS please.
0 Likes
danb1 Absent Member.
Absent Member.

Re: login password not honoring caps

geoffc;2463314 wrote:
On 8/2/2017 2:34 PM, danb1 wrote:
>
> We have a weird issue with Self Service Password Reset portal.
>
> We are running the latest version 4.1.0.4 on a Windows 2012R2 server.
> It is connected to our Edirectory.
>
> Here is the issue we just discovered. I don't know if it's always been
> there or something new with version 4.1.0.4
>
> In Edirectory my password has capital letters in it. When I log into
> Edirectory for a PC or even log into Imanager i have to make sure I have
> my password correct with the capital letters in it.
>
> We have noticed when logging into Self Service Password Reset portal it
> uses the Edirectory password but doesn't seem to care if you use caps in
> your password or not.
> So for example....
>
> Bob has a password of TestMyPassword.12345! When logging into
> Edirectory Bob has to enter the password just like this in order to
> login.
>
> But....when logging into the Self Service Password Reset portal Bob can
> login with password testmypassword.12345!
>
> Is there something I am missing? Does this happen for other users
> running version 4.1.0.4 on a Windows server?


Are you pointing SSPR against your eDirectory? Sounds like it. Are you
syncing your UP to NDS password? NDS password is NOT case sensitive,
but UP can be if you set it thusly.

So looks like you are logging in with NDS password first, somehow.
Perhaps it is trying UP and falling back to NDS if that fails?



We do have SSPR pointing to eDirectory.
We also have UP setup and we have the check box checked for.. Synchronize NDS password when setting Universal Password
0 Likes
Knowledge Partner
Knowledge Partner

Re: login password not honoring caps

>> So looks like you are logging in with NDS password first, somehow.
>> Perhaps it is trying UP and falling back to NDS if that fails?

>
>
> We do have SSPR pointing to eDirectory.
> We also have UP setup and we have the check box checked for..
> Synchronize NDS password when setting Universal Password


I forget the SSPR settings, there are so many. Go look at the
eDirectory settings and look at the options. I suspect one is related.

0 Likes
danb1 Absent Member.
Absent Member.

Re: login password not honoring caps

geoffc;2463329 wrote:
>> So looks like you are logging in with NDS password first, somehow.
>> Perhaps it is trying UP and falling back to NDS if that fails?

>
>
> We do have SSPR pointing to eDirectory.
> We also have UP setup and we have the check box checked for..
> Synchronize NDS password when setting Universal Password


I forget the SSPR settings, there are so many. Go look at the
eDirectory settings and look at the options. I suspect one is related.


There are a lot of settings. I double checked the eDirectory settings and nothing is jumping out at me.
I also went through every setting and still nothing jumping out at me. I think it has to be something on the SSPR side cause outside of the portal everything works like it should. Not 100% sure though.
Thanks for your help!
0 Likes
Knowledge Partner
Knowledge Partner

Re: login password not honoring caps

On 8/3/2017 8:44 AM, danb1 wrote:
>
> geoffc;2463329 Wrote:
>>>> So looks like you are logging in with NDS password first, somehow.
>>>> Perhaps it is trying UP and falling back to NDS if that fails?
>>>
>>>
>>> We do have SSPR pointing to eDirectory.
>>> We also have UP setup and we have the check box checked for..
>>> Synchronize NDS password when setting Universal Password

>>
>> I forget the SSPR settings, there are so many. Go look at the
>> eDirectory settings and look at the options. I suspect one is related.

>
> There are a lot of settings. I double checked the eDirectory settings
> and nothing is jumping out at me.
> I also went through every setting and still nothing jumping out at me. I
> think it has to be something on the SSPR side cause outside of the
> portal everything works like it should. Not 100% sure though.
> Thanks for your help!


How old is your eDirectory? Specifically the replica your SSPR is using
for user data?

There is a setting NMAS_FIRST_LOGIN or somesuch that is set by eDir as
of like 8.7 or so and on wards. So if you had an ancient eDir and this
env setting was not set, it would work like this. It seems incredibly
unlikely, but who knows.


0 Likes
danb1 Absent Member.
Absent Member.

Re: login password not honoring caps

geoffc;2463370 wrote:
On 8/3/2017 8:44 AM, danb1 wrote:
>
> geoffc;2463329 Wrote:
>>>> So looks like you are logging in with NDS password first, somehow.
>>>> Perhaps it is trying UP and falling back to NDS if that fails?
>>>
>>>
>>> We do have SSPR pointing to eDirectory.
>>> We also have UP setup and we have the check box checked for..
>>> Synchronize NDS password when setting Universal Password

>>
>> I forget the SSPR settings, there are so many. Go look at the
>> eDirectory settings and look at the options. I suspect one is related.

>
> There are a lot of settings. I double checked the eDirectory settings
> and nothing is jumping out at me.
> I also went through every setting and still nothing jumping out at me. I
> think it has to be something on the SSPR side cause outside of the
> portal everything works like it should. Not 100% sure though.
> Thanks for your help!


How old is your eDirectory? Specifically the replica your SSPR is using
for user data?

There is a setting NMAS_FIRST_LOGIN or somesuch that is set by eDir as
of like 8.7 or so and on wards. So if you had an ancient eDir and this
env setting was not set, it would work like this. It seems incredibly
unlikely, but who knows.


Here is a new ndstrace with the options you wanted. Let me know if I missed anything but think I got it correct.
Our eDirectory is version 8.8 SP8 we are running on OES 11 SP3. I do need to apply the May, June and July maintenance updates/patches.
I may do those early tomorrow morning before staff get in or this weekend for sure.

Thanks again for your help!
0 Likes
danb1 Absent Member.
Absent Member.

Re: login password not honoring caps

In the SSPR log I see this ERROR. Not sure if this is related or not.

August 3, 2017 at 8:19:47 AM Central Standard Time, ERROR, state.CryptoCookieBeanImpl, {27187,bunnissd} error reading existing LoginServletBean cookie bean: 5076 ERROR_CRYPT_ERROR (unexpected error performing simple decrypt operation: 5076 ERROR_CRYPT_ERROR (unexpected error performing simple decrypt operation: Tag mismatch!)) [10.200.11.200]
0 Likes
Knowledge Partner
Knowledge Partner

Re: login password not honoring caps

On 8/3/2017 9:24 AM, danb1 wrote:
>
> In the SSPR log I see this ERROR. Not sure if this is related or not.
>
> August 3, 2017 at 8:19:47 AM Central Standard Time, ERROR,
> state.CryptoCookieBeanImpl, {27187,bunnissd} error reading existing
> LoginServletBean cookie bean: 5076 ERROR_CRYPT_ERROR (unexpected error
> performing simple decrypt operation: 5076 ERROR_CRYPT_ERROR (unexpected
> error performing simple decrypt operation: Tag mismatch!))
> [10.200.11.200]


Maybe, but more likely it does not like something in the pwmResponseSet
decrypt, which is a smidgen odd.

0 Likes
Knowledge Partner
Knowledge Partner

Re: login password not honoring caps

>> How old is your eDirectory? Specifically the replica your SSPR is
>> using
>> for user data?
>>
>> There is a setting NMAS_FIRST_LOGIN or somesuch that is set by eDir as
>> of like 8.7 or so and on wards. So if you had an ancient eDir and this
>> env setting was not set, it would work like this. It seems incredibly
>> unlikely, but who knows.5901

>
> Here is a new ndstrace with the options you wanted. Let me know if I
> missed anything but think I got it correct.
> Our eDirectory is version 8.8 SP8 we are running on OES 11 SP3. I do
> need to apply the May, June and July maintenance updates/patches.


This is new enough, so discard that odd thought.

Side note: What the heck is doing this query every 10 seconds against
your tree?

(&(objectclass=User)(networkAddress=*))

Some kind of Proxy, checking to see who is logged in?

Do make sure you have an index on network address on this replica, if so.

So parsing the trace. I am guessing sSPR is using the admin user so it
logs in first. (Double checks on login for expiraion and grace logins.

3288041216 LDAP: [2017/08/03 7:54:50.48]
(10.200.252.185:49386)(0x0003:0x63) Search request:
base: "cn=admin,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "loginGraceRemaining"
attribute: "passwordExpirationTime"
attribute: "loginGraceLimit"
3288041216 LDAP: [2017/08/03 7:54:50.48]
(10.200.252.185:49386)(0x0003:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3288041216 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0003:0x63) Sending search result entry
"cn=Admin,o=MV" to connection 0xe2cce00
3288041216 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0003:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00
3699529472 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0004:0x63) DoSearch on connection 0xe2cce00
3699529472 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0004:0x63) Search request:
base: "o=mv"
scope:2 dereference:0 sizelimit:2 timelimit:31 attrsonly:0
filter: "(&(objectClass=person)(cn=dayp))"
attribute: "1.1"
3699529472 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0004:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3699529472 LDAP: [2017/08/03 7:54:50.52]
(10.200.252.185:49386)(0x0004:0x63) Sending search result entry
"cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=MV" to connection 0xe2cce00

Looks for dayp in the o=mv subtree and finds it.


3699529472 LDAP: [2017/08/03 7:54:50.52]
(10.200.252.185:49386)(0x0004:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) DoSearch on connection 0xe2cce00
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) Search request:
base: "o=Students"
scope:2 dereference:0 sizelimit:1 timelimit:31 attrsonly:0
filter: "(&(objectClass=person)(cn=dayp))"
attribute: "1.1"

Yet it looks again in Students, interesting. Should have been happy
with first instance.

No Student i nstance found:
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00


Never noticed this before, but it is checking the Security Equivs on login:
3280406272 AUTH: [2017/08/03 7:54:50.100] Starting SEV calculation for
conn 92, entry .dayp.Building.Highview.Secondary.MV.MOUNDS_VIEW..
3280406272 AUTH: [2017/08/03 7:54:50.100] 1 GlobalGetSEV.
3280406272 AUTH: [2017/08/03 7:54:50.100] 4 GlobalGetSEV succeeded.
3280406272 AUTH: [2017/08/03 7:54:50.100] SEV calculation complete for
conn 92, (0:0 s:ms).

Not sure why it does three almost exact same queries:

3699529472 LDAP: [2017/08/03 7:54:50.103]
(10.200.252.185:49387)(0x0004:0x63) Search request:
base: "cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "objectClass"

They are slightly different (One is checking if the pwmAuxUser class or
whatevr is added.

Then it requests all attrs.

Checks to see if it is in the group for allowing SSPR usage.

3288041216 LDAP: [2017/08/03 7:54:50.106]
(10.200.252.185:49386)(0x0008:0x63) Search request:
base: "cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(groupMembership=cn=TestSSPR,ou=Tech,ou=District,o=MV)"
attribute: "1.1"


Reads the password policy that applies:

3438495488 LDAP: [2017/08/03 7:54:50.111]
(10.200.252.185:49386)(0x000b:0x63) Search request:
base: "cn=MV-Staff-Password-Policy,cn=Password Policies,cn=Security"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "nspmMaximumLength"
yada yada yada

Reads the SSPR stored C/R questions:
3284883200 LDAP: [2017/08/03 7:54:50.115]
(10.200.252.185:49386)(0x000c:0x63) Search request:
base: "cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "pwmResponseSet"
3284883200 LDAP: [2017/08/03 7:54:50.115]
(10.200.252.185:49386)(0x000c:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3284883200 LDAP: [2017/08/03 7:54:50.116]
(10.200.252.185:49386)(0x000c:0x63) Sending search result entry
"cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=MV" to connection 0xe2cce00
3284883200 LDAP: [2017/08/03 7:54:50.116]
(10.200.252.185:49386)(0x000c:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00
3701634816 LDAP: [2017/08/03 7:54:50.117]
(10.200.252.185:49386)(0x000d:0x63) DoSearch on connection 0xe2cce00
3701634816 LDAP: [2017/08/03 7:54:50.117]
(10.200.252.185:49386)(0x000d:0x63) Search request:
base: "cn=MV-Staff-Password-Policy,cn=Password Policies,cn=Security"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "nsimChallengeSetGUID"


Ok, I could go down this hole for a while, but it is irrelevant since
this is all post login. The login event is here:

3720582912 LDAP: [2017/08/03 7:54:50.98]
(10.200.252.185:49387)(0x0001:0x60) DoBind on connection 0x7b9880
3720582912 LDAP: [2017/08/03 7:54:50.98]
(10.200.252.185:49387)(0x0001:0x60) Bind
name:cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv, version:3,
authentication:simple
3720582912 AUTH: [2017/08/03 7:54:50.99] [00008a5c]
<.dayp.Building.Highview.Secondary.MV.MOUNDS_VIEW.> LocalLoginRequest.
Error success, conn: 92.


Could you do that again please with the +NMAS flag on.

(Simple authentication means not using GSSAPI (Kerb) or some other method.)
danb1 Absent Member.
Absent Member.

Re: login password not honoring caps

geoffc;2463380 wrote:
>> How old is your eDirectory? Specifically the replica your SSPR is
>> using
>> for user data?
>>
>> There is a setting NMAS_FIRST_LOGIN or somesuch that is set by eDir as
>> of like 8.7 or so and on wards. So if you had an ancient eDir and this
>> env setting was not set, it would work like this. It seems incredibly
>> unlikely, but who knows.5901

>
> Here is a new ndstrace with the options you wanted. Let me know if I
> missed anything but think I got it correct.
> Our eDirectory is version 8.8 SP8 we are running on OES 11 SP3. I do
> need to apply the May, June and July maintenance updates/patches.


This is new enough, so discard that odd thought.

Side note: What the heck is doing this query every 10 seconds against
your tree?

(&(objectclass=User)(networkAddress=*))

Some kind of Proxy, checking to see who is logged in?

Do make sure you have an index on network address on this replica, if so.

So parsing the trace. I am guessing sSPR is using the admin user so it
logs in first. (Double checks on login for expiraion and grace logins.

3288041216 LDAP: [2017/08/03 7:54:50.48]
(10.200.252.185:49386)(0x0003:0x63) Search request:
base: "cn=admin,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "loginGraceRemaining"
attribute: "passwordExpirationTime"
attribute: "loginGraceLimit"
3288041216 LDAP: [2017/08/03 7:54:50.48]
(10.200.252.185:49386)(0x0003:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3288041216 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0003:0x63) Sending search result entry
"cn=Admin,o=MV" to connection 0xe2cce00
3288041216 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0003:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00
3699529472 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0004:0x63) DoSearch on connection 0xe2cce00
3699529472 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0004:0x63) Search request:
base: "o=mv"
scope:2 dereference:0 sizelimit:2 timelimit:31 attrsonly:0
filter: "(&(objectClass=person)(cn=dayp))"
attribute: "1.1"
3699529472 LDAP: [2017/08/03 7:54:50.50]
(10.200.252.185:49386)(0x0004:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3699529472 LDAP: [2017/08/03 7:54:50.52]
(10.200.252.185:49386)(0x0004:0x63) Sending search result entry
"cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=MV" to connection 0xe2cce00

Looks for dayp in the o=mv subtree and finds it.


3699529472 LDAP: [2017/08/03 7:54:50.52]
(10.200.252.185:49386)(0x0004:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) DoSearch on connection 0xe2cce00
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) Search request:
base: "o=Students"
scope:2 dereference:0 sizelimit:1 timelimit:31 attrsonly:0
filter: "(&(objectClass=person)(cn=dayp))"
attribute: "1.1"

Yet it looks again in Students, interesting. Should have been happy
with first instance.

No Student i nstance found:
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3439548160 LDAP: [2017/08/03 7:54:50.53]
(10.200.252.185:49386)(0x0005:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00


Never noticed this before, but it is checking the Security Equivs on login:
3280406272 AUTH: [2017/08/03 7:54:50.100] Starting SEV calculation for
conn 92, entry .dayp.Building.Highview.Secondary.MV.MOUNDS_VIEW..
3280406272 AUTH: [2017/08/03 7:54:50.100] 1 GlobalGetSEV.
3280406272 AUTH: [2017/08/03 7:54:50.100] 4 GlobalGetSEV succeeded.
3280406272 AUTH: [2017/08/03 7:54:50.100] SEV calculation complete for
conn 92, (0:0 s:ms).

Not sure why it does three almost exact same queries:

3699529472 LDAP: [2017/08/03 7:54:50.103]
(10.200.252.185:49387)(0x0004:0x63) Search request:
base: "cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "objectClass"

They are slightly different (One is checking if the pwmAuxUser class or
whatevr is added.

Then it requests all attrs.

Checks to see if it is in the group for allowing SSPR usage.

3288041216 LDAP: [2017/08/03 7:54:50.106]
(10.200.252.185:49386)(0x0008:0x63) Search request:
base: "cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(groupMembership=cn=TestSSPR,ou=Tech,ou=District,o=MV)"
attribute: "1.1"


Reads the password policy that applies:

3438495488 LDAP: [2017/08/03 7:54:50.111]
(10.200.252.185:49386)(0x000b:0x63) Search request:
base: "cn=MV-Staff-Password-Policy,cn=Password Policies,cn=Security"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "nspmMaximumLength"
yada yada yada

Reads the SSPR stored C/R questions:
3284883200 LDAP: [2017/08/03 7:54:50.115]
(10.200.252.185:49386)(0x000c:0x63) Search request:
base: "cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "pwmResponseSet"
3284883200 LDAP: [2017/08/03 7:54:50.115]
(10.200.252.185:49386)(0x000c:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
3284883200 LDAP: [2017/08/03 7:54:50.116]
(10.200.252.185:49386)(0x000c:0x63) Sending search result entry
"cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=MV" to connection 0xe2cce00
3284883200 LDAP: [2017/08/03 7:54:50.116]
(10.200.252.185:49386)(0x000c:0x63) Sending operation result 0:"":"" to
connection 0xe2cce00
3701634816 LDAP: [2017/08/03 7:54:50.117]
(10.200.252.185:49386)(0x000d:0x63) DoSearch on connection 0xe2cce00
3701634816 LDAP: [2017/08/03 7:54:50.117]
(10.200.252.185:49386)(0x000d:0x63) Search request:
base: "cn=MV-Staff-Password-Policy,cn=Password Policies,cn=Security"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
attribute: "nsimChallengeSetGUID"


Ok, I could go down this hole for a while, but it is irrelevant since
this is all post login. The login event is here:

3720582912 LDAP: [2017/08/03 7:54:50.98]
(10.200.252.185:49387)(0x0001:0x60) DoBind on connection 0x7b9880
3720582912 LDAP: [2017/08/03 7:54:50.98]
(10.200.252.185:49387)(0x0001:0x60) Bind
name:cn=dayp,ou=Building,ou=Highview,ou=Secondary,o=mv, version:3,
authentication:simple
3720582912 AUTH: [2017/08/03 7:54:50.99] [00008a5c]
<.dayp.Building.Highview.Secondary.MV.MOUNDS_VIEW.> LocalLoginRequest.
Error success, conn: 92.


Could you do that again please with the +NMAS flag on.

(Simple authentication means not using GSSAPI (Kerb) or some other method.)


Thank you for your knowledge with all of this. I'm trying to make sense of the logs. 😉
That query is a syslog server we are running. I will shut it down temporary while I get a new ndstrace file.

I have been running the +NMAS option so maybe something isn't getting logged correctly?
I am doing this along with the trace options you wanted turned on under LDAP Server...

ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap +nmas +auth
set dstrace=*m9999999
dstrace file on
set dstrace=*r
#perform test here
dstrace file off
quit

I'll grab another file now with the syslog server shutdown.
Thanks again!
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.