on 07-30-2009 11:19 AM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
>
> 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
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
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
>
> 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).
>
> 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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
87 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.