Skip to Content

Is implementing Kerberos authentication for SAP a security risk?

This question was posed to me recently by an UNIX administrator who was reluctant to delegate SAP authentication to Kerberos KDC on Windows Active Directory. Even apart from the philosophical argument as to the security of UNIX vs. Windows the question is really if you are introducing a security risk in general when you delegate authentication of one application to another.  In this “keys to the castle” scenario what is essentially happening is the SAP system is accepting that Windows has done a good job authenticating you already and is willing to accept that authentication instead of doing another authentication itself. So how do you try to answer this question? Perhaps by starting to look at it from a few different perspectives we can make a start.

From a user productivity perspective:


  • The user only has to remember one user name and password.
  • The user doesn’t have to authenticate separately to each system, thereby improving the user experience and lowering barriers for users getting to the information they need.

From a system support perspective:


  • The help desk doesn’t get a flood of calls from casual SAP users who have forgotten their password since the last time they needed to go into the system.
  • If there is a problem with authenticating a user it becomes more complex to debug and resolve if authentication is being done by another application. If Kerberos is the only way to authenticate then it also becomes a single point of failure. In the case of SAP however you can generally fall back to other authentication methods.
  • It can also be confusing for support staff as it blurs the boundaries between systems so it becomes unclear which support group is responsible for dealing with the problem.

From a security perspective:


  • If a Windows account is compromised that has the knock-on effect of the SAP account also being open to attack. If the SAP system had a separate internal authentication process a compromised Windows account would not give an attacker an immediate access into SAP (of course if the user decided to use the same password for SAP as for Windows and the windows account was compromised then that offers no protection).
  • User administration, authorizations and permissions can potentially be managed from a single system. No need to duplicate users and groups in multiple systems. This is one of the goals of Identity Management systems.
  • There is only one authentication step happening which reduces the number of times a user name and password combination transits the network. After the initial authentication step the Kerberos ticket is all that is passed around the network – it is encrypted and therefore much more secure.
  • The security of the KDC server is extremely important. A compromised KDC server or KDC administrator credentials can compromise the entire system.

So what can be done to make things more secure if you are worried about implementing Kerberos? Here are some suggestions:


  • Improve the strength of your authentication by introducing strong password policies, certificate authentication and/or One Time Passwords (OTP).
  • Ensure you have strong passwords and good policies around password management for both the KDC and SAP server administrators and users.

Ultimately like most things in life there is no definite yes or no answer to this question, just various shades of grey. Making an informed decision and weighing up the risks and rewards will ultimately result in the right decision for each individual organization. What is important is to look at how sensitive the information your giving access too via SSO in your SAP systems is, if your Windows based authentication is not strong enough to protect that data then think about ways to further secure it. However in my opinion in general the small additional risk that the KDC servers are compromised is worth the reward if it means the user experience is improved and the number of help desk calls for password resets can be reduced.

You must be Logged on to comment or reply to a post.
  • Hi Simon

    Good topic. The main risk I can see happening is people walking away from their desktop without locking it. Some people start thinking about things like proximity cards etc, but that can lead to sloppy behaviours. “Lock before you leave”.

    The other issue is a support one. How can the support people try something as an end user for analysing porblems etc?  Interested in your ideas on this…


    • As always, security comes down to one aspect: humans.

      You can enforce the computer to lock the screen after X minutes being idle, you can give trainings on security and how easy it is to use windows+l, etc. The resistance of the end-user to work together with the security concept is the problem and normally prevents SSO.

      On the other hand, if you don’t use SSO, the user will also have a hard work. Logon to:
      – computer
      – proxy
      – portal
      – backend 1
      – backend 2
      – backend X
      – SAPGui

      SSO isn’t a solely factor of security, it’s about performance and transparency. And this is how you can gain user acceptance. Unfortunately, you gain user acceptance and loose some security, but users that have a problem in locking the computer also will have problems in using a Smartcard (and to remove it when leaving the computer).


    • Hi Michael,

      Thank you for your comments and insight. As you righly say people need to make sure that they lock their workstations in such a scenario.

      On the support front, one solution is to turn off automatic logon in the browser settings, that way the Kerberos logon will fail and the portal wil revert back to username/password. That way a support person could logon as someone else I suppose (but it would require a password reset once they were done)


  • If reduction of support messages for password reset is the main concern then for Java statcks we can opt for “Logon Help” functionality in SAP. /webdynpro/dispatcher/<br/><br/>using which a user can reset his password without manual intervention & receive a system generated passowrd.<br/><br/>kind Regards,<br/>Ronica

  • Our security team refused SAP standard Kerberos authentication because it is mandatory to use the obsolete (and compromised)DES algorithm for the windows user acessing the KDC server (Active Directory server).
    The standard is now to use AES or RC4 and it is not possible with the standard SAP implementation.
    The only current possibility that I know, is to buy an external (SAP certified product).
    It is time to improve the standard…
    • Hi Olivier,
      I have good news. Our developers have already developed a new login module that can accept lots of other encryption types. The new module is much more flexible — and you do not have to use DES anymore.
      I cannot post any release dates yet, but it will be available soon 🙂


      • This is great info, thank you both for your comments. I knew that DES had been compromised (from listening to Steve Gibson on Security Now at but for whatever reason I didn’t put 2 and 2 together! So thank you for your input 🙂

        Great that SAP have addressed this problem too and we await the solution eagerly 🙂

    • This is a very good blog, and I think many of the considerations/issues mentioned are specific to any SSO implementaiton, not just related to Kerberos with SAP. Also, if you want to use SPNEGO with RC4/AES when logging onto SAP NetWeaver, you can use the product described here: This product can also allow users to logon using Kerberos (e.g. Active Directory) credentials without IWA/SSO, so the user only needs to know their domain account and password, and can logon from domain workstation, shared workstation, somebody elses workstation, or login as a different user to the one logged onto Windows.
  • Very good and balanced blog and good news about the new login module mentioned.

    I only want to add that if hold a gun to someone’s head then they will normally do anything for you… 🙂

    Also, if you mix both SSO and passwords at the same time then generally security will decrease as the users will not notice that their accounts have been compromised via one of the authentication mechanisms.

    A usefull feature would be to present to the user a list of recent successfull and unsuccessfull logon attempts, but the myriad of UI’s and protocols which the SAP modules support make it difficult. It would be nice if it were an option though as monitoring (which is very possible) often does not care about the account as much as the user does.