Configuring SAP Cloud Connector to talk to Active Directory LDAP/LDAPs

 I just had an interesting case come through.  SAP has cloud SAAS now, and they have a product, the "SAP Cloud Connector" that allows integration from on-premises services to the cloud.

One of the services exposed through the SAP Cloud Connector (SCC) is integration with an LDAP server for authentication and roles.  Microsoft's Active Directory (AD) is, by a huge margin, the most commonly used LDAP server, but SAP's documentation was painfully lacking in detail on how to set it up.

Here's the missing manual.

The official documentation is here
Use LDAP for User Administration | SAP Help Portal

LDAP Configuration: Best Practices | SAP Help Portal

The configuration that worked for us is...

Host: dc1.contoso.com:636
Secure Host: Checked
Alternate Host: dc2.contoso.com:636
Secure Alternate Host: Checked
Connection User Name: (scc service account here)
Connection Password: *redacted*
Configuration:
 adCompat="true" 
 userBase="OU=MyOU,DC=Contoso,DC=Com"
 userSearch="(sAMAccountName={0})"
 userRoleName="memberOf"
 roleBase="OU=MyOU,DC=Contoso,DC=Com"
 roleSubtree="true"

Administrator Role:
CN=sccadmingroup,OU=Groups,OU=MyOU,DC=Contoso,DC=Com

A couple of other notes.  You'll notice that I set the OU to OU=MyOU,DC=Contoso,DC=Com above.  If I set it to just DC=Contoso,DC=Com, that does NOT work on ports 389/636.  It will work on ports 3268/3269, but then you will only be able to use universal groups for the roles.  This is because the application doesn't understand the multiple results returned in the ldap search if (insert explanation about AD partitions here) on port 389 when you query a forest root domain and Java poops itself with a "javax.naming.PartialResultException: Unprocessed Continuation" error.

If you want to use LDAPs, tls/ssl encryption, which you absolutely should, you have to have certificates on your domain controllers AND also import the certificates into Java's cacerts keystore.  SAP's instructions tell you how to do this.  What they DON'T say, infuriatingly, is that SCC uses its own JVM and the cacerts file the documentation points to isn't the one they actually use. :|

To find the JVM it actually uses we ran systemctl status scc_daemon and found it's under /opt/sapjvm_8/jre.  Our cacerts file was /opt/sapjvm_8/jre/lib/security/cacerts

You'll also note that I pointed the connections above to two specific domain controllers.  Normally I would not do that.  I'd want to point it to "contoso.com" so it would auto-discover DCs from DNS.  In this case I couldn't do that because the customer's domain controller certificates did not include contoso.com as a subject alternative name on the DC certificates.  We talked about how to fix that too, but that's a topic for another day.  

I hope this saves someone else some time and frustration.