I deployed a WCF in IIS7. I'm using AppFabric to cache some values. Everything work fine if I use NetWork identity( all items set into cache and get from cache successful). However, when I choose pool identity is ApplicationPoolIdentity, My AppFabric service stop working. I can't explain why.
Base on what I read before: "The good news is that Application Pool identities also use the machine account to access network resources. No changes are required."
(http://www.iis.net/learn/manage/configuring-security/application-pool-identities)
So, Can anyone tell me What happened?
I am assuming that you have given iis server account (machine$) permissions to access the cache....
can you check if applying http://support.microsoft.com/kb/2545850 on the IIS server makes a difference ?
Related
I'm having some trouble calling a web service from within a web application and I was hoping someone here might be able to help. From what I can tell, this seems to have something to do with the Kerberos double-hop issue. However, if it is, I'm not sure what to do to actually fix the problem. To make things harder, I don't have the proper permissions to make changes to Active Directory accounts, so I need to know what to ask for when requesting changes. In my situation, I need to pass the credentials (Integrated Windows Authentication) from a web application onto a backend web service so that the web service runs under the proper user context.
Here's my exact issue:
This works
This doesn't work
The only difference between the working scenario and the non-working scenario is that the working scenario is running the application on localhost (whether a developer's PC or on the server in question) and the non-working example is running on another machine. The code between both scenarios is exactly the same.
What I've tried
Adding an SPN to the domain account that runs the app pool for each server setspn -a http/server1 DOMAIN\account
Different methods of impersonation
Removing the impersonation code using(...) and executing the web service call as the app pool account. This works as expected.
Does anyone have any idea on what I might be able to do in order to fix this problem?
The intermediate server must be trusted for delegation. Otherwise no credential will be delegated and the intermediate server cannot impersonate the original client.
More often than not the reason is that Server 1 does not pass a delegation token to Server 2. So when Server 2 tries to use that authentication ticket to go somewhere else (probably a SQL server) it fails.
You should set the impersonation level for the WCF call
ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation
http://msdn.microsoft.com/en-us/library/system.servicemodel.security.windowsclientcredential.allowedimpersonationlevel.aspx
I have an asp.net web app which works fine in Windows XP machine in a domain. I am porting it to a Windows 7 stand alone machine. The app uses a web service which makes a call to sql server. The web server (IIS 7.5) and SQL Server are on the same stand alone machine.
I enabled Windows authentication for the website and web service. The web service uses a trusted connection connection string. The web service credentials uses System.Net.CredentialCache.DefaultCredentials. I noticed username, password and domainname are blank after the call! The webservice and web site use the 'Classic .NET AppPool' with NetworkServices identity.
I am getting an exception "NT AUTHORITY\ANONYMOUS LOGON" in the database call in the web service. I am assuming it's related to the blank credentials.
I am expecting ASPNET user to be the security token to the database. Why is this not happening? Did I miss a setting?
(Usually this happens when sql server and web server are on two different machines in a domain, delegation & double hopping, but in my case everything is on a dev box)
It sounds like you're experiencing the "double hop" problem. It basically means that you're not allowed to forward the clients privileges to a third party, usually a sql server on another machine.
I've answered this before, perhaps that answer will help you further.
Your problem seems to be related to the web service passing the correct credentials to SQL server.
There are a few layers of security for you to check. But the first and easiest is to make sure you have disabled any security other than Windows Integrated. IIS will always use the simplest security protocol. So if you have Anonymous and Windows Integrated enabled then you web site will always choose Anonymous.
Next each site in IIS7+ runs under an app pool which can have separate security. Then under all that the IIS Windows Service runs under a specific account.
Buy default you shouldn't really have much problem with app pool and IIS security as it pretty much works out of the box, but it's worth checking.
One more thing I would check is the named pipes in SQL. My knowledge isn't vast but I know that named pipes can be used for communication on the same server between various applications, IIS and SQL being two of them.
If names pipes is disabled through the SQL configuration manager then I would have expected a different error, but it's worth enabling.
Hope this helps.
Mike
I'm trying to get an ASP.NET website running on Vista (IIS7), using SQL Server and Windows Authentication. No matter what I do, when I connect to the database, I get the exception:
SqlException was unhandled
Login failed for user 'MyDomain\MachineName$'.
It doesn't seem to matter what settings I apply, I cannot get IIS7 to pass through my Windows login credentials.
Extra details:
Both the SQL Server and my local machine are on ActiveDirectory
Vista Enterprise, IIS7
SQL Server 2005
Anonymous Authentication disabled, Windows Authentication enabled
Impersonation on/off makes no difference
All Identities (NetworkService, LocalSystem, etc) give the same result
Classic and integrated pipelines give the same result
Help!
Impersonation on/off makes all the difference, when properly configured. What you want is caled 'constrained delegation' and you need to configure IIS and ASP for it:
How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Configure ASP.NET Impersonation Authentication (IIS 7)
Configuring Servers for Delegation
By default, the IIS server is not allowed to impersonate you towards the SQL Server. There's an MSDN article on how to configure it. The configuration process is complex and error prone.
If your production ISS and SQL Server run on different servers, you'll need a domain admin to configure impersonation trust between the two servers. This is typically a no-go in a big organization.
In addition to not being deployed by normal admins, impersonation also prevents users from sharing their connections in the SQL connection pool. This results in a very noticeable performance penalty for even small (5+ users) websites.
Did you try to create a new user account for your application, grant it the appropriate rights on the Sql Server, and then set the application pool to run under this new account?
This is what I usually do, and it works. I'm not running my application under NetworkService, LocalSystem or other builtin accounts.
Does your connection string contain Integrated Security=SSPI?
Have you switched the asp.net context to be a domain user as well?
Here is an MSDN article on this topic
http://msdn.microsoft.com/en-us/library/2xzyzb0f.aspx
I'm getting a 401 (access denied) calling a method on an internal web service. I'm calling it from an ASP.NET page on our company intranet. I've checked all the configuration and it should be using integrated security with an account that has access to that service, but I'm trying to figure out how to confirm which account it's connecting under. Unfortunately I can't debug the code on the production network. In our dev environment everything is working fine. I know there has to be a difference in the settings, but I'm at a loss with where to start. Any recommendations?
Have you looked in the IIS logs?
I would also recommend looking in the Security event log on the server for authentication failures. You should find a footprint of the failed authorisation attempt here. Be warned though - it is not unusual to get 10s of security events a second, so ideally you need to be able to access the event log as the requests are failing.
If you do not specify which credentials to use in your ASP.NET page when you instantiate the web service then I believe it defaults to NT_Authority\Anonymous.
If you're using System.Net.CredentialCache then your web service needs to be in a trusted domain, accessed over HTTPS and using either NTLM, Kerberos or Digest Auth otherwise it does not pass the credentials from the cache.
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultnetworkcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
Perhaps the production server uses a different user for its application pool than your dev environment? I once spent a day figuring that one out. Another option would be the (lack of) impersonation in the web.config
Please note: In each step I describe below I'm logged in as the same domain user account.
I have a web application that controls a service on a remote machine (via ServiceController). When I connect to the website remotely and attempt to control the service, I get an InvalidOperationException: Access is denied.
I know it CAN work, because when I connect to the website from the web server (remote desktop in, login as my domain user, then open the webpage), it works as expected.
I have configured IIS and ASP.NET to require windows authentication and impersonation. I log the current thread's principal when this fails, and I see that the thread is running under my identity whether I'm connecting remotely or from the server itself.
I have tried forcing IIS to use Kerberos authentication, NTLM authentication and both at the same time; whether my principal reports its AuthenticationType as "Negotiate" or "NTLM" it doesn't matter. None of them work when I connect remotely (from my local machine)
ANOTHER weird thing about this is that if I'm debugging from my local machine/connecting to the remote server, it works every time! But I'm NOT debugging, it fails every time!
What in the heck could be going on here?
Your scenario is delegation and not impersonation. Delegation is hard to achieve and it depends on many thing that are done right.
A place to start would be Kerberos authentication and troubleshooting delegation issues
David Wang blog is a very useful resource on thous issues.
"ANOTHER weird thing about this is that if I'm debugging from my local machine/connecting to the remote server, it works every time! But I'm NOT debugging, it fails every time!"
That's a clear indication that you have permission issues. When you run in the debugger you're running as the logged on user, when you're not debugging it runs as whatever IIS is set to use (NETWORK SERVICE by default). Try setting (temporarily!) the Enable anonymous access using your domain account as the user and see if that works. If it does then it means your IIS is not setup properly to impersonate (and it's probably running as NETWORK SERVICE).
Permissions in IIS can be a bitch to fine tune properly...
Good luck!
P/S: This looks more like a network administration question than a programming one (see https://stackoverflow.com/questions/321618/stackoverflow-is-for-programming-questions-here-are-some-better-forums-for-your#321756)