No SNC for writing passwords back to NW AS ABAP

[rondv]

Hi,

I'm on NW IDM 7.2 sp9 absolute latest patch levels. windows 2012 /ms sql 2012. I have latest SAP Provisioning Framework Version 2 loaded.

In all the documentation I read on the topic of writing back permanent passwords to a NW AS ABAP when a user is newly created in the IDM admin UI it says I need to configure SNC.

For me that is not a straight forward proposition as it appears complex and ambiguous in the docs i find (and I need to be aware that my situation is half-way through an SSO implementation so there is that with the snc/...insecure settings for the NW AS ABAP, but i digress), and I've never done it and have no Security consultant help. But, I'm a long time ago Basis certified person so I know where to look and try some things:-).

So, I tried being lazy and provision a user without the SNC configured between the NW IDM AS JAVA and the NW AS ABAP i am testing with.

Of course the password appears not arrive in the NW AS ABAP, as the doc warns me it won't w/o SNC.

In general my setup (NW IDM on NW AS JAVA <-> NW AS ABAP) works fine, I can get users from the ABAP system, and add and remove them from there by driving this from the IDM by using the privileges and the SAP Provisioning Framework setup.

Here are my questions about this if any of you are game to explain:

1. How does the NW IDM AS JAVA know the link is not encrypted with SNC, or does it not?
2. How does NW IDM decide not to send a permanent password? (yes, I've done the mods to make that work in IDM and NW AS ABAP authorizations as blogged about in other posts)
3. Does that even matter? Is the SNC just a precaution to encrypt the traffic for productive setups, but I could do my testing without it in my lab systems?
4. When I fill in the password (twice of course) in the NW IDM Admin UI, and the checkbox in the UI is not ticked for password disabled, does this mean the user record in IDM indeed is not password disabled, or if the user record is, should this checkbox be checked?
5. The provisioning step goes and indeed creates the user in the NW AS ABAP, but in there in the SU01 Logon Data tab, it indeed shows password deactivated. In my log it says "sap_abap_handlePasswordDisabled: password could not be activated because there was no password defined for user <xyz>. How can this be, the password is clearly set in the UI?
6. Does the UI set encrypted passwords automatically or do I need to modify something somewhere for that to happen?
7. I read a lot of posts on this MX_PASSWORD_DISABLED setting. How do I find out which one of my test users has this? Many posts say I need to check, but I didn't read how.

I've also read various posts in this community about turning off the password disabled check in the create and modify abap jobs during initial loads but that seems odd to me, shouldn't the SAP Provisioning Framework just work after all this usage and feedback in the field over the years?

I want to avoid reading an ABAP server user set and then end up disabling passwords when I modify them in IDM, which right now to my uninitiated knowledge seems to be a problem I might have (but I will do some more testing in the lab to see).

[ChrisPS · Accepted solution]

Hello Ronald -

- AS Java uses SSL not SNC for encryption

- The requirement for SNC for permanent passwords comes from the ABAP server (a check is done there) and is mandatory for setting productive (permanent) passwords otherwise an initial password will be set for the user that must be changed at first logon

- when you set a password in IdM this stores it in the attribute MX_ENCRYPTED_PASSWORD i.e. yes there is automatic encryption of passwords

In terms of seeing the value of MX_PASSWORD_DISABLED you need to use a display task in the UI with this attribute set as one of the display attributes.

Regards,

Chris

SAP AGS

[rondv · Accepted solution]

Hi Chris,

Thanks for responding.

As to MX_ENCRYPTED_PASSWORD, I've found that in my version of the SAP Provisioning Framework V2 the handling of encrypted passwords is commented out in the to and from passes. No documentation to alert one on this, just off. I did a display task on this and found that encyrpted passwords are consistently not copied from the NW AS ABAP, or converted to the ENCRYPTED attribute when I make a new user in the UI. Now that I've gone through all the to and from passes and the web tasks it has become clear to me what is doing what, or not, with the passwords.

I'm cool with it not working, as I initiallydon't want IDM to do anything with passwords, not the ones it read from the ABAP system, or write them back if the user is made in IDM. However, now we seem to need a document on how to enable the whole thing. If I get some time I'll see if i can add to the SAP PF V2 and make it a selectable option, with or without password management based on a repository contant one can set.

I add a question to the community:

- keys.ini. Do I need to put the one I make on the IDM JAVA system to other JAVA or ABAP systems I manage with the IDM? I can only find docs on changing the keys.ini on the IDM system, but all leave ambiguous if I need to put this file on other servers that are managed so they can use the encrypted passwords once I will indeed use them.

[terovirta · Accepted solution]

keys.ini is used only internally by IdM, so just copy the file to the Portal hosting the UI (just follow the UI-component installation instructions) from under the IdM/MMC installation. Don't copy the file elsewhere as ABAP wouldn't know what to do with it.

The passwords are decrypted by IdM in the Create User or Change Password plugin before sending to ABAP/Java.

regards, Tero

[terovirta · Accepted solution]

Ronald De Vries wrote:

Hi Chris,

Thanks for responding.
As to MX_ENCRYPTED_PASSWORD, I've found that in my version of the SAP Provisioning Framework V2 the handling of encrypted passwords is commented out in the to and from passes.

If I generate the jobs from the templates I have in my PF2, only the passwords are commented out in the load jobs.

Either way, what is commented out by default (after the job is generated from the template) don't matter, you need to enable the attributes in your configuration according to the requirements.

As long as the keys.ini matches in the Portal hosting the UI to the version MMC/runtime uses, the password provisioning works pretty much out of the box (as long as correct fields are enabled).

regards, Tero