How-to Guide: Provisioning Users from LDAP (Docker-based) into SAP Cloud Identity Services (IPS)

But sometimes LDAP is still needed. I decided to reproduce this scenario and, at the same time, get my first hands-on with Docker: run OpenLDAP, connect User Interface, wire it through SAP Cloud Connector, and test provisioning into CIS → Identity Directory (IdDS).

Goal

Spin up OpenLDAP in Docker with a GUI (phpLDAPadmin).Configure Docker networking and port mapping.Connect LDAP to SAP Cloud Connector (SCC).Set up Identity Provisioning (IPS) to write into CIS.

The beauty of containers is their lightweight nature and the ability to spin up everything with a single script.

For this setup I used:

bitnami/openldap → the LDAP server holding user entries.osixia/phpldapadmin → the GUI for user administration, so I don’t have to manage everything via CLI.

By exposing ports from the internal Docker network (via docker-compose), you can:

access phpLDAPadmin locally in the browser to create test users,connect a local SAP Cloud Connector instance to the same LDAP through the mapped port, and then expose it into your BTP Subaccount.

Next step: solving a few practical issues.

Step 1. Running OpenLDAP in a container

Problem: OpenLDAP by default only listens inside the container (389) and is not accessible from the host.Solution: map a host port, e.g. 13890:389.

Step 2. Docker Networking (docker-compose)

Problem: containers may not see each other by hostname if not attached to the same user-defined network. Basic networking tools (nc, telnet) are also missing inside the images.Solution: create a custom Docker network in docker-compose and connect both openldap and phpldapadmin to it. Inside the network use port 389; for external access, use the mapped port.

Step 3. phpLDAPadmin Integration

Problem: phpLDAPadmin expects to connect to localhost:389 by default.Solution: configure environment variables in docker-compose.

Intermediate Result

OpenLDAP and phpLDAPadmin are up and running in Docker. Internal networking and port mapping are configured.You can now add test users via GUI and prepare LDAP for SCC → IPS integration.

Connecting SAP Cloud Connector (SCC)

In SCC, create a new connection for your BTP Subaccount using LDAP protocol, pointing to localhost:13890.

Back-end TypeProtocolInternal HostVirtual HostPrincipal TypeNon-ABAP SystemLDAPlocalhost:13890ldap:389None

Important: your Subaccount must have the Connectivity service plan enabled in SAP Cloud Identity Services. This allows IPS to reach on-prem systems via SCC.

After successful setup, BTP Cockpit shows something like:

Exposed Back-End Systems (SCC Location ID)

ldap:389LDAPNon-SAP SystemAvailable

Configuring Identity Provisioning (IPS)

In IPS, create an LDAP source according to the usual SAP Help documentation. You can use default Transformations here. Key detail: the LDAP user object must contain the mail attribute. If not present, IPS will skip the entry. Even the two default users shipped with the OpenLDAP container are enough to test the provisioning chain.

End-to-end check:

LDAP → SCC → BTP → IPS → Identity Directory

Conclusion

Using containers makes it extremely fast to spin up a fully working LDAP provisioning scenario for SAP BTP. This approach is safe and easily reproducible also for testing transformations and mapping without touching a production corporate directory.

P.S. Below you can find my docker-compose.yml file as a reference for your own setup:

services:
openldap:
image: bitnami/openldap:latest
container_name: openldap
environment:
LDAP_ADMIN_USERNAME: admin
LDAP_ADMIN_PASSWORD: password
LDAP_PORT_NUMBER: 389
networks:
ldap-net:
aliases:
– openldap
ports:
– “13890:389”
– “16360:1636”

phpldapadmin:
image: osixia/phpldapadmin:latest
container_name: phpldapadmin
environment:
PHPLDAPADMIN_LDAP_HOSTS: openldap
PHPLDAPADMIN_HTTPS: “false” # deactivate HTTPS
networks:
– ldap-net
ports:
– “8080:80”
depends_on:
– openldap

networks:
ldap-net:

Setting up user provisioning from a corporate LDAP into SAP Cloud Identity Service (CIS) — Identity Provisioning (IPS) is not the most common task — most customers today rely on Microsoft Entra ID (in sync with AD FS, for example).But sometimes LDAP is still needed. I decided to reproduce this scenario and, at the same time, get my first hands-on with Docker: run OpenLDAP, connect User Interface, wire it through SAP Cloud Connector, and test provisioning into CIS → Identity Directory (IdDS).GoalSpin up OpenLDAP in Docker with a GUI (phpLDAPadmin).Configure Docker networking and port mapping.Connect LDAP to SAP Cloud Connector (SCC).Set up Identity Provisioning (IPS) to write into CIS.The beauty of containers is their lightweight nature and the ability to spin up everything with a single script.For this setup I used:bitnami/openldap → the LDAP server holding user entries.osixia/phpldapadmin → the GUI for user administration, so I don’t have to manage everything via CLI.By exposing ports from the internal Docker network (via docker-compose), you can:access phpLDAPadmin locally in the browser to create test users,connect a local SAP Cloud Connector instance to the same LDAP through the mapped port, and then expose it into your BTP Subaccount.Next step: solving a few practical issues.Step 1. Running OpenLDAP in a containerProblem: OpenLDAP by default only listens inside the container (389) and is not accessible from the host.Solution: map a host port, e.g. 13890:389.Step 2. Docker Networking (docker-compose)Problem: containers may not see each other by hostname if not attached to the same user-defined network. Basic networking tools (nc, telnet) are also missing inside the images.Solution: create a custom Docker network in docker-compose and connect both openldap and phpldapadmin to it. Inside the network use port 389; for external access, use the mapped port.Step 3. phpLDAPadmin IntegrationProblem: phpLDAPadmin expects to connect to localhost:389 by default.Solution: configure environment variables in docker-compose.Intermediate ResultOpenLDAP and phpLDAPadmin are up and running in Docker. Internal networking and port mapping are configured.You can now add test users via GUI and prepare LDAP for SCC → IPS integration.Connecting SAP Cloud Connector (SCC)In SCC, create a new connection for your BTP Subaccount using LDAP protocol, pointing to localhost:13890.Back-end TypeProtocolInternal HostVirtual HostPrincipal TypeNon-ABAP SystemLDAPlocalhost:13890ldap:389NoneImportant: your Subaccount must have the Connectivity service plan enabled in SAP Cloud Identity Services. This allows IPS to reach on-prem systems via SCC.After successful setup, BTP Cockpit shows something like:Exposed Back-End Systems (SCC Location ID)ldap:389LDAPNon-SAP SystemAvailableConfiguring Identity Provisioning (IPS)In IPS, create an LDAP source according to the usual SAP Help documentation. You can use default Transformations here. Key detail: the LDAP user object must contain the mail attribute. If not present, IPS will skip the entry. Even the two default users shipped with the OpenLDAP container are enough to test the provisioning chain.End-to-end check:LDAP → SCC → BTP → IPS → Identity DirectoryConclusionUsing containers makes it extremely fast to spin up a fully working LDAP provisioning scenario for SAP BTP. This approach is safe and easily reproducible also for testing transformations and mapping without touching a production corporate directory.P.S. Below you can find my docker-compose.yml file as a reference for your own setup:services:
openldap:
image: bitnami/openldap:latest
container_name: openldap
environment:
LDAP_ADMIN_USERNAME: admin
LDAP_ADMIN_PASSWORD: password
LDAP_PORT_NUMBER: 389
networks:
ldap-net:
aliases:
– openldap
ports:
– “13890:389”
– “16360:1636”