Using this form of user authentication will alleviate headaches for you, the security team, and the end-user by reducing the number of user credentials and providing a central source of user names.

Basis and Security:  They are typically treated as opposite sides of the same coin. A lot of companies will put the two of them together under one technical lead. As Basis Administrators, we can’t help but pick up some security knowledge, even if we don’t want to. Part of the Basis/Security symbiotic relationship comes from Basis having to configure things for Security purposes. Centralized User Administration (CUA) is a great example of this. Basis configures the connections and the main CUA server, so that Security can have a single point of user and role administration for the ABAP stack.

What about Java? Java requires the same level of user administration, and, with Enterprise Portal using Employee Self Services/Manager Self Services (ESS/MSS), could possibly have the largest user base of any SAP instance in a company’s landscape. Should the security team be forced to manage users and groups on each individual instance? A perfectly good question to which we Basis administrators have an answer. In short, no.
The Java stack has the ability to tie directly into Active Directory (AD). We can set it as the source database for the User Management Engine and allow the Security team to assign roles based on AD groups. This will also alleviate some stress on the end-users by removing another set of credentials they have to remember.

The Java stack has the ability to tie directly into Active Directory (AD).  We can set it as the source database for the User Management Engine and allow the Security team to assign roles based on AD groups.  This will also alleviate some stress on the end-users by removing another set of credentials they have to remember.

The steps illustrated below assume a working understanding of structures in Active Directory and the options under “User Management” of the SAP Java Stack.

As with any changes you apply to any of your instances, make sure you have a good and recent backup of both your database and file system of the target instance. Also, if you already have some security configuration in place, these changes will erase that configuration.

Open a web browser and navigate to https://<hostname>:5xx00 where <hostname> is your Java instance host and “xx” is the system number.  Click on the “User Management” link.  Log in as someone with full administrative privileges.  Once in “User Management” click on the “Configuration” button towards the top of the page.

You are now seeing all the tabs related to UME configuration. The first tab is open by default, “Data Sources”. Click the button labeled “Modify Configuration”.

In the “Data Source:” drop-down, select “Microsoft ADS Read-Only (Flat Hierarchy) + Database”. Click the “Save All Changes” button.

Select the “LDAP Server” tab. Click the “Modify Configuration” button. The fields under this tab are specific to each organization:

• Server Name: <Windows Domain Controller (DC) to be used for authentication>
• Server Port: <Port on which the DC is listening for AD requests.  389 is the default>
• User: <Service user with read access to AD>
• Password: <Password for service user entered above>
• User Path:  <Highest level in AD the service user is visible>
• Group Path: <Highest level in AD groups can be seen.  Usually the same as <User Path>>

Only check “Use SSL for LDAP Access” if that is the security policy of the company. This requires some extra configuration not covered in this blog post.

Check “Use Unique Attribute for UME Unique ID”. In the field enter “sAMAccountName” (without quotes).

Once all the fields have been filled in correctly, click the “Validate Configuration” button. You should then see “Connection test successful” with a green check beside it appear towards the top of the page.

Upon a successful connection test, restart all nodes. When the system is back up, log back into User Management as Administrator. Do a search on your username and verify that the Data Source is “LDAP”.

At this point, you have successful configured the UME to use Active Directory (using the Lightweight Directory Access Protocol) as the user store. You may now provision the proper access to the necessary group(s) by assigning roles to AD groups instead having to rebuild those groups in Java.