Skip to Content
“Please, Spock, do me a favor … ‘n’ don’t say it’s `fascinating’…” — Dr. McCoy
“No… but it is… interesting…” — Spock (The Ultimate Computer)

 

One of the things that I really dislike hearing about the SAP IDM system, is that it’s not good for anything but working with SAP environments. The fact is that nothing could be further from the truth. IDM was not originally designed or developed by SAP. As people who have followed my blogging know, SAP IDM was originally the MaXware Identity Center which was designed as a platform agnostic, vendor neutral application. It truly is a piece of middleware that easily connects systems that can be accessed by protocols such as LDAP (Active Directory), ODBC/JDBC (Oracle, SQL Server, DB), ASCII Feeds, or any application that offers a JAVA API. (Many modern on premise and cloud applications) If an application can be accessed or initiated by the command line, that is also supported.

I wanted to write this blog about 4 weeks ago in response to a question on the IDM Community, but a number of issues, including my current project, got in the way. I was also lacking a good approach to the issue. But got to talking to some people recently who thought that that just because a solution is from SAP, that means it can only run for SAP, and since this blog is all about Active Directory, I thought it would be a good way to reinforce this.

The issue was that a community member wanted to know how to access particular items for various Active Directory (AD) objects in IDM. The following represents a piece of standard IDM functionality that not everyone knows so deeply but can be quite helpful when designing jobs or tasks that use a “To LDAP” pass type.

Most often this technique is used to get information about a “template user” so that the IDM engineer can see what attributes are populated (available) in AD for a “to type” operation by loading the populated attributes from the template object into the destination tab.

To get the most out of this exercise, it is useful to identify an entry in AD that will have the attributes that are needed already populated in the AD object to serve as a template.  I often go into AD using ADUC or a similar tool to make sure that attributes I am interested are populated. It is important to remember that this technique will only work for populated attributes for the test object that is selected. Now, let’s take a look.

To start with, a “To LDAP Directory” pass type is used, from either an action task in a workflow, or a pass in a job, and the destination tab is selected, select the Insert template command button, and then choose “Directory entry template. . .”

In the Directory Browser window, populate the values as needed.

Note that the various parts of the LDAP URL are populated here and do not work with any type of IDM constant. (I have purposefully not populated the pass connection settings to keep things separate.) Things here pretty much need to go manually. Although not shown directly in the screenshots, LDAP operators such as |, &, and ! will work when setting the filter.

Once your LDAP search parameters are set (and correct), this box will show up.

Choose an attribute that is defined for your template user (e.g., Armin Zola) you’ll see a list as shown below:

Choose one and the Directory Object Properties window will appear. Click on the Copy to LDIF syntax button and then close the window. Yes, I know it seems strange, but this is the correct process.

You’ll see all of the populated attributes appear in your destination tab.

You will probably want to disable a number of these values if you won’t be using them when writing / updating the AD entry. Note that some of these values will be encoded in different formats such as the  which is hex encoded, also some time related attributes will be encoded in different formats. Remember the more attributes that need to be populated per entry, the longer the overall operation will take.

What if there is a need to work with a different type of object, say a group. Just change the filter and go through the same process.

Which means that the find box will change.

Follow the same steps to have the template insert.

 

The final thing to consider is how to change the default directory parameters. To do this select Tools and then Directory from the MMC

Update the values as needed and then select “Save credentials/URL as default” Just remember any time you need to change this again, you’ll need to go back here.

Hopefully this will be helpful to when there is a need to work with Active Directory objects.

One last note. I realize that basically all of my posts to date have been centered on SAP IDM 7.2. There’s a good reason for this. All of my active projects to date have been 7.2 focused so that’s what I have needed to support and report on. Most likely in the next few months my focus will finally change to IDM 8.0. I haven’t decided what I will do with all of this 7.2 related content. It’s possible I will update it for 8.0 and release on a separate blog site, or in some other format or media. I’ll be speaking to people in the SAP community to see what makes the most sense.

 

 

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Jaya Kumar

    Hi Matt,

    This Blog very informative and useful. Thank you very much.

    I have one doubt. If we assign group from AD, which will later synced/assigned as privilege in IDM. Is it possible to delete that privilege directly by IDM.?, since we tried in test, idm unable to delete those privileges. Could you please provide suggestions/help here.

    Thank you very much.

    Regards,

    Jay

    (0) 
    1. Matt Pollicove Post author

      Hi Jay, there should be a direct link between the AD group and the related IDM privilege via the framework, but this is not something I’ve looked at recently.  It might help to post this as a separate question with some more detail and screenshots.

      Thanks,

      Matt

      (0) 

Leave a Reply