Skip to Content

Whenever your LDAP users (or users available in your Java system in general) are different from the users in your backend systems it is not straight forward to perform single sign on from the J2EE Engine to the backend system. Usually the SAPLogon Ticket (that is used for SSO from the J2EE to the backend system) contains the logon userid.
But the SAPLogon Ticket can do more. It can also contain one more user id that can be extracted and used by the backend system. So lets say you have your J2EE Engine connected to your Active Directory where you use the username holger. “Unfortunately” in your backend system the user id is “bruchelt”. The trick now is to not only include the userid “holger” in the SAPLogon Ticket created when logging on to the J2EE Engine, but also the username “bruchelt”. When you then try to access the backend, the backend take the second mapped username “bruchelt” and log you in. (unfortunately unlike in Java in the UME this cannot be changed: whenver the second username is available in the SAP Logon Ticket it will be used)
There are basically two ways to include this second username in your logon ticket. One is via an attribute in the ADS itself (which I personally find the perfect solution so that you have to maintain the userids only there) or in the UME (the benefit here is that you can do this without having to involve your ADS guys)

Username is taken/maintained from ADS

http://help.sap.com/saphelp_nw70/helpdata/EN/0b/d82c4142aef623e10000000a155106/frameset.htm

Setting in ADS

First of all the SAP username has to be maintained in some attribute for your user. In my example I take the attribute extensionAttribute1 and put here the username SAPUSER1:

image

 

Via the config tool change the dataSourceConfiguration file

Now I have to adjust the dataSourceConfiguration file that I am currently using. To check which file is currently in use, just open the config tool and go to UME LDAP data :

image

Then switch to the Editor Mode:

image

And go to cluster_data -> server -> persistent -> com.sap.security.core.ume.services and select the file you saw in the steps above:

image

Open this file and make sure that the REFERENCE_SYSTEM_USER is set as an attribute for $usermapping$

image


  
     
  

Then make sure that the REFERENCE_USER points to your field in ADS which contains the SAP username:

image

Finally make this ADS field available in the UME

image

To be able to see the mapped userID wie add REFERENCE_USER as an additional attribute go to cluster_data -> servcer -> cfg -> services -> Propertysheet com.sap.security.core.me.service

image

And add the field $usermapping$:REFERENCE_SYSTEM_USER to the ume.admin.addattrs field:

image

image

Then we change the reference system mapping type from internal to attribute:

image

image

Last step: define a mastersystem

image

image

If you do not want users to selfmaintain these attributes (which you probably do not want!) make sure to set:
ume.admin.self.addattrs  none
as well.

image

That should be it. When you log on to the J2EE Engine next time, it will also map the username stored in the ADS field extensionAttribute1 to the SAP Logon Ticket. This username can then be used when accessing other systems.

  

Username is taken/maintained in UME

If you do not want to / cannot maintain the SAP usernames in the ADS then this is the way to go.

Via the config tool change the dataSourceConfiguration file

Again via the config tool open the dataSourceConfiguration file that you are currently using.
Remove the following lines

  
image

And remove these lines:

image

Now follow all the steps mentioned above:

enable usermapping

image
 
To be able to see the mapped userID we add REFERENCE_USER as an additional attribute:

image
 
$usermapping$:REFERENCE_SYSTEM_USER

image

Then we change the reference system mapping type from internal to attribute:
image

image

Last step: define a mastersystem

 

image

image

If you do not want users to selfmaintain these attributes make sure to add:
ume.admin.self.addattrs  none
as well.
image

That should be it. When you log on to the J2EE Engine next time, it will also map the username that you have maintained for each user to the SAP Logon Ticket. This username can then be used when accessing other systems.

  

Links:

Single Sign-On to SAP Systems
– http://help.sap.com/saphelp_nw70/helpdata/EN/4d/dd9b9ce80311d5995500508b6b8b11/frameset.htm

To report this post you need to login first.

17 Comments

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

  1. Michael Nicholls
    but without some sort of audit I can see how both mechanisms can be abused. Auditting in AD is probably a little easier, so that later on someone can say “I wonder why Michael mapped his username to blah”. With the standard UME tools there is no obvious audit, so the same question won’t be posed…
    (0) 
    1. Holger Bruchelt Post author
      Hi,

      I fully agree. However, if you need usermapping (because you have two different userIDs in your system) there is no other way.
      An administrator of your HR system can also check all your data. Same with an ADS/Exchange admin. So “some” trust to the admins in your company has to be there.
      Of course I would only allow very few people to maintain these fields (in either ADS or UME).
      I think — I would have to doublecheck — that the security trace of the UME does show you if something on an userobject is changed – and by whom. So I think you should be able to monitor this in UME as well.
      Regards,
      Holger.

      (0) 
      1. Krishna Thallavarjalla
        Hi

        Excellent Blog Just In Time for me

        but need a small clarification do I need to create any Portal System and Map it to User Mapping of the UME Configuration or  where will the Users give there SAP User ID.
        How does it know which SAP System it has to send to and what does none specify fo Key ume.admin.self.addattrs.

        Thank you once again

        Regards
        siddi

        (0) 
  2. John Travolta
    Hi Holger,

    Great post.

    You say “… the backend will first try to authenticate the user “holger” – which is not working. So it checks the second entry “bruchelt” and that works just fine …”.

    My question is, what about users in J2EE Engine different from backend, but can conflict. For example:
    J2EE User     Backend User
    holger          bruchelt
    nicholls     holger

    The ticket for user holger contains a second entry bruchelt, but because backend always test the first entry, even if there is a second one, in this case, holger will enter in backed as nicholls.

    Is it possible to configure the backend to use the second entry, and only if it doesn’t exist, should use the first one?

    Regards
    John

    (0) 
    1. Holger Bruchelt Post author
      Hi,

      that is a good question. I know that in the J2EE you can configure just that (see Note 843061). For the ABAP system I have to check.

      Regards,

      Holger.

      (0) 
  3. Vijith Kumar
    Hi Holger,

    A good blog… We tried your first method and it worked with ease ……. Just one concern regarding the fall back thing which you mentioned in the blog.. You said that the backend system would first try to logon with the Portal user id and if it fails then the mapped user id …but when we tested the same it was always using the mapped user id to logon to backend even though the portal user id was there in backend …. Is there any configuration to be done so that iff portal user id does not exist in backend only then should it logon with mapped user id

    Regarding the second method you have said to use UME Internal reference system as the reference system.
    But how do we create a system object for UME internal reference system to do user mapping?

    Thanks & Regards,
    Vijith

    (0) 
    1. Holger Bruchelt Post author
      Hi,

      I have to research the first question. The second question with the “UME Internal reference system”: this is basically just a dummy value you must use in order to have a mapping possibility.

      Regards,

      Holger.

      (0) 
  4. Isvarya Bolisetti
    Hello Holger,

    your blogs on Kerberos and J2EE mapping helped me a lot.

    As discussed, for maintaining the ABAP user mappings in Portal database, the property ume.usermapping.refsys.mapping.type should be internal, not attribute.

    regards,
    Isvarya

    (0) 
  5. Scott Summers
    Thanks to share this, was very helpfully for me.

    But, Does it works on multidomain configuration??
    I’m trying to set as you explain, but i am finding lot of properties which I am not sure if I have to declare properties for every LDAP…

    Thanks a lot for this blog!

    (0) 
    1. Holger Bruchelt Post author
      Hi,

      yes, this should also work in multidomain configuruations. However, since there are several ways to setup multidomain, I cannot really tell you what you need to do.
      Maybe you can just start with one ldap and then work your way from there…

      Regards,

      Holger.

      (0) 
  6. Judith Leitner
    Hello Mr. Bruchelt,

    As we plan to make some changes in our Portal config and I’m new to all of this, your blogs user mapping and Kerberos have been very helpful but I still have some questions.

    Our portal is configured to use an LDAP directory as its data source and we are using Kerberos authentication with SPNEGO for SSO.

    We presently have 2 AD domains configured and the AD/Portal userid of each user is the same as the user’s backend SAP userid.  So SSO works smoothly.

    Now, we want to add a new AD domain to the configuration.

    The problem is that the in the new AD domain, the AD/Portal userids will be different from the backend SAP userids.  So we will need to configure user mapping.   We have decided to use an LDAP Directory Attribute to store the SAP userid.

    I understand that we should set ume.r3.mastersystem.uid.mode = 1   and we hope that this will cover the case when the LDAP Directory Attribute is not yet set to the SAP userid in the additional AD domain.

    My question:  Do we need to define the same LDAP Directory Attribute in the 2 AD domains which already exist in the configuration?  Or will   ume.r3.mastersystem.uid.mode = 1   allow SSO to the backend SAP systems to continue to work correctly for the existing domains?

    Another (maybe silly) question:   Is it possible to run the Wizard in “read-only” mode to see what was chosen the first time it was run?  Or is it always “update” mode?

    Thanks in advance for your advice.

    Kind Regards,
    Judith

    (0) 
    1. Holger Bruchelt Post author
      Hi Judith,

      I assume the already connect 2 AD domains would not use usermapping, but would instead use their existing samaccountname for mapping. Only the new third domain requires usermapping.
      If that is the case, then I don’t think there is an easy solution with your SPNego Login Modul (you mention the Wizard, so I assume you are still using the “old” SPNego Wizard.

      Having said that, I think the new SPNEGO Login Module might be a solution for you (see New SPNego login module – just around the corner with a lot of great comments and also https://service.sap.com/sap/support/notes/1457499).
      With the new Login Module you can configure the Mapping Mode and lookup for each domain individually. So you could use “no-mapping” for the 2 old domains, and a mapping via an LDAP attribute for the third.

      So I would recommend to first update to the new Wizard. Once everything is again working, you can configure the third domain and “play around” with it.

      If you want you can sent me an email and we can discuss furhter.

      Regards,

      Holger.

      (0) 
      1. Judith Leitner
        Hi Holger,

        We upgraded our development environment to the new SPNEGO and added our third AD domain to the UME configuration.  We configured usermapping because the userids defined in the third AD will be different than those in the backend SAP systems.  This works fine for most of our portal applications.

        But…  We have several BEX Web Application iViews (SAP NetWeaver 7.0 Format) defined and, when we try to access them with an AD user which is not the same as the backend BW user, the SSO does not work.

        In the Portal security.log, I can see the following entries (note that FDACLNT100 is our ERP 6 backend and BWDCLNT100 is the BW ABAP backend):

        “Info”,”2011-04-07″,”09:18:09:182″,”ABC123     | USERMAPPING.USE     | USER.AD_D30.abc123     |      | systemtype=[SAP_R3], system=[‘FDACLNT100’], uses strong encryption=[false], remote user ID=[extjleitner]”,”ABC123″,”/System/Security/Audit”,”/usr/sap/FDE/JC10/j2ee/cluster/server0/log/system/security.log”,”com.sap.security.core.util.SecurityAudit”,”sap.com/irj”,”uxfm502c.fabricom-gdfsuez.suez”,”Server 0 10_14308″,

        “Info”,”2011-04-07″,”09:18:09:811″,”ABC123     | USERMAPPING.USE     | USER.AD_D30.abc123     |      | systemtype=[SAP_BW], system=[‘BWDCLNT100’], uses strong encryption=[false], remote user ID=[(none)]”,”ABC123″,”/System/Security/Audit”,”/usr/sap/FDE/JC10/j2ee/cluster/server0/log/system/security.log”,”com.sap.security.core.util.SecurityAudit”,”sap.com/irj”,”uxfm502c.fabricom-gdfsuez.suez”,”Server 0 10_14308″,

        “Info”,”2011-04-07″,”09:18:10:199″,”ABC123     | USERMAPPING.USE     | USER.AD_D30.abc123     |      | systemtype=[SAP_BW], system=[‘BWDCLNT100’], uses strong encryption=[false], remote user ID=[(none)]”,”ABC123″,”/System/Security/Audit”,”/usr/sap/FDE/JC10/j2ee/cluster/server0/log/system/security.log”,”com.sap.security.core.util.SecurityAudit”,”sap.com/irj”,”uxfm502c.fabricom-gdfsuez.suez”,”Server 0 10_14308″,

        For the BW system, the remote user ID is set to “none”.  I imagine that this means that the logon ticket for BWDCLNT100 does not have the mapped userid, although the one for FDACLNT100 does. 

        What could be wrong with my configuration so that the logon ticket creation for the BW system is ignoring the usermapping?

        Thanks and Kind Regards,
        Judith

        (0) 
  7. Bishnu Priya Sahoo
    Hi Holger,

    I am entirely new to SPNego.I was going through all documments available but I am not sure whether SPNego can be configured in Portal where the UME is Portal database since this is the configuration in my dev system.

    It would be helpful if you can throw me some light on it.

    (0) 
    1. Holger Bruchelt Post author
      Hi,

      yes, SPNego will also work when the UME is configured with the database.
      I would highly recommend to take a look at the new SPNego login model ->
      New SPNego login module – just around the corner and https://service.sap.com/sap/support/notes/1457499

      If the usernames in the ADS and in the UME are the same, then configuration is pretty simple. If not, then you have to perform a mapping in the UME which is also no big deal 🙂

      Regards,

      Holger.

      (0) 
      1. Bishnu Priya Sahoo
        Hi Holger,

        Thanks for you reply.
        Actually Portal is running on NetWeaver 04S EhP1 (7.01) SP06 and the new SP Nego module applies for SP08 and above.So I will not be able to use it.
        But just to ensure,Will I still be able to use the previous SPNego module ?
        The User on AD and Portal database are same ,so we need not go for mapping

        Regards,
        Priya

        (0) 
      2. Bishnu Priya Sahoo
        Hi Again,

        Also in my case what is the resolution mode I will be using,I was just going through the Datasource Configuration xml for database ,there is no attribute like UniqueName etc which I can use for KPN Prefix.

        Regards
        Priya

        (0) 

Leave a Reply