Knowledge Partner
Knowledge Partner
234 views

Google driver question: is NOVLGGLEUSER-sub-otp_HandleDeleteEventsstill relevant?

This policy in the output transform is used to rename about-to-be-deleted
objects in Google, because Google doesn't immediately delete objects, it
leaves them around for a while. By renaming them, first, the driver
ensures that a later <add> event won't error out because the new object
name conflicts with a deleted but not yet purged object in Google.

For some time now, I've been ignoring a problem here where a user account
is deleted (account lifecycle), so it gets renamed and deleted in Google,
but then the user returns to an active status. What I've been seeing
happen, if they come back during the period where Google has marked the
account as deleted, but has not yet purged it, is that the driver hits
the matching rule, finds the deleted account, and restores it.

That would be fine, except that what the driver doesn't do is rename the
restored account back to what it used to be named before this rename-then-
delete policy was applied to it. So what I see is student (z025853) has a
Google account (z025853@students.niu.edu).

He gets deleted, so in Google I see him renamed and deleted as
(z0258531442257504@students.niu.edu).

He comes back, so I see the driver process an <add> for him, the matching
rule finds him, and he ends up restored as
(z0258531442257504@students.niu.edu).

I have this in old traces, and can see it happening like:


<modify class-name="UserEntry" event-id="LidGen
Input#Publisher#0:7e671a46-e021-4f8b-8d77-1e135e4d07f7" from-merge="true"
qualified-src-dn="O=NIU\OU=Users\CN=Z025853" src-dn="\NIU-FLAT\NIU\Users
\Z025853" src-entry-id="905613">
<association>Z0258531436059158@students.niu.edu</association>
<modify-attr attr-name="GivenName">
<remove-all-values/>
<add-value>
<value timestamp="1416192435#4" type="string">David</value>
</add-value>
</modify-attr>
<modify-attr attr-name="FamilyName">
<remove-all-values/>
<add-value>
<value timestamp="1416192435#5" type="string">Gersic</value>
</add-value>
</modify-attr>
<modify-attr attr-name="IsSuspended">
<remove-all-values/>
</modify-attr>
<operation-data/>
</modify>


I had a few minutes while waiting on somebody else to do something, so I
thought I'd see about fixing this. It seemed that it should be possible
to catch the <modify> with the @from-merge=true on it, and rename the
restored account back to what it should be (z025853@students.niu.edu). It
turns out not to be quite that simple, but I don't understand why not.

In watching the trace now, I don't see the driver matching policies find
the deleted account. So, with no match, there's no <modify @from-
merge=true> to do anything with. The <add> proceeds through the usual
processing, and a new account is created.

I suspect that this is a change in how the shim and the back end Google
API work. I think the old shim, prior to spring 2015, and the old Google
API worked one way, and the new shim, with the new Google API, work
differently in this regard. If so, then it seems to me that NOVLGGLEUSER-
sub-otp_HandleDeleteEvents is no longer relevant and could be removed
from the Google Apps User Package.

The point of this rename was to stop name collisions with deleted
objects. If I delete an object now, and create a new one that should
conflict, it doesn't. The matching rules that used to find the deleted
object by its alias, no longer do, so the <modify> never happens, and I
can't therefor catch the <modify> and add a <rename> to it.

I'm thinking, therefor, that NOVLGGLEUSER-sub-otp_HandleDeleteEvents is
no longer needed, and could be removed.

Alternately, I'm missing something here and I should be seeing the
Matching Rules find the deleted account, but I'm not.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.microfocus.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
Labels (1)
0 Likes
2 Replies
Marcus Tornberg Super Contributor.
Super Contributor.

Re: Google driver question: is NOVLGGLEUSER-sub-otp_HandleDeleteEventsstill relevant?


Hi David.

I came to the same conclusion a month ago. I have disabled these rules
as the makes no sense to have them anymore.

The problem I ran into was a timing issue when the renamed user was not
found for deletion probably because the rename event wasnt fully handled
fully by Google before the delete event.

This happened for about 1% of delete events.


--
marcus_jonsson
------------------------------------------------------------------------
marcus_jonsson's Profile: https://forums.netiq.com/member.php?userid=1157
View this thread: https://forums.netiq.com/showthread.php?t=54319

0 Likes
cpedersen Outstanding Contributor.
Outstanding Contributor.

Re: Google driver question: isNOVLGGLEUSER-sub-otp_HandleDeleteEvents still relevant?

I looked into this, as I was of the exact same opinion. But was told
that it's still there to handle name collision / name reuse.

The thing with finding deleted users and re-activating them might be an
issue.....

Casper


On 9/18/15 3:30 PM, David Gersic wrote:
> This policy in the output transform is used to rename about-to-be-deleted
> objects in Google, because Google doesn't immediately delete objects, it
> leaves them around for a while. By renaming them, first, the driver
> ensures that a later <add> event won't error out because the new object
> name conflicts with a deleted but not yet purged object in Google.
>
> For some time now, I've been ignoring a problem here where a user account
> is deleted (account lifecycle), so it gets renamed and deleted in Google,
> but then the user returns to an active status. What I've been seeing
> happen, if they come back during the period where Google has marked the
> account as deleted, but has not yet purged it, is that the driver hits
> the matching rule, finds the deleted account, and restores it.
>
> That would be fine, except that what the driver doesn't do is rename the
> restored account back to what it used to be named before this rename-then-
> delete policy was applied to it. So what I see is student (z025853) has a
> Google account (z025853@students.niu.edu).
>
> He gets deleted, so in Google I see him renamed and deleted as
> (z0258531442257504@students.niu.edu).
>
> He comes back, so I see the driver process an <add> for him, the matching
> rule finds him, and he ends up restored as
> (z0258531442257504@students.niu.edu).
>
> I have this in old traces, and can see it happening like:
>
>

> <modify class-name="UserEntry" event-id="LidGen
> Input#Publisher#0:7e671a46-e021-4f8b-8d77-1e135e4d07f7" from-merge="true"
> qualified-src-dn="O=NIU\OU=Users\CN=Z025853" src-dn="\NIU-FLAT\NIU\Users
> \Z025853" src-entry-id="905613">
> <association>Z0258531436059158@students.niu.edu</association>
> <modify-attr attr-name="GivenName">
> <remove-all-values/>
> <add-value>
> <value timestamp="1416192435#4" type="string">David</value>
> </add-value>
> </modify-attr>
> <modify-attr attr-name="FamilyName">
> <remove-all-values/>
> <add-value>
> <value timestamp="1416192435#5" type="string">Gersic</value>
> </add-value>
> </modify-attr>
> <modify-attr attr-name="IsSuspended">
> <remove-all-values/>
> </modify-attr>
> <operation-data/>
> </modify>
>

>
> I had a few minutes while waiting on somebody else to do something, so I
> thought I'd see about fixing this. It seemed that it should be possible
> to catch the <modify> with the @from-merge=true on it, and rename the
> restored account back to what it should be (z025853@students.niu.edu). It
> turns out not to be quite that simple, but I don't understand why not.
>
> In watching the trace now, I don't see the driver matching policies find
> the deleted account. So, with no match, there's no <modify @from-
> merge=true> to do anything with. The <add> proceeds through the usual
> processing, and a new account is created.
>
> I suspect that this is a change in how the shim and the back end Google
> API work. I think the old shim, prior to spring 2015, and the old Google
> API worked one way, and the new shim, with the new Google API, work
> differently in this regard. If so, then it seems to me that NOVLGGLEUSER-
> sub-otp_HandleDeleteEvents is no longer relevant and could be removed
> from the Google Apps User Package.
>
> The point of this rename was to stop name collisions with deleted
> objects. If I delete an object now, and create a new one that should
> conflict, it doesn't. The matching rules that used to find the deleted
> object by its alias, no longer do, so the <modify> never happens, and I
> can't therefor catch the <modify> and add a <rename> to it.
>
> I'm thinking, therefor, that NOVLGGLEUSER-sub-otp_HandleDeleteEvents is
> no longer needed, and could be removed.
>
> Alternately, I'm missing something here and I should be seeing the
> Matching Rules find the deleted account, but I'm not.
>
>


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.