Skip to Content

According to Gartner, 20% to 50% of tickets opened with Helpdesk concern password problems. The estimated cost of treatment is 15 euros (META Group Resp. Gartner IT Key Metrics Data, summary report, 2011).


This blog co-authored with Benjamin GOURDON is based on several customers’ experiences which are looking for an alternative to single sign-on.


The purpose of this blog is to present an easy solution to implement designed to greatly reduce the number of calls to the support. This method, proven by many customers, provides a lower ROI than 3 months.

Password management challenges

You want to synchronize the password of all your users throughout your IT landscape with a simple solution which is able to provision SAP and non-SAP applications. SAP Netweaver Identity Management can easily help you for this.

Illustration of the password synchronization challenge

Of course it is possible to simply reset SAP passwords directly from SAP IDM web interface but this blog deals with password synchronization from user’s Windows session (Active Directory domain password) to SAP and non-SAP applications. This means that we have to be able to detect the change of password in your Active Directory and then provision it as a productive password to applications (user is not prompted to change it at the first connection).

So this blog suggests an easy solution to implement a complete password synchronization using SAP Netweaver Identity Management in 4 steps:

  1. Catch the change of password at Active Directory’s side
  2. Send this password to your Identity Center
  3. Handle the new password to write it in the IdStore
  4. Trigger the provisioning of the password to applications

 

Illustration of the 4 steps methodology

Step 1 & 2: Catching change of user password end sending it to your Identity Center

SAP Netweaver Identity Management provides a tool which allows to catch the change of password in Active Directory: Password Hook. It has to be installed on each domain controller to ensure a complete monitoring of password changing flows.

For installation prerequisites and procedure please have a look on SAP documentation here:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0bce8df-02e8-2d10-11a3-b61f8df4e4b1

Find below an example of Password Hook configuration (not enabled on this screen):

When Password Hook detects a password change it executes automatically a job configured and exported as .dse file from your Identity Center. For job definition you can do the following:

The new password is then sent to your SAP Netweaver Identity Management database in a temporary table. I recommend the following columns for the table:

  1. Automatic Incremental key
  2. User unique ID
  3. User encrypted password
  4. Date of modification
  5. Name of the controller which sent the password

To encrypt the password you should use the same keys.ini file of your Identity Center to encrypt the password before sending it to IDM (DES3 encryption).

The first column has a very important role in our workflow: it allows to know which password has been treated by the runtime by comparison with another internal counter at repository level.

The last column is an additional information about which domain controller sent the password. It can be useful if you want to know if a domain controller or if the Password Hook is down.

Step 3: Handle new password in Identity Center

To trigger the new password entered in the temporary table you should use an Event Agent which keep watching the automatic incremental key of the table as described below:

 

So when a new line appears the Event Agent executes a defined job composed by 4 passes to execute actions (including scripts):

  • Update MX_PERSON customized attribute like Z_ENCRYPTED_PASSWORD_FROM_AD

  • Write log into a log table

  • Delete the entry in the temporary table

  • Increment a counter on the repository (as variable) to ensure that temporary table’s key = repository variable

Maintaining a counter at repository level permits to ensure that there is no lag between entries treated in the temporary table and entries treated in Identity Store. In case of problems (Event Agent down) it permits to identify easily how many passwords are waiting for treatment.

Step 4: New password provisioning to applications

If SAP IDM is designed to provision Active Directory password, Password Hook will be started automatically every time password is modified. So the challenge is to synchronize to other applications only the good password which is from the user himself. Here is a simple and pragmatic method to address this issue.

Because it is not possible to make any check or workflow at Password Hook side, you have to make your checks in your Identity Center before writing definitively the new value of the password.

So triggers (Add and modify event tasks) on attribute Z_ENCRYPTED_PASSWORD_FROM_AD are needed to start a customized workflow assuming following values:

  • Attribute Z_ENCRYPTED_PASSWORD_FROM_AD, corresponding to the new encrypted password received from AD and Password Hook
  • Attribute MX_ENCRYPTED_PASSWORD, corresponding to the current encrypted password in IdStore
  • Global constant Z_DEFAULT_PASSWORD, corresponding to the default value defined for reset password by administrators (example of value : Welcome123)

Illustration of the workflow used to check password in IdStore



Remark: Instead of using a customized attribute in productive IdStore, the other option that could be used is to add a Staging Area IdStore to execute these checks.

The corresponding configuration in the Identity Center below (including queries for the two Conditional tasks):

 

You are now able to ensure coherence and synchronization of your user’s passwords.

  Think about your end users wellness gain and enjoy the time you will save in the future on workload of user’s support!


To report this post you need to login first.

14 Comments

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

  1. Per Krabsetsve

    Good stuff, well thought out, explained & illustrated!

    Have you considered using the uRunJobNow function to start the job in IdM in the “PasswordHook To IdM” job instead of an event agent? It could reduce the complexity of the implementation and help ROI further by removing a component/moving part, especially if the event agents are not used for anything else in the implementation. I know there’s some challenges such as how to get the jobid but they could be solved with a uSelect call & a little effort I believe.

    A To LDAP operation against a VDS service towards the Identity Store would also be an option for the “PasswordHook To IdM” job, while keeping the rest of the suggested workflows here intact.

    Best regards,

    Per Christian Krabsetsve

    (SAP Labs Norway)

    (0) 
    1. Benjamin GOURDON

      Thanks for your comment. Indeed yes, you are correct, a LDAP request through a VDS connection will replace as well an Event Agent. This does not reduce components but the solution is at least more integrated. I will try this way on my next project.

      (0) 
    2. Jeremy Baars Post author

      Hi,

      Thanks for the comment.

      I’m not a big fan of the uRunJobNow method because of the good jobID to find. But I agree with you it could be a good way to simplify the solution.

      Concernaning the VDS option, as Benjamin said it could be a good point to test but only if a VDS is needed in the target solution for other use (HCM scenario or something else).

      Best regards

      Jérémy

      (0) 
  2. Roorda Sietze

    Quite complicated though. I would prefer a solution where a system checks the user’s password against AD directly (for example via the LDAP interface); both ABAP and JAVA AS are able to do that. Perhaps this is also true for some other systems that must be connected. This leaves the password synchronization for those systems that are not able to check the user’s password directly against AD (or LDAP or whatever).

    One important thing is that AD (or LDAP) must be up to enable the password check. This requirement is not there if password synchronization is used.

    (0) 
    1. Benjamin GOURDON

      Thanks for your comment. This blog is very focused on password synchronisation. There are, indeed, so many different ways to process authentication. By the way, I really don’t know about a standard interface to check password against AD into ABAP system without third party system. Can you please provide us some details on it?

      (0) 
      1. Roorda Sietze

        One way to do that would be to configure the JAVA AS to authenticate against LDAP and then use login tickets (beware security risk!). Users first login to JAVA AS and are then sent to ABAP. This only requires configuration and no third-party software.

        It must be possible to configure the ABAP AS Server to use LDAP directly as well, but I can’t find a link at the moment :-(. That way, yo don’t need the JAVA AS server….

        (0) 
        1. Benjamin GOURDON

          Hi Roorda,

          You are right. Go through an authentication in JAVA (http) and then use SAP Logon Ticket to open authentificated connection with the SAP Gui will work. But this approach changes a lot the generic authentication process. Users get used to enter a password into SAP Logon directly. In this case, change is something to deal with.

          Regarding LDAP synchronization with ABAP, the standard is restrictive and will not let you synchronize fancy attributes such password, validity date and so on…

          To conclude, you point an important thing: There are various architectures and solutions to answer issues of authentication process. There is not only one good idea, but at least one proposal by context.

          Cheers,

          Ben

          (0) 
        2. Martin Stingl

          Hi Roorda,

          I’m very interested in a method to authenticate the ABAP AS directly against AD. It would be a great help if you could post a desription of that process. I’m searching for it for a while but haven’t found anything useful.

          Cheers,

          Martin

          (0) 
  3. Ian Daniel

    Hi Jeremy,

    I think this is a great technology solution, and I’ve been through a similar process, trying to sell this into customers previously, and despite the incredible ROI, it still seems a very hard sell.

    I’d be very interested to hear how this proposal is received, assuming you are taking it to market, and I’d also be interested to hear what experience anyone else has had with getting interest in Password Self-Service projects.

    Thanks,

    Ian

    (0) 
  4. Esther SIMHI

    Hi, thanks for this post.

    Does anyone hav a solution for “end to end password synchronisation” without AD?

    Actualy, the scenario without AD is the following: you can reset a password from IDM and send it to all connected systems, so that you have one password for all your landscape.

    Hence, when your UID expires, you receive a popup from SAP saying “new password”.

    –>then if you change it, you no longer have the same password in all sap environments.

    You could advise to go and reset the password from <hostname>:port/idm/pwdreset.

    Hence, in reality, I would not try to ask my 5000 SAP users “not to answer to the SAP popup”… but to “go to this url”…   –>More: let’s imagine they actualy go to  <hostname>:port/idm/pwdreset : they could receive a “Access denied” message because they are already logged in…

    Help, I am lost!

    (0) 
    1. Benjamin GOURDON

      Hi Esther

      You are right, there is no way to retrieve password from SAP backends and synchronize it over your landscape.

      You should desactivate the policy password regarding the password expiration in all your backends. Then design a workflow in SAP IdM to force your users to change their password at your expectation.

      Both anonymous and authenticated web forms can be used for this.

      Ben

      (0) 
      1. Esther SIMHI

        Hello Benjamin,

        Thanks for your answer !

        What kind of workflow from IDM could force users to change their passwords?

        Let’s imagine I block a user after 42 days from IDM , and I retrieve password policy from sap abap backend.

        Then what would happen after 42 days at SAP abap backend? no popup saying “new password” but an error message saying “user is locked”?

        I would really apreciate your help on this topic,

        Regards,

        Esther

        (0) 

Leave a Reply