Commander
Commander
600 views

Desktop SSO / Fallback Auth / Password Expiration Issues


Hi All,

I'm configuring an authentication contract for use with a saml SP in our
environment which consists of multiple user stores (AD + edir), and
wondering if anybody has a NAM setup which does the following;

1) Desktop SSO
2) Fallback to Username / Password Form for users not able to desktop
sso (ie, external users)
3) Uses the Password Expiration Servlet option on the contract

Retrieval of attributes required in the saml assertion needs to come
from eDir.

I've tried a number of setups and whilst I can get the desktop sso &
fallback options working and can login to the saml SP without issues,
each time I redirect a user to a Password Expiration URL, the LDAP
credentials which I'd like to use via Identity Injection or Form Fill,
appear to be unavailable.

If I swap the contract to be a standard form based login using a
ProtectedPasswordClass and don't offer any desktop sso, the credentials
are available when redirecting the same user to the Password Expiration
URL.

I'm keen to know if this is possible (assuming it is), and if you can
describe your class / method / contract setup you're using to achieve
this, it would be appreciated.

Thanks in advance.


--
gbatty1
------------------------------------------------------------------------
gbatty1's Profile: https://forums.netiq.com/member.php?userid=2072
View this thread: https://forums.netiq.com/showthread.php?t=56536

0 Likes
8 Replies
Commander
Commander


To provide some more context;

1) Head Office Users will exist in AD + eDir and should be able to
desktop sso, and the password expiration URL is not used / needed by
these users.
2) External Users exist only in eDir, and the password expiration URL is
needed for these users.

I have tried combinations such as;

* Contract using Kerberos (AD) with fallback to ProtectedPasswordClass
and password fetch (edir) - Desktop SSO works, fallback works, but when
attempting to login via the fallback form with a user who has an expired
password, the user is directed to the password expiration URL but the
credentials just used appear unavailable to use on the form fill /
identity injection.

* Contract using Kerberos (eDir) with fallback to ProtectedPasswordClass
- Desktop SSO works, fallback works, but when attempting to login via
the fallback form with a user who has an expired password, the user is
directed to the password expiration URL but the credentials just used
appear unavailable to use on the form fill / identity injection.

* Contract using ProtectedPasswordClass - No Desktop SSO of course,
login works fine and when attempting to login with a user who has an
expired password, the user is directed to the password expiration URL
with the credentials just used available to use on the form fill /
identity injection.


--
gbatty1
------------------------------------------------------------------------
gbatty1's Profile: https://forums.netiq.com/member.php?userid=2072
View this thread: https://forums.netiq.com/showthread.php?t=56536

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

gbatty1 <gbatty1@no-mx.forums.microfocus.com> wrote:
>

To provide some more context;

1) Head Office Users will exist in AD + eDir and should be able to
desktop sso, and the password expiration URL is not used / needed by
these users.
2) External Users exist only in eDir, and the password expiration URL is
needed for these users.

I have tried combinations such as;

* Contract using Kerberos (AD) with fallback to ProtectedPasswordClass
and password fetch (edir) - Desktop SSO works, fallback works, but when
attempting to login via the fallback form with a user who has an expired
password, the user is directed to the password expiration URL but the
credentials just used appear unavailable to use on the form fill /
identity injection.

* Contract using Kerberos (eDir) with fallback to ProtectedPasswordClass
- Desktop SSO works, fallback works, but when attempting to login via
the fallback form with a user who has an expired password, the user is
directed to the password expiration URL but the credentials just used
appear unavailable to use on the form fill / identity injection.

* Contract using ProtectedPasswordClass - No Desktop SSO of course,
login works fine and when attempting to login with a user who has an
expired password, the user is directed to the password expiration URL
with the credentials just used available to use on the form fill /
identity injection.


Believe I solved that using the pre-expire check in SSPR and configuring a
login URL. (Rather than a password expiration URL)

You can also use grace logins but I found that confused things too much.

--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...

Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Commander
Commander


Thanks for the reply Alex,

Assuming you use the returnURL parameter in the login redirection URL?
Something like http://tinyurl.com/hx4og95

If not, how do users navigate to their intended resource after renewing
their passwords, or having their password checked for expiration?


--
gbatty1
------------------------------------------------------------------------
gbatty1's Profile: https://forums.netiq.com/member.php?userid=2072
View this thread: https://forums.netiq.com/showthread.php?t=56536

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

gbatty1 wrote:

>
> Assuming you use the returnURL parameter in the login redirection URL?
> Something like http://tinyurl.com/hx4og95
>


Yes, something like that. My memory is a bit vague as I set this up a
while back at a customer I no longer have access to.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Commander
Commander


alexmchugh;271068 Wrote:
> gbatty1 wrote:
>
> >
> > Assuming you use the returnURL parameter in the login redirection

> URL?
> > Something like http://tinyurl.com/hx4og95
> >

>
> Yes, something like that. My memory is a bit vague as I set this up a
> while back at a customer I no longer have access to.


Thanks again Alex, I appreciate your responses.

We currently use the password expiration URL option on a contract and
use PWM to enforce challenges response setup and enable the user the
ability to reset their password when required. The contract uses a
password protected class, but needs to change to offer desktop sso for
the appropriate users as described above.

Off the top of my head the password redirect URL is something like
http://tinyurl.com/zk3sq2a.

The end result is only users with an expired password are redirected and
essentially only the external users are redirected as internal users
change password using another method.

I imagine if we use the login redirect option on the contract, all users
will be redirected regardless of expired password, and the end result
would be internal users would be forced to setup challenge response as
well.

You implied there may be another way based around Grace logins? I would
be keen to learn more if you're able to provide some insight or any
other potential solutions you can think of.

Thanks,


--
gbatty1
------------------------------------------------------------------------
gbatty1's Profile: https://forums.netiq.com/member.php?userid=2072
View this thread: https://forums.netiq.com/showthread.php?t=56536

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

gbatty1 wrote:

> I imagine if we use the login redirect option on the contract, all
> users will be redirected regardless of expired password, and the end
> result would be internal users would be forced to setup challenge
> response as well.
>


I used /sspr/private/CommandServlet?processAction=checkExpire to avoid
this.

Though I think I worked around this with profiles or some LDAP filter
scoping within SSPR. Can't recall that bit exactly. I do know, we had
nearly the same setup and requirements you mentioned originally. The
one thing that we did have differently was that Access Manager used
Bart Andries SMS class.

> You implied there may be another way based around Grace logins? I
> would be keen to learn more if you're able to provide some insight or
> any other potential solutions you can think of.


I think it was as simple as set grace logins to a specific large value
for external users so even once their password had expired, they could
still login and change their password.

I liked the checkExpire approach best. Have had lots of niggling issues
with the expired password redirection.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Commander
Commander


alexmchugh;271094 Wrote:
> gbatty1 wrote:
>
> > I imagine if we use the login redirect option on the contract, all
> > users will be redirected regardless of expired password, and the end
> > result would be internal users would be forced to setup challenge
> > response as well.
> >

>
> I used /sspr/private/CommandServlet?processAction=checkExpire to avoid
> this.
>
> Though I think I worked around this with profiles or some LDAP filter
> scoping within SSPR. Can't recall that bit exactly. I do know, we had
> nearly the same setup and requirements you mentioned originally. The
> one thing that we did have differently was that Access Manager used
> Bart Andries SMS class.
>
> > You implied there may be another way based around Grace logins? I
> > would be keen to learn more if you're able to provide some insight or
> > any other potential solutions you can think of.

>
> I think it was as simple as set grace logins to a specific large value
> for external users so even once their password had expired, they could
> still login and change their password.
>
> I liked the checkExpire approach best. Have had lots of niggling issues
> with the expired password redirection.


Thanks Alex,

I'm trying this approach, but think I'm running into PWM bugs now 😞

If I have the configuration in PWM setting
_check_Expire_During_Authentication_=_TRUE_, and then use a login
redirection of;

http://tinyurl.com/z5kkp3g

Unfortunately, the user is forced to submit challenge response
questions, but not forced to change passwords when the password is
expired. Changing the processAction to CheckExpire or CheckResponses has
the no difference, with a user with an expired password not forced to
change passwords.

We seem to have worked around this bug at the moment by using the
Password Expiration URL in NAM, and then sending the user to;

http://tinyurl.com/he688qs

I'll report back any updates / changes, but happy to hear of any other
ideas to get a working solution.


--
gbatty1
------------------------------------------------------------------------
gbatty1's Profile: https://forums.netiq.com/member.php?userid=2072
View this thread: https://forums.netiq.com/showthread.php?t=56536

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

gbatty1 <gbatty1@no-mx.forums.microfocus.com> wrote:
>
>
> Unfortunately, the user is forced to submit challenge response

questions,

We disabled challenge response questions as the customer did not want this
feature.

> but not forced to change passwords when the password is

expired.

Isn't that a separate config item in SSPR

> Changing the processAction to CheckExpire or CheckResponses has

the no difference, with a user with an expired password not forced to
change passwords.
>


The exact cmdlet action is dependant on the other SSPR settings related to
password expiry and such.

--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
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.