gdrtx Absent Member.
Absent Member.
735 views

SSPR 3.3.1.0 Unable to establish session password error


We have a new instance of SSPR installed on Tomcat (Tomcat from IDM 4.5
ISO) on a Windows Server 2012. SSPR is configured to talk to IDM 4.5
(eDir 8.8 SP 8). When trying to do user activations we are getting
errors of "Unable to establish session password" errors after entering
our identity data (workforceID and Date of Birth (MM/dd/yyyy)). We have
verified the Proxy User DN and password configured in SSPR is correct.
We have logged into iManager and an LDAP browser using the prixy user
data successfully. Any ideas what could be causing this issue? I have
installed SSPR on Linux many times but never ran across this issue until
now?


--
gdrtx
------------------------------------------------------------------------
gdrtx's Profile: https://forums.netiq.com/member.php?userid=1660
View this thread: https://forums.netiq.com/showthread.php?t=55739

0 Likes
3 Replies
Knowledge Partner
Knowledge Partner

Re: SSPR 3.3.1.0 Unable to establish session password error

On 04/19/2016 11:35 AM, gdrtx wrote:
>
> We have a new instance of SSPR installed on Tomcat (Tomcat from IDM 4.5
> ISO) on a Windows Server 2012. SSPR is configured to talk to IDM 4.5
> (eDir 8.8 SP 8). When trying to do user activations we are getting
> errors of "Unable to establish session password" errors after entering
> our identity data (workforceID and Date of Birth (MM/dd/yyyy)). We have
> verified the Proxy User DN and password configured in SSPR is correct.
> We have logged into iManager and an LDAP browser using the prixy user
> data successfully. Any ideas what could be causing this issue? I have
> installed SSPR on Linux many times but never ran across this issue until
> now?


I'd probably setup ndstrace to see what you can see via LDAP. Be sure to
go to the LDAP Server object first and check all of the Trace/Screen
checkboxes, then refresh the service:


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


Grab the ndstrace.log file to see what may show up in there. Perhaps add
the +auth option in dstrace to get a bit more information about
authentication if needed.

--
Good luck.

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

Re: SSPR 3.3.1.0 Unable to establish session password error


Don't know if this is any help but the SSPR error I got was the same as
yours.
Beforehand, I assigned the Sample Password Policy to OU=users,O=data
under the assumption that the underlying OU's would inherit it. After
that, the SSPR error occured. The policy was originally assigned to
(amongst other OU's) OU=students,OU=users,O=data. When I once again
assigned the policy directly to OU=students,OU=users,O=data, the issue
was resolved for the user objects in that OU.


--
joer999
------------------------------------------------------------------------
joer999's Profile: https://forums.netiq.com/member.php?userid=6162
View this thread: https://forums.netiq.com/showthread.php?t=55739

0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 3.3.1.0 Unable to establish session password error

Thanks for sharing your result in this thread as well.

For those who follow, Universal Password (UP) policy assignment works like
this, which I lovingly call the rule of "ones", and applies in this
specific order (first match wins):

1. One user. Apply a policy to a user, and that one wins.
2. One container. Apply the policy to the container and objects in that
container, but that container only, are impacted. This is like a
one-level search in LDAP, not a subtree search.
3. One partition. Apply to a partition root, and all objects in that
partition are impacted, but like the one-container above, not child
partitions.
4. One tree. Apply the UP policy to the 'cn=Login Policy.cn=Security'
object and it applies to the one tree, and the whole tree.

The reason for this, if you think about it, is performance. The first
three checks can be done by the server performing the authentication
without checking with any other servers. Only the last check might
require walking the tree (if the server does not hold a copy of Security,
which is a bit odd). Since logins impact end users, and end users
complain about slow logins, performance is used to guide this design.

Admittedly, as eDirectory folks we're used to inheritance, so this is not
the same way that things like ACLs work, but ACLs do not impact logins.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
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.