Anonymous_User Absent Member.
Absent Member.
735 views

SSPR errpr 5045

I installed SSPR 4.2 using my test eDirectory as its LDAP source and it
worked fine in all respects. I then wiped the configuration and ran the
guided install again, this time specifying the production tree as its
LDAP source. It refuses to save the challenge responses, giving me a
5045 error. I have double- and triple-checked the rights assignments
from the documentation, specifically that [This] has write privileges to
pwmResponseSet and userPassword. What else could be wrong?

eDirectory version information:

Test
highest version -- eDir 9.0.3 HF1
lowest version -- eDir 8.8.8 Patch 5

Prod
highest version -- eDir 8.8.8 Patch 10 HF1
lowest version -- eDir 8.8.7

The product documentation says eDirectory 8.8.8 Patch 10 is a
requirement -- does that mean ALL servers must be at or above that
level? If so, the test environment should also fail.

Thoughts?

Thanks
0 Likes
6 Replies
Knowledge Partner
Knowledge Partner

Re: SSPR errpr 5045

The presence of those ACLs also means that you have schema extended,
presumably correctly, so that is good. I suppose rights could be blocked
somewhere down the tree, but that seems unlikely. Does it still work if
you try to configure against the Test environment again? Have you tried
making sure the attribute is not present on the user before trying to set
these new responses (in case something put them there before? I presume so)?

Have you tried getting ndstrace output to see what SSPR is doing at this
point when it fails?


ldapconfig set 'LDAP Screen Level=all'

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


By default the output will be at
/var/opt/novell/eDirectory/log/ndstrace.log so just post that here.

If there is something in the catalina.out that may be useful too.

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

Re: SSPR errpr 5045


> The presence of those ACLs also means that you have schema extended,
> presumably correctly, so that is good. I suppose rights could be blocked
> somewhere down the tree, but that seems unlikely. Does it still work if
> you try to configure against the Test environment again?


Yes, it worked against test. I compared access rights for [This]
between test and prod environments and they look identical.

> Have you tried > making sure the attribute is not present on the user before trying to set
> these new responses (in case something put them there before? I presume so)?
>

I created a brand-new test user in the prod vault for that purpose.


> Have you tried getting ndstrace output to see what SSPR is doing at this
> point when it fails?
>
>

> ldapconfig set 'LDAP Screen Level=all'
>
> ndstrace
> set dstrace=nodebug
> dstrace +time +tags +ldap
> set dstrace=*m9999999
> dstrace file on
> set dstrace=*r
> #Perform test here
> dstrace file off
> quit
>


I had looked at ndstrace with +LDAP, but I forgot the ldapconfig command
preceding it. I tried what you suggested, and I see "err = illegal
attribute (-608)" after the statement "add: pwmResponseSet" at line 374.
(I will paste the logfile into another reply if you want to see it.)

I do have the pwmResponseSet attribute in my schema in both trees, but I
see some discrepancies in the pwmUser object class. In test, pwmUser
has class flags "Ambiguous Naming", "Ambiguous Containment", and
"Auxiliary Class". The object class in prod lacks the Auxiliary Class
flag. Additionally, the pwmUser object class in Prod has a ton of
unrelated attributes associated with it, while in test it has only the
"pwm" attributes.

I'm guessing I need to delete that object class and recreate it
correctly. Since it lacks the 'Auxiliary Class' flag, I wonder if I
will be able to do so.






0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR errpr 5045

-608 means you are trying to add an attribute where it is not allowed,
meaning the class of that object does not permit it.

The description you provide of different object classes (for pwmuser)
sounds like the cause of the current problem. Yes, if you can be sure
NOTHING uses pwmUser class and try to delete it, then add it back. Since
this is an effective class, that may be tricky, as this is why Auxiliary
classes exist. I guess we'll see.


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

Re: SSPR errpr 5045


> -608 means you are trying to add an attribute where it is not allowed,
> meaning the class of that object does not permit it.
>
> The description you provide of different object classes (for pwmuser)
> sounds like the cause of the current problem. Yes, if you can be sure
> NOTHING uses pwmUser class and try to delete it, then add it back. Since
> this is an effective class, that may be tricky, as this is why Auxiliary
> classes exist. I guess we'll see.
>


Is there a chance I could do more damage by attempting to delete the
class, or will it just refuse to permit the operation?

I had a similar experience when I first installed SSPR (4.1.0.0 at that
time) in my test environment. I assumed it was because I had done
something wrong, so I deleted and recreated all of the pwm attributes by
hand using iManager. I can't remember if I did the same for the pwmUser
object class though.






0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SSPR errpr 5045

After verifying that the object class pwmUser is added during the SSPR
install (meaning nothing else uses it, right??) I went ahead and deleted
the class and recreated it using the class definition from test. SSPR
then successfully saved my challenge responses.

I wonder if I've found a bug in SSPR, given that I've had to tinker with
the schema configuration on two different installs after letting the
guided install do the schema configuration for me.




0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR errpr 5045

On 10/19/2017 12:30 PM, Doug wrote:
> After verifying that the object class pwmUser is added during the SSPR
> install (meaning nothing else uses it, right??) I went ahead and deleted
> the class and recreated it using the class definition from test. SSPR
> then successfully saved my challenge responses.


Thank-you for sharing your steps and final resolution. This will likely
help others if they get into the same fix.

> I wonder if I've found a bug in SSPR, given that I've had to tinker with
> the schema configuration on two different installs after letting the
> guided install do the schema configuration for me.


I suppose you may have found a bug, but before reporting it we may want to
see if you havea backup or something of your schema so we can confirm
whether or not that class existed prior tothe use of the SSPR installer.
It has been in use for a lon time, and generally schema extensions are
done with one command that either works or fails entirely. This usually
means that trying to remove the class is not risky if the class is in use
because eDirectory will just reject the attempt regardless of anything
until the situation is rectified. Also, it means that if you extend
schema from some installer it either works the right way or not at all.
pwmUser has, as far as I remember, always been an auxiliary class, and the
definition as such is included with the creation of the class, so creating
it in another way is pretty unlikely, but every developer feels that every
bug is unlikely until it is encountered, so take that for whatever it is
worth.

If we can confirm that a tree had no pwmUser class at all, and then after
the install it had it as a non-auxiliary class, then there is definitely a
bug in my opinion. If you had experimented with SSPR, or its predecessor
PWM, then maybe the situation is different. Production environments can
be funny because they are meant to be pristine and they should be up all
of the time, which means we try to keep cruft out of them, but if cruft
gets in we may just leave it as long as things still work.

Let us know if you have a way to check, such as production eDir backups
you can restore in an very isolated environment to check, or LDIF exports,
or something like that, or if you can duplicate it in a new (clean of
pwmUser stuff) environment and we'll try to get it resolved to avoid this
in the future for you or others.

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