Integrate R/3 System with LDAP

[Former Member]

We have multiple R/3 systems in our environment. Currently users have separate logins and passwords to access each of these systems through SAPGUI. This password is different from the corporate password. I want to know if there is a way to integrate R/3 systems with LDAP so that users can use corporate password to login to all these systems.

[tim_alsop]

Krishna,

Yes, this is possible, especially if the LDAP authentication server you are using is Active Directory. Please advise if this is the case, so that I can explain more, and refer you to other information available which will help.

Thanks,

Tim

[Former Member]

Hi Krishna,

Tims answers is a bit ambigiuos. You can not do it directly, as the SAP system does not permit to synchronize passwords. What can be done is using SSO (which is what Tim is referring to). There are a number of partners providing SSO capabilities for the SAP Gui. You can find the list in the <a href="http://www.sap.com/partners/directories/SearchSolution.epx">SAP Partner Directory</a> searching for 'Secure Network Communication (SNC)' as certification category.

Regards,

Patrick

[tim_alsop]

Patrick,

I hope you don't mind, but I wanted to explain why I responded to Krishna in the way I did.

I did not suggest anything which was suggesting this could be done directly, but thank you for giving the link to SAP partner directory. I know that SAP docs often refer to SSO when involving SNC and SAP GUI, but SSO is not always required by the SAP customer. Some customers like to authenticate each user who logs onto SAP using SAP GUI via. a common ID and password (or other form of authentication). Also, some customers like to use SNC with SAP GUI just for encryption and integrity of communications, so SSO is not required in this case.

Since Krishna didn't ask for SSO, I didn't mention SSO and didn't want to assume anything until my question about Active Directory was answered.

Thanks,

Tim

[Former Member]

Krishna,

If you have portal implemented you can use that as SSO launch pad.

You can have links created for each systems. The moment the user click on the link, he/she goes straight into session manager screen. You have to enable SSO between Portal and backend system.

Again users have to login to portal. You can get ride of this also if you have netegrity's siteminder, which can be integrated with active directory, so in the nutshell all you have to do is sign on to NT/ windows and you are all set.

Hope I did not confuse you.

[tim_alsop]

> You can get rid of this also if you have netegrity's siteminder,

> which can be integrated with active directory, so in

> the nutshell all you have to do is sign on to NT/

> windows and you are all set.

>

Nixon,

Can you explain the above in more detail please ? I am interested in how SiteMinder integrates with Active Directory ? Do you have any links to information which explain this level of integration ? I was under the impression that SiteMinder is normally installed on Web servers, e.g. on Windows servers, or external ITS server running ITS. Is the ITS PAS module the one you are referring to ?

Cheers,

Tim

[Former Member]

Tim,

Yes, you are correct - SiteMinder is normally installed on Web Servers.

As I said you need portal to do this. You can have the agent installed on Portal server directly or on a proxy server (if you are using one). I prefer it on proxy, as you keep you SAP server clean. SAP likes that way

Key here is to tweak authschemes.xml file to have header as default authentication.

The setup I worked on had apache server as reverse proxy. This is where we installed the agent, which infact enabled single signon to EP 6.0.

From EP 6.0 we had link for backend servers. Then we enabled single sign on between portal and backend system also.

There are lot of threads on how to open the gui in a new full window.

Hope this helps.

[tim_alsop]

Nixon,

Thankyou. Yes, this helps.

In summary - the Active Directory integration is provided because the Windows web server running IIS is using Integrated Windows Authentication to authenticate the user logged onto the workstation. This user is then put into a HTTP header variable, so that the SAP Header Variable login module can be used to determine the SAP user id to use.

- is this correct ?

Regards,

Tim

[Former Member]

Actually, the use of IIS is for Active Directory integration using NTLM. This method is "out" though - unless otherwise needed. In general, SAP are recommending the use of Kerberos for unauthenticated sign-on. Obviously the KDC infrastructure must be in-place as a prerequisite.

About the header variable, I am not sure what IIS Integrated Authentication does with the IISProxy but I don't think that it's like the header variable integration like SiteMinder or other EAM tools use.

When you use header based authentication - the browser hits the EAM, the EAM proves the user (VIA another mechanism against the AD or other), inserts the header (in the case of siteMinder it's SMUSER=) and then forwards the request onto the J2EE where the authentication stack receives and trusts the header, extracts the UserID from it and checks the group assignment from the user datasource. Finally, it relates the Group assignment to the role VIA role==>group mapping and the user sees their stuff.

That's it in a nutshell...

So to answer to your questions:

1/ Active Directory integration can be provided VIA IIS or Kerberos, both are based on the domain logon already done

2/ Header based logon is a different scenario but your guess at the process is basically right. The only difference is that the IIS doesn't use header based authentication. You can replace IIS with an EAM like Tivoli or SiteMinder.

Again, I hope that this helps. Clarity is important when understanding the options.

Kind regards,

Judson

[tim_alsop]

Judson,

See my comments below :

> Actually, the use of IIS is for Active Directory

> integration using NTLM. This method is "out" though -

> unless otherwise needed.

In fact, IIS supports Kerbeors and NTLM for Integrated Windows Authentication (if enabled in IIS security configuration). Unless you are running a very very old version of IIS and/or not using Active Directory as domain controller then NTLM is only available, so sine this is unlikely we generally assume Kerberos is being used when referring to Integrated Windows Authentication in IIS web servers.

> In general, SAP are recommending the use of Kerberos for unauthenticated

> sign-on. Obviously the KDC infrastructure must be in-place as a prerequisite.

Yes, the KDC is Active Directory.

> About the header variable, I am not sure what IIS

> Integrated Authentication does with the IISProxy but

> I don't think that it's like the header variable

> integration like SiteMinder or other EAM tools use.

With IIS proxy (which SAP do not support anymore) the IIS server authenticates the user using Kerberos (via GSS-API and SPNEGO protocol between browser and web server) and then the HTTP header variable populated by the IIS proxy is used by the NetWeaver login module. If products such as SiteMinder or other EAM tools, or IBM WebSeal etc. then these products will obtain the ID of the user from somewhere, and this might include taking the ID of the user who has authenticated using Integrated Windows Authentication (e.g. Kerberos).

> When you use header based authentication - the

> browser hits the EAM, the EAM proves the user (VIA

> another mechanism against the AD or other), inserts

> the header (in the case of siteMinder it's SMUSER=)

> and then forwards the request onto the J2EE where the

> authentication stack receives and trusts the header,

> extracts the UserID from it and checks the group

> assignment from the user datasource. Finally, it

> relates the Group assignment to the role VIA

> role==>group mapping and the user sees their stuff.

Yes, this is roughly correct.

> That's it in a nutshell...

>

> So to answer to your questions:

>

> 1/ Active Directory integration can be provided VIA

> IIS or Kerberos, both are based on the domain logon

> already done

I understand what you are saying, but "VIA IIS or Kerberos" suggests it is one or the other, but IIS is using Kerberos, or IIS might have another product installed which is authenticating the user, or it might be using Basic Authentication - in any case the ID of user is put into a HTTP header and this is used by NetWeaver to determine who the external user is, and then this is mapped onto a SAP user ID.

> 2/ Header based logon is a different scenario but

> your guess at the process is basically right. The

> only difference is that the IIS doesn't use header

> based authentication. You can replace IIS with an EAM

> like Tivoli or SiteMinder.

I am not sure what you mean by this. Surely when IIS has an EAM product installed it will be authenticating the user and putting the ID in the header.

> Again, I hope that this helps. Clarity is important

> when understanding the options.

Yes, I agree.

Regards,

Tim

[Former Member]

To answer the first question:

<a href="http://http://help.sap.com/saphelp_nw2004s/helpdata/en/0c/632441cd87a12be10000000a1550b0/frameset.htm">This doc should explain.</a> You still have to maintain the passwords on each system but you can use LDAPSYNCH and an Active Directory proposal import to the AD (to embed the SAP attributes into the AD schema). This can be done to the central CUA system. Then the CUA configuration distributes the ID's across each ABAP system.

If you do have an SAP Portal in-place on AS Java, SSO is the way to go and it can point to many backend AS ABAP systems making the problem of many systems and passwords a non-issue.

I recommend and have implemented Kerberos "unauthenticated" signon to the SAP portal (<a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/43/4bd58c6c5e5f34e10000000a1553f6/frameset.htm">Active Directory and a KDC</a>) and then SSO to the backend. This way we can integrate one screen for SRM, ESS, etc, etc, etc... (big list here). It's seemless and adding a third party in the middle is sometimes too much management :-).

If your requirements are to simplify access to the SAP R/3 backend, the SAP Portal path is a great way to go.

I hope that this helps,

Judson

[Former Member]

Missed the first URL:

http://help.sap.com/saphelp_nw2004s/helpdata/en/0c/632441cd87a12be10000000a1550b0/frameset.htm

and here is one other:

http://help.sap.com/saphelp_nw2004s/helpdata/en/95/49cb3a663bfc70e10000000a114084/frameset.htm

Regards,

Judson

[tim_alsop]

Krishna,

Did you get the answer to your question in this forum post ? If not, please let me know how I can clarify anything ? If you did, can you please award points ?

Thanks,

Tim