Skip to Content
Author's profile photo Frank Schuler

Use LDAP for your SAP Cloud Connector Authentication

In this blog I explain the mechanism with which the SAP Cloud Connector (SCC) authenticates against LDAP providers to help you secure your SCC leveraging LDAP authentication:

As explained in the respective SAP Cloud Platform Documentation, after installation, the cloud connector uses file-based user management. Initially there is one Administrator user with the password manage:

which needs to be changed on the first logon as part of the Initial Setup:

However, this still represents a security risk as highlighted by the SCC because it only allows for one administration user and therefore all changes in the Audit logs are against that Administrator user rather than the actual user:

As an alternative to this file-based user management, the cloud connector also supports LDAP-based user management. If you have an LDAP server in your landscape, you can configure the cloud connector to use the users available on that LDAP server as described in my respective blog: Secure your HANA Cloud Connector with OpenSSL certificates – Part 3. All users that are in a group named admin or sccadmin will have the necessary authorization for administrating the cloud connector. This group membership is checked by the cloud connector.

To make this mechanism transparent, in this blog I take a reverse approach and configure an Active Directory Lightweight Directory Services (AD LDS) instance to work with the example configuration of the respective SAP Cloud Platform Documentation to authenticate my SCC administration users:



I start with creating a new AD LDS instance with the Active Directory Lightweight Directory Services Setup Wizard:

For this I need a unique instance:

That I can name however I want, because the instance will only be referenced by their respective LDAP ports that I configure next and not by their name:

I except the standard LDAP ports:

Next comes the first bit of configuration that must match the standard configuration since I want to make that work as it is. This means that my Partition name must match the domain component from its JNDIRealm based userPattern lookup string for the administration users userPattern=”uid={0},ou=people,dc=mycompany,dc=com“:

Then I confirm the standard File Locations:

Use a Network service account to run my AD LDS:

And my Currently logged on user as my AD LDS Administrator:

I import the MS-User.LDF Lightweight Directory Interchange Format (LDIF) file:

Review the setting and install:

Which finishes successfully:

With this I connect to my AD LDS instance with EDSI Edit. Importantly, I have to specify the Partition name from before as the Connection Point:

And add my login credentials and port number in the Advanced settings:

To match the organizational unit from the default configuration JNDIRealm based userPattern lookup string for the administration users userPattern=”uid={0},ou=people,dc=mycompany,dc=com”, I create the respective LDAP object:

Within this, I create my first SCC administration user. I can chose that name however I want, because it is not part of the standard configuration:

And set its password via Reset Password:

I also add my SCC administration user to my AD LDS Administrators to be able to use it to query my instance. This does not have to be the same user, but it can and from my perspective simplifies the setup. For this I add it to the members of the Administrators group:

Since SCC considers all users that are in a group named admin or sccadmin to have the necessary authorization for administrating the cloud connector, I create one of those as a group in a new organizational unit groups as per the its JNDIRealm based roleBase lookup string for the administration users roleBase=”ou=groups,dc=mycompany,dc=com”:

Further examining the JNDIRealm based roleSearch lookup string for the administration users roleSearch=”(uniqueMember={0})”, I realize that the uid of any SCC administration user userPattern=”uid={0},ou=people,dc=mycompany,dc=com” has to be in the uniqueMember attribute of the group. Since I do not have the groupOfUniqueNames class available in my AD LDS, I use the group classs with its member attribute instead and add my administration user respectively:

With this, I am done, but to avoid any surprises, I test my configuration with an LDAP tool like the free Softerra LDAP Browser. First I check that I find a group with common name sccadmin within the organizational unit groups and display its member:

Then I check that a user with this common name exists in organizational unit people:

Since it does, I am ready to switch my SCC to authenticate against my AD LDS. Please be aware of the 2 changes to the example configuration:

  1. roleSearch=”{member={0}}
  2. userPattern=”cn”={0},ou=people,dc=mycompany,dc=com”

Which requires a SCC restart but thus, after confirming that my SCC administration user is a pure Service User with no further LDAP authorizations, my security risk has been reduced to low:

Also, I can now easily add additional SCC administrators by just creating them in the people organizational unit and adding them to sccadmin group.

I hope this reverse approach of making the SCC LDAP example configuration work while still modifying it slightly gives you enough insight to successfully authenticate your SCC against your LDAP.


This is the final SCC LDAP configuration used:



Assigned Tags

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

      Thank you  for the detailed post. In my scenario, we would connect to existing AD DS and our naming convention requires to have the group names captured differently. Can you share if different group names are possible and if so how the LDAP query needs to be constructed.

      Author's profile photo Nelis Lamprecht
      Nelis Lamprecht

      The above blog configuration doesn’t look right. Unless I have misunderstood something I would expect it to look like the following otherwise there is no point in creating the group sccadmin:


      Edit: the above configuration pattern is incorrect, see below.

      Author's profile photo Nelis Lamprecht
      Nelis Lamprecht

      For those wishing to use MS Active Directory LDAP service and give a specific group e.g. sccadmin users access while still adopting high availability(userPattern cannot be used with high availability) you can use the following configuration pattern which works for me:


      I then added a custom administrator role in the form of(distinguishedName):


      You will obviously need to change the above according to your own schema.

      Author's profile photo Mir Imran Ali
      Mir Imran Ali

      Hi Nelis,

      In our environment we are setting HA for SCC with LDAP Authentication. We tried to use the configuration shared by you but unfortunately its not working and giving below error.

      Configuration is working with userPattern but we cannot use as this is an HA setup.


      Could you please check if you had the similar issue while doing the config.

      Please advise.


      Author's profile photo Nelis Lamprecht
      Nelis Lamprecht

      You need to ensure the following for a successful bind:

      1. SCC must have a valid SSL certificate and be working
      2. You must use a secure connection to AD i.e. LDAPS on port 636


      Author's profile photo Paul Kalina
      Paul Kalina


      I would just add that by default CC will not search in child OUs.

      To enable this feature add the following parameters:

      Author's profile photo Armado Cappello
      Armado Cappello

      this blog helped me a lot, to anybody that tries the same activity, remember :

      set in AD LDS for the users the parameter msDS-UserAccountDisabled = FALSE

      when testing the connection for ldap, the user must be like CN=ldapuser,OU=people,DC=mycompany,DC=com

      myconfig is below


      Author's profile photo Nils Knieling
      Nils Knieling

      Hi Frank, many thanks for your article. Helped me a lot to connect the SAP Cloud Connector with Secure LDAP from Google: