AD ADAM

I’ve recently had a chance to work closely with Microsoft ADAM.  It’s been a couple of years so I had to refresh myself about some of the things that differentiate the two.  While we were discovering the differences (some of which caused us to doubt the existence of logic, LDAP standards, and our very sanity) 

  • There’s no sAMAccountname attribute in ADAM
  • There”s no useraccountcontrol attribute either

I’m certain that there are many others and good reasons for all of them (at least within the Microsoft universe)  However, all was not lost as it gave me an opportunity to share a few excellent troubleshooting tips when working with NW IDM:

  • Disable all attributes and re enable them one at a time. Eventually you’ll find out what attributes are causing the issues.
  • Try switching run-time engines. Yes the Windows Engine is on the way out, but it often gives different error information. Same goes for Windows jobs, try the java engine.
  • Create a template user and then read it in.  This will give you a good idea of what attributes are required since the template engine will only return populated attributes. (this works great in tandem with the first tip.

Now these methods work great for database, directory and Identity Store passes.  

Speaking of Identity Store and Database passes that use queries in the source, if you’re having trouble, test the query directly in a SQL environment (MS SQL Query Analyzer or Oracle iSQL)  Get it working there (with better error trapping) and then paste it back into the Source Tab.

For an extra directory based tip… If to LDAP passes are giving you grief, redirect the out put to LDIF (LDAP is the standard) then you can read the output directly.  Great for catching syntactial issues.  If you have LDIF files associate with a viewer (or notepad) just double clock on the filename in the destination tab after the task/job completes for easy viewing.   Just don’t forget to change it back!

Advertisements

When Enterprise Systems Collide…

It’s no secret that there are many systems in the Enterprise and that sometimes they seemingly come into conflict.  How many places are there where one can:

  • Change information about themselves
  • Change information about others
  • Change a password
  • Add new roles
  • Add  new access

Well there are many.  One of the challenges of Identity Management is to examine, balance and ultimately limit what a given user can do from a given interface. Ultimately it is in the best interest of administrators and users to do this so that workflows and processes are as streamlined as possible.

This means that the IdM system does not need to be the center of the universe for updating information if prior to its introduction the HCM system had a perfectly good Self Service Module.  It also means that not every application needs to have its password maintenance functionality turned on, especially if passwords are being sent from another interface (i.e., OS password change, HD Delegated Administration, IdM password self serviceIn a heterogenous environment, evaulate all functionality, then act.

There’s no need to reinvent or reuse the wheel more than necessary.

Object Tax

Software companies spend a fortune persuading people that their software will make them more productive and then they cut the legs out from under their own claims by licensing fees that make no sense.  When you charge by the person, the object in the directory, and so forth you create a powerful incentive for a company to avoid using your product in a way in which they obtain maximum value.   You limit the productivity of your software and because of this the actual costs are much higher.  Marketing and sales executives at many firms don’t understand what it is they sell much less the impact of their pricing models.   When you’re driven by making your quarterly numbers, pricing structures like this seem wonderful.

To Synch or Not To Synch

Password synchronization has been a requirement since the early days. There is a lot of fuzz going on in the industry surrounding this ‘feature’, but let’s face it – It comes down to a simple question: How convenient do you want your Business Support Solution to be? Do you want it idiot proof or secure? There is this widely respected and agreed  statement that only a one-time token is safe enough to protect your holy data from unwanted access, but when it comes to passwords more than one of them is too much hassle to deal with. Sure, there is products out there that will give you the technology to synchronize everything back and fourth, but is this in accordance with CIA (Confidentiality, Integrity and Availability – not the agency)? I don’t think so. Let’s be honest to ourselves: It is always a balance between what the business wants IS/IT to deliver and what make sense from a infrastructure point of view. But fortunately there is SSO and our beloved child NW IdM 7 that will solve some of these problem.

Comments, anyone?