Kasper de Jonge PowerPivot Blog

yes, the word that any BI or IT pro dreads: Kerberos .. Imagine you want to run Power View in a SharePoint farm on top of a SSAS database running in Tabular mode. You probably want to use security so you can secure the data by the user that is actually running the report using the AS security features.

But most likely you won’t run your AS instance on a machine that is inside of the SharePoint farm. When all of your machines are inside the same SharePoint farm, SharePoint will take care of passing the credentials between the machines. But as soon as one of the machines lives outside of the farm you have to setup Kerberos to make sure the security is correctly passed on between machines. Configuring Kerberos is a lot of (hard) work if Kerberos is not already set up correctly in your organisation.

But there is some good news on this with SQL server 2012. In SQL Server 2012 we introduce the BISM file that allows us to start a Power View report based on the connection information in this BISM file. Whenever a connection is made from Power View to the Tabular database it tries to connect using the credentials of the user that is executing the Power View report. If Kerberos is not configured this connection will fail regardless of him having access.

But there is a fall back scenario, when using the BISM connection to connect to a tabular database ADOMD will give it another try using the execution account the Reporting Services app server is running under and then switch to the actual user who initiated the connection. All you have to do is add the execution account the Reporting Services app server is running under to the administrators of the AS instance and this connection will succeed even without Kerberos is set up. Admin connections are always allowed cross machines, under the covers ADODM uses the effectiveusername connection string parameter to switch to the actual user initiating the connection after connection is being made.

This post is dedicated to Marc Valk my esteemed former colleague with whom we battle the Kerberos beast several times at my previous job .

Some colleagues of mine upgraded their host system to Windows 7. Since that moment they couldn’t connect to our test SSAS server to test the new developed analysis cubes from Excel.

The following error occured:

The following system error occurred: The security database on the server does not have a computer account for this workstation trust relationship. .

My collegue Bas Kroes found the answer while searching the internet on the MS forums:

Did you by chance install Windows 7 on your workstation (the one you re-imaged)?  I understand that this issue arises in Windows 7 due to a component called “Windows Live Sign In Assistant”.  From my understanding, you basically have 3 options:

1. Configure Kerberos on your SSAS server http://support.microsoft.com/kb/917409
2. Uninstall Windows Live Sign In Assistant on each workstation
3. Use SSPI=NTLM in your connection string to force NTLM as the Security Support Provider Interface

#1 is probably the preferred method, as it addresses the problem server-side, whereas #2 and #3 are both client-side workarounds.

found at http://social.msdn.microsoft.com/Forums/en-US/sqlanalysisservices/thread/b058635f-6d3e-4240-a555-1dbd945ae25a

Chris web  just found  a very detailed white paper from Boyan Penev and Mark Dasco about setting up Kerberos for Microsoft BI which he and I thought was worth linking to for future reference:
http://bp-msbi.blogspot.com/2009/04/enhanced-security-and-integration-of.html