Is it possible to use the SIA service account as a proxy for a SQL Server connection using OLE DB? This way, anytime a report was refreshed, the SIA service account would be used when authenticating to the reporting database? This is a common pattern in software development to minimize database maintenance (when there is sufficient security being enforced at the application layer - BOBJ provides this).
This would make SQL Server database security management very easy for the DBAs (just add the BOBJ service account to the database and assign dbreader).
I would think this would be an option, but a Relational Connection only provides the following 3 Authentication modes when using the IDT to create and publish a Relational Connection (OLEDB/MSSQL):
Use BusinessObjects credential mapping
This takes the username and password from the "Database Credentials" section of the BusinessObjects User object for the user in the current session. It passes the info as hard-coded SQL authentication.
Use single sign-on when refreshing reports at view time
This is ONLY for end-to-end single-sign-on (as the error message in the next paragraph specifies) and uses the Windows AD credentials for the user in the current session. It is this method of authentication that I'd like to use, i.e. Windows Integrated Security, but I'd like to have the SIA account act as the account that makes the connection, not end-to-end.
Use specified username and password
This is for hard-coding usernames and passwords (only SQL authentication in OLE DB).
I've tried leaving the "Cache security context" option OFF in Windows AD Authentication settings, hoping it would default to using the service account for authentication to the database... to no avail. It fails during tests in the IDT with the message:
"Single Sign-On failed in the CMS. Please contact your system administrator for details. : The authentication provider (secWinAD) associated with this logon session does not have inter-process Single Sign-On enabled. Contact your system administrator for details. (FWB 00019)"
Alternatively, a SQL user could be hard-coded into the connection (same simple maintenance on the DBA side), but we'd really like to rely on Windows Integrated Security if possible!
Is there a way?
Any help is greatly appreciated!
David