CUA and LDAP Integration: Questions

[Former Member]

I have a few questions on implementating CUA with ldap integration.

All SAP systems in our landscape are R/3 4.6C. I want to integrate these systems with microsoft ADS. The issue with R/3 4.6C is the release doesn't integrate with LDAP directly but through a SAP Web AS. I am thinking of implementing a SAP Web AS 6.40 to integrate with the ldap (MS ADS 2000). I want to set this system as the CUA server for which each R/3 4.6C system will be its child/CUA client. This way all users needing access to R/3 4.6C CUA client systems should provide their domain credentials to login.

I want to authenticate all users through the LDAP datasource so if a user is locked in MS ADS, they will not be able to login in SAP. How does the synchronization between the CUA server and ldap work? Will the CUA server store user information in its own database which it will synchronize with ldap or is it direct authentication via LDAP? If the link between the CUA server and ldap server is broken, will users till be able to login?

If anyone has implemented such an infrastructure or has knowledge on this, any help would be greatly appreciately.

[tim_alsop]

Fahad,

What you are trying to achieve is very common, but in my experience it is not common to implement this solution using LDAP due to the way the SAP app servers support different authentication methods, and also for security reasons. Instead, the Kerberos protocol is used since Active Directory uses Kerberos for authenticating users at the workstation. You can therefore use the fact the user has already authenticated, use the credentials issued by AD and provide the user with SSO when logging onto SAP applications. The Web browser can be used to logon to SAP and also SAP GUI or any app which uses SAP APIs (e.g. JCO or RFC) - all can be made to use the credentials from the workstation, already available. This means there is no password syncronisation is required, and no communication between SAP server and ADS during logon is required. Also, with SAP GUI logons you can improve security, by encrypting communication session and providing data integrity between SAP GUI on Windows and SAP app servers on the network.

The above solution also works well with CUA, since CUA will ensure that each SAP app server has the required mapping information (maintained using SU01 and stored in USRACL table) to map the Kerberos id of user at workstation onto a SAP user which will determine role/profile ...

If you need more info on this, I suggest you search this SDN forum as there are many other similar posts that I have responded to, or ask and I will explain some more.

Take care,

Tim

[Former Member]

Tim,

Thank you for your reply. Our environment is a bit different. Our dev and test systems reside in the development domain. Our staging system resides in the staging domain and the production system resides in the production domain. Apart from these three domains (development, staging, and production), there is the client domain which all users log into. There is no bi-directional trust between the production domain and the development and client domain, nor is their any bi-directional trust between the staging domain and the development and client domain. If a user needs access to the SAP system, they need to log into the client domain via their workstation pc, open the sap front-end logon and provide their user credentials to log in to the system. Currently the users that require access to the SAP systems are stored in the SAP database as well as the system's domain. I need to authenticate these users via the system's domain. So the users that need access to the production system will get authenticated through the production domain.

This is why I choose to implement CUA. .

Message was edited by:

Fahad Shafi

[tim_alsop]

Fahad,

It is important not to confuse authentication domain with network domain (e.g. domain used for network address of server).

Just to make sure I understand, lets take an example of a typical user in your company. Do they have a user account in client domain as well as in production domain ? Also, do you have one way trust between domains ?

If I understood correctly then a user normally logs onto workstation using client domain, and then you want to use different domain to authenticate the user to the SAP apps depending on whether the SAP app is a production, dev or test system. Is this correct ? If so, this implies that the user might have 4 userid's and passwords to remember, or did I missunderstand ?

Thanks,

Tim

[Former Member]

Tim,

Yes you understood correctly. All users exist in the client domain. If a user requires access to the production domain he/she will need to be created in the production MS ADS. Yes there is one way trust (arrows depict flow of communication):

production domain --> client domain

production domain --> development domain

staging domain --> client domain

staging domain --> development domain

You are correct, the user does have 4 user IDs for each domain to remember. We follow a strict naming convention, the adminstrators assign the IDs but yes they must keep track of each password.

[tim_alsop]

Fahad,

If you setup your production SAP app servers to use a principal/key from the production domain, when a user logs onto a workstation using an account in the client domain they will be able to authenticate to the production app servers without re-authenticating - this is possible due to the fact that production domain has one way trust with client domain, so it trusts that the user in client domain has authenticated, and trusts the cross-realm Kerberos TGT issued by client domain. The SAP system in production domain would then map user1@CLIENT-DOMAIN to a SAP user found in the production SAP user store, e.g. USER1 (via info in USRACL table).

- Is this what you want ? e.g. your users will get Single SignOn, but they will not be required to authenticate to production domain using the account called user1@PROD-DOMAIN. Instead, they will only authenticate to client domain when they first logon to their workstation.

If the above is not what you want, then it sounds like you need a solution which asks the user to authentication when they logon to each SAP instance, as they select it in SAP Logon, and the domain they use to authenticate will be based on which SAP system they logon to ? In this case you will be ignoring the fact that the user has logged onto their workstation using an account in the client domain.

- e.g. user logs onto workstation as user1@CLIENT-DOMAIN, then they start SAP Logon, and select production SAP system, and press logon button. Then, they will be given a new SignOn screen where they can enter a valid account name and password for a user in the production domain. When they press enter, if the account name and password causes MS ADS to issue a valid Kerberos credential, then this can be used to log them onto SAP and be mapped onto a SAP user in the production SAP system.

Please let me know if I am getting close ?

Thanks,

Tim

Thanks,

Tim

[Former Member]

Tim,

the second option is what I am looking for, single sign-on is not an option for us.

[tim_alsop]

Fahad,

Thankyou. I thought you were not looking for SSO, since you are happy for your users to have multiple IDs and passwords, but you want them all in MS ADS domains instead of in SAP db.

The second option was provided since it describes exactly how our product works. I represent a vendor called CyberSafe, and we specialise in providing solutions which use MS ADS authentication with SAP apps. Please email me if you are interested to evaluate our products and get the functionality you requested. Alternatively you can check out our website at <a href="http://www.cybersafe.com/links/snc.htm">this location</a>

If you are wondering if what you are trying to achieve is possible using standard SAP solutions, then I am afraid the answer is that it is not, so you need to consider a third-party product such as ours to help you meet your needs.

PS. We can also offer the exact same functionality described in option 2 for users accessing SAP apps via Web browser. We do not just support SAP GUI.

Regards,

Tim

[Former Member]

Tim,

CUA and its integration with LDAP should be sufficient for the second option. I just had these initial questions which I ask in this forum:

How does the synchronization between the CUA server and ldap work? Will the CUA server store user information in its own database which it will synchronize with ldap or is it direct authentication via LDAP? If the link between the CUA server and ldap server is broken, will users till be able to login?

[tim_alsop]

Fahad,

I understnad that the sync between SAP and ADS via LDAP protocol is for user information, but not passwords. This is because MS do not expose passwords or hashed passwords via LDAP protocol. This is why using Kerberos is a better option.

I am sure if anybody else is aware of a way this can be done they will respond to this post, but I think you will find that the LDAP sync in SAP will not do what you want.

Thanks,

Tim

[Former Member]

Tim,

Thank you for the information. Is it safe to assume that if a user is locked in MS ADS, they won't be granted access in the CUA that is synchronized with MS ADS?

What if the link between CUA and MS ADS is broken, will the users still be able to login to CUA and thus the CUA clients?

[tim_alsop]

Fahad,

If you use the SAP LDAP sync then the only info from AD which will be synced is info such as user name, address etc. Any authentication related info, such as whether the user has been locked due to invalid passwords, or locked via an adminstrator will not be synced with SAP.

However, if you use Kerberos to authenticate with AD, and also use Kerberos for auth with SAP, when a user is locked in AD they will not be able to signon to SAP, and this will be immediate. e.g. when they are locked for some reason, if they try to logon to SAP a fraction of a second after this they will be denied access. There is no need to wait for any background sync to occur.

If you are using SAP LDAP sync, then this is completely complementary to the solution I have described using Kerberos to authenticate to SAP. In this case authentication does NOT require any connection between SAP and ADS. The SAP LDAP sync solution will only sync non-authentication related information.

In my experience customers use the LDAP sync provided by SAP so that when a user is added to ADS, this user gets added to SAP, but since it is not possible to sync the password - for a new user a default password needs to be set during this sync process. if you need to allow users to authenticate using ADS passwords then you need to use Kerberos.

I know this is complex, so I hope I have helped you understand what options are available. If anything is not clear, please let me know and I will try and explain differently.

Thanks,

Tim

[Former Member]

Tim,

Thank you for the response, do you have any documentation on using kerberos to authenticate with AD? I don't know how this will work with our infrastructure since users don't directly log into to the SAP system's domain. They log in to the client domain and not all users in this domain have access to the systems, only the functional users and administrators have access.

[tim_alsop]

Fahad,

As I mentioned in an earlier post, our company provides a product which does this for you. The product is installed on each workstation and this part of our solution will authenticate the user when they logon via SAP Logon, and the credentials issued by ADS when the user logs onto their workstation will be ignored (e.g. the client domain credentials). The credentials obtained when they logon to a SAP system will be used instead. Our software also installs on the server to provide a secure connection between workstation and server, and so that SAP app server supports Kerberos authentication via our product.

The documentation for our product can be provided if you are intersted to evaluate our solution. To arrange this you need to contact me offline from SDN. I can also arrange a conf. call with you to discuss further, or demonstrate our solution working the way you want it to.

Regards,

Tim