on 05-27-2010 10:06 PM
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...?
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
25 | |
12 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.