Skip to Content
Technical Articles
Author's profile photo Carsten Olt

Correct handling of passwords after implementing SAP Single Sign-On

Passwords are seen as the key to our information and should, therefore, be selected and handled with care. They accompany us in everyday life and are often used when accessing the operating system or when logging on to company applications such as SAP.

For good reasons, securing access data is very important from an IT security perspective because credentials are seen as the primary gateway for most kinds of threads leading to compromised systems.

In their day-to-day work, users are faced with more and more accounts for different systems and applications. For each application, it is best to remember a secure and complex password and to renew it regularly.

This cannot work, overwhelms many users and has no advantages from an IT security perspective, this ball usually goes backward and weakens overall security.

Single Sign-On (SSO) has the potential to solve many of the problems associated with passwords. But still, there are lots of companies not using SSO at all, which is a bad idea. Others are still have passwords despite using SSO and consequently never deactivated the passwords for their Sap users. Possible, but also a bad idea, as this should only be the case for some exceptions.

This principle also applies in the SAP environment: “Avoid passwords whenever possible and use SSO”.

Single Sign-On (SSO) is a centralized session and user authentication service in which one set of login credentials can be used to access multiple applications. With one set of credentials, (single or multi-factor authentication) you can enable and disable user access to multiple systems, applications, and resources”

Complexity | Integration | Centralization

Meanwhile, SAP landscapes have become significantly more complex than one decade ago. They consist of a wide variety of different systems that interlink closely with existing IT components and extend into the cloud. Applications running within this hybrid SAP environments are made to be consumed from anywhere and on any device. And this requires authentication.

Due to its multi-system landscape and decentralized password management, the SAP landscape is an ideal environment for SSO, helping to significantly reduce the total number of passwords required for several systems and to eliminate password logons.

Using SSO outsources authentication to a central system that verifies your identity and based on that issues a security token. Once you got that you can access your various SAP applications. Such a central system can be secured much better than each SAP system itself. The access to the respective SAP system is then only possible using security tokens such as X.509 certificates, a Kerberos ticket or a SAML assertion or JWT. This meant that the user had to identify himself beforehand once, which under some circumstances may require the use of multi-factor-authentication.

The security tokens themselves are cryptographically protected and of course, do not contain any credentials such as passwords. With SSO gone are the days when users had to remember dozens of passwords for different systems or had to change them frequently. An additional advantage is the ability to quickly lock out certain users like when an employee leaves the company.

In the best-case scenario, having no access to the Active Directory (as your central system) also means that access to on-premise SAP applications and integrated cloud applications such as SAP Ariba or SuccessFactors is no longer possible.

Besides the efforts and costs related to password-reset-calls, there are also security issues. Nobody wants to be a victim of phishing emails. And nobody intentionally uses a very simple password so that hackers have a particularly easy game using a dictionary or brute-force attack.

Most users are familiar with the current regulations and recommendations for secure passwords yet using passwords still is a prone process. However, if the company does not provide an SSO solution, the secure handling of access data ultimately remains with the user, and yeah!


The goal of a complete SAP Single Sign-On implementation is to increase security by confidentiality, integrity, and authenticity. No unencrypted connections are allowed to that system (exceptions possible) and there are only a few accounts left having a password at all and permission for password-based access.

Unfortunately, this does not happen in many cases and so passwords continue to exist in the SAP systems and are forgotten soon. If they still exist and SNC+SSO is not enforced, users and adversaries can easily bypass security and (try) perform direct system logons. Password policies, therefore, remain active and regular password changes are also required. The transition to a password-free user can then be carried out automatically and planned by the SAP system over a certain period. Alternatively, users can be involved in the process and delete their password using a kind of self-service procedure.

If all users are enabled for SSO on all required SAP systems and there are no other reasons against it, the users’ passwords can be deactivated in this system. All applications on this system, consumed via the DIAG, RFC or HTTP protocols are taken into account and configured accordingly. In this case, it is recommended to configure the profile parameter login/password_change_for_SSO = 3 (the password is deactivated without a message). Users no longer see a password change screen. A positive side effect – if the passwords are deactivated, there are no password hashes in the database.


Even with the use of SAP Single Sign-On, you cannot avoid passwords at all. Basically, there are user accounts that still require a password like those exceptions for transport imports and other maintenance tasks or for interfaces used for system-to-system communication (S2S).

In addition to a few dialog users (exceptions), there are usually many service and system users. The security level for the test and development systems differs from the security level for production systems. Under no circumstances, it should be allowed to use the same password on the different SAP systems. All the more important is the correct technical and organizational handling of these user types & passwords and to make use of the most secure hash method possible in your SAP system.

The SAP systems should not generate backward compatible hash values (BCODE, PASSCODE). It is recommended to configure the systems only using Code Version H (PWDSALTESHASH). This is implemented using the profile parameter  login/password_downwards_compatibility = 0

Based on this parameter, the following hash encoding method is used in SAP NetWeaver as standard: RFC2307, algorithm = iSSHA-1, iterations = 1024, saltsize = 96

You can add additional security by using more recent hash methods such as SHA-256 and a 10 times higher number of iterations. This massively increases the resources and time required to calculate (attack) SAP password hash values using tools such as oclHashcat and the likes.


After implementing and enforcing SNC/TLS and SSO normally 98% of all users in the SAP system no longer have a password. Nevertheless, a proper password policy has to be implemented. This is especially important for those users who have to continue working with passwords (exceptions).

The German Federal Office for Security (BSI – Bundesamt für Sicherheit in der Informationstechnik) is publishing the IT-Grundschutz Catalogues annually each February. It is a compendium that covers technical, organizational, infrastructural and personnel aspects and is to be seen as a systematic approach to information security (ISO/IEC 27001 compatible). Many of the recommendations and guidelines outlined there are influencing the SAP world as well.

In its current edition of the “BSI Grundschutz Compendium Feb 2020”, there is a section which is now advising against regular password changes. A forced regular change of passwords is therefore outdated. Unfortunately, the 2020 edition is not yet available in English.

Better to set a separate and secure password for each SAP system. This is perfectly fine and still best protects against so-called credential stuffing or password spraying and also “brute force” attacks. An increase in user awareness of the subject “passwords” can be supported by the use of SSO. The number of required passwords is reduced to a minimum, making IT systems easier to use again.

With over 800 pages, the BSI work is not an easy meal. It contains security requirements for SAP systems as well. Like in APP.4.2.A31 in that a securely configured single sign-on is recommended or APP.4.2.A18 in which it is advised to switch off any unsafe communication and enforce the use of SNC and TLS and thereby enables the use of various SSO methods.

So check them out and update your SAP password policies and authentication strategy to reflect the newest recommendations!


The use of single sign-on offers many advantages such as increased productivity and security and creates greater acceptance by end-users and system operators. If the risk of abuse in the SSO environment is classified as high, SSO is no longer considered sufficient for the risk classification. In these cases, multi-factor authentication can be used.

Different MFA methods in the form of hardware and software tokens are supported both in the environment of various identity providers and with the SAP on-premise and cloud solutions such as SAP SSO 3.0 and SAP IAS.

If an adversary gets in possession of access data, the gates are open for further attacks based on that credential pair or the password-schema. They will then try it for other accounts or systems as well. Thanks to AI & machine learning, there are very complex algorithms that already predict future passwords, the keyword is “Password-Guessing Machines”.

If the past has shown us one thing, it is that we cannot rely on the fact (or wish) our credentials on various IT systems are secured in the best possible way. Hence, it is best not to work with passwords at all. Use a well-secured SSO architecture whenever possible. Especially when working on cloud applications, no passwords should be used for authentication. Instead take advantage of SAML 2.0 and outsource the authentication to a central and trustworthy identity provider.


  • Use passwords only if there is no way to set up a more secure authentication method.
  • Always use encrypted connections to your SAP systems (SNC+TLS).
  • Enforce encryption and authentication with security tokens.
  • Make sure the procedures and algorithms are state-of-the-art (e.g. Hashes!)
  • Use a different and strong password for each system.
  • Create long and complex passwords using a generator.
  • Use a password manager (…and write down the master password on a piece of paper).
  • Use two-factor authentication for critical systems or privileged accounts.
  • Include your corporate authentication into your SAP security strategy

Have a peaceful day!

(Cross Posted Content | Original Source here)

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Lutz Rottmann
      Lutz Rottmann

      Hi Carsten Olt ,

      nice overview! Some remarks on login/password_change_for_SSO from my side.

      According to my experiences a full coverage of all logins with SSO is not easily achievable.
      Example: an ESS Scenario, where there is SAML2 SSO to the Web UI, but administrators or power users use GUI without SSO. With your configuration proposal, these users will lose their password access if their first login after login/password_expiration_time is an SSO login.

      So as a compromise I typically recommend the following set of parameters to disable unused passwords without regularly locking people out because of accidentally deactivated passwords:

      login/password_change_for_SSO = 0
      = Don’t ask users for password change and don’t deactivate or do anything else with the password on SSO login after login/password_expiration_time

      login/password_max_idle_initial = 2
      = Deactivate passwords set by administrators if not used for two days

      login/password_max_idle_productive = 120 (must be larger than login/password_expiration_time  which is 60 in this example)
      = gives users the chance to change their password for additional 60 days after password expiration, even if they login regularly using SSO e.g. in an ESS scenario.

      So passwords that are not used get invalid after some time, but power users who need their passwords, have some additional time to change password even if they login regularly with SSO. Numbers of parameters can be adjusted to the adequate security / comfort trade off.

      Best regards, Lutz

      (PS: Sorry for the strange formatting. Seems to be an editor bug.)

      Author's profile photo Carsten Olt
      Carsten Olt
      Blog Post Author

      Hi Lutz,

      that is a nice approach, thanks a lot for your update. 

      I consistently recommend the approach that (without exception) all dialog users (must) use SSO, and thus only token-based authentication is possible, even for power users. But there are ALWAYS exceptions - and you are right. You never stop learning 😉

      Cheers Colt

      Author's profile photo Luis Guereca
      Luis Guereca

      Hi Carsten and Lutz,

      Thanks a lot for your recomendations.

      I would like to ask for recommendations to solve this scenario.

      It seems once you activate SSO in ARIBA all your Ariba users will need to use SSO, when you do not really require it for all your Ariba users.

      Having Ariba SSO activated we may have these scenarios:

      1. Ariba users inside own network accessing thru SSO (to Ariba and non Ariba apps)
      2. Ariba users inside own network accessing with Ariba user and password (No SSO)
      3. Ariba users outside own network accessing with Ariba user and password.(No SSO)

      If activating Ariba SSO forces to use always SSO access for all Ariba users we will incurr in SSO additional costs for all Ariba users when we do not really want to apply SSO for all scenarios.

      Is there a way to implement Ariba access with SSO for some users and with-out SSO Ariba access simultaneously?.

      I am not sure if you can achieve it by doing Configuring Application Gateway in ARiba network.

      Thanks a lot for your recomendations.

      Luis Guereca


      Author's profile photo Carsten Olt
      Carsten Olt
      Blog Post Author

      Dear Luis,

      the original article aimed to deal with passwords in the SAP on-premise SAP environment, especially ABAP systems.

      I am not an Ariba expert... after enabling SSO in SAP Ariba (SAML enablement) based on my experience, it is impossible to log in with user + password for enterprise users (IMHO for third-party users it is still possible).

      However, you can use an SAP Identity Authentication tenant to handle authentication and implement various scenarios to delegate authentication towards your internal IdPs or authenticate external users (consultants, partners, customer) via a local IAS user. That should help you to handle the most authentication requirements.

      Cheers Colt

      Author's profile photo Luis Guereca
      Luis Guereca

      Hi Colt,

      Thank you very much for your comments and quick response.

      My understanding is the same, after enabling SSO in SAP Ariba (SAML enablement) it is impossible to log in with user + password for enterprise users.

      I am looking for a workaround on the authentication mecanism (corporate web server) to discriminate the scenarios.

      Your suggestions are really interesting based on SAP Identity authentication tenant to implement various scenarios to delegate authentication to:

      1. Towards the internal IdPs.
      2. To Authenticate external users (consultants, partners, customer) via a local IAS user

      When Ariba user calls Ariba on demand app, Ariba redirects to a corporate authentication page, Authentication mecanism is based on SAP IDM and SSO (in our scenario), and grants access to Ariba solution in the cloud.

      So do you think is possible to filter when user will be under SSO and when user will not be under SSO thru SAP identity authentication?

      Thanks in advance,

      Luis Guereca