views:

140

answers:

1

Hi

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.

A: 

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.

Shlomo
I've run the SQL Profiler trace and the correct user identity is being passed to Server B when Server A is accessed locally.
JumpingJezza
Got that. I meant can you set up a test page on Server C to see if the user is being authenticated properly? Also, it would be easier to refer to them as SSAS server, Application Server, and Web Server. :)
Shlomo
Oops sorry Server C isn't really a server, I mean the client's PC. Server A is Web Server, and Server B is SSAS. I'll edit original question :)
JumpingJezza
Thanks, now it's clearer. I'm going to guess the problem is in your web.config or IIS settings. Check out the edit.
Shlomo
Great link. I can see why the webpage test would be useful but I don't want to setup iis on that server. The web application can hit a SQL Server database on the same server as the SSAS and running a profile trace - the identity is correct. So maybe just a cube specific issue? The connection string I am using unsuccessfully is "Provider=MSOLAP; Initial Catalog=xxx; Data Source=yyy;SSPI= Kerberos;"
JumpingJezza
I should add the "SSPI=Kerberos" part of the connection string is something I've added lately. The new error message I get with this is "The security database on the server does not have a computer account for this workstation trust relationship"
JumpingJezza
Sorry, I assumed the .NET application was ASP.NET, is it just a console app or something?
Shlomo
No it is a typical C# ASP.Net web project. It is designed for a user to browse a cube with a GUI via the web.
JumpingJezza
So can you add some sort of debug.aspx page to the ASP.NET project?
Shlomo
Yes it shows Page Identity: mydomain\me Windows Identity: mydomain\appPoolidentityUser Thread Identity: mydomain\me
JumpingJezza
Found a link: http://support.microsoft.com/kb/810572. I'm guessing your delegation isn't working right. See which of those steps isn't happening...
Shlomo
Ahah! Found the missing part of the puzzle! I was under the delusion that the SSAS service was running as NETWORK SERVICE, when in fact it had been set up to run as a specific user. Registering a SPN for the OLAP service as described [here](http://support.microsoft.com/kb/917409) on the SSAS server fixed it! ie **Setspn.exe -A MSOLAPSvc.3/Servername mydomain\theuser**. I'm marking your answer as correct coz this has been going on for 2 months and your prompt replies pushed me to check every step thoroughly. :)
JumpingJezza