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.
