SAP R/3 Authentication with Active Directory on Win2k server.

[Former Member]

Hello list ,

We are running SAP R/3 4.7 with WebAS 6.2 on Solaris and a Windows 2000 Active Directory domain. Our users access SAP in 3 ways

1) SAP GUI .

2) SAP BW

3) Travel & Expense - a java application that records users travel details and posts a transaction to SAP using the SAP userid and password.

Wish to implement SSO for all our users.

Some research we have done suggests

1) Using Kerberos for authentication. while it appears that microsoft krb 5 implementation will work only on windows servers, it is not clear how well are other krb implementations supported by SAP. OSS note # 150380 and link http://help.sap.com/saphelp_nw2004s/helpdata/en/44/0ebf6c9b2b0d1ae10000000a114a6b/content.htm

2) OSS note # 352295 suggest there could be some issue using KRB 5 shipped with unixes.

"All of the major Unix vendors seem to be shipping a version of Kerberos 5 these days. These implementations should be wire-interoperable with each other and with Microsoft W2K (not necessarily W2K3!), however they may not be interoperable with SAP's shared library interface to GSS-API v2 mechanisms."

3) There are some commercial solutions like - CyberSafe that provides krb based SSO at a fee. Has anyone tried this software ?

I have created an OSS ticket but we are still in a queue since 5 days already.

Has any one from the list implemented a similar solution ? What are the best practices and way to go for a robust solution.

4) Another option that we have is to start with user synchronization. Where in Users created in Active Directory get synchronized with SAP .

What is mandatory for us is that Users marked disabled in Active Directory should be blocked in SAP by synchronizing user information at regular interval. If anyone has implemented this solution I will appreciate if they give me some pointers.

Thanks in advance.

Harsh Busa

[WolfgangJanzen]

Well, you have asked multiple questions - so I'll have to provide multiple answers (not just one single one):

(1) SNC is the method of choice to enable SSO for the SAP proprietary protocols RFC and DIAG (used by SAPGUI).

Yes, for pure Windows landscapes (both, client and server) note 352295 provides a solution (SNC wrappers based on the Windows SSPI). For mixed environments (=> UNIX application servers) you either need to use (certified) SNC products on both sides (client and server) which you need to purchase. Or, if you are very experienced with Kerberos and willing to take the risk (of not being supported by anyone), you can try to setup a Kerberos-based SSO solution using various Kerberos implementation (of multiple vendors). Another approach could be: enable a UNIX system to utilize Microsofts ADS to verify Kerberos credentials (e.g. see <a href="http://www.vintela.com">Vintela</a>).

(2) ABAP systems are not capable for SPNEGO support (=> "Windows integrated authentication", using the browser)

(3) LDAP synchronization (available in ABAP) does not provide any SSO functionality; it's only about user master data (not logon data).

Regards, Wolfgang

[tim_alsop]

Wolfgang,

In your response to item (1) you said :

"Another approach could be: enable a UNIX system to utilize Microsofts ADS to verify Kerberos credentials (e.g. see Vintela)."

I just wanted to clarify this statement for anybody else who is following this forum post. The Vintela product, when used with SAP on UNIX is nothing more than a Kerberos GSS-API library, which can be used for SAP SNC. I also understand that the Vintela product has not yet been certified by SAP, but the CyberSafe product, which Harsh mentioned in his original post, is SAP certified, and include Windows libraries as well, not just UNIX libraries. You also mentioned that the Vintela product allows utilisation of the Microsoft ADS to verify Kerberos credentials, making this sounds special, but this is the same that is implemented with the other options you mentioned, e.g. A SAP certified SNC library, or the use of open source code on UNIX, will both utilise the Microsoft ADS to verify Kerberos crednentials. I therefore think there was no need to give a special mention of the Vintela product, when it is not providing anything more than you had already mentioned, when describing the other options available for UNIX and SNC/Kerberos libraries.

Thanks,

Tim

[WolfgangJanzen]

Tim,

you are perfectly right: that Vintela product is not certified (as SNC solution).

But you are not quite right regarding the separate treatment. The major difference between that product and the SNC certified products (such as CyberSafe, Entrust, ...) is: Vintela uses different SNC libraries on the client side (=> our Windows SSPI wrappers, see <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/352295">SAP note 352295</a>) and the server side (=> their own SNC library, not certified). And that is actually also one reason why that solution cannot be certified ...

Well, those Windows SSPI wrappers provided by SAP (=> gsskrb5.dll, for example) are also not "SNC certified", but SAP provides support (being in contact with Microsoft). Well, as some people might know, there are also some interoperability issues between different Microsoft OS versions ... - resulting in reactive patches of our SSPI wrappers.

I really do <u>not</u> want to promote <u>any</u> product - neither the one of Quest Software Inc., nor the one of <a href="http://www.cybersafe.ltd.uk/">CyberSafe Ltd</a>, nor <a href="http://www.entrust.com">Entrust Inc.</a>, nor <a href="http://www.secude.com/">SECUDE IT Security GmbH</a>, nor ...

I do not even want to disencourage anyone from implementing his own Kerberos-based solution (or any other solution which provides an GSS API), provided that this person is able to help himself. Reason: if products of different vendors are used and interoperability problems occur the usual finger-pointing will start. In the end you'll not get support by anyone ... - as long as you are aware of this (and capable of helping yourself) you can go ahead. Some (known) universities are belonging to that group ... - but it might not be appropriete to the vast majority of customers.

[tim_alsop]

Wolfgang,

Thankyou. I understand why you mentioned the specific product now, and the reason is made clear in your latest post.

Cheers,

Tim

[Frank_Buchholz]

> [...]

> 4) Another option that we have is to start with user

> synchronization. Where in Users created in Active

> Directory get synchronized with SAP .

>

> What is mandatory for us is that Users marked

> disabled in Active Directory should be blocked in SAP

> by synchronizing user information at regular

> interval. If anyone has implemented this solution I

> will appreciate if they give me some pointers.

See:

Synchronization of SAP User Administration with an LDAP-Compatible Directory Service

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

You can define any mapping between LDAP attributes and ABAP user master data fields based on a function module. Reading the disabled-Attribute in Active Directory, it should be possible to set the users validiy period or lock/unlock the user using BAPIs.

Kind regards

Frank Buchholz

[Former Member]

is it possible to even sync passwords? our goal is to have one team dedicated to user management (add new user, remove old user, disable/enable user, assign/reset password) centralized on AD.

thank you.

[tim_alsop]

Matro,

The Active Directory database does not allow access to passwords. Instead, Kerberos authentication is used, and during the Kerberos authentication of a user, AD generates a key using the stored password. It is therefore not possible to sync passwords with LDAP server as suggested previously due to fact that LDAP bind uses different method of password storage, and that AD does not allow access to passwords or keys - obviously it is more secure this way

Cheers,

Tim

[Former Member]

yes, this make sense.

thank you for your prompt reply. I also read note 603208 in the meanwhile.

[fralarsen]

Hi,

I have implemented SSO and Identity Management on several large SAP projects (where LDAP synch. between SAP and AD is just one part of the whole picture), so if you have any specific questions, don't hesitate to contact me. My focus areas are SSO/CUA/LDAP/AD/MIIS/User Administration and provisioning

I have implemented CyberSafe software at different customers to enable secure SSO both to standalone ITS (ITS 6.20), SAP GUI, BW (Bex etc.), integrated ITS and SAP EP (NetWeaver). I think they are the only certified vendor of kerberos SSO software to SAP.

It is easy to configure, very stable and their support is outstanding - they even help solve problems which have nothing to do with their own software.

At one project we discovered an issue with the SP level on Windows XP and Windows 2003 which gave problems, but CyberSafe assisted in solving it anyway. So no finger pointing there

Best regards

Frank

http://www.omada.net

[Former Member]

We are in a process of evaluating different solutions.

On implementing SSO what we so far understand is Cybersafe, Vintela etc are commercial solutions which means engaging and managing another vendor, solution, licenses and whole lot of compliance issues, so this will definitely take time to go through.

User information synch between AD / LDAP seems to be easy win for us since there are fewer dependencies, so as we evaluate thirdparty SSO we want to getting on with LDAP sync.

We are also trying to understand what kind of non third party solutions ( something that can be configured with win2k / 2k3 and / or SAP ) would be there if we were to setup SSO.

[WolfgangJanzen]

Please notice: LDAP synch will not provide any SSO functionality for the ABAP stack. It only keeps the user master data (username, address, phone number, ...) in synch.

The only non third party solution for SSO (=> SNC: => SAPGUI and RFC) is the one described in <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/352295">SAP note 352295</a>. But it requires that both, client and server, are running on Windows.

If your SAP application servers are running on UNIX you require a (certified) third party solution. Kindly read the previous postings regarding supportability.

On <a href="http://service.sap.com/security">http://service.sap.com/security</a> you'll find a section "Certified Security Partners" which provides an overview. Here's a direct link to <a href="http://www.sap.com/partners/directories/ProductSearchResults.epx?context=ZTLdd91hFNNUKZ5%2fSQ1pJpyNwN637GuauoAWuRyZZE6SF3ITHGv7wERSup65ii6TJyhPAMzkbJaiay9tlYoPb%2bD2IDdkVyF%2fBgMyusAcE95Rul6AahO823rT%2f2OebzHfsChL3GWz7F%2b3hwEoJDzFgIjPn9NroWI%2b%7ceppb5hktYrv6pW7%2f93NEunAi3bOxdD9553HOU44%2bz%2fjj%2fP5vgjWQllrZIlLTaWkIFY%2fTLek7ho3rYILMbxehP86Dx24LlNKGfReV%2fauJJVKpr%2f72dWL1oGWKrBse%2fPmHlcDlZRoHDul4MZrORnk%2biQ%3d%3d">certified SNC solutions</a>.

[Former Member]

Wolfang

Many thanks for the information. We have a two fold objective in SSO . First is auditary compliance and the second is since we are tying all systems together is a futher logical step to enable sso for our users.

Considering another situation, if we were to implement SAP Portal and connect all our sap systems and applications to it will it be able to take care of my user info synch and sso using the browser ?

Portal implementation is on our roadmap and we can make it happen earlier.

Thanks

Harsh

[WolfgangJanzen]

Well, the "Enterprise Portal" is designed to be the central access point: users will first access the EP (where they will logon using UID/PWD or SPNEGO, obtaining a SAP logon ticket). They will then call web-based services / applications which are provided by some backend systems (those backend systems need to be configured to accept the SAP logon ticket which has been issued by the EP).

That implies that all systems in the EP landscape do have a synchronized (if distributed) or common (e.g. LDAP) user/identity management.

Using SAP logon ticket requires that all systems are using the same userID (for one single user). In practice the system landscape might consist of ABAP and J2EE systems; in that case the rule mentioned above is slightly less strict: all ABAP systems need to use the same ABAP userID and all J2EE systems need to use the same J2EE username - because a SAP logon ticket is able to contain (only) two identity attributes (ABAP userID, J2EE username). The EP is then in charge of providing the required mapping between J2EE/EP username and ABAP userID.

In a DualStack installation (aka AddIn installation) the J2EE system is using the ABAP user management as UME provider; therefore no user mapping is required.

Please notice: there is a /community [original link is broken]

Regards, Wolfgang

[Former Member]

Hi Frank

Can you please contact me off the list ? You can find my email address in my profile .

Thanks !

Harsh

[Former Member]

Hello Frank,

I'm looking at a simple scenario in a pure Windows environment - ECC 6.0, SQL 2005, SAPGUI for Windows, Active Directory.

When logging on to SAPGUI for Windows, my users must be presented with a SAP logon screen, but I need to have the id and password that they enter authenticated against AD. I don't want them passed directly into SAP through Windows domain logon authentication.

I'm thinking by your posts and others like it that out-of-the-box SAP can't do this and that 3rd party software such as CyberSafe will be needed to accomplish it.

True? Any elaboration is appreciated.

Kind regards,

Rex L. Farris

[Former Member]

Hi, all

This information might be usefull for late readers.

I started investigation on SSO two years ago and I felt the same problem users using mixed environments find (Unix SAP servers and MS ADS servers) : You need a Kerberos solution. And you either install a free but non-supported version, or you have to pay to have one (with probable license costs). I know some installations are using such solutions (Repsol Spain), but you need a team with strong knowledge

I ended up playing with Enterprise Portals and noticed how easy it was to implement SSO with it. So I went ahead and today I have successfully deployed:

- SSO for sapgui for a lot of systems (using local Wingui)

- BexWeb for our BW systems (pages rendered in Portal)

Our Portals is binded to LDAP, so SAP users only have to know their Windows password. Neat!

I recommend.