Skip to Content

SAP Single Sign On - Kerberos with Windows AD

Dear all,

At the moment, our users connect to their Windows client using an Active Directory password and then connect to the SAP systems using a SAP password.

We are looking to implement SAP SSO 3.0 with Kerberos tokens. Users would login to Windows AD and then they would access the SAP systems with SAPGUI / Portal without the need of a password.

The advantages in terms of

more productivity/less help desk calls/ less or no passwords travelling in the network are clear. Also the subsequent implementation of SNC is a big plus.

However, some people in the organisation see this as removing a layer of security and also moving the accountability of security from the SAP admins to the Windows AD admins (which are in fact an external company, not unusual nowadays).

I am interested in the opinions of people that have already implemented SSO. How do you mitigate the risks / address the concerns about the fact that implementing SSO means that the SAP admins are not in charge of the security any more and also the fact that if a Windows AD password is compromised, you end up having an intruder in your SAP system, while, before SSO, they would only have access to a PC.

Many thanks


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Jan 10, 2017 at 02:36 PM

    Hi Andreas,

    indeed that is one of the discussions you have, when it comes to pros and cons of SSO implementations. No brainer, your security will increase due to encrypted communications (TLS, SNC) and by replacing static password (and stored hashes in the SAP DB) with a standardized security token such as Kerberos.

    In addition to that, since SSO 2.0/3.0 you can choose to implement a multiple sign-on approach, which means you have to authenticate always - with your AD credentials - when starting a SAP GUI connection or opening the portal. This is mainly to eliminate the other ID theft-risk often mentioned by CISOs, such as the user leaves his computer without properly locking his screen.

    Main point in your case is the TRUST. At the moment you trust your SAP system(s) user store and admin staff. Now you "outsource" the job authenticating your users at a different Identity Provider, in that case the Active Directory domain (external staff). If you can not trust the AD sufficiently incl. all its security measures and policies in place - especially when it comes to a strong password policy - you are doing hard. We had have some cases, where the AD is operated by external staff, or large companies with multiple forests... but there are solutions available if you need to trust a different IDP.

    I would not argue that SAP admins are no longer in charge of security, as the account is still there and can be managed and monitored as before, with the difference to replace the passwords with a harder-to-steal kerberos service ticket. If you reduce passwords you decrease attack surface and potential non technical attacks against user identities such as malicious password reset requests or social engineering attacks. Users are more aware and in charge about their (only one and most important) password as if they would have 15 of them...

    The risk is your AD password policy (which is required but accepted as there is only one strong password) and a good and reliable way for the initial authentication. Whenever you have high-risk applications you can combine authentication with a second factor for those. Also it is part of risk management to evaluate if the risk is higher or lower, if someone "only" has access to PC.

    Just my two cents.

    Cheers, Carsten

    Add comment
    10|10000 characters needed characters exceeded