Highlighted
Absent Member.
Absent Member.
788 views

What is best way to configure SSPR for a subset of users


Hi,
Our eDirectory LDAP for our NAM protected B2B portal has all LDAP users
in a single OU. We want to configure SSPR so:
If a user is added to the SSPR password policy in eDirectory then they
CommandServlet?processAction=checkExpire will be triggered on login and
if inside warning period or if password expired then approariate SSPR
screens wil be displayed. However, if the user hasn't been added to the
SSPR password policy we want their login to continue as normal. We want
to gradually rollout SSPR to users in a staged manner i.e. no big bang.
Is this possible or does the users OU have to be assigned to the
password policy so that from day one all users have to use SSPR?
Using Change Password Permission LDAP filter does this allow us to limit
the SSPR users to only those we have already assigned to the password
policy e.g.
LDAP Search FIlter:
(&(objectClass=inetorgperson)(nspmPasswordPolicyDN=cn=SSPR_Policy,ou=Password
Policies,o=Security)) ?
If we configure the NAM login contract for B2B to have Redirect Login
URL setting will users who are not part of the password policy be able
to login normally?
Thanks
Mark


--
ratclma
------------------------------------------------------------------------
ratclma's Profile: https://forums.netiq.com/member.php?userid=7886
View this thread: https://forums.netiq.com/showthread.php?t=55319

0 Likes
4 Replies
Highlighted
Absent Member.
Absent Member.

Re: What is best way to configure SSPR for a subset of users

ratclma wrote:

>
> Hi,
> Our eDirectory LDAP for our NAM protected B2B portal has all LDAP
> users in a single OU. We want to configure SSPR so:
> If a user is added to the SSPR password policy in eDirectory then they
> CommandServlet?processAction=checkExpire will be triggered on login
> and if inside warning period or if password expired then approariate
> SSPR screens wil be displayed. However, if the user hasn't been
> added to the SSPR password policy we want their login to continue as
> normal. We want to gradually rollout SSPR to users in a staged
> manner i.e. no big bang. Is this possible or does the users OU have
> to be assigned to the password policy so that from day one all users
> have to use SSPR? Using Change Password Permission LDAP filter does
> this allow us to limit the SSPR users to only those we have already
> assigned to the password policy e.g.
> LDAP Search FIlter:
> (&(objectClass=inetorgperson)(nspmPasswordPolicyDN=cn=SSPR_Policy,ou=P
> assword Policies,o=Security)) ?


I'm not sure if this will work in the way you wanted.
This filter restricts the access to the "change password" function. It
does not bypass the checkExpire function.

> If we configure the NAM login contract for B2B to have Redirect Login
> URL setting will users who are not part of the password policy be able
> to login normally?
>


Do these other users have another password policy assigned which
enforces password expiration? If so, then the checkExpire should still
kick in.

If they do not have any password expiration, then they will redirect
via CommandServlet?processAction=checkExpire just fine (I have
configured this at one customer, where they also wanted a staged
rollout)
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: What is best way to configure SSPR for a subset of users


Alex McHugh;264999 Wrote:
> ratclma wrote:
>
> >
> > Hi,
> > Our eDirectory LDAP for our NAM protected B2B portal has all LDAP
> > users in a single OU. We want to configure SSPR so:
> > If a user is added to the SSPR password policy in eDirectory then

> they
> > CommandServlet?processAction=checkExpire will be triggered on login
> > and if inside warning period or if password expired then approariate
> > SSPR screens wil be displayed. However, if the user hasn't been
> > added to the SSPR password policy we want their login to continue as
> > normal. We want to gradually rollout SSPR to users in a staged
> > manner i.e. no big bang. Is this possible or does the users OU have
> > to be assigned to the password policy so that from day one all users
> > have to use SSPR? Using Change Password Permission LDAP filter does
> > this allow us to limit the SSPR users to only those we have already
> > assigned to the password policy e.g.
> > LDAP Search FIlter:
> >

> (&(objectClass=inetorgperson)(nspmPasswordPolicyDN=cn=SSPR_Policy,ou=P
> > assword Policies,o=Security)) ?

>
> I'm not sure if this will work in the way you wanted.
> This filter restricts the access to the "change password" function. It
> does not bypass the checkExpire function.
>
> > If we configure the NAM login contract for B2B to have Redirect Login
> > URL setting will users who are not part of the password policy be

> able
> > to login normally?
> >

>
> Do these other users have another password policy assigned which
> enforces password expiration? If so, then the checkExpire should still
> kick in.
>
> If they do not have any password expiration, then they will redirect
> via CommandServlet?processAction=checkExpire just fine (I have
> configured this at one customer, where they also wanted a staged
> rollout)


I didn't need to do the above think the config file was corrupt went
back to an older version of the xml file and was able to configure
everything correctly. one thing I did need to configure which isn't
mentioned was to add the identity server url to the redirect whitelist
e.g. https://login.some.company.biz/nidp/idff/sso Most of it works now.
But get a strange behaviour on the primary login contract. As we have
the 3 urls we have 3 login contracts one for each url as we have
separate login.jsp files for each with the appropriate branding for the
different urls. All users are able to login and get appropriate warning
pages if within SSPR warning periods and if they're not then they are
forwarded to where they were going. So that's all as it should be.
However, for one of the login contracts if the user has not been
assigned to a password policy they get a 5015 error because the
commandservle
GET http://tinyurl.com/jj4br6v HTTP/1.1
login.some.company.biz GET http://tinyurl.com/jc9x7x6 HTTP/1.1
Host: login.some.company.biz

GET http://tinyurl.com/zeddvj9 HTTP/1.1
GET https://some.company.biz/sspr/private/CommandServlet HTTP/1.1
GET https://some.company.biz/sspr/private/CommandServlet HTTP/1.1

For the same user authenticating with one of the other login contracts
we get the correct commandservlet and consequently user forwarded to
where he was going as expected.
GET http://tinyurl.com/h68a9bo HTTP/1.1

So NAM must be doing something odd with the login contract or the NAM
reverse proxy it is using is wrong but I've checked and I can't see
anytihng obviously different. Have you seen anything like this?
Thanks
Mark


--
ratclma
------------------------------------------------------------------------
ratclma's Profile: https://forums.netiq.com/member.php?userid=7886
View this thread: https://forums.netiq.com/showthread.php?t=55319

0 Likes
Absent Member.
Absent Member.

Re: What is best way to configure SSPR for a subset of users


Alex,
As an update I tried configuring the login contract for
https://some.company.biz with Login Redirect
URL=https://some.other.biz/sspr/private/CommandServlet?processAction=checkExpire&forwardURL=<RETURN_URL>
and while I had to do an extra login it worked correctly.
Equally if I configured the login contract for https://some.other.biz
with Login Redirect
URL=https://some.company.biz/sspr/private.CommandServlet?processAction=checkExpire&forwardURL=<RETURN_URL>
then I got the additional login but it failed with a 5015 error.
So it would seem the issue is clearly with the URL called by Login
Redirect URL. I have checked the 3 reverse proxies and confirm the
proxy service for /sspr, protected resources, authorisation policy and
injection policy are all configured the same. The only thing I can
think is different is that https://some.company.biz is the first reverse
proxy and so is the one configured for the ESP, does this have any
bearing?
You mentioned Realms on the other thread is that significant?
Thanks
Mark


--
ratclma
------------------------------------------------------------------------
ratclma's Profile: https://forums.netiq.com/member.php?userid=7886
View this thread: https://forums.netiq.com/showthread.php?t=55319

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: What is best way to configure SSPR for a subset of users

ratclma;2419355 wrote:
Alex,
As an update I tried configuring the login contract for
https://some.company.biz with Login Redirect
URL=https://some.other.biz/sspr/private/CommandServlet?processAction=checkExpire&forwardURL=<RETURN_URL>
and while I had to do an extra login it worked correctly.
Equally if I configured the login contract for https://some.other.biz
with Login Redirect
URL=https://some.company.biz/sspr/private.CommandServlet?processAction=checkExpire&forwardURL=<RETURN_URL>
then I got the additional login but it failed with a 5015 error.
So it would seem the issue is clearly with the URL called by Login
Redirect URL. I have checked the 3 reverse proxies and confirm the
proxy service for /sspr, protected resources, authorisation policy and
injection policy are all configured the same. The only thing I can
think is different is that https://some.company.biz is the first reverse
proxy and so is the one configured for the ESP, does this have any
bearing?
You mentioned Realms on the other thread is that significant?
Thanks
Mark


This was fixed by setting a Global Advanced Option NAGGlobalOptions NAGRenameCookie=off
At least it was for standard NAM protected resources. however, I now get a 5075 error when accessing a SAML site. I'll raise a new thread for that problem.
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.