Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"

plummb wrote:

>
>
> I performed the delete event while the driver was off. The cache
> inspector did not show me an association, but it also did not show me
> the association listed for other cached events, that processed just fine
> post-startup.


I concur with Aaron, this is extremely odd that you don't get a "Start transaction" prior to the delete.
Have you tried bumping the trace level up even higher, that might give a clue.

Did you do the Java7 updte that was part of the 4.0.2.2 engine patch?

Could it be rights/permission related?
If I recall correctly, DXEvent is the component that saves events into the filter, likely that runs with differing (higher) rights than the individual drivers.

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

Re: ADDriver Delete Events "Operation vetoed on unassociated"

On 9/4/2014 12:10 PM, Alex McHugh wrote:
> plummb wrote:
>
>>
>>
>> I performed the delete event while the driver was off. The cache
>> inspector did not show me an association, but it also did not show me
>> the association listed for other cached events, that processed just fine
>> post-startup.

>
> I concur with Aaron, this is extremely odd that you don't get a "Start transaction" prior to the delete.
> Have you tried bumping the trace level up even higher, that might give a clue.
>
> Did you do the Java7 updte that was part of the 4.0.2.2 engine patch?
>
> Could it be rights/permission related?
> If I recall correctly, DXEvent is the component that saves events into the filter, likely that runs with differing (higher) rights than the individual drivers.


The more I read about the symptoms, the more I think that somehow this
may be tied to replication?

I.e. The delete happens on one replica vs the driver replica, somehow
causing the difference. But I have no way to quantify it.

It 'feels' like a delete on my replica would have the Assoc since before
the delete is processed, it can be captured. But maybe when the delete
syncs over it somehow does not?

But if this theory were correct we ALL would have seen this over the
years, and no one has, as far as I recall.

Very odd.


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"

Geoffrey Carman wrote:

>
> The more I read about the symptoms, the more I think that somehow this may be tied to replication?
>
> I.e. The delete happens on one replica vs the driver replica, somehow causing the difference. But I have no way to quantify it.
>
> It 'feels' like a delete on my replica would have the Assoc since before the delete is processed, it can be captured. But maybe when the delete syncs over it somehow does not?


You could be right, the original poster said that the delete happens on a read-write replica and IDM is on the master.

The delete event seems to indicate it originated on the master, at least from the event ID.
I can't see a clear yes/no answer as to whether the delete occured on a filtered read/write replica or not.
Can understand how a filtered replica might omit some attributes required for IDM to determine the deleted object's association status and this might impact replicated deletes. Is that what you were hinting at Aaron?

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

Re: ADDriver Delete Events "Operation vetoed on unassociated"

On 9/4/2014 1:10 PM, Alex McHugh wrote:
> Geoffrey Carman wrote:
>
>>
>> The more I read about the symptoms, the more I think that somehow this may be tied to replication?
>>
>> I.e. The delete happens on one replica vs the driver replica, somehow causing the difference. But I have no way to quantify it.
>>
>> It 'feels' like a delete on my replica would have the Assoc since before the delete is processed, it can be captured. But maybe when the delete syncs over it somehow does not?

>
> You could be right, the original poster said that the delete happens on a read-write replica and IDM is on the master.
>
> The delete event seems to indicate it originated on the master, at least from the event ID.
> I can't see a clear yes/no answer as to whether the delete occured on a filtered read/write replica or not.
> Can understand how a filtered replica might omit some attributes required for IDM to determine the deleted object's association status and this might impact replicated deletes. Is that what you were hinting at Aaron?


A filtered replica, without DirXMl-Associations and you expect ANYTHING
to work with IDM seems really silly. But you never know.


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"


It was suggested that I run a full repair on the servers and did so. I
also checked for Obits and found none. I checked sync and it appears on
time. I created another accounts, put through some changes and then
deleted. Same thing:

http://tny.cz/66804f17

One thing i did see during the repair was this:

ERROR: Invalid server ID in backlink obituary is purged: 00008047
Attribute 540f387f, Obituary
Object ID: 0001c8e9, DN: CN=PROCFLOW.OU=Users.OU=Person.O=IDM.T=META

So I reran the repair afterwards to verify this was corrected by
ndsrepair.


--
plummb
------------------------------------------------------------------------
plummb's Profile: https://forums.netiq.com/member.php?userid=1727
View this thread: https://forums.netiq.com/showthread.php?t=51659

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"


All,
I figured out the issue. When I noticed a lag (~ 40 minutes) in
replication on my driveset partition, I realized all 3 other servers
were holding a sub-reference, instead of read-write. I update this,
which corrected replication timing and immediately resolved the delete
issue.


--
plummb
------------------------------------------------------------------------
plummb's Profile: https://forums.netiq.com/member.php?userid=1727
View this thread: https://forums.netiq.com/showthread.php?t=51659

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"


As a follow up FYI: Customer actually found that the Subordinate
reference replica placement was not the source of the issue.

During a delete event we believe the association is being read from
cache or from jclient.
Recommended customer remove the index on the DirXML-Association
attribute and recreate the index.
During the index recreation, it caused interruption with User
Application services. The Index recreation was also taking
substantially longer that it should have been. (over an hour).

So the customer rebooted the server. After the reboot the drivers came
back up and the index created in a couple of minutes.
Additional delete events contained the association.

eDirectory had been running for 45 days and these issues began after the
last reboot. A restart of NDSD would likely have resolved the issue
without a recreating the index.


--
denchris
------------------------------------------------------------------------
denchris's Profile: https://forums.netiq.com/member.php?userid=908
View this thread: https://forums.netiq.com/showthread.php?t=51659

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"


plummb;248618 Wrote:
> All,
> I figured out the issue. When I noticed a lag (~ 40 minutes) in
> replication on my driveset partition, I realized all 3 other servers
> were holding a sub-reference, instead of read-write. I update this,
> which corrected replication timing and immediately resolved the delete
> issue.


I just wanted to post an update on this with what ended up resolving
it.

It appears that either the eDirectory or index of DirXML-Associations
was corrupt. We tried rebuilding the index, before restarting
eDirectory, but deleting the index caused the User Application JBoss
instance to crash, and also prevented anyone from being able to
authenticate directly to this box. The index itself never finished
rebuilding, even though we gave it over an hour to do so. After
eDirectory was stopped and started the index rebuilt almost instantly,
the User Application's JBoss instance was able to be restarted and
authentication was able to function again. Also, the issue with delete
events not having an association on them was resolved.

In short, stop and restart eDirectory and that should fix the issue.

If it doesn't though, dropping the index, rebuilding it, and then
stopping and restarting eDirectory resolved it in this case, although
I'd be surprised if you had to follow all these steps.


--
rmonson
------------------------------------------------------------------------
rmonson's Profile: https://forums.netiq.com/member.php?userid=3059
View this thread: https://forums.netiq.com/showthread.php?t=51659

0 Likes
jtl1 Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"

On 2014-09-03 01:25, plummb wrote:
>
> This same event transpires on any of my users. Sync is just fine between
> eDir and MAD. All passwords and meta data sync just as intended. When
> trying to delete, this event occurs. I can recreate this with any
> account.
>
> Here is a new account (exported in LDIF with driver association):
> dn: cn=MyTest,ou=Users,ou=Person,o=IDM
> changetype: add
> DirXML-Associations: cn=mmcf
> domain,cn=eDirMeta,o=IDM#1#240cd0c1276899428c5869
> fb7098a607
>
> Here is the Level 3 on the delete event
>
> [09/02/14 19:19:00.206]:mmcf domain ST:Processing events for
> transaction.
> [09/02/14 19:19:00.206]:mmcf domain ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.0.2.2">DirXML</product>
> <contact>Novell, Inc.</contact>
> </source>
> <input>
> <delete cached-time="20140902231900.169Z" class-name="User"
> event-id="VMIDMMETA#20140902231900#3#1:9ead8b3c-b506-4482-e68f-3c8bad9e06b5"
> qualified-src-dn="O=IDM\OU=Person\OU=Users\CN=MyTest"
> src-dn="\META\IDM\Person\Users\MyTest" src-entry-id="116773"
> timestamp="1409699668#1"/>
> </input>
> </nds>
> [09/02/14 19:19:00.207]:mmcf domain ST:Applying event transformation
> policies.
> [09/02/14 19:19:00.207]:mmcf domain ST:Applying policy:
> %+C%14Csub-etp-Scoping%-C.
> [09/02/14 19:19:00.208]:mmcf domain ST: Applying to delete #1.
> [09/02/14 19:19:00.208]:mmcf domain ST: Evaluating selection criteria
> for rule 'Veto specify events'.
> [09/02/14 19:19:00.208]:mmcf domain ST: (if-operation equal "move")
> = FALSE.
> [09/02/14 19:19:00.208]:mmcf domain ST: (if-operation equal "sync")
> = FALSE.
> [09/02/14 19:19:00.208]:mmcf domain ST: Rule rejected.
> [09/02/14 19:19:00.208]:mmcf domain ST: Evaluating selection criteria
> for rule 'Break if the Event is wanted'.
> [09/02/14 19:19:00.209]:mmcf domain ST: (if-association associated)
> = FALSE.
> [09/02/14 19:19:00.209]:mmcf domain ST: (if-class-name equal
> "User") = TRUE.
> [09/02/14 19:19:00.209]:mmcf domain ST: (if-src-dn in-subtree
> "idm\person") = TRUE.
> [09/02/14 19:19:00.209]:mmcf domain ST: Rule selected.
> [09/02/14 19:19:00.209]:mmcf domain ST: Applying rule 'Break if the
> Event is wanted'.
> [09/02/14 19:19:00.209]:mmcf domain ST: Action: do-break().
> [09/02/14 19:19:00.210]:mmcf domain ST:Policy returned:
> [09/02/14 19:19:00.210]:mmcf domain ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.0.2.2">DirXML</product>
> <contact>Novell, Inc.</contact>
> </source>
> <input>
> <delete cached-time="20140902231900.169Z" class-name="User"
> event-id="VMIDMMETA#20140902231900#3#1:9ead8b3c-b506-4482-e68f-3c8bad9e06b5"
> qualified-src-dn="O=IDM\OU=Person\OU=Users\CN=MyTest"
> src-dn="\META\IDM\Person\Users\MyTest" src-entry-id="116773"
> timestamp="1409699668#1"/>
> </input>
> </nds>
> [09/02/14 19:19:00.211]:mmcf domain ST:Applying policy:
> %+C%14Csub-etp-Reset Attributes%-C.
> [09/02/14 19:19:00.211]:mmcf domain ST: Applying to delete #1.
> [09/02/14 19:19:00.211]:mmcf domain ST: Evaluating selection criteria
> for rule 'Reset DirXML-ADAliasName if changing'.
> [09/02/14 19:19:00.211]:mmcf domain ST: (if-operation equal
> "modify") = FALSE.
> [09/02/14 19:19:00.211]:mmcf domain ST: Rule rejected.
> [09/02/14 19:19:00.211]:mmcf domain ST: Evaluating selection criteria
> for rule 'Reset DirXML-ADContext if changing'.
> [09/02/14 19:19:00.212]:mmcf domain ST: (if-operation equal
> "modify") = FALSE.
> [09/02/14 19:19:00.212]:mmcf domain ST: Rule rejected.
> [09/02/14 19:19:00.212]:mmcf domain ST: Evaluating selection criteria
> for rule 'Block Empty Modifies'.
> [09/02/14 19:19:00.212]:mmcf domain ST: (if-class-name equal
> "User") = TRUE.
> [09/02/14 19:19:00.212]:mmcf domain ST: (if-operation equal
> "modify") = FALSE.
> [09/02/14 19:19:00.212]:mmcf domain ST: Rule rejected.
> [09/02/14 19:19:00.212]:mmcf domain ST:Policy returned:
> [09/02/14 19:19:00.213]:mmcf domain ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.0.2.2">DirXML</product>
> <contact>Novell, Inc.</contact>
> </source>
> <input>
> <delete cached-time="20140902231900.169Z" class-name="User"
> event-id="VMIDMMETA#20140902231900#3#1:9ead8b3c-b506-4482-e68f-3c8bad9e06b5"
> qualified-src-dn="O=IDM\OU=Person\OU=Users\CN=MyTest"
> src-dn="\META\IDM\Person\Users\MyTest" src-entry-id="116773"
> timestamp="1409699668#1"/>
> </input>
> </nds>
> [09/02/14 19:19:00.213]:mmcf domain ST:Applying policy:
> %+C%14Csub-etp-Exch%-C.
> [09/02/14 19:19:00.214]:mmcf domain ST: Applying to delete #1.
> [09/02/14 19:19:00.214]:mmcf domain ST: Evaluating selection criteria
> for rule 'Capture Delete Event, get homeMDB from AD'.
> [09/02/14 19:19:00.214]:mmcf domain ST: (if-class-name equal
> "User") = TRUE.
> [09/02/14 19:19:00.214]:mmcf domain ST: (if-operation equal
> "delete") = TRUE.
> [09/02/14 19:19:00.214]:mmcf domain ST: Rule selected.
> [09/02/14 19:19:00.214]:mmcf domain ST: Applying rule 'Capture Delete
> Event, get homeMDB from AD'.
> [09/02/14 19:19:00.215]:mmcf domain ST: Action:
> do-set-local-variable("local.homeMDB",scope="policy",token-parse-dn(dest-dn-format="slash",length="1",src-dn-format="ldap",start="-1",token-dest-attr("mmcHomeMDB"))).
> [09/02/14 19:19:00.215]:mmcf domain ST:
> arg-string(token-parse-dn(dest-dn-format="slash",length="1",src-dn-format="ldap",start="-1",token-dest-attr("mmcHomeMDB")))
> [09/02/14 19:19:00.215]:mmcf domain ST:
> token-parse-dn(dest-dn-format="slash",length="1",src-dn-format="ldap",start="-1",token-dest-attr("mmcHomeMDB"))
> [09/02/14 19:19:00.216]:mmcf domain ST:
> token-parse-dn(dest-dn-format="slash",length="1",src-dn-format="ldap",start="-1",token-dest-attr("mmcHomeMDB"))
> [09/02/14 19:19:00.216]:mmcf domain ST:
> token-dest-attr("mmcHomeMDB")
> [09/02/14 19:19:00.216]:mmcf domain ST: Token Value: "".
> [09/02/14 19:19:00.216]:mmcf domain ST: Arg Value: "".
> [09/02/14 19:19:00.216]:mmcf domain ST: Token Value: "".
> [09/02/14 19:19:00.216]:mmcf domain ST: Arg Value: "".
> [09/02/14 19:19:00.217]:mmcf domain ST: Action: do-if().
> [09/02/14 19:19:00.217]:mmcf domain ST: Evaluating conditions.
> [09/02/14 19:19:00.217]:mmcf domain ST: (if-local-variable
> 'local.homeMDB' match ".+") = FALSE.
> [09/02/14 19:19:00.217]:mmcf domain ST: Performing else actions.
> [09/02/14 19:19:00.217]:mmcf domain ST: Action: do-break().
> [09/02/14 19:19:00.217]:mmcf domain ST:Policy returned:
> [09/02/14 19:19:00.217]:mmcf domain ST:
> <nds dtdversion="4.0" ndsversion="8.x">
>
> <input>
> <delete cached-time="20140902231900.169Z" class-name="User"
> event-id="VMIDMMETA#20140902231900#3#1:9ead8b3c-b506-4482-e68f-3c8bad9e06b5"
> qualified-src-dn="O=IDM\OU=Person\OU=Users\CN=MyTest"
> src-dn="\META\IDM\Person\Users\MyTest" src-entry-id="116773"
> timestamp="1409699668#1"/>
> </input>
> </nds>
> [09/02/14 19:19:00.220]:mmcf domain ST:Applying policy:
> %+C%14CFISMA%-C.
> [09/02/14 19:19:00.220]:mmcf domain ST: Applying to delete #1.
> [09/02/14 19:19:00.220]:mmcf domain ST: Evaluating selection criteria
> for rule 'Check Last Login Time - Act Accordingly'.
> [09/02/14 19:19:00.220]:mmcf domain ST: (if-operation equal
> "trigger") = FALSE.
> [09/02/14 19:19:00.220]:mmcf domain ST: Rule rejected.
> [09/02/14 19:19:00.221]:mmcf domain ST:Policy returned:
> [09/02/14 19:19:00.221]:mmcf domain ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.0.2.2">DirXML</product>
> <contact>Novell, Inc.</contact>
> </source>
> <input>
> <delete cached-time="20140902231900.169Z" class-name="User"
> event-id="VMIDMMETA#20140902231900#3#1:9ead8b3c-b506-4482-e68f-3c8bad9e06b5"
> qualified-src-dn="O=IDM\OU=Person\OU=Users\CN=MyTest"
> src-dn="\META\IDM\Person\Users\MyTest" src-entry-id="116773"
> timestamp="1409699668#1"/>
> </input>
> </nds>
> [09/02/14 19:19:00.222]:mmcf domain ST:Applying policy: %+C%14CVeto
> Trigger%-C.
> [09/02/14 19:19:00.222]:mmcf domain ST: Applying to delete #1.
> [09/02/14 19:19:00.222]:mmcf domain ST: Evaluating selection criteria
> for rule 'Veto Trigger Events'.
> [09/02/14 19:19:00.222]:mmcf domain ST: (if-operation equal
> "trigger") = FALSE.
> [09/02/14 19:19:00.222]:mmcf domain ST: Rule rejected.
> [09/02/14 19:19:00.222]:mmcf domain ST:Policy returned:
> [09/02/14 19:19:00.222]:mmcf domain ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <source>
> <product edition="Standard" version="4.0.2.2">DirXML</product>
> <contact>Novell, Inc.</contact>
> </source>
> <input>
> <delete cached-time="20140902231900.169Z" class-name="User"
> event-id="VMIDMMETA#20140902231900#3#1:9ead8b3c-b506-4482-e68f-3c8bad9e06b5"
> qualified-src-dn="O=IDM\OU=Person\OU=Users\CN=MyTest"
> src-dn="\META\IDM\Person\Users\MyTest" src-entry-id="116773"
> timestamp="1409699668#1"/>
> </input>
> </nds>
> [09/02/14 19:19:00.223]:mmcf domain ST:Subscriber processing delete for
> \META\IDM\Person\Users\MyTest.
> [09/02/14 19:19:00.223]:mmcf domain ST:Processing returned document.
> [09/02/14 19:19:00.224]:mmcf domain ST:Processing operation <status> for
> ..
> [09/02/14 19:19:00.224]:mmcf domain ST:
> DirXML Log Event -------------------
> Driver: \META\IDM\eDirMeta\mmcf domain
> Channel: Subscriber
> Object: \META\IDM\Person\Users\MyTest
> Status: Warning
> Message: Code(-8019) Operation vetoed on unassociated object.
> [09/02/14 19:19:00.302]:mmcf domain ST:End transaction.
>
>

Does the driver have rights to read the DirXML-Association attribute? Check direct rigths or security equivalence.

Best regards,
Tobias
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"


Security Equiv is as the admin account. The sync of data is working
fine. It just doesn't see an association at the time of delete.


--
plummb
------------------------------------------------------------------------
plummb's Profile: https://forums.netiq.com/member.php?userid=1727
View this thread: https://forums.netiq.com/showthread.php?t=51659

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"

On Tue, 02 Sep 2014 23:25:46 +0000, plummb wrote:

> Here is a new account (exported in LDIF with driver association): dn:
> cn=MyTest,ou=Users,ou=Person,o=IDM changetype: add
> DirXML-Associations: cn=mmcf
> domain,cn=eDirMeta,o=IDM#1#240cd0c1276899428c5869fb7098a607


This LDIF does seem to show a valid association, but where did it come
from? Does the GUID in the association value there match the GUID in your
MAD Domain? Export both objects (eDir / MAD) to LDIF and let's see the
results.


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

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"


David, the objectGUID value in MAD is binary. I can't seem to export it.
Though, if I look it with a LDAP browswer I see:

objectGUID: {1E1F5296-53E3-4941-8785-0FD677166AF0}
objectSid: S-1-5-21-964382842-1330588478-199955091-137442

The association GUID, is as I outlined before (I assume):
DirXML-Associations: cn=mmcf
domain,cn=eDirMeta,o=IDM#1#240cd0c1276899428c5869f b7098a607


--
plummb
------------------------------------------------------------------------
plummb's Profile: https://forums.netiq.com/member.php?userid=1727
View this thread: https://forums.netiq.com/showthread.php?t=51659

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: ADDriver Delete Events "Operation vetoed on unassociated"

plummb wrote:

>
> David, the objectGUID value in MAD is binary. I can't seem to export it.
> Though, if I look it with a LDAP browswer I see:
>
> objectGUID: {1E1F5296-53E3-4941-8785-0FD677166AF0}
> objectSid: S-1-5-21-964382842-1330588478-199955091-137442
>
> The association GUID, is as I outlined before (I assume):
> DirXML-Associations: cn=mmcf
> domain,cn=eDirMeta,o=IDM#1#240cd0c1276899428c5869f b7098a607


The association is the same value as object GUID, it's just represented in a different way.
Googling packed GUID should list many scripts that can translate between the two formats.

Your association value translates to: {c1d00c24-6827-4299-8c58-69fb7098a607} which is not the same wa



--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
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.