petitp Absent Member.
Absent Member.
799 views

PWNotify: "Last Referenced Time" is not replicated

Hello,

the Password Expiration Notification Service driver (cf. PWNotify in https://www.brummelhook.com/dirxml.html) uses the attribute "Last Referenced Time" to store the last time it did a check to discover who needs to be notified.
This attribute is not replicated (cf. "Last Referenced Time" in https://www.novell.com/documentation/developer/ndslib/schm_enu/data/sdk1336.html).
This might cause trouble when the driver is stopped on one server and started on a replicated server:
it will calculate who needs to be notified from the last time it did a check on the replicated server, which might be many months before the time of the last check on the original server.
This would send duplicate notifications, thus spaming the users (and probably also the messages will be confusing, since it would warn late about future expiration, e.g. "will expire in 15 days" when there is only one day left).

- Has this been an issue for you ?
- How can it be fixed?
e.g. would replacing "Last Referenced Time" with a replicated attribute with TimeStamp syntax do the job? Which one?

Thanks in advance for your lights!

Dominique
Labels (1)
0 Likes
9 Replies
Knowledge Partner
Knowledge Partner

Re: PWNotify: "Last Referenced Time" is not replicated

On 8/21/2018 5:04 PM, petitp wrote:
>
> Hello,
>
> the Password Expiration Notification Service driver (cf. PWNotify in
> https://www.brummelhook.com/dirxml.html) uses the attribute "Last
> Referenced Time" to store the last time it did a check to discover who
> needs to be notified. > This attribute is not replicated (cf. "Last Referenced Time" in
> https://www.novell.com/documentation/developer/ndslib/schm_enu/data/sdk1336.html).


You are correct sir. It was chosen for that specific reason, that it is
flagged as Per-Replica.


> This might cause trouble when the driver is stopped on one server and
> started on a replicated server:


Yes. But this is true for all IDM drivers and their per server values.

> it will calculate who needs to be notified from the last time it did a
> check on the replicated server, which might be many months before the
> time of the last check on the original server.
> This would send duplicate notifications, thus spaming the users (and
> probably also the messages will be confusing, since it would warn late
> about future expiration, e.g. "will expire in 15 days" when there is
> only one day left).
>
> - Has this been an issue for you ?
> - How can it be fixed?


There is a GCV that allows you to say, only look from this time, on your
first poll.

Look under Schedule and Targets GCV, the Initial Notification Time,
which describes itself as:

Time taken as LastRunTime when this driver is started and LastRunTime
cannot be read from the driver object's Last Referenced Time attribute.
This usually occurs only on first start of the driver after initial
deployment, or after restoring a backup or moving the driver to another
server. In this case set this GCV to the time the last successful
notification processing took place to prevent double notifications. This
is necessary because Last Referenced Time is a per-replica attribute and
does not get replicated to other servers.
Use Debug Date/Time Format as defined above.


Almost like that sneaky critter Lothar thought about this already. (He
is annoying that way!)

0 Likes
petitp Absent Member.
Absent Member.

Re: PWNotify: "Last Referenced Time" is not replicated

Hello,
thanks for your answer!

>> the Password Expiration Notification Service driver (cf. PWNotify in
>> https://www.brummelhook.com/dirxml.html) uses the attribute "Last
>> Referenced Time" to store the last time it did a check to discover who
>> needs to be notified. > This attribute is not replicated (cf. "Last Referenced Time" in
>> https://www.novell.com/documentation/developer/ndslib/schm_enu/data/sdk1336.html).
>
> You are correct sir. It was chosen for that specific reason, that it is
> flagged as Per-Replica.

What is the purpose of not replicating that time stamp?


>> This might cause trouble when the driver is stopped on one server and
>> started on a replicated server:
>
> Yes. But this is true for all IDM drivers and their per server values.

I don't understand:
a driver should be designed so that it serves a particular purpose,
and the characteristics of the objects used should be chosen accordingly.
In this case I fail to see why the time stamp is stored in a non replicated attribute.

We did setup a replica server so we have some redundancy.
If the server where the driver runs fails, we would like to
start the driver on the replicated server: that is it's purpose!
I'd like to write a script to facilitate the failover of all the drivers,
but this issue is an obstacle for PWNotify (see below).

> There is a GCV that allows you to say, only look from this time, on your
> first poll.
>
> Look under Schedule and Targets GCV, the Initial Notification Time,
> which describes itself as:
>
> Time taken as LastRunTime when this driver is started and LastRunTime
> cannot be read from the driver object's Last Referenced Time attribute.
> This usually occurs only on first start of the driver after initial
> deployment, or after restoring a backup or moving the driver to another
> server. In this case set this GCV to the time the last successful
> notification processing took place to prevent double notifications. This
> is necessary because Last Referenced Time is a per-replica attribute and
> does not get replicated to other servers.
> Use Debug Date/Time Format as defined above.

I know about that GCV and forgot to mention it in my initial post.
But that is exactly the obstacle mentioned above: because the
Last Referenced Time is not replicated one has to script the change
of the Initial Notification Time GCV; it is quite annoying, especially if
one cannot consult the value of Last Referenced Time stored
on the failed server (it is probably guessable, but this is
a lot of hassle when the value could be up to date on the replicated server!)

Besides the GCV has its problem as well:
if the driver has ever run on the replicated server, then
Last Referenced Time would contain an ancient date value and
the Initial Notification Time GCV is ignored, causing duplicates messages anyway.


Perplexed...
Dominique
0 Likes
Knowledge Partner
Knowledge Partner

Re: PWNotify: "Last Referenced Time" is not replicated

>> You are correct sir. It was chosen for that specific reason, that it
> is
>> flagged as Per-Replica.

>
> What is the purpose of not replicating that time stamp?


Also a good question. Lothar is probably jumping off some perfectly
servicable mountain, so I will defer to him on this topic.

You can pick any attribute you want, and switch the driver over to use,
fairly simply. Really it is just read in one or two policies and then
written in another.

Heck, want some fun? Make a package that overlays, and simply schema
maps Last Referenced Time to some other attribute? And then reformat
the simple string attr to look structured. Then you can add it on top
of existing package, no issues.



>>> This might cause trouble when the driver is stopped on one server and
>>> started on a replicated server:

>>
>> Yes. But this is true for all IDM drivers and their per server values.

>
> I don't understand:
> a driver should be designed so that it serves a particular purpose,
> and the characteristics of the objects used should be chosen
> accordingly.
> In this case I fail to see why the time stamp is stored in a non
> replicated attribute.
>
> We did setup a replica server so we have some redundancy.
> If the server where the driver runs fails, we would like to
> start the driver on the replicated server: that is it's purpose!
> I'd like to write a script to facilitate the failover of all the
> drivers,
> but this issue is an obstacle for PWNotify (see below).
>
>> There is a GCV that allows you to say, only look from this time, on

> your
>> first poll.
>>
>> Look under Schedule and Targets GCV, the Initial Notification Time,
>> which describes itself as:
>>
>> Time taken as LastRunTime when this driver is started and LastRunTime
>> cannot be read from the driver object's Last Referenced Time

> attribute.
>> This usually occurs only on first start of the driver after initial
>> deployment, or after restoring a backup or moving the driver to

> another
>> server. In this case set this GCV to the time the last successful
>> notification processing took place to prevent double notifications.

> This
>> is necessary because Last Referenced Time is a per-replica attribute

> and
>> does not get replicated to other servers.
>> Use Debug Date/Time Format as defined above.

>
> I know about that GCV and forgot to mention it in my initial post.
> But that is exactly the obstacle mentioned above: because the
> Last Referenced Time is not replicated one has to script the change
> of the Initial Notification Time GCV; it is quite annoying, especially
> if
> one cannot consult the value of Last Referenced Time stored
> on the failed server (it is probably guessable, but this is
> a lot of hassle when the value could be up to date on the replicated
> server!)
>
> Besides the GCV has its problem as well:
> if the driver has ever run on the replicated server, then
> Last Referenced Time would contain an ancient date value and
> the Initial Notification Time GCV is ignored, causing duplicates
> messages anyway.


That is a good point.

0 Likes
Knowledge Partner
Knowledge Partner

Re: PWNotify: "Last Referenced Time" is not replicated

petitp wrote:

> What is the purpose of not replicating that time stamp?


So you can run the driver in parallel on multiple servers in a driverset, which
are possibly configured differently (scope, timing, email templates etc.)

> We did setup a replica server so we have some redundancy.
> If the server where the driver runs fails, we would like to
> start the driver on the replicated server: that is it's purpose!


Nothing stops you from using a different and replicated attribute to store the
timestamp if that makes more sense for you. Just copy the PWNotifyBase package
and edit policies P-ET200/800 to your liking.

You could even use a GCV instead of a fixed attr name and make this a
configurable setting. Or I could do it in the next version, maybe... 🙂


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
petitp Absent Member.
Absent Member.

Re: PWNotify: "Last Referenced Time" is not replicated

Hello,

Tanks for your answer:

>> What is the purpose of not replicating that time stamp?
>
> So you can run the driver in parallel on multiple servers in a driverset, which
> are possibly configured differently (scope, timing, email templates etc.)

Interesting!
I never considered running a driver in parallel.

> Nothing stops you from using a different and replicated attribute to store the
> timestamp if that makes more sense for you. Just copy the PWNotifyBase package
> and edit policies P-ET200/800 to your liking.

OK.
So this leaves my question of which attribute to choose.

I assume that to replace Last Referenced Time an attribute should also
be in the objectClass Top. Non inherited attributes in DirXML-Driver or even DirXML-Subscriber
or DirXML-Publisher are probably too risky to use by PWNotify.

cf. https://www.novell.com/documentation/developer/ndslib/schm_enu/data/a3he30j.html
https://www.novell.com/documentation/developer/ndslib/schm_enu/data/a3heftc.html
https://www.novell.com/documentation/developer/ndslib/schm_enu/data/a3hefu3.html

Adding a custom auxiliary class to the PWNotify driver object might be also possible,
but modifying the schema seems far fetched for this purpose.

- So which other attribute would you suggest?


PS:
The only two other attributes in these object classes with Timestamp syntax
(2.16.840.1.113719.1.1.5.1.19) are objectVersion (Top)
and DirXML-Act2 (DirXML-Driver), but both are read only (NO-USER-MODIFICATION).
If one also considers DirXML-Subscriber:
same for DirXML-Timestamp and DirXML-Timestamp2.
So the attribute should be in another syntax, e.g. Directory String.
0 Likes
Knowledge Partner
Knowledge Partner

Re: PWNotify: "Last Referenced Time" is not replicated

>> So you can run the driver in parallel on multiple servers in a
> driverset, which
>> are possibly configured differently (scope, timing, email templates

> etc.)
>
> Interesting!
> I never considered running a driver in parallel.


To be fair nor did I, but with different LDAP scopes (GCV so per-replica
as well) that could be pretty effective!

>> Nothing stops you from using a different and replicated attribute to

> store the
>> timestamp if that makes more sense for you. Just copy the PWNotifyBase


> OK.
> So this leaves my question of which attribute to choose.
>
> I assume that to replace Last Referenced Time an attribute should also
> be in the objectClass Top. Non inherited attributes in DirXML-Driver or
> even DirXML-Subscriber
> or DirXML-Publisher are probably too risky to use by PWNotify.


I was originally going to say, it should be Timestamp syntax, since LDAP
allows you to do < and > searches with a date string. but I was wrong.
That is for the Password Expiration Time, not for the storage of the
timestamp.

How about DirXMl-DriverStorage? Loopback does not use that I think. It
is a string field, usually an XML blob, but just string. Actually, I
looked, it is a stream, but it can hold a simple string.

This is a logical place to store it...

If you are using the Ourobous eDir version of PWNotify, where it is one
eDir driver talking to itself then the shim might be using the
DirXMl-DriverStorage attribute.

You could use "Used By" which is path syntax. Use the driver itself as
the Volume, and either namespace or path components as the date.


> cf.
> https://www.novell.com/documentation/developer/ndslib/schm_enu/data/a3he30j.html
> https://www.novell.com/documentation/developer/ndslib/schm_enu/data/a3heftc.html
> https://www.novell.com/documentation/developer/ndslib/schm_enu/data/a3hefu3.html
>
> Adding a custom auxiliary class to the PWNotify driver object might be
> also possible,
> but modifying the schema seems far fetched for this purpose.
>
> - So which other attribute would you suggest?
>
>
> PS:
> The only two other attributes in these object classes with Timestamp
> syntax
> (2.16.840.1.113719.1.1.5.1.19) are objectVersion (Top)
> and DirXML-Act2 (DirXML-Driver), but both are read only
> (NO-USER-MODIFICATION).
> If one also considers DirXML-Subscriber:
> same for DirXML-Timestamp and DirXML-Timestamp2.
> So the attribute should be in another syntax, e.g. Directory String.
>
>


0 Likes
Knowledge Partner
Knowledge Partner

Re: PWNotify: "Last Referenced Time" is not replicated

On 08/27/2018 06:57 PM, Geoffrey Carman wrote:
>>> Nothing stops you from using a different and replicated attribute to

>> store the
>>> timestamp if that makes more sense for you. Just copy the PWNotifyBase

>
>> OK.
>> So this leaves my question of which attribute to choose.
>>
>> I assume that to replace Last Referenced Time an attribute should also
>> be in the objectClass Top. Non inherited attributes in DirXML-Driver or
>> even DirXML-Subscriber
>> or DirXML-Publisher are probably too risky to use by PWNotify.

>
> I was originally going to say, it should be Timestamp syntax, since LDAP
> allows you to do < and > searches with a date string. but I was wrong.
> That is for the Password Expiration Time, not for the storage of the
> timestamp.


Yes, it does not matter the type, since it is not used for range searching.

> How about DirXMl-DriverStorage? Loopback does not use that I think. It


Um, Geoffrey? I think you are both searching for REPLICATED attribute.
Replacing one non-replicated attribute for another seems like a bit of
work for nothing.

I am a little skeptical that this is worth the effort in any case. The
only downside if you lose that attribute value (e.g. when failing over to
another server) is that users may get one more e-mail than they would
otherwise. Also, your system may send out a few more e-mails on its first
run through the users with sooner-than-later-expiring passwords.

--
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: PWNotify: "Last Referenced Time" is not replicated

>> How about DirXMl-DriverStorage? Loopback does not use that I think. It
>
> Um, Geoffrey? I think you are both searching for REPLICATED attribute.
> Replacing one non-replicated attribute for another seems like a bit of
> work for nothing.


Forgot that was per-replica. Oops.


> I am a little skeptical that this is worth the effort in any case. The
> only downside if you lose that attribute value (e.g. when failing over to
> another server) is that users may get one more e-mail than they would
> otherwise. Also, your system may send out a few more e-mails on its first
> run through the users with sooner-than-later-expiring passwords.
>


0 Likes
Knowledge Partner
Knowledge Partner

Re: PWNotify: "Last Referenced Time" is not replicated

petitp wrote:

> So this leaves my question of which attribute to choose.


I'd use a CIS attribute in an aux class and store the timestamp as a
yyyyMMddHHmmss string. You'd have to edit the timestamp conversion in both
places where the value is read and written, as well as the attribute name.

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
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.