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: 

EP6 and AD LDAP - Pointing the User Path to a Security Group

Former Member
0 Kudos

Hi experts,

Our company will be reorganizing its Active Directory LDAP structure (which we don't have much control over) similar to the following:

MyCompany (Root)

|_Production (OU)

|__NY (Security Group)

|___User1*

|___User2*

|__FL (Security Group)

|___User3*

|___User4*

|__CA (Security Group)

|___User5*

|___User6*

  • = User referenced from another domain. [These users are merely pointers/references to the actual user objects which reside in other domains]

We are currently testing this structure against EP6 using a flat hierarchy. However, we are unable to authenticate users.

Using the ConfigTool, we set the Group Path to the OU -> Production and User Path to the same OU -> Production. But we have no success authenticating.

We have tried varies combinations for the Group/User paths, as well as switching between the two hierarchies, flat and deep. But still no luck.

Basically, we'd like our User Path to point the Organizational Unit -> Production, which cascades into the referenced users.

We have searched all of SAP Marketplace/SDN and googled but came up with very little. Any help will be greatly appreciated.

Many thanks,

Mike

4 REPLIES 4

Former Member
0 Kudos

Before the restructure, are you able to authenticate right now? There are some LDAP tools you should use, outside of SAP, to make sure that the users path can be reached through the new LDAP setting.

0 Kudos

Hi Pat,

My apologies for the very late response. We managed to use a few LDAP tools to verify the users path.

In the end, we submitted an OSS message with SAP support. The outcome was the following: "We do not support any kind of pointers on the ADS." "A solution would be to use the global catalogue and to put these users in there."

In our case, we're not in a position to use/touch the global catalog. So, we'll just have to find an alternative approach.

Thanks,

Mike

0 Kudos

Michael,

If your requirement is to use Active Directory accounts to authenticate users to access the portal, I can provide you with a product which does this. The product consists of two authentication login modules, one of them uses Integrated Windows Authentication and the other displays a login screen and accepts a valid Active Directory account name and password before an SSO2 ticket is issued. The authentication protocol used by both products is Kerberos. Hopefully you are aware that Active Directory is actually a Kerberos authentication server, so the product makes use of this fact.

Please let me know if you are interested, and if you have any questions. If you would like me to demonstrate this product to you, please let me know and I can set up a web meeting to give you a demonstration.

Take care,

Tim

0 Kudos

Michael,

Some more info related to my last post :

When using Kerberos to authenticate with AD the OU of the user account is not required in the authentication request. Instead, the AD account name, domain and password are required. If the user account is in a different domain to the domain being used for the authentication request, then AD handles this by referring the client (where the request was sent from) to another domain where the actual user resides - this all happens automatically and without client side configuration.

I hope this info helps you to understand some of the advantages of using Kerberos to authenticate to AD instead of LDAP.

Regards,

Tim