cancel
Showing results for 
Search instead for 
Did you mean: 

Password-Provisioning to ABAP as productive Password possible?

Former Member
0 Kudos

Hi SDN

I'd like to provision the password received from the AD Password Hook to the connected backend systems, so the users in my company have the same password in every system they use (ADS/LDAP, Workflow & SAP ABAP).

In ADS I can use "useraccountcontrol" to state that users DON'T have to change their password on first login.

However, I experienced that the users still have to change their (initial, admin-set) passwords in the ABAP-Backends. Additionally, the standard procedure does not permit the new password to be the same as the old (initial) one along with other sumbling blocks.

In a post dated Aug. 2008 ([here|😉 I read that it is not easily possible / recomended to create a workaround for this.

Is there an update / solution / best practice relating to NW-IdentityManagement (7.x)?

Because - as I think - this kind of same-password-provisioning should/could be a key functionality of IdentityManegement solutions in general.

Regards

Michael

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi all

Thanks for your replies so far.

What I described above was more like a "nice-to-have" for our organization and a question about the possiblites SAP NW IdM supplies.

I think under these circumstances we won't implement password provisioning to our different backend systems.

@Matthew

In our environment we have several SAP -Systems, Portals and one ADS/Exchange. We don't use CUA or similar. So if someone changes his passwrod in one SAP ABAP system I will still have the problem described above in the other systems.

Also: Which password do you expect to be propagated? The one from ADS, SAP ABAP or Workflow?

@Matthias

I think an Enterprise Portal doesn't help here, as we have SAP ABAP backends or "technologies" that are not connected to the Portal or suit into a web interface (just imagine SE80). Or did I miss something?

On the other hand I experienced several times that SAP NW Portal uses ABAP as user-source. Then a username/password provisioning to other (ABAP/ADS) systems is still a nice-to-have

@Julius

You are right with "lowest common denomintor". On the other hand I could provision a "complex" password which could suit most of the needs.

I'd be interested in some details about what you mentioned about "internal only" and setting productive passwords As I'm currently on IdM 7.0.2 I might not know about some features implemented in IdM 7.1, but I will soon be learning & using 7.1

In general I'm surprised that SAP IdM offers self-PW-services if these cannot be synchronized with other SAP systems. As I think, IdM (as of standalone 7.0) is then "just" another system where a user has to remember a password.

Does anyone use the ADS-Password-Hook functionality? What for?

Thansk for any help so far. Maybe someone yomes up with additional information!?

Regards

Michael

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

>

> In general I'm surprised that SAP IdM offers self-PW-services if these cannot be synchronized with other SAP systems. As I think, IdM (as of standalone 7.0) is then "just" another system where a user has to remember a password.

Yes, SAP NetWeaver Identity Management 7.1 SP 2 provides such password self-services.

And yes, you can configure your IdM to provision the IdM password to other systems (one-way distribution) and demand that the IdM password should be set as "productive password" (also for NWAS ABAP systems - which require a certain Support Package level, see [SAP Note 1287410|https://service.sap.com/sap/support/notes/1287410] - currently not released, yet).

But Julius Bussche is also right stating that you have to find the "lowest common (security) denomintor" regarding password policies if you want to have only one single password for the entire landscape (of heterogenous systems) - and you might even fail so (if there is no common set of password rules).

Regarding "ADS Password Hook":

maybe it's worth considering to use Kerberos / SPNEGO (aka "Windows Integrated Authentication"), instead?

Edited by: Wolfgang Janzen on Jul 31, 2009 1:31 PM

Former Member
0 Kudos

Hi Wolfgang

Thank you for your reply.

I'm curious about the release and the release date.

Question answered, so far

Regards

Michael

Former Member
0 Kudos

Hi everybody,

my customer is also considering to use the AD password hook to provision the user's password to SAP/CUA. Besides the problem that the password needs to be changed after the first logon in SAP, there is also the problem that the AD password policy is not fine-grained enough that it would match with the SAP password policy. E.g. SAP does not allow "!" to be the first character of the password and the password must not be "SAP*".

Does anybody know whether the default SAP policies can be disabled or weakened?

Best regards

Holger

Former Member
0 Kudos

Hi Holger

I don't know if the SAP password policy can be changed.

But you could use the "Filter"-functionality of the AD password hook for this purpose. This would involve some custom development. As far as I know the new AD-password will be rejected if it doesn't match your Filter. This way you could enforce a password policy to AD which is similar to the SAP one.

Maybe this helps.

Regards

Michael

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

>

> Hi everybody,

>

> my customer is also considering to use the AD password hook to provision the user's password to SAP/CUA. Besides the problem that the password needs to be changed after the first logon in SAP, there is also the problem that the AD password policy is not fine-grained enough that it would match with the SAP password policy. E.g. SAP does not allow "!" to be the first character of the password and the password must not be "SAP*".

>

> Does anybody know whether the default SAP policies can be disabled or weakened?

>

> Best regards

> Holger

Sorry, but that's not possible - and anyway: it's the wrong approach.

Have you ever considered to use local Windows accounts and keep them synchronized accross many workstations? I guess that you did not even think about such an approach. The better approach is to use a domain controler (as SSO solution).

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

>

> Hi Holger

> I don't know if the SAP password policy can be changed.

> But you could use the "Filter"-functionality of the AD password hook for this purpose. This would involve some custom development. As far as I know the new AD-password will be rejected if it doesn't match your Filter. This way you could enforce a password policy to AD which is similar to the SAP one.

>

> Maybe this helps.

> Regards

> Michael

Well, that filter could even check if the password candidate complies with the current ABAP password rules - by calling the remote callable ABAP function module PASSWORD_FORMAL_CHECK. But please notice: that only checks the (basic) password rules but not the (additional) password change rules. When changing a password (not to be mixed up with setting a password, for which you require administrative rights) additional rules will be checked (e.g. the password history, the number of characters in which old and new password are different, etc.).

From all that you can conclude: it does not work reliably.

It can be expected to work even less reliably the more backend systems are involved (usually there is more than just one ABAP system involved) since every system is evaluating it's own (local) password policy (including own, local password history).

Regards, Wolfgang

Former Member
0 Kudos

Hi

Thank you all for your highly valuable replies and suggestions. My question is more than answered: No, not (yet/easily) possible and not advised to do so.

Regards

Michael

Answers (3)

Answers (3)

Former Member
0 Kudos

If you want to synchronize passwords, then you will anyway have the problems of the "lowest common (security) denomintor".

AFAIK, it is now possible to even set a productive password from the IdM (but I am not sure about the release details of it).

However I cannot imagine that this is implemented via the BAPI_USER_CHANGE function (as SU01 cannot do it for DIALOG and COMMUNICATION type users) but rather an SAP IdM specific (internal only) feature...

Other options of SSO and even a password self-service are available as well.

My personal recommendation would be to go for a "password vault" for such accounts.

Cheers,

Julius

Former Member
0 Kudos

This is really an architectural question. Matthew is right pointing to an ESSO approach. But if you only want to provision to SAP you might want to consider an Enterprise Portal. The password would come from LDAP and the change of SAP passwords would be obsolete.

Regards,

Matthias

Former Member
0 Kudos

Michael,

Best Practice in this is to utilize an eSSO solution to handle these various systems and applications.

However if you must do it this way why not just force setting a password on login and then have that password be propogates?

Matt