Identity Management just isn’t what it used to be

 

It feels like Identity Management, whether we are discussing managing employee or customer identities, that it’s not just about managing user names and passwords. Of course, this has been the case for several years. But those of us in the industry are realizing there is a new paradigm where suspicion is the new normal, and this means that everyone involved needs to find new ways to manage and operate in this new model.

The recent Scattered Spider and related attacks are hitting us where we are most vulnerable, the intersection of customers and support, using social engineering to get organizations to reset passwords, along with standbys such as adversary-in-the-middle tactics.[i] Microsoft has also done a great job of describing its tactics and overall strategy.

As a result, the efforts of the Scattered Spider group have done an excellent job of making anyone involved in IT Support and Security very concerned, and have left their customers feeling overwhelmed with doubt and insecurity. “Is this user who they say they are?” is a bigger concern than ever before.

There is one thing that has become abundantly clear for both organizations and customers: Suspicion must be the new normal. It’s a sad, but true reflection on the state of things right now. For customers, it means manual verification of information requests. Do not submit or provide data over the phone without independently verifying that they are communicating with the right people. Of course, this means separate phone calls or other interactions, which means in complicated scam scenarios that this might not be enough, and of course, it slows everything down. It’s really nothing less than a new form of digital terrorism.

For the large organizations, it means that ensuring both employee and customer security is even more critical than ever. Ensuring that employee and customer data is properly segmented and that proper entitlement governance policies are in place is more essential than ever. Additionally, new patterns should be considered for verifying incoming user requests. The most promising method is using stronger identity verification mechanisms, such as liveliness checks, and when the strongest measures are called for, submission of government documents such as ID Cards, Driver’s licenses, and passports. This, of course, can unfortunately increase authentication and authorization friction in areas where there had been motivation to reduce or eliminate it.

There is hope that the use of concepts in Self-sovereign identity will make this verification easier through the encapsulation of identity-related data via an identity wallet secured by technologies such as blockchain. However, this is still an evolving, niche technology.

While we wait for this technology to mature, it is crucial for organizations and individuals who digitally interact with them to exercise caution and remember that when it comes to protecting one’s digital identity, “Paranoid people live longer.[ii]”

---

[i] https://www.cybersecuritydive.com/news/scattered-spider-expands-tactics-recent-hacks/753220/

[ii] I’ve used this expression for over thirty years of my IT career. I can’t believe it has taken me this long to use it in a blog entry.

The Goldilocks Syndrome

 

“Then Goldenlocks sat down in the chair of the Great, Huge Bear, and that was too hard for her. And then she sat down in the chair of the Middle Bear, and that was too soft for her. And then she sat down in the chair of the Little, Small, Wee Bear, and that was neither too hard nor too soft, but just right. So she seated herself in it, and there she sat till the bottom of the chair came out, and down she came plump upon the ground.”[i]

I’ve been making this observation formally ever since I started in the software field at a company called Magic Solutions back in the late 90s and probably informally before then. You see, it’s been my experience that when organizations roll out new enterprise concepts, particularly in IT and more specifically in IT Security and Governance, it goes through at least three revisions. I’ve seen this happen in several models whenever there is some sort of organizational hierarchy. In my Help Desk days, it was about Ticket Subject Organization, in Identity it’s usually the organization of the Directory Service (Security Groups and Organization Unit structures) or role/entitlement hierarchies.

For the record, I’ve been involved in all of the scenarios listed below, and I’ve been confident I nailed it nearly every time. As I’ve become more experienced, I mention that these structures will most likely change over time and that the first time is seldom the charm.

The first one is usually pretty much what the organization thinks they need. This might be in consultation with experts either during the sales process or when working with the implementation specialists. This frequently suffers from a lack of flexibility, in that not all use cases have been properly considered and weighted. It’s good enough for now, and the project to review how things are configured is pushed to the next version of the application / architecture review.

The second time around, the organization is looking to be flexible, so that any potential scenario can be handled. Now we have the opposite problem, where different parts of the organization have too much control and the solution becomes too cumbersome and there is little to no organization. It’s complete anarchy, audit logs become so incomprehensive that they border on being meaningless, and nobody is happy.

At the third time through the process, I believe that we are starting to maybe see a proper solution that has structure, and is somewhat flexible to new scenarios. In terms of our introduction quote, it’s not too rigid, and it’s not too open, but just flexible enough.

Sometimes this is because the structure is more open, or because there’s a stronger change control process in place. Sometimes it is because the organization itself has changed, changing in size, complexity, governance needs, or just a plain old change in culture. Change will still occur, but with the lessons learned the process should be more manageable.

---

[i] https://en.wikisource.org/wiki/The_Story_of_the_Three_Bears_(Brooke) That’s how this version spelled it. Emphasis is mine.

Identity Management as Kitchens and driving on the New Jersey Turnpike

Those of you who have been following me for years are aware of my preference for Identity Management Programs over one-off Projects.  The fact is, one might consider that a proper program goes something like this:

1. Set up the Directory/IDP
2. Define Roles
3. Set up Access Management (SSO/MFA)
4. Set up LCM processes
5. Implement Fine-grained authorization
6. Implement Self-Sovereign Identity and digital wallets

Of course, this list and its order depend on the needs and culture of the organization being served. In the long term, it is virtually impossible to do just some of this. It’s like upgrading or updating your kitchen. Now the Dining Room looks off, which makes the Den look dated, and then the carpeting, and then, of course, the bedrooms. All because one part of the house was improved.

My thinking has always been that you can’t really grant access until you have some sort of Identity store in place, which is usually the Directory Service for the Workforce and an IDP when it comes to CIAM.

Furthermore, steps two and three are somewhat interchangeable, but if you need to organize your identities, it’s likely due to an Access Management requirement, so you may want to complete this task sooner rather than later.

LCM needs are required regardless of use case, but of course take different forms. For the Workforce, this is more about how an employee progresses through their corporate career. On the CIAM side, this might involve subscriptions, optional services, and the ability to unsubscribe and be forgotten.

Refining all these processes and connecting them to additional applications will likely require some form of fine-grained authorization to ensure that all users can access only what they are intended to.

Once all of this is in place and working, we can begin to think about utilizing this information for digital wallets and establishing the foundations of Self-Sovereign identity using wallets. This will ensure that, in any given Identity-based transaction, only the minimum required attributes are shared.    

As far as the Identity Program goes, it’s like driving on the New Jersey Turnpike; the construction and work never seem to end. As soon as we finish one round of repairs and upgrades, it’s probably time to start over again.

You've read my ramblings, now listen to them!

You've been reading my ramblings for years here and on SCN. Now you have a chance to listen to some of my thoughts on SAP IDM and a bit on SAP IDM 8 I was recently interviewed by long time colleague and fellow IDM Expert,Scott Eastin for his IDM Masters Interview Series. 

Please take a moment to listen to the interview and support Scott's efforts!

BTW, please let me know if this is interesting and if we should consider a regular podcast / YouTube discussion of SAP IDM, along with topics that you would like to see covered!

Thanks!

What comes after IDM?

People often ask me what comes after Identity Management? My answer is that it depends.

As I've discussed before, it's really up to what the organization requires and simply tacking on new workflows, approvals, and functionality is only really useful if it will actually be used.  However, I think we can make a few generalizations about what might occur as part of a far reaching and comprehensive IdM program.

Assuming that the initial project succeeded in its goal of creating an authoritative data store and basic provisioning, there's always the goal of adding more applications and additional attributes in existing applications that can be provisioned as part of workflow.

Password management is always popular.  If your application allows password provisioning or linking into a SSO or password management solution, this is a great place to add in further automation.  Your organization's help desk will appreciate it, I'm sure.

Adding in a compliance solution (sometimes referred to a certification or attestation) is always something organizations look into as a part of that overall IdM program. Some applications such as SailPoint IIQ have this built in, while others such as SAP GRC or Oracle Identity Governance are separate, but complementary modules to the Identity Management offering.

However what I think is one of the key places that the IdM program manager should be looking at is automation of IT processes. Every day the Help Desk and the System/Network administrators are using untrackable and un-auditable tools for editing user accounts. IT Management and Audit staff have no idea exactly what these people are doing as they are on the job.  At the very least, there is the possibility that users will be accidentally granted the wrong entitlements, and in the worst case, there could be the creation of undocumented SuperUsers. If we can direct these actions through the user provisioning application, then we can have an audit trail that tells us:

• Who was worked with
• What was done to them
• Who did the work
• When the work happened

It also becomes a lot easier to do these tasks when they are placed in the IdM solution.  This lets our Server Admin and Help Desk teams work on the more detailed analysis and troubleshooting that they were hired for rather than mundane user management, all while creating a more secure and audited environment.

Some thoughts on database locking in Oracle and Microsoft SQL Server

Deadlocks are the bane of those of us responsible for designing and maintaining any type of database system. I’ve written about these before on the dispatcher level. However this time around, I’d like to discuss them a little further “down” so to speak, at the database level. Also in talking to various people about this topic I've found that it’s potentially the most divisive question since “Tastes good vs. Less filling”

Database deadlocks are much like application ones, typically come when two processes are trying to access the same database row at the same time. Most often this is when the system is trying to read and write to the row at the same time. A nice explanation can be found here. What we essentially wind up with is the database equivalent of a traffic jam where no one can move. It’s interesting to note that both Oracle and Microsoft SQL server handle these locking scenarios differently. I’m not going to go into DB2 at the moment but will address it if there is sufficient demand.

When dealing with SQL Server, management of locks is handled through the use of the “Hint” called No Lock. According to MSDN:

Hints are options or strategies specified for enforcement by the SQL Server query processor on SELECT, INSERT, UPDATE, or DELETE statements. The hints override any execution plan the query optimizer might select for a query. (Source)

When NOLOCK is used this is the same as using READUNCOMMITTED which some of you might have be familiar with if you did the NetWeaver portion of the IDM install when setting up the data source. Using this option keeps the SQL Server database engine from issuing locks. The big issue here is that one runs the risk of having dirty (old) data in the database operations. Be careful when using NOLOCK for this reason. Even though the SAP Provisioning Framework makes extensive use of the NOLOCK functionality, they regression test the heck out of the configuration. Make sure you do, too misuse of NOLOCK can lead to bad things happening in the Identity Store database.

There is also a piece of SQL Server functionality referred to as Snapshot Isolation which appears to work as a NOLOCK writ large where database snapshots are held in the TEMPDB for processing (source) This functionality was recommended by a DBA I worked with on a project some time ago. The functionality was tested in DEV and then rolled to the customer’s PRODUCTION instance.

Oracle is a little different in the way that it approaches locking in that the system has more internal management of conflicts through use of rollback logs forcing data to be committed before writes can occur and thus deadlocks occur much less often (Source) This means that there is no similar NOLOCK functionality in the Oracle Database System.

One final thing to consider with database deadlocks is how the database is being accessed, regardless of the database being used.  It is considered a best practice in SAP IDM to use To Identity Store passes as opposed to uIS_SetValue whenever possible (Source)

At the end of the day, I don’t know that I can really tell you to employ these mechanisms or not. In general we do know that it’s better not to have deadlocks than to have them and to do what you can to achieve this goal. In general, if you are going to use these techniques, do make sure you are doing so in concert with your DBA team and after careful testing. I have seen Microsoft SQL Server’s Snapshot Isolation work well in a busy productive environment, but I will not recommend its universal adoption as I can’t tell you how well it will work in your environment. I will however recommend that you look into it with your DBA team if you are experiencing Deadlocks in SQL Server.

TechEd 2012 Wrapup

Quicker than I thought possible, another TechEd has come and gone. It's been a fantastic TechEd this year.

From the SAP Identity Management perspective we saw some exciting new things this year:

• NW IDM Service Pack 6 is scheduled to be released in the next couple of weeks with some nice new features.
• Longer term enhancements will see the end of the dreaded MMC console! I don't think we'll see this in the next couple of enhancements, but I think we'll see it by the end of 2013!
• Virtual Directory received a renewed focus with sessions not only on standard SAP use cases but also in dealing with Identity Services.
• SAP SSO got some nice attention as well.  I'd expect that next year we'll have some hands-on sessions as well.

One thing that I did notice this year was a near complete lack of attention to GRC.  This has me wondering many things.  I don't think that GRC is going away, as the compliance space is very hot right now with all the big companies (IBM, EMC, Oracle, CA, etc.) involved and some other small players (SailPoint, Aveksa) are growing at a rapid pace.

I've not been able to get any confirmation from anyone at SAP, but if I put my thinking cap on, I would say that we're looking at the beginning of a re-alignment of how GRC is being included in workflow. Stay tuned!

SAP TechEd 2012: Day 1

Day 1, all I can really say is Wow! I attended sessions on the latest addition to the SAP's Identity Management line up, some of it's oldest technology and the future of the NetWeaver IDM.  After today's session, my mind is completely blown away.

I started the day with two informative sessions on SAP's Single Sign-on Offering based on the technology asset acquisition from SECUDE about 18 months ago. SAP has clearly recognized that information security must begin at the login and proceed from there.  I'm looking forward to learning more about it over the next year or so.  It's a major technology on my radar and should be considered as a key strategic goal for all SAP implementations.

The next session was based on a favorite technology of mine, the Virtual Directory Server (VDS).  Virtual Directory technology has been the "next big thing" in Identity Management for many years now. It appears that SAP's use of Virtual Directory not only as an LDAP proxy, but also as a Web Services Proxy could very well make this the case, particularly in the SAP ecosystem. Miroslav Jokic, SAP's VDS expert, back to the MaXware days gave a great presentation. In an hour long session, Misa gave a thorough overview of VDS, explaining it's architecture, basic use cases and extended use cases when working with Web Services. Clearly this is a technology whose time has come.

The third session of the day dealt with best practices for implementing SAP IDM. While focused on consultants, Kåre Indrøy, presented a good 10 point plan that is applicable to any IDM implementation. In the second half of the presentation, we received an excellent briefing on the new SAP Rapid Deployment Framework for IDM developed by SAP Consulting. While somewhat limited in scope, it certainly does appear to be something that can be quickly implemented for most small to mid-sized clients if all of the pre-requisites are met.

All of these new features will be available in NetWeaver IDM SP 6 which should be available in 2-3 weeks.  Most are also available in SP 5, but not through the Web UI.

Now we come to the Crown Jewel of the day, which was a 2 hour presentation by Kåre and John Erik Setsaas showing the latest functionality to be released shortly in Service Pack 6 for NetWeaver IDM 7.2 and what we can expect to see in the next 6-9 months. Approvals are being enhanced again, making them more functional than ever, particularly where declines and assignments are involved.  Automatic Delegation is now available to designate temporary approvers when the primary approver will not be available.  

NOTE: Everything that follows is conceptual and is not guaranteed to be in any future version of NetWeaver Identity Management.

Trace functionality is also improved with additional control from the Web UI, which will be a boon to IDM developers. Also added to the Web UI is a new SQL Execution reporting interface that will report on database queries that last longer than a predefined limit.  This is a significant enhancement of the Configuration Analyzer's ability to detect inefficient queries and will be something that IDM Administrators will be very interested in.

The last part of the presentation was the really exciting part.  Kåre and John showed us some of the functions that we could be seeing beyond Service Pack 6. Access to the Administration Console looks like it will be getting some tightening along with some locking of objects being worked on in the Admin console. It's been a long standing issue that only one user should be accessing an IDM object in the MMC console at a time (Personally, I'm not found of two people looking at the same configuration at the same time) When the user is done editing and checks the object back in, it becomes available for editing by another IDM administrative user, Additional UME based security is being considered to restrict access to the IDM administrative objects as well.

Also it has been confirmed that DB2 will be supported by IDM in the near future.  The DB2 version will only work if the DB2 Database has been prepared to run in "Oracle Mode"  I'm sure we will be getting more information soon.

The Pièce de résistance of the afternoon was a brief overview of an early alpha version of a new Development UI. I'm not going into a lot of detail here since it was such an early release, but suffice it to say that a 21st century, eclipse based interface is on the horizon, and for those like me who have been working with this interface for the last 8+ years it appears that this will be the answer to our prayers.

I did not cover everything mentioned in these presentations for a couple of reasons.  One, I'd be writing for hours and I need to get some sleep tonight so I can be ready for tomorrow's sessions.  Two, this is SAP TechEd and you should be here.  If you're wondering is it worth it, I say YES! Hopefully this information will make you feel the same way!

Watching $'s in JavaScript

Every time I write a script that uses repository constants, I always have trouble remembering how to pass their values properly.  Hopefully this posting will make me remember.

Both the "%" and "$" characters are used by JavaScript, so if the following code is encountered you will get an error:

var LDAP_SEARCHURL = "ldap://" + %$rep.LDAP_HOST% + ":" + %$rep.LDAP_PORT% + "/" + %$rep.LDAP_STARTING_POINT% + LDAP_SEARCH;

The dollar sign is used for calling a type of function and I believe the percent symbol is used for a mathematical operation. The solution is simple, just place the constants in quotes:

var LDAP_SEARCHURL = "ldap://" + "%$rep.LDAP_HOST%" + ":" + "%$rep.LDAP_PORT%" + "/" + "%$rep.LDAP_STARTING_POINT%" + LDAP_SEARCH;

It seems that IDM is smart enough to evaluate the value in the quotes and realize that the value is a repository constant and evaluate the value properly.

Common Identity

I do a lot of research to keep up with the goings on in the Identity Management world. A lot of it is based on the goings on with SAP NetWeaver Identity Management, monitoring SDN, and the new documents that can be found on the main NW IDM page.

However there is a lot that goes on in the overall study of Identity Management.  I found Dave Kearns article from Network world to be very interesting and informative, and was sad to see it end.  Unfortunately many of the best sources for overall IdM information come from the various consulting groups, which require subscriptions.

There are, however several good blogs that one can find out there.  In particular I like to follow Matt Flynn, Jackson Shaw, Dave Kearns new blog, and Nat Sakamura.

There is also of course, the Planet Identity blog, which I think is one of the best overall sites that monitors IdM related information.

However, one source that always seems to teach me something new all the time is the Identity Commons website and mailing list. These folks don't just talk about user provisioning or access control or authentication or single sign-on or anything so simple. These  folks talk about how all of these things come together. Not just Identity Management, but the Management of Identity, on line, off line, between the lines and every other which way. I don't often participate in the discussions, but I always learn something from them and they have changed the way I approach the discipline of Identity Management.

For instance, a recent discussion about the use of various types of encryption and security turned into a whole discussion about the nature of Identity and what is required to track how Identities prove themselves between Relying Parties and that before we can worry about security we need to consider the overall model that Identities use to relate to each other and transact with various organizations (Relying Parties)

One of the posts pointed to a paper that starts to describe the terminology of how this all works. It's some fascinating reading that I think will again change the way I view identities as they relate to the various simple tasks of user provisioning, access control and authentication.

BTW, you might have noticed that the blog has gone through some formatting changes to take advantage of some of Blogger's latest advances.  Due to this I lost some of the gadgets and the blogroll.  I'll be getting them back up again as soon as I can.

Dispatcher Errors

Recently when working on a new QA system based on a copy of the PROD database when I encountered an error that I had never seen before when starting up the first dispatcher. I highlighted it below:

Running MxDispatcher_d1.
[21.09.2011 18:37:19-539] - Initialized log for com.sap.idm.ic.services.api.MXMCApi. Log level is Debug
MxDispatcher version: 7.10.5.2 Built: 07.06.2011 16:20:24 (c) Copyright 2008 SAP AG. All rights reserved.
Java VM: Sun Microsystems Inc.   Version: 1.5.0_22
Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
Java lib/ext: C:\Program Files (x86)\Java\jdk1.5.0_22\jre\lib\ext
CLASSPATH: d:\sap\idm\Java\mxdispatcher.jar;d:\sap\idm\Java\mxmcapi.jar;D:\jdbc2.0\sqljdbc_2.0\enu\sqljdbc.jar;
[21.09.2011 18:37:19-557] - MxDispatcher:Reading prop files
[21.09.2011 18:37:19-557] - MxDispatcher:Loading driver: com.microsoft.sqlserver.jdbc.SQLServerDriver
[21.09.2011 18:37:19-639] - MxDispatcher:Creating connection to : jdbc:sqlserver://NWIDMSBX:1433;databasename=mxmc_db;user=mxmc_rt;password=********
[21.09.2011 18:37:21-369] - MxDispatcher:Reading main MxDispatcher configuration ...
[21.09.2011 18:37:21-593] - MxDispatcher:Dispatcher configuration d1 not found
[21.09.2011 18:37:21-594] - MxDispatcher:Error reading main MxDispatcher configuration ...
[21.09.2011 18:37:21-594] - The first config load failed:Dispatcher configuration d1 not found

I went through all of the normal dispatcher configuration checks, JAVA configuration, drivers, and database configuration. Everything looked OK, My ODBC checks were ok, and I knew that I was contacting the database server and that the ports were open. One suspicious thing was the extremely long length of the dispatcher name, however was not the the cause.

What we actually found was that the server names were not correct after all. The ODBC connection was pointed to the correct server, but the Java runtime connection was to the wrong server. Nothing like the confusion in moving configurations from one environment to another!  After ensuring once again, that I had the correct configuration, I regenerated the dispatcher scripts and all was fine.

So the cause of this error is when there is a connection string mismatch if you should see this in the future.

More from the JAR

An ugly issue came up not too long ago on my project.  We were seeing the error messages referencing an mxmc_admin based connection string as mentioned in Too Much in the JAR

So, I said to myself, I know how to deal with this, and proceeded to show off my knowledge by going to the MMC Console, selecting Tools/Option and selected the JAVA tab and found… nothing wrong. Only one extension present, JDBC driver JAR was right.  Felt the virtual pie in the face.

So we started looking.  I did insist that the root of the issue was a JAVA conflict and no one on the team had any real reason to doubt me.

Eventually we found the issue, and it was indeed related to JAVA.  It seemed that there were multiple JDBC drivers installed and like the JARs, this can be a bad thing.

There were two SQL Server drivers specified. It turns out one was for SQL Server 2000 and one for SQL Server 2005.  For reference here are the drivers:

2005: com.microsoft.sqlserver.jdbc.SQLServerDriver
2000: com.microsoft.jdbc.sqlserver.SQLServerDriver

Hope this helps you next time you get a conflict!

The Tao of IDM

The best soldier does not attack. The superior fighter succeeds without violence. The greatest conqueror wins without struggle. The most successful manager leads without dictating. This is intelligent non aggressiveness. This is called the mastery of men. 

So why would I lead an Identity Management blog entry with a quote from the Tao Te Ching? Basically it sums up a recent issue I had in my current project.


As a part of this project, I am helping to get a young engineer familiar with IDM.  Working together we needed to create a query that would return only specific types of users for an IDM export Job.  I explained the basic process for executing the export and watched him work on various queries to return the correct users, while advising him about database structures and useful techniques. As an elaborate query began to take shape it was starting to look way too complicated.  I started thinking that there had to be a better way to accomplish our task.


Then I remembered that since we were doing a "To Database" task we could specify the Identity Store as the source and used the built in editor to build the correct query.  It took seconds to build and we quickly checked the query by doing a copy/paste to Microsoft SQL Server.  It worked perfectly and we were up and running.


Here's an example of the query that we created:

So what's the takeaway on this?  Look to see what the system can do rather than build something from the outside. At the very least, use the tools to build the query and then customize it (just remember that using an external query editor on the edited query make using the built in tool not work). 


And here's how easy it was to generate the query:

There's no need to reinvent the wheel

IDM MMC Navigation Tip

Ok, I won't make this all about the problems with the MMC Console.  We all know what they are. However, one thing that's always ticked me off is navigating through a long list of attributes or scripts.  If that list gets to be too long, it turns into a scrolling list. Of course good naming conventions help, but we'll talk about that another time.

Quite by accident, I discovered that you can click on the list of attributes then scroll through with the arrow keys, and more importantly, if you go to the very top, you are automatically brought to the other end of the list so you can keep on scrolling.

Hopefully this will save you some time, effort and aggravation!

If you didn't write it down, it didn't happen!

We've all been there. It's crunch time. Where did the time go? Weeks of requirement gathering, architecture, development, unit test, integration test, and now go-live with a whole bunch of dependencies and C-level attention is right on top of us.  There's only time to address the last minute issues.

Throughout the project, the PM has been screaming for documentation.  Where's the completed architecture  Where's the test plan that you said you worked against? How about a run-book? And on, and on and on...

Too many architects, leads and engineers regard documentation as a necessary evil at best. Until it comes time that YOU are the one inheriting the project and YOU have to try and understand what some guy did in the past.  If you're really lucky, you know the guy or he's still with the client, or maybe even your practice if you're a consultant.

We all seem to forget that documentation is just as important as any piece of code, fancy database query or complex workflow.  It's the basis for the whole project.  It needs to be focused on just as much as any piece of development or testing.

The fact is, if you have a good design, any engineer can build the solution.  If you have a good test plan, the QA meeting flies right by and the change control board meeting becomes a coffee break rather than a Homeric battle to prove that your solution is up to snuff.

It also benefits you as an architect/engineer/consultant.  If it's written down, it's easy to reference for future work.  Remember, when you're sitting in the corner office as the CIO and someone comes up to ask you "back when you were the IDM lead, how did we do ... ?"  Well if it's written down, you'll know!


What ticks me off even more, is that it's SO easy to create even basic documentation in NetWeaver IDM. Fill in the documentation tab for tasks and folders with a few notes, references and examples. Put some comments in your scripts and then run the system report.  The most you might have to do is install the MMC console on your desktop so that you have access to Office. Then just run a bare bones system report.  Voila!

Just in case you haven't figured it out, I have inherited Phase II of a project with sparse technical documentation and everyone involved in this Phase is paying for it. In reality this is seldom any one person's fault.  There's limited time and multiple pressures as I mentioned in the opening of this essay, however that needs to stop being the excuse.

Based on the lack of documentation created in the past, there's increased attention on design and architecture documents, so at least the lesson has been learned in this situation.

It sure would have been easier to write if there was even some documentation.  Now I'm living in a world where nothing was written down, so I don't know what happened!

Troubleshooting "To passes"

Now on to a different troubleshooting tip.

Sometimes when executing a "To Pass" you'll have an error in writing to that destination be it a database or a directory service.  When writing to a database, you might encounter an error saying something like "the table cannot be created" or the dreaded LDAP 49, "Unwilling to perform"

Basically, what's going on here is that there's a problem writing to the database or the directory service, so you should check a couple of basic things:

1. Is the data format in the destination actually supported? In regards to a database, just because the destination grid says tinyint, this does not mean your Oracle database back end supports it (or smallint on the Microsoft SQL side for that matter)  Always double check this first.

2. Try disabling all of the destination attributes except for the first one and run the task again.  If it works, enable the second destination attribute and keep on with it, leaving attributes that work enabled and ones that don't work disabled. Don't forget that the first line in the destination grid refers to an key, so if this isn't working, make sure that the value must be unique and properly formatted for your destination in terms of type and format.

You can then look back at the disabled attributes and see what works and what does not.  More likely than not there's a formatting issue going on or something in an attached script. When working with Directory Services in a "To LDAP" pass, I've also found it helpful to change the output type to LDIF as shown below.

After this is done the results of the pass will be sent to a text file, which is sometimes easier to review, just don't forget to change it back when you're done!

Good luck and  feel free to post your own favorite troubleshooting tips as comments!!

Too much in the JAR

Recently had a problem where Import/Export was not working.  I kept getting an interesting Error Message:

What was really interesting about this was the user that was referenced, mxmc_admin.  Now this is interesting, because during the Identity Store creation process, you are prompted to use mxmc_rt as the user and there is no time during the install that you are asked to create a JAVA based connection string using mxmc_admin.

This started a great deal of troubleshooting and conversations with people who have a great deal of knowledge with IDM's moving parts. Ultimately we wound up looking at the options in IDM's MMC interface.

The problem was in the Classpath Extension. It seems in this installation we had the old Microsoft SQL 2000 JARs loading before the SQL 2005 JAR. Since the MS SQL 2000 drivers were no longer needed, I removed them, regenerated my dispatcher scripts and restarted the dispatcher services. I was now able to export without a problem. I'm saying it's the order that the JARs are ordered in since I looked at my personal sandbox system and saw that I had the following Classpath: 

And my Import/Export works just fine, thank you very much.

Some more good troubleshooting to come...

Strategic IDM

Interesting post on SAP's IDM Blog.  Basically. the author is stating that if you want to plan your SAP implementation in a strategic manner, you must use IDM and not CUA (Central User Administration). This is a nice follow up to SCI104 from TechEd, which I reported about as well.

Nice to see that SAP is starting to get a little more aggressive here.  If you are a SAP Shop and rely on CUA, it might be time to start thinking about how you plan to deploy.  Additionally, if you're a SAP Shop on SUN IDM, and not too keen on a switch to Oracle, SAP IDM might be the something to look into!

As always, leave a comment or email me if you have questions about what needs to happen in these implementations!

Learning from your mistakes

I love making mistakes.  It's probably the best teacher in this world of Identity Management. In honor of that (and before the technical content, some thoughts on making mistakes:

Never say, "oops."  Always say, "Ah, interesting."  ~Author Unknown

It's always helpful to learn from your mistakes because then your mistakes seem worthwhile. ~Garry Marshall, 'Wake Me When It's Funny'

Lost some time on my current project while NetWeaver needed to be reinstalled, no big deal since I could prototype a few things on my local environment and try and prepare for some of the challenges we knew would be coming up. Nevertheless, as soon as the server was ready, I was eager to get going.


Reconfiguring NetWeaver went through without a snag.  We even were able to observe a few things that were done differently the rebuild and documented some best practices. When things are going this well, I should know better and start concentrating on what I'm missing. There's just too many things going on for things to be going this smoothly.


We configured the JDBC Driver and then the JDBC Datasource (IDM_DataSource) which went through without a problem (and part what caused us grief before)  My "Spidey Sense" should have been going off like crazy now.


We then went in and configured the Roles and a test user.  Then we setup that same user in the Identity Store via the MMC console. Now it was time for the big test, loading the Web UI, which came up with no errors (We were also getting Access denied, service down messages from the Web UI last time around). We logged in, which was further than we got before, but we still had a problem.

We only saw the Monitoring tab.  I checked the assigned roles for the user and removed idm.monitoring.admin (my read/write role for monitoring), logged back in and still only saw monitoring.  How strange.

Did some thinking, did some Googling, read some slightly related SDN posts with no clear relation or answers and did some more thinking.

As I pondered the install process and the login process, it hit me! Turns out we were so excited that we skipped an essential step!  We never configured the JMX layer and set the Identity Store value or the Keys.ini location. (Good thing I only tried to log in and not change any passwords!)

Loaded NetWeaver Visual Administrator, navigated to the Configuration Adapter node and found the tc~idm~jmx~app node and flipped on edit mode, made the two changes and I don't even think I needed to log in again, all my tasks came up on a Web refresh.

I made a dumb mistake and got ahead of myself.  Fortunately we got it all working without too much time lost.

So what did I get from this:

1. Always follow the documentation.  It's the best way to make sure you don't forget anything.
2. If you're having a problem, use tools like Google and SDN.  Even a "slightly related" posting can help you brainstorm.
3. Get another set of eyes to look things over. People from the BASIS team can be your best friends here.  Even if they've never heard of IDM, they probably know more NetWeaver than you.
4. When all else fails, go back to #1 and RTFM, most likely you misread something!

One of the interesting things about mistakes is that a lot of people (including famous ones) make them all the time. So in honor of that, here's some more quotes:

Do not fear mistakes. You will know failure. Continue to reach out. ~Benjamin Franklin 

I've learned that mistakes can often be as good a teacher as success.  ~Jack Welch 

Setting Passwords in Microsoft Active Directory

The project that I am currently working on is starting in a different way than any other Identity Center (or Identity Management!) project that I have ever worked on. Rather than starting with AD/LDAP provisioning, role management or synchronization, they are starting with password management.
Usually I’m not a fan of this but there were a few reasons that this worked. First off, their authoritative source is SAP HCM, which is a relatively new implementation, so we know that the identity data is good and clean (They actually did a cleansing project when moving the data from their old legacy system). Also password management is a key need for the organization that will go far in proving the value and effectiveness of SAP NetWeaver Identity Management.

I have to admit that I went into this project with a lot of confidence. I’ve been successful in password management Proofs of Concept and done some work with the Password Hook that is a part of the SAP IDM offering. However as I’ve seen many a time there’s a world of difference between a PoC and a productive system.

What could the difference possibly be, you wonder? Well a lot of PoC systems have IdM and AD on the same host. Not so in production. This brought up a number of differences and changes that I needed to make the basic change AD password task that comes with NW IDM.
One of the things I’ve noticed in several Password Management projects with NW IDM is that even though the JAVA engine is preferred for most operations, that never works where Microsoft Active Directory is concerned.  In this case, the Windows engine is still superior.
Here is the code I developed

' Main function: pwdnext

Function pwdnext(Par)
HOST = ugetconstant("rep.LDAP_HOST")
LOGIN = ugetconstant("rep.LDAP_LOGIN")
PORT = ugetconstant("rep.LDAP_PORT")
strPassword = ugetconstant("rep.LDAP_PASSWORD")

RD= par("RD")
PWD = par("PWD")
strPath="LDAP://" & HOST &  "/" & RD

strUsername = LOGIN
Set adsNamespaceLDAP = GetObject("LDAP:")
Set adsMyObject = adsNamespaceLDAP.OpenDSObject (strPath,strUsername,strPassword,200)

strPath="LDAP://" & HOST &  "/" & RD
'Find user
Set adsUser = GetObject(StrPath)
'Set initial password
adsUser.SetPassword PWD
adsUser.SetInfo
'Set flag to NOT force user to change the password on first login
adsUser.Put "pwdLastSet", -1
adsUser.SetInfo

End Function



Since I didn’t mention it before, this script works with a TO GENERIC pass type.  Always the best when you need to bring in lots of information from the target screen.  This code is also pretty much the “bare essentials” and lacks support for handling encrypted passwords, validation logic, etc. The big changes I needed to make to the script from the original were the inclusion of the adsMyObject which allowed for a bind to Active Directory.  This code also exists in the pwdopen script, but it seems that the bind does not carry over.

The other very important thing that needs to happen is that the dispatcher service setup must also be properly configured. It is essential that the service be running with credentials that can make Active Directory changes. The following screenshot provides an example.

Dispatcher Service Log On Configuration

One of the key benefits of this approach is that there is no need for SSL to be setup between the IDM server and the Domain Controller.  A working SSL configuration is still required, however, when setting passwords in SAP's UME.

I hope this post has helped you out with understanding how password management can be achieved in SAP NetWeaver Identity Management 7.1, SP5. This example should work for any NW IDM 7.x implementation.