Use integrated identity information to create and manage identities and control access to enterprise resources. We provide identity and access management, single sign–on (SSO), access governance, and more.

Detect and respond to all potential threats quickly and decisively. By monitoring user activities, security events, and critical systems, we provide actionable security intelligence to reduce the risk of data breach.

Get affordable, high-performance disaster recovery. We protect your workloads and help you meet or exceed RPOs and RTOs of an hour or less, with mirroring-like performance at a price point approaching tape.

Toolkit Rules in Identity Manager Part 2

In the article: Toolkit Rules in Identity Manager Part 1 I started talking about approaches to writing toolkit rules in Identity Manager to use to test data in the tree, report on it, and possibly clean it up.

The example I started with in the first part of the article was the case where I have some custom attributes, DirectorEID that comes from my Human Resources system, denoting the EmployeeID of the Director for each User.

Of course in eDirectory, I really want to use the Distinguished Name (DN) of the object so that I get all the benefits of using a DN. (If the object is moved or renamed, all is good, the attribute stays up to date.

Whereas if I stored the DN in a string attribute, then I would have to be sure to update it whenever that object moves or is renamed. A great example of this is in an article on Work Orders (Making Sure Your Work Orders Work!), where the suggested solution is build rules to do this checking, but I suggested in the comments it would be much easier to just store the DN in a DN Syntax attribute, which oddly enough is missing in the base schema for a Work Order. I have put in an enhancement request through Bugzilla for the addition of some attribute, say DirXML-nwoTarget that is DN syntax, but in the short term, whenever I personally need to do it, I create an aux class with a custom attribute like acmeWorkOrderTarget for this purpose.)

In my example, the users should all have the DirectorDN attribute populated with the right value, based on the DirectorEID attribute. But like most times, the real world is not that simple, and stuff happens. Therefore, I need to first off confirm everyone has the value set, and report all those who do not. Second if I am ready, then fix those that are wrong.

The basic rule I suggested in part 1, is this (see Part 1 for an explanation of what each step is trying to do:

Thus the test is, operation is trigger (which is what trigger Jobs do), and there is a operation property called source, that is the common name of the Job object. That is a pretty easy way to test it.

There is another approach that makes life a lot easier, using some attribute to trigger it. Initially I used to build the rule, disable the rule that actually does the ‘fixing’ of the problem, and report on it until I am ready to go. Once I am ready, I edit the rule to enable the fix it actions, and then I fix it. What we can do is actually trigger on the attribute changing to one of two different values. Lets say 42 to report, and 43 to fix the problem. This way, I can see the report, say ok, lets fix it, run the fix it tool, see that it claims to have fixed everything, and then run the report rule again to confirm it really succeeded.

If I wanted to that, the condition block would probably look more like this:

That was the easy part, now to make it do something different based on what triggered it. What I would do is basically wrap the ‘fix it’ part in a test for the triggering condition. I would take this action:

You could also extend this by using two jobs, one to report, and one to fix, in the same method. (I will skip that since I like using 42 much better!)

Reporting via Email:

We talked about reporting and fixing the problem, but we really have not delivered any kind of report yet, that was left as an exercise to the reader. Well lets talk about that now. There is a great token, Send Email that we can use, that pretty much covers the whole issue.

I happen to have strong feelings about how this should be used. I think you should avoid hard coding any values into the do-send-email token, so that it is easy to reuse from one rule to another. I think Global Configuration Values (GCV) should be used through out to make this portable and easy to use.

For example, the token requires you to specify a SMTP server. Never hard code a value here, even worse, never use an IP number! This is the kind of stuff that changes all the time at the back end, and who wants to troubleshoot why a report is failing, because the mail guys moved the SMTP server.

I pretty much always add a GCV to the driver set called smtpServer, and specify the IP name of the SMTP server of the local site in it. The field you set the SMTP server name (server), does not take a Token GCV, so you have to use the tilde GCV tilde notation, so it would look like ~smtpServer~ in the server field.

As a consultant, I walk into a site, help them with a project or issue, and then walk away. For the duration of the project, I want to receive these reporting emails. Once I am done with the client, I really am not interested in them any longer. So I always set up a GCV called toErrorEmails, and toCCErrorEmails. I put myself in the toErrorEmails GCV (By the way, to add more than one, use a comma to separate email addresses in the GCV) and the local support guys. Finally, at least on the addressing front, many SMTP servers and mail systems frown upon email without a From: value. Thus we set up a GCV called fromEmail, usually idm@acme.com or whatever the site name is. If there are multiple trees, (say Dev, QA, and Prod), I usually name it idm-dev@acme.com, idm-qa@acme.com, and idm-prod@acme.com so I can easily tell which tree is sending the report.

We still need to put some useful values in the Subject and Message strings still.

The ‘message’ is pretty easy, as you will notice we have been building the MESSAGE local variable as we go along containing all the interesting stuff the rule has done so far. At the simplest level, we can make it look like:

We will come back to this one and expand it a lot more later, since we can do some nice cosmetic things, but for now that is quite helpful.

The ‘subject’ string can be made really useful as well. Lets report the time in nice readable format, add in the driver name (we can use the built in GCV dirxml.auto.driverdn so no hard coding here, it returns the current driver name where the rule is running), so you know with certainty where it is coming from, some descriptive text, and finally, if we have it, the value of the trigger that started this rule off, so we know how it started. We try and show the operation attribute SomeTriggerAttribute, which will be blank if it is not there, and then the operation property, source, in case we started it from a Job. We should only ever trigger it via one of the two methods, so only one value should ever show up in the subject.

It would be nice to know up at the top of the report message, how many users had the correct values, how many had the wrong values, and perhaps for how many cases we could not find the EID of the director. To get that data we need to use some counters. One thing I have noticed is that there is no integer type for local variables, only string and node set, so it is best to initialize the counter variables up front, so lets do that for DIR-CORRECT-COUNT, DIR-WRONG-COUNT, and DIR-NOTFOUND-COUNT variables even before we do our query for USERS.

Note in all four cases I use the number() function. In reality it is not needed, usually only needed on subtraction (since the minus sign (-) is a valid value in a variable or function name in XPATH, and if you do not space it correctly, XPATH is not sure. (See this article for more details on XPATH and math XPATH and math). But it does not seem to incur much of a performance hit, and it guarantees no string to number conversion issues.

We will need to include these strings in the message, but we will come back to that in part 3. Stay tuned for the next part, where we start looking at more neat things we can include in the message to be helpful and informative. The rule as it sits now at the end of part 2, is attached as an XML file you can copy and paste into your environment, looks something like this:

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.