Search code examples
.netwindows-authenticationolapkerberosssas

Connecting to Microsoft Analysis Services cube with double hop windows authentication


I'm trying to enforce windows authentication for users of a .Net application on Web Server to access a cube on a Microsoft Analysis Services database on SSAS and just going nuts trying to get it to work!

I am using <identity impersonate="true" /> in the web.config. Anonymous access is turned off in IIS and Integrated Windows Authentication is selected. The appPool is running as a specified identity; a separate windows account which has been granted "Account is trusted for delegation" in Active Directory. I have also got the network guys to create and register a SPN for this identity on Web Server. The users trying to access the .Net application do not have "Account is sensitive and cannot be delegated" selected on their AD accounts.

It works fine if the user is accessing the .Net application locally from the Web Server, but when accessing the .Net application from the client's PC they get an error: "an error was encountered in the transport layer" "the peer prematurely closed the connection". Doing a trace with SQL Profiler I can see that the NTUserName trying to authenticate unsuccessfully is ANONYMOUS LOGON.

Why is it not delegating the user's authentication??

Solution:

Registering a SPN for the OLAP service as described here on the SSAS server fixed it! ie Setspn.exe -A MSOLAPSvc.3/Servername mydomain\theuser.


Solution

  • Sounds like your web application isn't really grabbing their identity and/or passing it on to the .NET app. Can you set up a test page to verify it's getting their Windows ID?

    Edit: This article may help: http://www.eggheadcafe.com/articles/20050703.asp

    Try setting up a blank debug.aspx page, have it say in the code behind something like:

    private void Page_Load(object sender, System.EventArgs e)
    {
        Response.Write("Page Identity: " + Page.User.Identity.Name);
        Response.Write("Windows Identity: " + System.Security.Principal.WindowsIdentity.GetCurrent().Name);
        Response.Write("Thread Identity: " + System.Threading.Thread.CurrentPrincipal.Identity.Name);
    }   
    

    Hit that page from client PC, this will help you figure out what the web page is actually working as. The article may help you resolve how to fix the issue.