SAP – Active directory integration for shared workstations
In the new modern SSO world where most of the companies choose SSO based login to their workstation/applications in various ways.
There are certain big companies around the world face a common challenge where they want to integrate Active Directory based login to SAP ERP system but the user id in AD is more than 12 characters which cannot be accepted by SAP. Also in very few industrial scenario’s the end users share a common workstation with single windows AD based logon but use individual login ID for application logon. In this case the below are the standard solution that can be used to mitigate these scenario’s.
- The easiest solution is to keep the SAP id and AD different and use Kerberos based SSO login mechanism where map the UPN as email id for the user in SAP with the AD SAMACCOUNTNAME.
- Introduce a SAP JAVA portal system where it accepts both SSO or Non-SSO based AD integration where the user id with 12 character restriction is not there. However we need to enable user mapping between JAVA to ABAP system since both systems user id is different. Another challenge is each time the user has to download the SAP GUI shortcut from the JAVA portal and need to double click it for login, (its a tedious process and bad user experience).
- We can also introduce SAP IDM here but we will face the same difficulty as the end ABAP system does not accept more that 12 characters.
However all these scenario’s will not work on common workstation login (except JAVA portal based – bad user experience).
Fortunately we have a standard SAP solution to this problem using SAP Secure Login Server.
The Secure Login Server is a central service that provides X.509v3 certificates (out-of-the-box PKI) to users and application servers. We can use secure login client software installed on the workstations to create handshake between SAP and the authentication server.
Using Secure Login Sever we can even create multiple logon scenarios like with and without SSO using the same infrastructure and different authentication server at the backend (interesting right ?) .
In this blog i am not going to explain how to install & setup SAP SLS (Secure Login Server). We have many SAP blogs which already explains the installation and configuration steps of SAP Secure Login Server.
A quick intro into SAP Single Sign On 3.0 | SAP Blogs
SAP Secure Login Server – your own CA on Hand … | SAP Blogs
i am going to cover the steps involved post setting up SLS server and how to integrate a SAP ABAP system with SLS which should provide both SSO and non SSO based logon mechanism.
Lets have a quick look on how the Environment Using Secure Login Client and Secure Login Server works.
The Secure Login Client is responsible for the certificate-based authentication and Kerberos-based authentication to the SAP application server.
The Secure Login Server is the central server component that connects all parts of the system. It enables authentication against an authentication server and provides the Secure Login Client with a short term certificate. You can set the initial configuration and administration in the Secure Login Administration Console. The configuration data is stored in the database and can be displayed using the J2EE Engine GUI Config Tool in the path Secure Login Server.
The Secure Login Server provides authentication profiles to the Secure Login Client, Secure Login Web Client, or to the application server. It allows flexible user authentication configurations (for example, which authentication type should be used for which SAP application server).
The following authentication methods are supported by SAP Secure Login Server:
- Microsoft Active Directory Service (ADS)
- RSA SecurID token (via RADIUS)
- ABAP-based logon
- SAP NetWeaver AS for Java User Management Engine
- SAP NetWeaver AS for Java SPNego3.2.2
In this example i am going to cover the important steps involved to connect Microsoft Active Directory (ADS) with SAP secure Login Server and create an authentication mechanism without SSO on a shared workstation and with SSO on a normal workstation using the same setup and different secure logon profiles.
Below are the systems involved for the explanation.
- Active Directory server 2019 (Domain: tlabh.com)
- SAP NetWeaver 7.5 AS ABAP
- SAP Secure Login Server (SAP SSO 3.0) running on AS JAVA NW 7.5
- Windows 10 workstation (Users: common, User1 & User2)
Once we have installed and setup the SAP SLS ready, we need to setup the SLS server with Root CA configuration and issue an entry for “SSL Sub CA”
Once created we need to go to SSL configuration page in NWA and in the server identity in the edit mode click on the button “Copy Entry” and the newly created SSL server certificate to the Secure Login server.
Remove any other default server Identity certificates (like ssl-credentials) and keep only the new server certificate.
Restart ICM or whole JAVA instance once saved.
Create two Authentication Profiles, one for the SSO based login and Another for Non-SSO based login.
Open the SLAC page (Secure Login Administration Console), in the “Profile Management” tab select the “Windows Authentication (SPNEGO)” profile and click on “copy to New Profile” button to create a copy of the profile and provide your desired name. Here i am creating “UME_Profile_No_SSO” profile for Non-SSO login and “UME_Profile_With_SSO” for with SSO login.
From the “Authentication Configuration” tab select the policy name as “basic”
In the “Enrolment Configuration” tab modify the hostname with proper FQDN and make sure “Automatic logout when last SNC session is closed” option is checked this is important. Optionally you can set “Inactive Timeout” seconds if required and save the profile.
Repeat the same steps to create another profile for with SSO (UME_Profile_With_SSO), the only difference here is do not check the option “Automatic logout when last SNC session is closed” and save the profile.
During the ABAP system SNCWIZARD configuration make an entry for X.509 credentials.
In the ABAP system create a CSR for the SNC SAPCryptoLib pse and sign the certificate from Secure Login Server “certificate management” section and apply the certificate to the SNC pse.
Make sure you add the SNC names for the user in SNC tab of SU01. In this case the SNC name for the User1 is like “p:CN=USER1000000012, OU=TLAB, O=TLAB, C=IN” and for User2 is like “p:CN=USER2000000012, OU=TLAB, O=TLAB, C=IN”
Add the desired profile to the Secure Login client. By clicking menu File –> options
Goto “Policy Groups” tab and enter the Secure Login Server host HTTPS url without any prefix and click on “Refresh” button then we should be able to see the default profile group is retrieved.
In this case i have added the Non-SSO profile to “SecureLoginDefaultGroup” and created a new group named “SecureLoginSSOGroup” for the SSO profile.
Make sure you keep the Secure Login server profile as default for applications.
With these settings we can logon to shared workstation with “common” user from Active Directory into the windows but we can use any other single user credentials to login to logon SAP where there will be a popup raised by Secure login client to enter AD credentials and once SLC finds the valid certificate than the user is authenticated.
With the same setup we can allow SSO based login for other workstations which is based on single user login by just modifying the Secure login group in the Secure Login client.
The Secure Login Server has introduced a variety of options that can be chosen and tuned as per needs for the customer. There could be a lot of other scenarios where Secure Login Server can be utilized and leveraged as per business needs.
I did a test and it seems the UME_Profile_No_SSO Policy Configuration Name "basic" uses "UME credentials (and not AD credentials)
So we need for that the user existing in SLS Java UME.
Our Profiles SPNEGO_SSO (to our WinAD) and SAML_SSO (to our own IDT) are configured without any user in SLS JAVA UME.
For shared Workstation, is it possible to configure a profile SPNEGO_NO_SSO with "basic" WinAD credential without defining the user in UME?
Yes, We can do that by changing the SLS - AS JAVA UME pointing to Active Directory. So that all AD users get synced with SLS and you can use the same Policy configuration.