Single Sign On with Windows ADS

[Former Member]

Hi All,

Hi All,

We have ECC 6.0, BI 7.0, EP 7.0 under implmentation with WIN2K3 ADS Environment. At present , Users are logged on entering UName / PW each time they want to access the System .

End user within WIN2K3 Envirornment would access the ECC / BI Servers through Portal. Portal would also have some non-SAP Add Ons. With this non-SAP Add Ons which user would need to aceess as well - we want to Implement SSO for this environment. We have a plan to

- Implement SSO between Portal and ECC 6.0 and BI 7.0 - Each through STRUSTSSO

So, under this Backdrop,

- Is SSO through Log On Ticket ( STRUSTSSO ) is feasible on WINDOWS ADS ?

or

- We MUST go for User Mapping Option of SSO as Portal also has some Non-SAP Add-On + WIN2K3 ADS ?

- Which one would be better - SSO Log On Ticket / SSO User Mapping / Kerberos Authentication ? Any RoadMap level inputs ?

Beside this, can anyone provide links / other resources for SSO implementation under WIN2K3 ADS Environment ?

Many Thanks in Advance,

- Ishan

[tim_alsop · Accepted solution]

Ishan,

If you are using SAP GUI then you need to use SNC support in SAP GUI nad SAP ABAP to allow authentication via Active Directory authentication, and for SSO it is best to use the Kerberos credentials already on workstation after user logs onto domain. This means you need an SNC library that uses Kerberos protocol.

If you are using Web browser and want to use Active Directory authentication, and your workstations are on Intranet then you can use the Negotiate protocol which is implemented using the SPNEGO protocol. In SAP NetWeaver it is possible to configure a J2EE custom login module that uses this protocol to authenticate users. There is no need for any client software since the web browser already supports this protocol.

With the web browser logon, the users Active Directory credentials would be used to pass the users principal name to the SAP system, and then this would be mapped onto a valid SAP user and client number. Once this SAP user has been determined an SSO2 ticket would be created so that every other page access from same browser would not cause the use to be re-authenticated, instead the SSO2 ticket would be used to determine the users identity. It is important to understand that the SSO2 ticket is only used for this, and can be created after a trusted authentication method has been completed.

Hopefully this answers some/most of your questions.

Please let me know if you have any doubts or more questions.

Thanks,

Tim

[Former Member · Accepted solution]

Thanks a Lot, Tim ! These are very helpful inputs.

Now, we have 2 types of users at present within the same corporate intranet and as you have mentioned :

#1 Portal Users : User Log on to WorkStation > Access through Web Browser > ADS Credentials > Use SPNEGO > Configure J2EE Custom Log In Module to Use Negotiate Protocol of SPNEGO > ADS Credentials Passed and mapping / varification to Valid SAP Client , User No. >Upon +ve confirmation, SAP Issuse SSO2 Ticket

...For this I don't need any additional module installation : I use STRUSTSSO within Portal , SPNEGO Config is done as per Note

1. 994791.

?? As I understand Kerberos not in picture here as , I am using SSO and NOT Log On Tickets

#2 Functional Users using SAP GUI : User Log On to WorkStation > Use ADS Authentication , Kerberos Credentials already on

W/Station > Need of SNC Library using Kerberos Protocol

?? For this, is there any other option ? SNC seems not much feasible in our environment - cost point as well as implementation

time point .

?? We need Unified Approach ( If Possible !!) for Portal Users as well as for SAP GUI Users - Is there any common solution for

both of this ?

....One solution I can think of is : Integrate SAP GUI in Browser through the use / config of ITS for each of the Functional User

and just like Portal User ..he will also be authenticated through ADS + SPNEGO as mentioned in # 1. ...But, Can this GUI

Deployment on Browser ( for Functional Users ) can be done on Mass Scale ? Beside this, if there is better solution which can

save us for this ' Publish GUI in Browser ' Task, then I would certainly go for it..

#3 : After #1 , #2, As I understand I still need STRUSTSSO for Back End Security between Portal to ECC 6.0 , right ? As the

above 2 Scenarios, Takes Care of only front end security .

Pl. help .

Many Thanks Again,

Best Regards,

- Ishan

[tim_alsop · Accepted solution]

Ishan,

I think you are confused with logon tickets (e.g. sso2 tickets).

When you use spnego as you have described you are actually using Kerberos tickets to authenticate the user at the workstation. But, this is only the INITIAL authentication, and after successful initial authentication and the SAP user has been determined the SAP system will create an SSO2 logon ticket, which will then be sent by browser as a cookie when pages are accessed using same browser. This logon ticket is then verified by SAP and used to determine the identity of the already authenticafted user.

SNC and SPNEGO work very well together and give you the unified approach you are looking for. I spend 100% of my time working with customers every day of the week doing exactly this This is very common approach and very easy if you use the right products and tools to make it possible.

STRUSTSSO2 is used simply to allow SSO2 tickets to be trusted, so you can authenticate on one system (e.g. portal) and then access pages in another with out re-authenticating.

Thanks,

Tim

[Former Member · Accepted solution]

Thank You Very Much, Tim ! This clears all my doubt.

Best Regards,

- Ishan