Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Implementing SAP password rules in Active Directory?

Former Member
0 Kudos

Hi guys

We have implemented SAP Secure Login Server and SAP Login Client in a retail company. This works very well for our GUI users. Most of our users in the shops however, logon to the SAP systems through a browser. We have enabled the single sign on to the BSP,  ABAP Web Dynpro and Java Web Dynpro pages using the Secure Login Server as intermediary. A redirect application is setup on the SLS to redirect to the various different Netweaver servers after issuing a SAP logon ticket. This all works very well, but our project sponsors would like a fall back solution in case the SLS for some reason is not available or able to authenticate the users. The assumption is that once the users get used to single sign on they will have forgotten the original password to their SAP user id's by the time the single sign on setup for some reason is not functioning.

The idea thus came up to synchronize user passwords from AD to the SAP systems and we do have an Microsoft ILM setup that appears to be capable of doing exactly that. However, the problem now is, that the password rules implemented by default in the SAP systems, are more restrictive than the password policy in place in AD. Consequently we may very well have the case that a user selects a new password in AD which is not strong enough to be synchronized to the SAP systems. We then thought that it might be an option to implement the SAP password rules in Active Directory, but this does not seem to be trivial. Would you have any suggestions to how we can solve this problem? Our Active Directory is based on Windows 2008.

Best regards,

Anders

1 ACCEPTED SOLUTION

Former Member
0 Kudos

You should delete the passwords, and if SSO infrastructure fails then redirect those who cannot logon to a password self-service where they can reactivate it for themselves if needed.

That works best and creates least noise.

Cheers,

Julius

8 REPLIES 8

Former Member
0 Kudos

You should delete the passwords, and if SSO infrastructure fails then redirect those who cannot logon to a password self-service where they can reactivate it for themselves if needed.

That works best and creates least noise.

Cheers,

Julius

0 Kudos

Interesting suggestion. Would you have an example of how to implement the self service? Is it built in to an SAP product? We are not using Netweaver Identity Management.

Best regards,

Anders

0 Kudos

I know that SAP GRC includes this as a webservice. But it is really easy to build -> create a webservice wrapper around the user BAPIS:

FM BAPI_USER_GETDETAIL to get the SMTP address of the user who wants a new password

FM SUSR_GENERATE_PASSWORD to generate a cryptic initial password

FM BAPI_USER_CHANGE to set the password for the user

FM SO_OBJECT_SEND to email the new password to the user

Of course you can add more security features (like excluding some user groups / types, captcha text, etc) but that would be the basic idea.

Cheers,

Julius

0 Kudos

Excellent suggestion. I will try to implement this solution and possibly blog about it if I am successful.

Thanks a lot and best regards, Anders

0 Kudos

Just to be sure: the reason why this approach is a good idea is because SSO typically does not fail and if it does then not for long. You do not need to disturb the peace and tranquillity of deactivated passwords for all users just because a few of them might actually want to be logging on during the interval where SSO is not available.

If you cannot fix the SSO problem by Monday morning 8:30, then redirect login attempts to the self-service and then offer password again only for those who actually need it during the interval and they can decide for themselves (you can also issue a message stating the estimated downtime on the redirect page).

This works very well.

Resetting all users passwords and then sending it to all of them does not work very well... particularly if some of them are on holiday or have some "personal connection data". If you have CUA set to global passwords, then you should certainly steer well clear of this failover approach.

Another little tip: to authenticate the user requesting a password for themselves who could not authenticate themselves beforehand (perhaps portal authentication is also failing), you can use an LDAP bind to ask them for their AD password before the SAP password is reset. See function module SSFT_PPPI_SIGN and SAP notes related to it and the BADI for AD authentication via LDAP binding. But ideally your redirect will authenticate the user before SAP and they can only reset their own password as they already are authenticated. The user names will ideally have to be the same.

Cheers,

Julius

tim_alsop
Active Contributor
0 Kudos

Hi,

There are many ways to implement SSO for applications which are web based. It seems the main reason for your project sponsors concern is that you have a single point of failure. Generally I find it is better to implement SSO without any single point of failure and then it never goes wrong and nobody will be concerned.

Maybe it is best to illustrate my point by considering other parts of your infrastructure. Do you have a backup network in case your network goes wrong ? Probably not. This is because the network is setup without a single point of failure so if a router dies the network will still work whilst the router is fixed. Similarly, if an Active Directory domain controller breaks, then another will be used instead whilst the broken DC is fixed.


So, perhaps you can re-architect your SSO implementation, and then you won't need to have to implement other methods of logon.

Thanks

Tim

Former Member
0 Kudos

Good point. If the whole network does down then you need a plan B.

But if the user can still reach the login screen / negotiation, then it is a good idea to have a plan B available to cover the time interval until SSO is available again for those who do want to login in that interval.

In such an unlikely scenario (loss of cabin pressure etc...) it is IMO best to resort back to passwords as that excludes any other failures.

Such services can also be useful if the SSO solution does not support scenarios where passwords are requested because SSO is not negotiates (eg. transporting) -> customer can request a "one time password" from such a service to be able to perform the task. You can even attach the authorizations to perform the task to the request for the password, and have workflow approvals inbetween.

Lots of points of failure....

Cheers,

Julius

Former Member
0 Kudos

Hello again, actually the current SSO architecture should be fairly resistant to error except for one thing. We have a Web Dispatcer on Secure Login Server with four different instances. Two of the instances are run from one datacenter physically separated from the other two instances. The Netweaver server is however configured to get its users from our Active Directory using LDAP. In the LDAP configuration in NetWeaver Administrator it seems to be only possible to configure one LDAP source and that is a little bit of a concern even though it is our primary domain controller.

As I understand it, a Windows desktop will fall back to another domain controller should the primary controller not be available, but I wonder how it works if Netweaver is not able to authenticate against the configured domain controller? Is it possible to configure that Netweaver should fall back to an alternative domain controller? Or maybe this single point of failure is not really a concern if Netweaver keeps its own copy of the user even though the source is LDAP. Maybe there is a regular synchronization of users going on but not a direct connection to AD when a logon event takes place?

Best regards, Anders