Password Hook - Password flowing from AD to SAP ABAP

[Former Member]

Hello, I was wondering if anyone has used the Password Hook software provided that takes a password change from Active Directory and flows it to SAP Identity Center. We have followed the Password Hook document, buthave been unable to get it to function.

We keep running into an error in the Password Hook:

[ Wed Jul 22 15:02:34 2009 ] "D:\Program Files\SAP\IdM\Identity Center\DSERT.exe" "D:\Program Files\HookConfig\newpass.dse" "-DUSER=ZWC0055" "-DPASSWORD=Conagra01"
[ Wed Jul 22 15:02:34 2009 ] Wait timed out for the last process.
[ Wed Jul 22 15:02:34 2009 ] ===================================

It appears to be capturing the password change and trying to relay it, but cant seem to execute the IC job.

If anyone has this up and going, can you tell me the job and attribute string you used in the Password Hook Config and the jobs used in IC (the one in the document is setup).

I am not sure about what jobs should be setup in IC to flow it to ABAP either so that might be my next hurdle.

[former_member701257]

Dear Jeremy,

I was reading thorugh one of your blog where you have configured Password Hook - Password flowing from AD to SAP ABAP

I'm also currently doing the same exercise for a customer. Can I request you to please share some documents on this.

This would really help me to implement this solution in the customer system.

Thank you very much.

Regards,

Amlan

[Former Member]

With the solution I outline here, it does not assume the same password used throughout the company.

The "feature" you refer to will prompting the user to change their password at login is called the "Administrative Password".

The "Productive Password" is the usable password that only the user knows, not the one set by the administrator. This is the one that comes over from AD, or that is set by the user when prompted.

In order to set the Productive Password, you must know their previous password. Since it is unlikely that the system will, the solution is to set the Administrative Password to something the system knows, then it can immediately set the Productive Password...which it recieved from AD.

For this particular solution, it does not include account provisioning. To enable provisioning, there would need to be scripts/jobs to trigger off either AD as a Leading System of another system to prompt the account creation. The password dilema then goes into motion: either a script would be needed to see if there was already a password stored in SAP IdM for that user (ie and existing user, just getting SAP access for the first time) or if not (new user to the company) then a default password would be required, just like in AD. Once the user logs into AD, and i would assume be required to set their first time password, then it would flow to SAP and be consistant.

[Former Member]

Hi

As I recently asked in antoher thread I'm interested how you solve the fact that the users have to change their passwords on first login? Is that OK for you?

Do you have the goal in mind to use a single password throughout your company systems?

Or is your solution just designed for the case that a new employee enters the company and his account is initlially provisioned to different ABAP systems, based on his AD attributes?

Regards

Michael

[Former Member]

Yes, we finally got it working, with the help of an SAP consultant.

So, this seems to be largely undocumented....

The password hook program and instructions provided dump the username and password to a file.
IC will need a job to pick up that file and put the contents into the people repository, using the MX_Password field
The repository needs to be set to enable password syncing (main screen, second tab). This takes the MX_Password and encrypts it to MX_EncryptedPassowrd
Then, there needs to be a trigger job to see that change, and execute scripts that do the following:
Set the Administrative Password for the user to a constant (known to IC)
Once thatis done, set the Productive Password to what is in the IC people repository.

What this means to the SAP systems is that the password policies must be removed. Al password policies must be derived from AD, as it is the "Leading System" (SAP IdM term). While AD has different password policy options, I would consider it as secure for password policies as any other system, including SAP. Both have their flaws.

So that is how it works. We have completed our Proof of Concept with it and are moving into the build of Dev and Prod systems next week.

[Former Member]

Hi Jeremy,

What this means to the SAP systems is that the password policies must be removed. Al password policies must be derived from AD, as it is the "Leading System" (SAP IdM term). While AD has different password policy options, I would consider it as secure for password policies as any other system, including SAP. Both have their flaws.
So that is how it works. We have completed our Proof of Concept with it and are moving into the build of Dev and Prod systems next week.

doesn't this mean that you had to disable all password policies in the ABAP system? So if a user changes his password manually in the ABAP system, no password policies would apply? If this is the case, that would not be an option for my customer.

Best regards

Holger

[Former Member]

Yes, so we engaged SAP and got some help. It appears that some of the documentation is missing from the guide. The job in the guide writes the username and password to a file, but it stops there.

We had to build a standalone job that took that and wrote the data to a new DB table. After that, we built another job that read the temp table and put the data into the MX_Password or MX_ECNRYPTED_PASSWWORD attributes in the Identity Store repository.

We are stuck with what to do next to get it into SAP. We have tried setting triggers on the schema attribute, and the repository itself.

[Former Member]

Hi,

did anybody really successfully manage to provision the AD passwords to SAP ABAP systems?

As far as I know are the SAP password policies are stricter than the AD password policies.

The SAP password policy does e.g. not allow "!" to be the first character or that the first three characters of the password are all the same.

So if you provision the AD password into SAP ABAP systems, there should always be a percentage of password changes that will fail.

Has anybody found a solution how to get around this problem?

Best regards,

Holger

[Former Member]

Hi Jeremy

Do you already have a solution for your problem?

During the last days I managed to get the Hook to work and am currently facing the hurdle you speak of

I "simply" follwed the PW-Hook-Guide, although I changed the Runtime from Windows to Java. Now the Username & new Password is written to a CSV file as intended by the Notification & to a text file by the Filter

My configuration is as follows (copied from LogFile):

FilterProg  = 'E:\Program Files\SAP\IdM\PasswordHook\newpass.bat'
Arguments	 = '%1 %2'
NotifyProg  = 'E:\Program Files\SAP\IdM\Identity Center\DSERT.exe'
Arguments	 = '"E:\Program Files\SAP\IdM\PasswordHook\newpass.dse" "-DUSER=%1" "-DPASSWORD=%2" "-DRELID=%3"'

Did you check "Redirect program output to file" in the PW-Hook config (along with Log Level - All)? Maybe this'll help.

I don't use any environment vairables. Do you?

Did you check "Encrypt PW" in PW-Hook config? I did...

To Matthews event-task solution I found an interesting link [here|]

Hope I could help.

Regards

Michael

Edited by: Michael on Jul 30, 2009 12:42 PM

[Former Member]

That's because, to the best of my knowledge, the password hook task cannot execute an IC task or workflow as it is called by DSERT.EXE which is the standalone (DSE) runtime.

The typical use case is to fire a job that will execute one or more DSE passes that will change passwords as needed in connected systems.

If you wanted the hook to fire off a workflow, you best bet would be to have it make a change to a value monitored by an event agent (change an LDAP attribute for the user to be affected for example)

BR,

Matt