allenmorris Absent Member.
Absent Member.
1075 views

SSPR 3.3.1 stopped notification of password expiry

Hello,

One of the weirdest things happened two weeks ago. Our SSPR server just stopped notifying users their passwords are about to change. I usually do not pay to much attention to a couple days without an email about password expiry, then when a week goes by and I know my password is within the notify window, I get a bit alarmed.

Okay, some background. Our certs are coming up to expire on September 26th and I will be away on vacation, so I decide to do the updates early. I ran the LDAP cert update on Aug 8th and everything went fine. I have the tomcat certs yet to do. Questions on that will be in a different post.

On Aug 26, 18 days later, I received the last admin notification of emails being sent to users with their password expiring. I've gone through most everything I can find on troubleshooting this issue. I've test LDAP continuity, SMTP continuity, and sort of walked back through the configuration. I though maybe licensing, though unable to find anything specific. The 26th was a Sunday, so I didn't think it would have been something I did which caused the issue.

Any suggestions wold be greatly appreciated.

Many thanks,

Allen
0 Likes
8 Replies
Knowledge Partner
Knowledge Partner

Re: SSPR 3.3.1 stopped notification of password expiry

Have you manually verified that some users have passwords that are
expiring soon? What is the query you are using for that?

Do you see SSPR querying (I presume) eDirectory for soon-to-be-expired
passwords on users? How do those queries look? Use ndstrace to catch the
quer(y/ies).

Any test environment? Does it have the same issue?

Do you get the e-mails because you get all e-mails along with the users
themselves?


--
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
Knowledge Partner
Knowledge Partner

Re: SSPR 3.3.1 stopped notification of password expiry

On 9/5/2018 4:19 PM, ab wrote:
> Have you manually verified that some users have passwords that are
> expiring soon? What is the query you are using for that?
>
> Do you see SSPR querying (I presume) eDirectory for soon-to-be-expired
> passwords on users? How do those queries look? Use ndstrace to catch the
> quer(y/ies).
>
> Any test environment? Does it have the same issue?
>
> Do you get the e-mails because you get all e-mails along with the users
> themselves?


I have never actually tried this functionality in SSPR. Anyone know how
it works, under the covers?

0 Likes
allenmorris Absent Member.
Absent Member.

Re: SSPR 3.3.1 stopped notification of password expiry

Thank you for your reply.


Have you manually verified that some users have passwords that are
expiring soon? What is the query you are using for that?


There are 22 users who should have gotten notifications their passwords are expiring.

Do you see SSPR querying (I presume) eDirectory for soon-to-be-expired
passwords on users? How do those queries look? Use ndstrace to catch the
quer(y/ies).


I guess this is done on the LDAP box. This is one of my IDM vault boxes, is ndstrace installed with DS? Can it be ported to a log file. Dah, been to long.

Yes, I have the server in a development environment, it hasn't been running in two years.

Many thanks,

Allen
0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 3.3.1 stopped notification of password expiry

On 09/05/2018 03:14 PM, allenmorris wrote:
>
> I guess this is done on the LDAP box. This is one of my IDM vault
> boxes, is ndstrace installed with DS? Can it be ported to a log file.
> Dah, been to long.


ndstrace would be on the eDirectory side, as it is part of that product.
Yes it will write to a log file or you can run it so that output writes to
the screen and then you can save that out. It is probably easier to use a
log file:


#turn up tracing
ldapconfig set 'LDAP Screen Level=all'

#Load and configure ndstrace
ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap
dstrace file on
set dstrace=*r
#perform test from SSPR to query for users
dstrace file off
quit


The default path for the file is
/var/opt/novell/eDirectory/log/ndstrace.log and then it should show the
LDAP bind, query, and objects returned.


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

Re: SSPR 3.3.1 stopped notification of password expiry

Okay.

First, I was looking in the incorrect location. The expiry emails are not created or sent from SSPR, it done by IDM as a Job.

Second the Job was set up correctly, the issue was caused when the SSL cert expired on the server used. Finally tracked down the log file locations and there it was. I updated the certs via imanager and hopefully tonight the process will run.

Question. When correcting expiry dates on some users who where close to their password expiring, I noticed the updates where not going across the edir2edir driver. Now that I updated the Certs on the server on one side of the driver do I need to re-cert the driver itself? The server whose cert I had to update is my IDM vault server.

Many thanks for all the help you've been.

Allen
0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 3.3.1 stopped notification of password expiry

On 09/06/2018 08:14 AM, allenmorris wrote:
>
> First, I was looking in the incorrect location. The expiry emails are
> not created or sent from SSPR, it done by IDM as a Job.


Ah, that makes more sense.

> Second the Job was set up correctly, the issue was caused when the SSL
> cert expired on the server used. Finally tracked down the log file
> locations and there it was. I updated the certs via imanager and
> hopefully tonight the process will run.


Seems likely; you could kick off the job right now too, if you wanted.
Waiting is not bad, though.

> Question. When correcting expiry dates on some users who where close to
> their password expiring, I noticed the updates where not going across
> the edir2edir driver. Now that I updated the Certs on the server on one


Is the attribute you changed in the driver filter on this side? I'd guess
you are using Universal Password (UP) which calculates expiration times
locally rather than (usually) using a separate attribute. The other
attribute is there, mostly for backward compatibility, but it is not the
only thing that matters. If you are using UP, then if you change the
expiration to be farther out (into the future) UP will also override that
automatically, invalidating your change, because what you are doing is
against policy, and the policy was theoretically deemed to be
right/good/correct by the organization, therefore what you are doing is bad.

> side of the driver do I need to re-cert the driver itself? The server
> whose cert I had to update is my IDM vault server.


Chances are that the certificate you changed was the certificate used by
LDAP, and I would guess that you likely have different certificates for
driver configuration objects' connections. If not, you should, but the
only way to know for sure is to test. Perhaps test by doing something you
know will synchronize, like creating a test user, or changing a user's
password.


--
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
Knowledge Partner
Knowledge Partner

Re: SSPR 3.3.1 stopped notification of password expiry

On 9/6/2018 10:14 AM, allenmorris wrote:
>
> Okay.
>
> First, I was looking in the incorrect location. The expiry emails are
> not created or sent from SSPR, it done by IDM as a Job.


Ya, that makes more sense, I could not quite imagine how SSPR would
implement this functionality sensibly.

> Second the Job was set up correctly, the issue was caused when the SSL
> cert expired on the server used. Finally tracked down the log file
> locations and there it was. I updated the certs via imanager and
> hopefully tonight the process will run.


Good to knonw.

> Question. When correcting expiry dates on some users who where close to
> their password expiring, I noticed the updates where not going across
> the edir2edir driver. Now that I updated the Certs on the server on one
> side of the driver do I need to re-cert the driver itself? The server
> whose cert I had to update is my IDM vault server.


Look at the certs in use by the eDir driver, did they too expire? They
are not linked to the server cert, rather to the CA cert.

Default is 2 years, so if you made them all at the same time, then they
likely expired together. If not, not.



0 Likes
allenmorris Absent Member.
Absent Member.

Re: SSPR 3.3.1 stopped notification of password expiry

Hello again,

Thank you for your suggestions.

f you are using UP, then if you change the
expiration to be farther out (into the future) UP will also override


Good to know, that is exactly what I was trying.

like creating a test user, or changing a user's
password.


Yes, thanks for the idea, I had just complete this process and it worked fine.

As for the eDir2eDir certs, I just went ahead and updated them. Even if they weren't expired, there are fine for two years now.

Will need to put this on my calendar. Even though our new IT Directory is saying IDM will be gone within three years. He is a strict any thing that was Novell is outdated type person.

Many thanks,

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