Use LDAP for your SAP Cloud Connector Authentication

[architectSAP]

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:

userPattern="uid={0},ou=people,dc=mycompany,dc=com"

roleBase="ou=groups,dc=mycompany,dc=com"

roleName="cn"

roleSearch="(uniqueMember={0})"

 

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.

Appendix

This is the final SCC LDAP configuration used:

 

roleBase="ou=groups,dc=mycompany,dc=com"

roleName="cn"

roleSearch="(member={0})"

userPattern="cn={0},ou=people,dc=mycompany,dc=com"