Skip to Content

        Client’s LDAP directories is connected to

NetWeaver Portal 7.0 but since username’s in LDAP directory are more than 12

Chars, it will be problematic for Users having name with more 12 chars to

establish SSO between Portal and R/3 System. To make the SSO possible, User

Mapping was performed on Portal Side. My blog demonstrate the steps to achieve


Clients LDAP Directory is connected to NetWeaver Portal 7.0, to access the

Portal, but the R/3 System contains User-ID with different names for the same

Portal User say for e.g.: if is the Corporate Mail ID for a User,

User uses “abc” to login into portal, but “abc” is having

different Username (say “LMNO”) in R/3 System, in that case there was

a need for User Mapping when the User connects for some information to R/3

System via NetWeaver Portal say for JCo Destinations we use Tickets or for

Transaction iViews or IAC iViews or for BSP applications or to Pull the UWL workitem

in Portal.

Because of Username length restrictions in R/3 system and since there are large

number of Users already created in LDAP directory, it was not possible for

client to change username whose length are greater than 12 Chars.

The possible solution for this is to create a Custom Attribute in LDAP (in our

case it was Microsoft ADS), which will help to store R/3 username against each

user in LDAP. (Custom Attribute is created by LDAP Administrators not by Portal


In my blog, I will not discuss on “How to configure LDAP in Netweaver

Portal”, already wonderful blogs are available on SDN Blogs for the same

which helped me too, to configure LDAP with Portal. My blog will focus mainly

on “User Mapping using the Custom LDAP Attribute to Login in R/3


Note:- Before proceeding further, make sure that LDAP (ADS) Administrator had

created a Custom User Attribute in LDAP and also assigned the values, to make

it more clear:- If Mail ID – ““,

then for this user there will be a custom user attribute in LDAP for which

value “abc” is assigned, so that while Login into portal user will

enter “abc.lmn” as

username but once logged into portal for any access to backend R/3 System,

Logon Ticket will replace abc.lmn with *abc *value so SSO will automatically login into the

R/3 system without asking the user principles again. (Attributes discussed in

more detail at end of the blog.)

In order to achieve this, First of all, Login into NetWeaver Portal with Super

Administrator rights, go to System Administration ->

System Configuration –

UME Configuration, here in Data Sources tab, download UME Configuration

file (for e.g.:-dataSourceConfiguration_ads_deep_readonly_db.xml) on your local

machine.*                2. *  Define the attribute mapping from the logical attribute REFERENCE_SYSTEM_USER to the physical attribute that actually stores ABAP user ID in your LDAP directory i.e. we need to mention the attribute physical name given in our LDAP directory. In our example employeer3id*                  3**. In our case, the Custom User attribute while creating was belonged to Class “person*”, so we have to explicitly specify the class so as to access Attribute value. 


        In following example, *person *object class contains *employeer3id *attribute, which contains the user’s ABAP user ID.</p>

<p>          …</p>

<p>           <dataSources></p>

<p>              …</p>

<p>               <dataSource id=”CORP_LDAP” …></p>

<p>                …</p>

<p>                    <privateSection></p>

<p>                           …     </p>

<p>+                          <ume.ldap.access.auxiliary_objectclass.user>+</p>

<p>+                                      person+* *

+       +


    • Before restarting Server Nodes, there are 2-more

Properties need to be changed via Config Tool on Server in Menu File ->

Configuration Editor of Config Tool.

ume.usermapping.refsys.mapping.type to

value  attribute – 

This property defines that the UME gets the user’s ABAP user ID from the LDAP

directory in the logical user attribute REFERENCE_SYSTEM_USER.

ume.r3.mastersystem to value UME Internal Reference System –  This property

is set to allow users to access all ABAP systems in which they have the same

user ID as in the ABAP central instance of the Enterprise Search appliance

using logon tickets.

     After doing changes in

XML file and values in the properties of Configuration Editor in Config Tool on

Portal Server, restart Server Nodes and test configuration by accessing a

transaction iView, you will find that inspite of Portal Login name and R/3

UserId different, the SSO worked and didn’t asked for any kind of

Authentication information.</p>


The values in LDAP needs to be maintained carefully because if wrong UserName

is given to some user it might expose the System to User with some other persons


<p>+Note: –

To edit XML File, to the point and exact Input is required for User Mapping.

The Attributes and Class Name need to be communicated properly, because the

Class and Attribute Name are case-sensitive as well as space-sensitive.+</p>

<p> </p>

<p>*What is attributes

in LDAP?*</p>

<p>Attributes are characteristic of an object

(person, thing, etc.), In LDAP, all User Account are created wherein,

attributes for a User Account is username, firstname, lastname, emailid,

telephoneno, to make it clear in XML way see the below code</p>

<p><user><br />

    <username>XYZ.LMN</username><br />

    <firstname>XYZ</firstname><br />

    <lastname>LMN</lastname><br />

    <emailid></emailid><br />

    <telephoneno>123456789</telephoneno><br />

    <department>SAP Systems</department><br />

    <designation>SAP Netweaver

Consultant</designation><br />


<p><br />

<person><br />

    <employeer3id>xyz</employeer3id><br />


<p>On portal side, if you go carefully through

config file written in XML language, in this file Initially all Logical

Attributes are created which are used by Netweaver Portal for its internal use.

Physical Attributes of LDAP are mapped to Logical Attributes of Portal and with

help of this mapping all User Attribute related values stored in LDAP are

available on Portal for usage.</p>

<p> </p>


-* As a POC (Proof of

Concept), please find below image wherein you can see that, I logged into

portal with test username “Abhishek.Singh” but while accessing R/3

Systems, SSO picked up mapped username “222222” to login into R/3

Systems.</p><p>!|height=500|alt=Proof of Concept for User Mapping|width=667|src=|border=vertical-align: middle; border: 1px solid black;!</body>

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Former Member Post author
      Hi Michael,
             Security? – I guess if Mapping is appropriate and Roles or Authorizations are given properly, I am sure that it will not cause any problem. If, wrong mapping is done between ADS Username & R/3 System username in ADS Directory, then definitely it will lead to security issues since SSO picks up mapped user value and connects to R/3 System.

      “Are you really happy that your AD admins won’t setup a user mapping to an inappropriate super user?” – Can you please elaborate.


      1. Former Member
        As an example, your AD administrator could set the AD field so that their own AD user gets the SAP id of a Basis person with sap_all. They could then do something dangerous in the SAP system and then remove the AD mapping…
        1. Former Member Post author
          Hi Michael,
               I accept in that case, If the ADS Admin had some wrong intentions then definitely he/she might mess up with the system and then change the mapping. But in that case, Clients need to regularly audit all these mappings in order to ensure secure System Landscape.
               But, Michael is there any solution to the concern you expressed, because if it is not secure then definitely there must be some way to make it secure, surely without using any Third-Party Vendor tools.
               I have to check with ADS Admin about generating automated logs of User Access and Information Change History.
          1. Former Member
            My personal opinion is that user mapping is generally a hack. Yes, the SAP username is shorter than the AD username, but why not issue everyone an AD username that is going to be unique long term? For example, rather than have Michael.Nicholls as a username, I should be issued a unique ID that is never reused and that can map to my “real” name. People change their names for religious or societal reasons, and their userename should not have to change when this happens.

            Of course you can have audit logs etc on the AD, but to me this is not a long term solution…

            1. Former Member Post author
              Hi Michael,
                 As you said generating Unique-ID in both systems will help in solving problem, but problem is, Client were I implemented, they are not ready to change existing ADS User-Ids created, citing Communication Overhead reason they have to communicate change to 3000+ ADS users in organization.


              1. Former Member
                They can always blame SAP!

                Realistically there will be problems later on (what happens when a second person joins the organisation with a username that already exists?) so it might be better to bite the bullet now rather than delaying it…

  1. Former Member

    Dear Tushar Shinde,

    Can we instead of creating a custom attribute use an existing attribute of AD which is not used e.g. FAX etc. and store the R/3 username in it?

    1. Former Member Post author

      Hi Tariq,

      Yes that is absolutely fine, but then that field should be available at SAP End as well in XML Mapping.

      Also you need to ensure if tomorrow that field is required you need a restructuring at both ends.

      Please prefer creating a custom field, I am sure it is not that complex or time consuming to add a custom field in Active Directory Schema.


      Best Regards

      Tushar Shinde


Leave a Reply