After uprading from 7.1 to 7.2 (June 2015) I started a series of newsletters / IdM tutorials for our administrators and approvers. By now I have written nine ones. I guess I’ll just drop some kind of the best here from which I think they might be useful for everyone out there. This one is actually a smaller part of the “whats new in 7.2” tutorial.
Ever since using 7.2 I was annoyed by the fact that there is no possibility to directly set system and only privs in the UI (say: like a button for the retry). Yes, I created a batch job for this in every project (or imported it). Yes, this works using the DIRECT_REFERENCE. Yes, I had to change the job every time I used it. Yes, it’s annoying. 🙂
As we are migrating our AD users from four domains to one domain, sometimes the nightly batch jobs doesn’t fix the system / only privs properly. Sometimes we delete a user and re-add it in another domain. And so on, a whole lot of sources why the system and only privs aren’t set correctly. At first I used the job, but it was quite annoying for me, because besides one other colleague we were the only two how are able to do it. After some weeks fixing the privs in the batch job I was fed up. What I did when someone reported a “user doesn’t get updated”: Looking at the user in the UI if the system priv is set. Most times, no it wasn’t. Going into the Identity Center fixing the system priv with the job. Back to the UI and triggering the provisioning.
I created a UI task with a subtask which is capable of doing exactly this. Not needed you may think? Oh well. 365 executions since August 2015 (2% of our identities). Almost 300 done by me, 50 done by my colleague and the rest of around 20 were executed by three other administrators.
The UI task
This is what it looks like:
I included the ACCOUNT and DN attributes (I still use both, DN for provisioning and ACCOUNT for nightly resync) to make it a bit more clear. There are even more systems but I just displayed the 4 AD domains here.
Side note: You make ask now: “Why do you have only privs of other domains set?” Because I couldn’t make group provisioning work elsewise. I actually use an additional batch job here, too 🙂
This is what the destination tab looks like:
Other target systems and the only privs work likewise. First part is the name of the priv which shall be checked, second the attribute name of the checkbox responsible for it.
Actually I use two scripts as I use my beloved checkOnError script almost everywhere. A former colleague said to me once if I use this one I miss out the error handling. Setting the !ERROR to “” is in 99,99% the correct thing to do. Actually I only remember one case where I didn’t use it (and I knew it beforehand). Plus some debugging with uWarning cases.
The main script isn’t really rocket science, just all cases covered including the NULLATTR case which is probably the most important one