"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
- Antoine de Saint-Exupry
If there's one thing IDM comes with out of the box, it's attributes. There's a lot of them. However, there's not always an attribute for everything that we need when implementing our solutions. Fortunately IDM makes it pretty darn easy to add them when needed to support additional systems either as sources or destinations of Identity related data. For this example, I'm going to specifically address a question that recently was posted on the IDM forum, that of adding the employeeID attribute from AD to IDM. For the purposes of this blog, I'll assume that you already know how to add an attribute to IDM.
First off, it's helpful to make sure that we know how and where the value is stored. Looking in AD, we see the employeeID attribute. Even though we see it's a number here, I've always treated this value as a String for formatting reasons. Good to know our test user has it populated already. 😃
So let's set up the job that will do the work. It's broken up into two steps. One to read the information from AD to a temporary database table, and then one to write the information to the Identity Store. Yes, I know this could be done in one pass, but I've found that often there is a need to update this job to account for other AD attributes and possibly to make some transformations on them as well. I find it easier to break them up do do this, and it also helps for troubleshooting reasons.
Best practice is to designate a repository for the job, which I have done here as "DS" my Directory Server test system. The nice thing about using a repository here is a lot of things get filled out for you, but there are a couple that need to be set manually.
First off we probably don't want to be overloaded with information so I've specified only a few attributes to return from AD, which I've circled in red below. The most important of those are sAMAccountName and employeeID (we will talk more about why these two are important in a bit). Note that these are not case sensitive, but it is important to not embed any spaces after the commas. IDM regards everything between the commas as the literal attribute name, so extra spaced will throw things off.
The next thing we need to tell IDM is how to look. To make everything work, the search type should be changed to SUB so that we look in all objects below the one specified in our Starting Point. (If there are questions about this, please ask in comments, if I go into every detail, this blog entry will be not just a book, but an encyclopedia) When we set the searchtype, we can also set a filter, which makes things easier, since we will now only see "users" and not other types of AD objects.
Once this is done, head over to the Destination tab and use the Insert Template / Data Source Template as shown below. IDM will automatically populate the attributes based on the Source Configuration. Interesting thing about IDM to note here, IDM populates these attributes based on sampling of entries specified in the source (based on page size spec in LDAP, and a flat figure of 2000 from a database as I recall, though this has most likely changed) and if the specified attributes are not populated in the source based on the search criteria, the attributes will not show up in the destination tab, and will have to be added manually.
If you want, you could run the job at this point and take a look at the results in your SQL Query tool. For our purposes, we will do this at the end. Regardless, you will need to know the basic query, which you can see in the screenshot below of our next pass, which is of a To Identity Store type.
After the query is specified, we once again use the Insert Template button to read the source (this time from a database table). Depending on what attributes were specified in the first pass, you might need to play with the destination a bit. Your Destination should like like the next screenshot.
Something to consider here. Remember how earlier in the blog we said there were two important attributes, sAMAccountName and employeeID? Obviously employeeID is important because obtaining this infomration is what the blog is all about. But why is sAMAccountName important? In my test environment, the IDM MSKEYVALUE and the AD sAMAccountName have the same value to provide a basis for linking between the two systems. It's possible your environment might use a different value such as cn, dn, or something else. If the reason you are populating IDM is to link via employeeID only, this might be an issue. Leave a comment with your details and we'll see what we can come up with.
After the mapping is all done and the destination is configured, go ahead and run the job. Hopefully it comes up with no errors! If it runs correctly, take a look in the database to see if employeeID is populated correctly. My test system uses MSSQL so I've run the query here. Things look good, we have a good employeeID set for Johnny Scooter!
I also configured my IDM UI to show employeeID, so I was able to see it here as well!
Hopefully this blog helps you understand how to link and load attributes from other systems into IDM. Please post your questions and comments!
- Antoine de Saint-Exupry
If there's one thing IDM comes with out of the box, it's attributes. There's a lot of them. However, there's not always an attribute for everything that we need when implementing our solutions. Fortunately IDM makes it pretty darn easy to add them when needed to support additional systems either as sources or destinations of Identity related data. For this example, I'm going to specifically address a question that recently was posted on the IDM forum, that of adding the employeeID attribute from AD to IDM. For the purposes of this blog, I'll assume that you already know how to add an attribute to IDM.
First off, it's helpful to make sure that we know how and where the value is stored. Looking in AD, we see the employeeID attribute. Even though we see it's a number here, I've always treated this value as a String for formatting reasons. Good to know our test user has it populated already. 😃
So let's set up the job that will do the work. It's broken up into two steps. One to read the information from AD to a temporary database table, and then one to write the information to the Identity Store. Yes, I know this could be done in one pass, but I've found that often there is a need to update this job to account for other AD attributes and possibly to make some transformations on them as well. I find it easier to break them up do do this, and it also helps for troubleshooting reasons.
Best practice is to designate a repository for the job, which I have done here as "DS" my Directory Server test system. The nice thing about using a repository here is a lot of things get filled out for you, but there are a couple that need to be set manually.
First off we probably don't want to be overloaded with information so I've specified only a few attributes to return from AD, which I've circled in red below. The most important of those are sAMAccountName and employeeID (we will talk more about why these two are important in a bit). Note that these are not case sensitive, but it is important to not embed any spaces after the commas. IDM regards everything between the commas as the literal attribute name, so extra spaced will throw things off.
The next thing we need to tell IDM is how to look. To make everything work, the search type should be changed to SUB so that we look in all objects below the one specified in our Starting Point. (If there are questions about this, please ask in comments, if I go into every detail, this blog entry will be not just a book, but an encyclopedia) When we set the searchtype, we can also set a filter, which makes things easier, since we will now only see "users" and not other types of AD objects.
Once this is done, head over to the Destination tab and use the Insert Template / Data Source Template as shown below. IDM will automatically populate the attributes based on the Source Configuration. Interesting thing about IDM to note here, IDM populates these attributes based on sampling of entries specified in the source (based on page size spec in LDAP, and a flat figure of 2000 from a database as I recall, though this has most likely changed) and if the specified attributes are not populated in the source based on the search criteria, the attributes will not show up in the destination tab, and will have to be added manually.
If you want, you could run the job at this point and take a look at the results in your SQL Query tool. For our purposes, we will do this at the end. Regardless, you will need to know the basic query, which you can see in the screenshot below of our next pass, which is of a To Identity Store type.
After the query is specified, we once again use the Insert Template button to read the source (this time from a database table). Depending on what attributes were specified in the first pass, you might need to play with the destination a bit. Your Destination should like like the next screenshot.
Something to consider here. Remember how earlier in the blog we said there were two important attributes, sAMAccountName and employeeID? Obviously employeeID is important because obtaining this infomration is what the blog is all about. But why is sAMAccountName important? In my test environment, the IDM MSKEYVALUE and the AD sAMAccountName have the same value to provide a basis for linking between the two systems. It's possible your environment might use a different value such as cn, dn, or something else. If the reason you are populating IDM is to link via employeeID only, this might be an issue. Leave a comment with your details and we'll see what we can come up with.
After the mapping is all done and the destination is configured, go ahead and run the job. Hopefully it comes up with no errors! If it runs correctly, take a look in the database to see if employeeID is populated correctly. My test system uses MSSQL so I've run the query here. Things look good, we have a good employeeID set for Johnny Scooter!
I also configured my IDM UI to show employeeID, so I was able to see it here as well!
Hopefully this blog helps you understand how to link and load attributes from other systems into IDM. Please post your questions and comments!
- SAP Managed Tags:
