We are running XI 3.1 WebI on Windows2008 / SQL 2008. We are using Windows AD as our authentication method and we have set up SSO to the SQLServer. We set up a customized logon page that retrieved user name and password from a proprietary mechanism and we were able to successfully logon to BusinessObjects without hitting the InfoView logon page and we were able to run queries.
Now we have been requested to set up Trusted Authentication so that we don’t use the password and assert the identity to BusinessObjects. We did that successfully to logon onto InfoView, but now that the user runs a query and they get the following error:
We have monkeyed with various combination of web.xml file values for those in conflict, but can’t seem to get it to work. We think this may be an instance where BusinessObjects is not getting a Kerberos Ticket for this user because we are using Trusted Authentication but SQLServer needs the Kerberos Ticket to allow the logon to SQL. Note: we need to do SSO to SQL because of row level security in some of the tables that the users access.
Anybody else out there running this similar configuration and have successfully set this up? I’m going to reach out to SAP and see how that goes!
I think you will need to use Vintela SSO so that you can use Kerberos delegation to do the double hop for authentication for SQL Server rather than Trusted authentication
Just out of interest, why do you need to use a Bespoke login page rather than using the inbuilt AD authentication?
We have/had Vintela set up and SSO to the DB was working, it was when we inserted the Trusted Authentication that cause the SSO to stop working.
We need a customized logon page because we have a proprietary token to securely obtain user credentials, so we are routing our users to a different logon page rather than inject code into the InfoView logon page.
The only way to get the token is to have authenticated via AD. So our Security Architects are removing the password from the token so we are to assert that the user’s token already means they are authenticated and trusted so we can log them straight into BO without having to re-authenticate. Once we did that we lost the SSO to the database we believe because the process of obtaining a Kerberos Ticket was bypassed (need to check with SAP on that).
I am reasonably sure that if you are generating a logontoken through other means, then you are bypassing the kerberos ticket generating process.
At my current customer I am using an ASP page in IIS to authenticate a user and then generate a logon token and then forwarding them on to Java Infoview using the following url:
Yep, we are doing the same thing, here is the snippet of code that generates a TrustedPrinciple:
//call BOE logon.
sessionMgr = CrystalEnterprise.getSessionMgr();
ITrustedPrincipal trustedPrincipal = sessionMgr.createTrustedPrincipal(strUser, strCMS);
objEnterpriseSession = sessionMgr.logon(trustedPrincipal);
.
.
.
//create a Token Manager object
ILogonTokenMgr objLogonTokenMgr = objEnterpriseSession.getLogonTokenMgr();
//get the token, good for 60 minutes and only 1 logon
String strLogonToken = objLogonTokenMgr.createLogonToken("", 60, 1);
strAppURL = strAppURL + "/logon/start.do?ivsLogonToken=" + strLogonToken;
So same stuff, just that we generate a TrustedPrincipal. I looked through docs to see if there are other parameters to force a Kerberos Ticket, but no luck so far
Out-of-the-box, Its not possible to do both SSO to the Microsoft SQL server and Trusted Authentication. For SSO to the Database to work, the user must be authenticated via AD. (Kerberos Ticket is needed). Trusted Authentication is based on the account’s generic Alias and will not generate a Kerberos Ticket. Manual log on in this case (Via secWinAD) or SSO via Vintela will be required.
(BOB member since 2008-07-16)
(BOB member since 2006-02-02)
(BOB member since 2008-07-16)