Enterprise Directory based Single Sign On

[Former Member]

Hello,

we have a SAP landscape with SAP R/3 implementations and SAP CRM implementations. Its mainly SAP GUI based clients. What is needed is to enable Single SIgn On of the SAP GUI clients and authenticated against our LDAP compliant Enterprise Directory. There are various suggestions of SAP Shortcuts and Logon Tickets, ITS based solution. Also some SNC certified external products are suggested. Anyone having implemented such a scenario.

cioa/sanjay

[WolfgangJanzen]

I'm sorry to say but ABAP systems do not offer the ability to perform a password authentication against an LDAP server. Also, SPNEGO (aka "Windows Integrated User Authentication") is not supported.

But: if your ABAP application servers are running on Windows, then the (free-of-charge) SNC solution described in SAP note 352295 might be of interest for you. Otherwise you need to purchase a (certified) SNC solution by a software partner (see SAP note 66687).

Regards, Wolfgang

[tim_alsop]

> I'm sorry to say but ABAP systems do not offer the

> ability to perform a password authentication against

> an LDAP server. Also, SPNEGO (aka "Windows Integrated

> User Authentication") is not supported.

>

> Regards, Wolfgang

Wolfgang,

If the "LPAP Server" is in fact a Kerberos server (such as Active Directory), then this is not true. The Active Directory server is often referred to as an "LDAP Server" so I wanted to make sure this was clear to Sanjay, and avoid any missunderstandings.

Also, even if the LDAP Server which Sanjay is using is not Active Directory, it is possible that he is also using Active Directory to authenticate users when they logon to their workstations. So, with this in mind it is possible to implement Integrated Windows Authentication to allow secure authentication to SAP applications.

Also, you said that "Integrated Windows Authentication" is not supported, which is wrong because this is exactly what you get when you use SNC/Kerberos. So, what did you mean by "not supported" ?

Thanks,

Tim

[WolfgangJanzen]

> If the "LPAP Server" is in fact a Kerberos server

> (such as Active Directory), then this is not true.

Sorry to disagree.

The SNC libaries of SAP note 352295 offer both, support for NTLM and MS-Kerberos (notice: MS-Kerberos might not be interoperable with other Kerberos implementations).

> The Active Directory server is often referred to as

> an "LDAP Server" so I wanted to make sure this was

> clear to Sanjay, and avoid any missunderstandings.

Yes, quite often one actually refers to MS ADS when referring to "LDAP Server".

> Also, even if the LDAP Server which Sanjay is using

> is not Active Directory, it is possible that he is

> also using Active Directory to authenticate users

> when they logon to their workstations. So, with this

> in mind it is possible to implement Integrated

> Windows Authentication to allow secure authentication

> to SAP applications.

Sorry, but here you mix up things.

"Windows Integrated Authentication" is Microsofts proprietary SPNEGO implementation (or actually: SPNEGO is the publically released version of "Windows Integrated Authentication", see IETF RFC 4559) - and it does not only provide support for MS-Kerberos but also for NTLM.

But in general, LDAP servers do not provide support for Kerberos based authentication. Most of them only provide support for password based authentication ("simple bind", see IETF RFC 2251). "SASL bind" (cf. IETF RFC 2222) offers more choices, one of them is "GSSAPI" which then allows to use Kerberos V5 (RFC 1510).

> Also, you said that "Integrated Windows

> Authentication" is not supported, which is wrong

> because this is exactly what you get when you use

> SNC/Kerberos. So, what did you mean by "not

> supported" ?

See above: I've stated that the <b>ABAP</b> server does not support SPNEGO. The NetWeaver Java server does support SPNEGO (as of 6.40 with some SP), however. See also

Please differentiate between GSS-API and SPNEGO ...

SNC is also based on GSS-API.

Cheers, Wolfgang

[tim_alsop]

> Sorry to disagree.

> The SNC libaries of SAP note 352295 offer both,

> support for NTLM and MS-Kerberos (notice: MS-Kerberos

> might not be interoperable with other Kerberos

> implementations).

I was not refering to SNC libraries provided by SAP when I mentioned Kerberos and MS AD. As you know, I represent one of the vendors who provides commercially supported Kerberos libraries, that are MS AD interoperable and SAP certified. Anyway, I was trying to make it clear that if "LDAP Server" = "Active Directory" and since "Active Directory" is a Microsoft KDC, then it is possible to use the SNC solutions which are Kerberos protocol based with the LDAP Server. This is confusing because of the reference to LDAP, but I think you know what I mean ? Hopefully we are in agreement now ...

> Sorry, but here you mix up things.

> "Windows Integrated Authentication" is Microsofts

> proprietary SPNEGO implementation (or actually:

> SPNEGO is the publically released version of "Windows

> Integrated Authentication", see IETF RFC 4559) - and

> it does not only provide support for MS-Kerberos but

> also for NTLM.

Actually Integrated Windows Authentication ("IWA" for short) is the MS propriatory term used to describe the way a user is authenticated to an application, using Windows Authentication technology (e.g. Kerberos or NTLM). It is true that MS first implemented IWA in IE and IIS when Windows 2000 was first released, and since then other solutions have become available using the same approach, and recently described in RFC4559 (Note : Until fairly recently, this was not an RFC, but just an individual IETF draft submission from John Brezaq at MS, which was rejected by the IETF at the time of Windows 2000 launch). Anyway, the approach now described in RFC4559 is for HTTP only, and, and is often called "SPNEGO", but in fact SPNEGO is a negotiation protocol defined in IETF RFC4179.

Often people refer to SPNEGO, when they actually mean RFC4559, but in fact SPNEGO = RFC4179, and is certainly not specific to HTTP. The actual SPNEGO protocol is applicable to any use of GSS-API where negotiation of a security mechanism is required. The fact that SAP decided to name their JAAS logon module after the SPNEGO negotiation protocol doesn't help this confusing use of terminology and standards.

So, you should not confuse SPNEGO with the actual SPNEGO standard. Also, IWA is not a technology that is only applicable to web browsers. I think we are in agreement that LDAP Server often (not always) refers to Active Directory. Very confusing

Thanks,

Tim

[WolfgangJanzen]

@Sanjay:

That clarifies that you cannot use the SNC libraries (provided by SAP) which are using the Windows SSPI. So far you have not confirmed that you refer to "MS ADS" when talking of "LDAP compliant Enterprise Directory". It's also not sure which kind of authentication is supported by that "LDAP compliant Enterprise Directory" (in case it's not "MS ADS").

@Frank:

Thanks for clarification (and moderation)

@Tim:

Well, in general we share a common opinion; we only differ in details. I was not aware that your "commercially supported Kerberos libraries" are "MS AD interoperable". As Frank correctly pointed out such interoperability is not assured in all cases. That's what an interested customer should clarify (=> supportability).

Theoretically "SPNEGO" (and "IWA") is not restricted to http - but practically it is. Same as SSL: in almost all cases it's used synonymously with "https".

SPNEGO is based on GSS-API, same as SNC. That's why there are those overlapping use-cases (which indeed is very confusing).

Let's talk plain:

SNC is used with SAP proprietary protocols (RFC and DIAG, DIAG is the protocol used by SAPGUI) which can be used to communication with ABAP servers. SNC is based on GSS-API v2. Third party security products which implement the GSS-API v2 can be used with SNC. A certification program (for SNC) exists.

ABAP servers (as of release 6.10) also offer the ability to communicate via http(s) with the client (directly, without any middleware like ITS). X.509 client certificates can be used for authentication (at ABAP systems). IWA/SPNEGO (in the http variant) cannot be used for authentication at ABAP systems (without the usage of an IIS, an external ITS and some PAS modules).

Cheers, Wolfgang

[WolfgangJanzen]

Oops - somehow my posting was stored twice.

Once is enough ... - I've deleted the 2nd one.

[tim_alsop]

Sanjay,

If your "Enterprise Directory" is in fact, Microsoft Active Directory then I suggest you use the Kerberos protocol since this is the same protocol used to authenticate your users when they logon to their Windows workstations, authenticating with Active Directory at this time. You will then be able to implement Integrated Windows Authentication and Secure SSO for SAPgui users, and have the option to improve the security of your connections to SAP applications (e.g. data integrity, session encryption). You can use Kerberos with SNC if your SAP servers are Windows using libraries provided by SAP (or from SAP partners), or from certified partners if your SAP server is on UNIX or Linux.

Thanks, Tim

[fralarsen]

Hi Sanjay,

It seems like Wolfgang and Tim have had some discussions regarding SSO definitions etc. ...

But I can't see that you have replied on the question regarding which platform your SAP systems is running on!?

To do it short - if you want to implement Secure Single Sign-On via SAPGUI - you have (in my opinion two options depending on your platform:

1. If you run SAP on Windows - SAP delivers a free solution for this based on Kerberos and AD. I have implemented this scenario at several customers without any issues at all. It is very simple to configure, but yet a stable and flexible solution.

2. If you run SAP on UNIX - you have to purchase a SAP certified SSO solution, since SAP does not delivers this. I recommend to use CyberSafe Trustbroker, since their solution is based on the Kerberos protocol and authentication against AD (or other KDC's). It is just as simple to implement as the SAP delivered solution - and I have great experiences with this vendor/solution on several projects.

If you run SAP on UNIX - you could also choose an open source or hardware vendor provided Kerberos solution, but since this is not supported by SAP, I do not recommend it.

If you have any questions regarding SAP SSO and/or SAP User administration & Provisioning, LDAP synchronization (Identity Management), I'll be happy to assist you - just provide contact details ...

Brgds,

Frank

[Former Member]

Hello All,

Thanks for these suggestions. Just to clarify the environment a little bit - We are using SAP installation on HP Unix 11i both for R/3 and CRM and the Enterprise Directory is Sun iPlanet Directory Server 5.2.

Regards,

Sanjay

[tim_alsop]

Sanjay,

I would first like to appologise for taking the discussion with Wolfgang slightly off subject, and discussing standards, and SPNEGO. I hope you found it useful/interesting anyway ?

Thankyou for providing more details on your requirements. I would now like to summarise the options available to you, and what we find other companies who have similar requirements have implemented :

Firstly, as you have heard - the SAPgui logon does not support LDAP authentication, and cannot support LDAP authentication. Instead, it supports SNC based authentication, and SNC requires cryptographic libraries implemented via a GSS-API interface, and installed on the Workstations and on your HP/UX servers. Since you are not using Windows servers for SAP you will need to contact a SAP partner who can provide you with SNC based SAP certified libraries.

The SNC and GSS-API standards provide a secure communciation between SAPgui and SAP application servers, and this session is secured using cryptographic keys. The keys used for the security needs to be issued by a "key server", and an LDAP server is NOT a key server, so LDAP auth is a much less secure method of authentication, compared to Kerberos or PK based authentication. You can use Kerberos (via SASL/GSS-API) or PK with LDAP, but this doesn't help much in your case.

Just so you can understand, if it was possible to use LDAP to authenticate a user via SAPgui, then the SAP server would have to receive a password from the user each time they logon a SAP system, and then contact the LDAP Server to check this password. This 'password checking' can be secured, but the problems with this approach are :

a) The users password needs to be passed to the SAP server so that the SAP server can check it. Having to pass the password across the network like this is obviously not very secure. There would be very little improvement on security of SAPgui logon compared to the normal method of SAPgui user authentication. Many companies are looking to improve security as well as provide SSO to users.

b) The user would have to provide their password each time they logon to a SAP system, so you would not get SSO, instead you are implementing "Common Authentication".

The above, is just for background understanding. As I (and Wolfgang) have both explained it is not possible to implement this method of authentiation with SAPgui, and you must therefore use SNC and a GSS-API library.

Our company works with many companies like yours who have similar/same set of questions/requirements so I am very used to this type of question. In these cases we have provided the following solution to the customer :

1. User logs onto their workstation using an Active Directory account and password (or another form of Active Directory authentication such as token card, biometric or smart card)

2. User starts SAPlogon, selects a system to logon to, and presses "logon" button. Then, using the identity of the logged on user, SNC is used to authenticate this user to the SAP system, and they don't have to enter any passwords.

3. If user needs to logon to other SAP systems in the landscape, they can do this also without having to provide their user name or password each time.

With this solution, there are no passwords transmitted across the network, and there are no passwords stored, so that they can be checked against an auth server. Instead, the authentication occurs when user first logs onto their workstation, and these credentials are used to authenticate.

You may be thinking, that the above will work for you, but what about your iPlanet server. As I have hopefully made clear, LDAP auth is not as secure as using cryptographic authentication, so SAP have not provided any way to use it with their products. However, you can synchronise the information in your LDAP server related to each user logging onto SAP with your SAP server, but you cannot sync the password that may be provided in the LDAP server. Effectively, you can use your workstation logon to Active Directory for authentication to SAP, and use your LDAP server to maintain user information which is not authentication related, and have the SAP user details automatically updated.

It is also possible to (but I am no expert on this) implement identity management solutions with SAP, so that users can be added to your directory, and automatically be added to your SAP system (if role determines this is required), and your user will also be added to your Active Directory server so that they can logon to your company network. Since the Active Directory authentication will be used to access SAP, everything required to give your users SSO is then implemented.

Sorry for the long post, but hopefully this answers most of your questiosn. If not, please let me know if I can explain anything further, or answer any related questions.

Regards,

Tim

[fralarsen]

To support easy user administration & Provisioning and provide SSO, I would recommend:

1. Implement SAP CUA (if not already in place

2. Implement LDAP import/synchronization of your SAP users from your Sun iplanet ldap directory

3. Since you use HP-UX - Implement CyberSafe Trustbroker SSO for SAPGUI

Brgds,

Frank

[Former Member]

Hello,

I need to clarify more probably - Windows users in our environment logon into the Windows systems and are authenticated against the Microsft Active Directory which is aligned with our SUN iplanet based Enterprise Directory Server. This is done to ensure a common logon for windows and several other LDAP compliant applications.

The solution from TIM is seemingly suitable now except that I need to clarify if the GSS API Library for SAP Application Server on HP Unix is provided by SAP or some external vendor and what are the best options.

cioa/sanjay

[tim_alsop]

Sanjay,

Thank you for clarification.

Since your SAP server is not running on Windows you need to contact a SAP partner. The solution I described, and libraries for HP/UX and Windows workstations + documentation can be obtained from CyberSafe (http://www.cybersafe.com). Please email <b><removed by moderator</b>

Thanks,

Tim

[WolfgangJanzen]

SAP only provides SNC libraries (SSPI wrappers) for MS Windows.

For other platforms you need to purchase a (SNC) partner product. Please clarify the interoperability issue if using different SNC products on client and server side.

There is a long list of certified SNC partner products - Tim has mentioned just one (sold by the company he is working for).

[tim_alsop]

> For other platforms you need to purchase a (SNC)

> partner product. Please clarify the interoperability

> issue if using different SNC products on client and

> server side.

I cannot speak of other products, only the products from my company (CyberSafe). We provide both client and server software, so that we can add new features to meet our customers needs (e.g. supporting users who are not logged onto a domain account, or using shared workstations), and we can also provide better support to our customers. For these reasons, we do not use, or support configurations where the customer wants to use the Windows SNC libraries provided by SAP.

>

> There is a long list of certified SNC partner

> products - Tim has mentioned just one (sold by the

> company he is working for).

My understanding is that many of the SNC partner products are using Public Key Cryptography, and if you are looking for a product which is using Kerberos so that you get improved integration with Active Directory the choice is limited.