Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Global Catalog + SSO

Former Member
0 Kudos

Hi all

We have a SAP NetWevar Portal 7.01.

We connected the UME to an Active Directory Global Catalog. Now, all the users in the AD forest are available in the portal and their user id's follow the next template:

Portal User Id = userid@domain-name

Therefore, most of the Portal user id's are longer than 12 characters.

We want these users to access backend R/3 systems with SSO (using SAPLogonTickets).

Nevertheless, as the Portal user id's are longer than 12 characters, they are not valid in ABAP systems.

Indeed, the SAPLogonTicket provided by the Portal has an empty user name (as explained in SAP Note 1159962).

Did anybody deal with a problem like this?

Is there any way to connect the UME to a Global Catalog an retrieve Portal user id's that do not contain the '@domain-name' extension?

Thanks in advance,

Jon

5 REPLIES 5

tim_alsop
Active Contributor
0 Kudos

Hello,

It seems to me that since you have chosen to make your portal userid's userid@domain format, this has introduced a problem with SSO2 tickets. if your users are known as userid in other SAP systems, e.g. in ABAP, why don't you use the same userid naming convention for users in all systems ? This would mean that a user can logon to portal as userid and when an SSO2 ticket is created to allow access to back-end systems, the SSO2 ticket will contain the correct userid.

This is how I have seen this done elsewhere. Typically authenticate user to portal using Active Directory / Kerberos / IWA, and once authenticated the user is given an SSO2 ticket which is stored in their browser and they can use this to access any other web enabled SAP systems that trust the SSO2 tickets created by portal.

Thanks,

Tim

Former Member
0 Kudos

Hi Tim

Thanks for your answer.

Yes, we considered this, but this is the problem:

- If we define "samaccountname" as the UME Unique Id, then we are getting all the users in the AD forest, but the Portal user id contains the '@domain-name' extension.

- If we define some other attributes (as "mail") as the UME Unique Id, then we are getting only the users of an AD in the forest; so this is not valid, in spite the user id's don't contain the '@domain-name' extension.

An attribute that provides all the users in the forest without the '@domain-name' extension would be the solution.

Thanks again,

Jon

tim_alsop
Active Contributor
0 Kudos

Jon,

I am not very familiar with using AD as UME, and using samaccountname within SAP. In my experience it is better to use ABAP user store in portal instead of using AD as UME user store. This avoids any issues like the one you are facing.

Thanks,

Tim

Former Member
0 Kudos

I think you should see this as a symptom of a sub-optimal strategy.

If you want to use the AD as the UME store, then it is better to first consolidate your systems into the same domain and harmonize the user naming conventions and convert the needfull using SAP's System Landscape Optimization service (not included in support fees) if required, and then tackle the portal.

There is an option to extract the user ID name from the logon ticket using verification filters, and then possibly issuing a new ticket - but I don't think it is scalable or would even work. Too complicated..

I would organize a meeting or little workshop with the AD folks and SAP program management at the same table and explain the constraints to them. Try to work it out from there with a plan.

Cheers,

Julius

Former Member
0 Kudos

Hi all

Finally we applied the following solution:

[Using an LDAP Directory for User Mapping with Tickets for SSO|http://help.sap.com/saphelp_nwce711/helpdata/en/0b/d82c4142aef623e10000000a155106/content.htm]

The portal user id's still contain the @domain-name extension, but the user id included in the SAP Logon Ticket refers to the user-id only. And so it works.

Thanks all for your interest,

Jon