Managing External Sources with SAP IDM

“Logic is the beginning of wisdom; not the end.” – Spock, Star Trek VI

I’ve been getting a lot of questions about managing external sources with IDM from a best practices perspective.  While I am not employed by SAP, I thought I would take the opportunity to share a few thoughts on this from both a logical viewpoint, along with my observations of watching people work with SAP IDM all these years.

Strictly from a compliance and governance standpoint, I’ve always been a fan of having IDM manage as much as possible. Reducing the use of disparate tools to manage digital identities in the SAP Landscape and the greater Enterprise will make your Internal Audit and Information Security groups happy. When we can centralize on a common tool that is capable of recording identity life cycle actions, approvals, notifications, escalations, delegations, etc., we make another step towards greater security and safety in our organizations.

Furthermore, since we can now put this all into a single tool, the Identity Management / Information Security team can create customized tasks and workflows to enable greater availability for these services to technical and non-technical managers, and in limited use cases, the users themselves (Self Service Password Reset and changes to personal data come to mind)

Ok, so this makes IDM the great equalizer.  Woo-hoo! Does this mean that we can only make changes to managed systems through IDM? I don’t think so.

Managing the data in a system/repository from IDM is all well and good, but management of the system by its administrators should not be restricted. While I would say that it is a best practice to manipulate the data as much as possible via IDM, maintenance need not require IDM.

Administrators usually need to get deeper into the system and do more than IDM can support, so using IDM for everything in systems such as Active Directory or HCM might just not be possible. My advice to those that ask me would be as follows:

• Whenever possible, work should be done through an audit-able system that requires logging in
• All work sessions should be recorded in a log, along with a summary of work done, particularly when there is no login or access prompt
• Maintenance to Production systems should always follow an established change control process
• When doing maintenance, follow a “two-person” rule, where changes are verified by at least one other person, when data files, deletes, or modifications are being done on a large scale
• Finally — DOCUMENT EVERYTHING!!!!! I can’t emphasize this one enough. Make sure there are thorough notes detailing what is being changed, anticipated results, scope of change, details of change, documented code, and so on.  You just can’t have enough documentation.

Again, these are my thoughts on the issue.  I’d be interested in hearing yours.