What permissions are necessary for a user to use web deploy to IIS running on a different server?
When I try to deploy from VS 2010 using that users credentials, I get the below error.
Error 36 Web deployment task failed.(Remote agent (URL https://server:8172/msdeploy.axd?site=site.name.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer.)
Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator.
Error details:
Remote agent (URL https://server:8172/msdeploy.axd?site=site.name.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer.
An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected.
The remote server returned an error: (401) Unauthorized. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I am able to use web deploy when I use my domain account (e.g. domain\user) with the following publish arguments.
My domain account is an administrator on the destination server, but granting the service account full admin privileges is not an option.
The user must have the following permissions.
Read/Write permissions on the site folder directory
WDeployConfigWriter and WDeployAdmin must be configured to have their password never expire and user cannot change password like the below screenshot
The account that runs the build should be enabled under IIS Manager Users
The account that the build runs under must have permissions to the site under IIS Manager Permissions
Configure Management Service
Configure Management Service Delegation like the below
Useful reference
Web Deploy 3.0 infuriating 401 error on publish
The user that the account runs under should be a Power User and must have full control permissions to the folder that the destination iis site is running from.
Related
CONTEXT
My client has an ASP.NET web application running in IIS 10 on Windows Server 2016. The web application needs to access files on network shares on different servers in a WORKGROUP environment. So, I created the same local user account on all servers, set the password to all the local user accounts to be the same, granted said user with full control permissions to the network shares, and reconfigured the IIS application pool to run under the identity of the aforementioned local user account. There is also a custom Windows service running under the same local user account for the same reason: to access files on remote network shares. All of this works fine. The web application and the Windows service can successfully access files from the network shares residing on servers other than the server on which IIS and the custom Windows service are both running.
ISSUE
However, there is a feature in the web application when an authorized user modifies a particular validation matrix record, it triggers a custom command sent to the aforementioned Windows service to cause the service to update its in-memory copy of the validation matrix. This worked fine when the IIS application pool was running under the built-in ApplicationPoolIdentity which apparently has permissions to interact with Windows services. But, the feature fails when the IIS application pool is running under the identity of the aforementioned local user account. The message in the exception is: Cannot open {SERVICE_NAME} service on computer '.'. Again, the Windows service and IIS are running on the same server. And recall that the Windows service is running under the same local user account as the IIS application pool identity.
QUESTION
How do I grant permissions to the local user account to allow said account the ability to issue the custom command to the Windows service from within the ASP.NET web application?
RESOLUTION ATTEMPTS
I've tried using subinacl.exe in an attempt to grant the necessary access but never got it to do anything other than to indicate Done 0, Modified 0, Failed 0, Syntax errors 0. I'm using version 4.2.1.1604 and executing it from an Administrative Command Prompt. The syntax I used was:
subinacl /service customServiceName /grant=localUserAccount
and the result is below
+service customServiceName
/grant=localUserAccount
Elapsed Time: 00 00:00:00
Done: 0, Modified 0, Failed 0, Syntax errors 0
I also tried /grant=localUserAccount=U and /grant=localUserAccount=F but to no avail ... same results as shown above.
I admittedly am not familiar with subinacl.exe and I saw somewhere that someone indicated earlier versions of subinacl.exe are buggy and suggested using version 5.2.3790.1180 which I cannot find. Result: failed.
I have added the local user account to the Administrators group on the server where IIS and the Windows service are running. Result: failed. CORRECTION 02/13/2023: This succeeded but required a server reboot for it to take effect. To be clear, I do NOT want to permanently add this user to the Administrators group. This was simply a test. As far as the server reboot being required for this to take effect is concerned, I tried recycling the application pool in IIS, restarting the Windows service of interest, and restarting the World Wide Web Publishing Service but no joy. Only a server reboot caused the addition of the local user account to the Administrators group to take effect from the standpoint of said local user having permissions to send a custom command to the Windows service from within the web application. I absolutely am inclined to believe that there is a better way to achieve the desired end without adding the local user account to the Administrators group. Surely someone else before me has encountered this and solved it.
The local user account is already set up in the Local Security Policy with the ability to "Log on as a service".
I have reconfigured the IIS application pool identity to NETWORK SERVICE and granted NETWORK SERVICE full control permissions to the network shares (which are on a different server in a WORKGROUP environment, not a domain environment). In this configuration, the feature to update the Windows service works, but access to the network shares is denied ... likely because NETWORK SERVICE is a built-in local account [with no password?? not sure on this] and does not behave the same as a "regular" local user account.
So, I have a catch-22 that has me stumped. I would be grateful for any insight on this dilemma.
Cheers!
Hi I am trying to deploy a website on an Azure VM and I already set all the configuration for make a deployment but this error appears when I tried to publish:
Error Web deployment task failed. (You connected to the remote computer ("saveci1.westus.cloudapp.azure.com") using the Web Administration Service, but it could not be authorized. Make sure you are using the correct username and password, that the site the one you are connecting to exists and that the credentials represent a user who has permissions to access this site.Get more information at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)
Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator.
Error details:
You connected to the remote computer ("saveci1.westus.cloudapp.azure.com") through the Web Administration Service, but could not be authorized. Make sure you are using the correct username and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access this site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.
Remote server error: (401) Not authorized. PoC 0
I follow all the steps from here https://github.com/aspnet/Tooling/blob/AspNetVMs/docs/create-asp-net-vm-with-webdeploy.md
Could you please check if is there any IP restriction configured for the resource group in Azure portal as it could be the reason.
Also i would suggest you to put a fiddler and trace the request which is causing the failure.
please check if you are behind any proxy, if yest then try to connect to a network that does not require this SSO through the proxy or use one of the many other ways to publish that do not require an SSO connection from your machine such as, FTP, VSTS, Git etc… and try to deploy it. Most of the time proxies are the reason which could cause failure in deployment.
As a workaround you could ftp to the site & do deployment via that method .
Hope it helps.
I am getting an "Access is denied" error on a 2012 R2 server when my web app on that server tries to access a self-hosted WCF service on that server using named pipes.
I do not have this issue on my development machine (Win 7). I can access the WCF service via the client test app on both the server and my development machine.
If I enable ASP.NET Impersonation on the web site using a user account that has full control permissions to the install folder for the WCF service, then the error goes away. I do not want to use impersonation since I understand it has significant performance penalties (not to mention security issues) and the WCF service is called for every user input during a session.
The strange thing is... If I set the app pool to run as either the user with rights to the service folder as described above or as a user with admin privileges, then I still get the error if ASP.NET Impersonation is disabled. The error will go away only after I enable ASP.NET Impersonation on the web site.
I do not have access to the source for the WCF service.
In this case, the web app was located on the D:\ drive and the Anonymous Authentication user (IUSR) did not have RX permissions to the web app location.
Note that if you are using Windows Authentication, then the same issue occurs if the Windows Authenticated user does not have RX permissions to the location of the web app.
The problem was resolved once I gave the authenticated user the proper permission.
Sometimes the solution really is just plain simple...
"Ain't got no gas in it" - Slingblade.
Short version:
For IIS 7.5 web applications with Windows Authentication does the end
user need to have Read file access?
Long version:
I have an intranet ASP.NET web app that uses windows authentication. It's installed at dozens of different companies and normally the authentication works fine: users navigate to the site e.g. http://appserver/MyApp, the app recognizes who they're logged in as and displays pages accordingly. I just installed it at a new client and encountered a problem:
When connecting e.g. to http://appserver/MyApp I'm prompted for windows credentials but after entering them I'm repeatedly prompted. After several re-entering credentials I'm shown a 401 error page saying "401 - Unauthorized: Access is denied due to invalid credentials.". So not only is it not passing through my identity but even when entering the username & password it's still denying access.
Giving Read & Execute permissions to the end users of the app solves this problem, but I don't think this should be necessary at all.
In the windows Application Event Log there's a message "File authorization failed for the request" along with Thread account name: NT AUTHORITY\NETWORK SERVICE and User: [the correct workstation users's domain account]. This suggests that the file access is being performed with the User's identity, not the AppPool identity of Network Service. Sure enough if I grant the end user Read & Execute permission (I didn't try Read only) to the application's directory then everything works correctly: when the user browses to the site they're authenticated automatically, not prompted, and the web site correctly recognizes their identity! Therefore my workaround solution is to give Read & Execute permission to Everybody on the application directory...but this is not an ideal solution.
This seems very strange. I've never needed to do this before in IIS 7.5, so far as I recall, and definitely never needed to in IIS 6 or IIS 7. Is this a new IIS7.5 thing? The documentation says that Impersonation is turned off by default. I added a element to the web.config to be sure, removed file permissions other than Network Service, but the problem remained.
Any thoughts? Is it normal for Windows Authenticated sites on IIS 7.5 for end users to need file permissions on the web server files?
Some relevant details:
Network Service
has Full Control file permissions to the app folder.
When connecting from the server itself I was prompted for credentials
but after entering them i'm authenticated and the application works
correctly including displaying my windows login and connecting and
retrieving data from the db. I later determined that it was prompting
for credentials because http://localhost was in the trusted sites
and therefore not recognised as the Intranet Zone and thus not
passing identity through. I also determined that it was working as
this user identity because it's an admin user who has file
permissions.
The web server is running Windows Server 2008 R2 / IIS
7.5. It didn't have IIS on it until I installed it. I installed the default features as well as Windows Authentication, ASP.NET, and
possibly a couple of other items. A separate WCF app I installed that
uses IIS, anonymous authentication & .net 2.0 is working fine on
that web server.
The app install process is a manual copy of files,
creation of IIS App Pools & web apps, updating connection strings,
etc.
I checked the IE security settings. It was recognizing the
server as in the Intranet zone and had the option 'Automatic logon
only in Intranet zone' selected. Also on Advanced Settings the
'Enable Integrated Windows Authentication' option was checked.
After
installing IIS I ran aspnet_regiis -i for .net 2.0 and
aspnet_regiis -iru for .net 4.0.
Anonymous authentication is
disabled for my app and Windows Authentication enabled.
The app is
running on ASP.NET v4 but there's another app I installed
experiencing the same issue running ASP.NET v2.
The app is running
with Identity = Network Service and in 32-bit mode.
Database
connection string includes Trusted Connection=True and database
permissions are granted to the web server account [domain]\[server]$
e.g. DGM\MyServer$.
In IIS > Authentication > Windows Authentication > Providers the list was Negotiate first then NTLM. I tried reordering so NTLM is first.
In the Windows Security Event Log there
were a series of Microsoft Windows security auditing events: Logon
and Logoff. They indicated that the Logon was successful and was
displaying the User Id of the workstation user. This are from when
I'm connecting from another workstation and receive a 401
Unauthorized after several attempts.
I see someone has had this problem reported here but with no solution. Originally I posted in the ASP and then the IIS forums with no answers so far.
Update:
This msdn article says
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser (my emphasis). Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request. This behavior applies to any requests that enter managed code. In earlier versions of ASP.NET, accessing files based on URIs such as "Default.aspx" triggered the access check. In ASP.NET MVC applications, where access to resources is typically performed using extensionless URLs, this check typically does not apply, because there is not a physical file to check. In that case, the FileAuthorizationModule class falls back to checking access-control lists (ACLs) for the folder.
This does suggest that the end user needs permissions to the files (in the case of .aspx) or the folder (for MVC) ... although still this seems slightly tucked away and non-definitive. This article about App Pools says they're used as the identity for securing resources, which contradicts the idea of needing to grant privileges to end users. Unless the rules are different for App Pools and NETWORK SERVICE, which could be the case but would be surprising.
Are authenticated users allowed to the app folder?
We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…
There are two IIS settings that control this:
Physical Path Credentials Physical Path Credentials Logon type
By default, Physical Path Credentials is set to Application User
(Pass-through authentication). This means that IIS doesn’t do any
impersonation when handling Windows Authentication requests. This can,
however, be set to a specific user (though not, unfortunately, the
application pool identity, which would be ideal). Physical Path
Credentials Logon Type is set by default to Clear-Text. For my testing
I set this to Interactive (though this may not be the correct value).
Possible values are Clear-Text, Batch, Interactive, and Network.
To set this up I did the following:
Created a local account (IIS-AccessUser)
Granted IIS-AccessUser read and execute access to the /home directory of the site.
Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
Set IIS-AccessUser as the Physical Path Credentials
Set Physical Path Credentials Logon Type to Interactive
Doing the above allowed me to log in to the application directly,
without having to allow Authenticated Users, or me having to be a
member of any of the groups in the /home folder. It also still
preserved .NET Authorization roles, so I still could not access parts
of the site that I was not allowed to.
The short answer is NO. You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.
We were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.
For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.
Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.
http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk
In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).
It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).
-- DSB
I have a web service running in IIS 6.0 on Windows 2003. It's authentication mode is Integrated Windows security (anonymous disabled), and authorization is done with Authorization Manager and an XML authorization store. My test user is a domain user (admin, actually) with membership in an authorized role.
I am testing this (for now) on the web server (localhost), and using (for now) Internet Explorer to access the web service (.asmx).
I can successfully open the web service (wsdl) page through localhost, like this:
http://localhost:8080/MyService/MyService.asmx
Using this url, integrated windows authentication succeeds (silently), and I am sucessfully authorized by AzMan to access the service. The same goes for the server name:
http://myserver:8080/MyService/MyService.asmx
Now I need to use the external host name (www.mysite.no) to access the service (this in order to get ssl to work with a certificate issued to that sitename). To do this, I add the host name to my HOSTS file, like this:
127.0.0.1 www.mysite.no
...then type this into IE:
http://www.mysite.no:8080/MyService/MyService.asmx
What happens then is that authorization fails. I get the IE/Windows login box and enter my correct credentials three times. Then I get a 401.1:
HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)
How is authorization through AzMan influenced by the host name?
Edit: I have reason to believe AzMan has nothing to do with it - it seems to be the authentication that fails.
I have reproduced the problem on another server. The essence seems to be that accessing localhost via an entry in the local host file somehow messes up the integrated windows authentication between the browser and IIS.
I have worked around the problem, now my curiosity is all that's left...
Enable audit login failure auditing & check the security event log on the host.
1) On the webserver, go to Control Panel, Administrative Tools, Local Security Policy.
2) Go to local policies, audit policy. Add failure for 'audit logon events'.
3) Close the MMC. Open a command prompt and type gpupdate.
4) browse to http://www.mysite.no. You will get the error again.
5) Launch event viewer (control panel, admin tools, event viewer). Navigate to the security event log and look for the login failure(s).They shoudl tell you something descriptive, like 'the user has not been granted the specified logon type'. Unfortunately the login type itself is not descriptive; logon type 2 is interactive (locally), 3 is 'access this computer over the network', 5 is 'logon as a service' (NT service, not WCF service). The rights required can be granted in the local security policy.
Also, check to see if you have a proxy enabled in IE. If your traffic is being routed to the proxy, it is possible that the proxy does not support NTLM. Add the host as a proxy exception while you test using IE.
My first guess is that it's not the host name.
The first thing to do is narrow down the problem as there are a couple things that could be going wrong.
First set the IIS site to anonymous access, and make sure you can pull up the web service. That will verify that you're accessing the right IIS web site and it's truly narrowed down to an authorization problem.
Also, check the Application Pool credentials, and the security settings on the file folder containing the web service as these could be contributors.