CA Service Management

I have a need to track who is inserting and removing people from groups. There are a number of people who have the rights but some aren't following our policies and I need to figure out who it is. I want to track it in the audit logs.  I've tried adding the following to the audlog_site.mod file...
 

The attribute seems to have added correctly and I can see it listed when I run a bop_sinfo against grpmem.

The trigger doesn't error when I start services but when I actually try and test it, it does throw errors.

Upon changing the notify_flag, the manager flag or inserting a new record, I get this error in the log

spelsrvr            10256 ERROR        interp.c               559 grpmem::audit_fields_site Unknown message.

Upon delete, the trigger doesn't even fire. No error, No audit log.

Has anyone else ever tried and gotten this to work? Any assistance would be appreciated.

brett_zipkin:

I have a need to track who is inserting and removing people from groups. There are a number of people who have the rights but some aren't following our policies and I need to figure out who it is. I want to track it in the audit logs.  I've tried adding the following to the audlog_site.mod file...
 

// Add to Grpmem object.
OBJECT grpmem {
    ATTRIBUTES  Group_Member {
        audit_userid LOCAL  SREL cnt TENANCY_UNRESTRICTED {
                                ON_NEW DEFAULT USER;
                                ON_CI SET USER;
                            };

    };
    
    TRIGGERS {
    POST_CI audit_fields_site(persistent_id, audit_userid,
                         manager_flag, notify_flag, member) 52
        FILTER( EVENT("INSERT(NX_AUDIT_INS) UPDATE(NX_AUDIT_UPD) DELETE(NX_AUDIT_DEL)") );
    };
};

The attribute seems to have added correctly and I can see it listed when I run a bop_sinfo against grpmem.

The trigger doesn't error when I start services but when I actually try and test it, it does throw errors.

Upon changing the notify_flag, the manager flag or inserting a new record, I get this error in the log

spelsrvr            10256 ERROR        interp.c               559 grpmem::audit_fields_site Unknown message.

Upon delete, the trigger doesn't even fire. No error, No audit log.

Has anyone else ever tried and gotten this to work? Any assistance would be appreciated.

Hi All,

Any ideas here for Brett?

Thanks!

Chris

I'm resurrecting this dead thread because I have the need to audit changes to arbitrary LREL tables and I can't be the only one. grpmem is a good example of this and one of the actual LREL tables I need to audit, so I'll use it as an example.

Building on Brett.Zipkin's trigger I managed to fire the trigger on insert, update and delete. He got it almost right, there was only two minor changes I made to his trigger and it started firing:

 PRE_VALIDATE audit_fields_site(persistent_id, audit_userid, manager_flag, notify_flag, member) 52 FILTER( EVENT("INSERT UPDATE DELETE") );

So I changed the evaluation phase from POST_CI to PRE_VALIDATE and removed the NX_AUDIT_INS/NX_AUDIT_UPD/NX_AUDIT_DEL from the filter.

The error comes form the fact that the trigger calls a method that doesn't exist. One must either implement it or call an existing method. Didn't explore the options yet so at this time I don't know whether there is a generic audit method that can be called or if I just need to implement it myself, but at least when editing the manager/notify flag on the group details the audit_userid is not defined, so it'll require some special love.

I'll reply to this thread if I have more findings to share.

The problem with auditing the grpmem table is that when you remove a users group membership the associated row in grpmem is deleted, not inactivated.  This means you won't be able to audit deletions via the grpmem object.

Instead, you may need to add a column to the cnt object to store who is making changes to the users group membership.  You can add a trigger to grpmem that fires an update_object_super method to update cnt.

Had a bit of fun with this one!  The following customization will add an activity log to a user contact when their group membership changes.

Edit: I removed this customization from this thread and moved it to this document.  Since my original post I made a few changes to the code and added minimal error handling.

Hi Bret,

Did you get a chance to implement these suggestions...

~Vinod.

Yes, we did.  Made a few modifications to the logging string value but yes.  It's working well for us.  Although looking at his separate document, what we implemented didn't include the notify flag or check mark adjustments.  Only the memberships.

That's great! I'm glad this is being used.  

Absolutely.  So helpful to us.  Thank you again.  I may eventually double back and look at your check mark tracker.