cancel
Showing results for 
Search instead for 
Did you mean: 

WinAD SSO errors for JAVA InfoView after SP3

former_member183781
Active Participant
0 Kudos

I had successfully deployed the WinAD SSO configuration for both the .NET and JAVA InfoView as documented in the SAP materials provided by Tim Ziemba and Miles Escow.

Yesterday, I applied the new BOE-XI (R-3.1) Service Pack 3 on our DEV server...and accepted the RE-DEPLOY WebApplications option during the install.

The .NET WinAD SSO is working 100% OK at http://<servername>/InfoViewApp/logon.aspx

However, after I updated all the server.xml and web.xml files as required for the Tomcat55 folders that were overwritten by the service pack - I am getting 404 "The requested resource is not available" errors for both the LogonService and the LogonNoSso.

http://<servername:8080>//InfoViewApp/logon/logonService.do

http://<servername:8080>/InfoViewApp/logonNoSso.jsp

If I comment-out the REALM and FILTER MAPPING sections that are mentioned on Pages 17 and 18 of Tim Ziemba's "Complete" document then I get a Manual Login Screen that works - but no SSO.

Is it possible that the logonService.do and logonNoSso.jsp are broken by BOE-XI (R-3.1) Service Pack 3, and is there any way to get those components back...?

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Tim

Many thanks for the information. Constrained delegation works now in our environment. I added idm.allowS4U parameter to the web.xml of InfoView, OpenDocument and dswsbobje. Furthermore I can confirm that it works with two dedicated users. We did that to be able to separate the "keytab" user from the "non-keytab" user on the backend.

Thanks again and Regards

Andreas.

Former Member
0 Kudos

Hi all

@Tim: You're referring to constrained delegation support added in SP3. I tried to set this up but unfortunately without success. In our current setup we defined two Windows users - one for the WebTier (actually for the keytab) with all SPNs configured. Furthermore we run our "backend" with a dedicated Windows user which has one SPN defined (CMSSSO). The WebTier user has the right to delegate requests to CMSSSO but this does not work in our environment. As soon as we allow "delegate to any service" it works perfectly fine.

Do you have any suggestions on how to fix the problem?

Many thanks!

Andi.

0 Kudos

Hi,

i`m not quite sure but i guess you should use the delegation for your CMS User. Maybe Tim can say more about it.

Regards

-Seb.

Former Member
0 Kudos

Hi Seb

thanks for your reply. Since we don't use SSO "down" to the DB level it should be enough to allow the WebTier user ("Vintela user") to delegate to the CMS user. I'm pretty sure it's a configuration issue since SSO works fine with "delegate to any" rights. Obviously our Security guys do not really like his setting because it basically allows the user to get a Service ticket on behalf of the origin user for each and every service in the domain.

Regards,

Andi.

BasicTek
Active Contributor
0 Kudos

The simplest thing to do would be to run all services involved under 1 account and add all spn's for that account to the list of constrained KB 1184989 shows how to set up vintela for constrained delegation the rest is on microsoft.

Regards,

Tim

Former Member
0 Kudos

Hi Tim;

We are having the same issue , when trying to open infoview in the browser

we get msg : HTTP Status 404 - /InfoViewApp/logon/logonForm.do

We followed your guide , and were able to create tickets , but cant get to infoview

we are running MS server 2008

bobj sp3 FP 3.5

Can you help

BasicTek
Active Contributor
0 Kudos

open a new thread for your issue, explain everything that has been done.

Former Member
0 Kudos

Hi Tim

I already did

BasicTek
Active Contributor
0 Kudos

I tested SSO on SP3 and it worked fine for me both for opendoc and infoview. I also tested constrained delegation which we added support for and that worked as well. There should be better vintela tracing in SP3 as in you can enable the djcsi tracing from my white paper but don't need to comment out the keytab anymore.

Commenting out the filter prevens the SSO from enabling so that is expected behavior.

Regards,

Tim

0 Kudos

Hi,

normally it should work.

Doublecheck if you dont have any typo in your .xml files. Do you have a backup of your .xml files from the time SSO worked ? If yes deploy them and test the SSO.

Regards

-Seb.