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

Question

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

Answer 1

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.