In IIS, I have a web service which runs under an application pool which has the identity of a user that has access to a drive on a remote machine. In this way, when the web service runs and it tries access the remote machine to read a file, we do not get any invalid authorization errors.
I have now written my first Node.js app but I am not sure how to allow access to a file stream from the app to the remote machine. I have the unc path name to the remote machine's file I want to read but I am not sure if I have to pass in the credentials of the user to access the file or I have to run the Node.js app under certain credentials.
Any clues?
I know there is node for IIS, but is there another way of doing this without IIS.
Update:
Just ran my app under my user account and this account is configured to allow access to a remote machine and I have access to the remote machine without changing my code (in other words just using the Unc path directly). However, how can I do this using another user's credentials (i.e. impersonation in Node.js?)
Node does not handle impersonation like .NET applications do, since NodeJS is not Windows specific, so it does not know about the windows way of handling rights and elevation.
But that is not a problem. I have used the following technique on large financial networks.
As you pointed out yourself, the best solution is to have a dedicated user account for your nodeJS application with sufficient rights to access the UNC, but with no other rights. Then when you run the application, run it as this user.
Let me suggest that your setup a service to run the nodejs application and in the service specify the user account. This makes it much easier and safer. If you application is ever hacked, the hacker will not be able to escape the restrictions of the account.
Related
Everything I've found via search on this talks about Read/Write for local drives only (typically C) and what I am having trouble with is getting the same Read/Write access for an application pool to a non-local drive, specifically a share on the file server.
We've set the Application pool to run the anonymous user under a domain account that we have explicitly verified has full control of the file share and yet the web app that use the application pool is unable to access this non-local share. It can however access a local copy of the shared folder if we copy the folder from the file server to the local drive.
This is a third party app and we'eve followed all the instructions from the vendor and so far this is unresolved. Their support is looking at this but I don't believe they have any idea on what's wrong. This same web app works fine with the same file server share when the web app is running under IIS6 on another sever so its something with IIS7.5. I figure its got to be something particular to IIS7.5 that is not in IIS6 that is the key.
Ideas?
FYI - The application pool is already set to classic mode.
I think that you will have to see the permission that you have. In iss7.5 you have the aplication pool running with an account, It can be a ApplicationpoolIdnetity, or a real one. if you want to access the share the application pool identity has to have rights to do so, or you can impersonate a user and then use the permission that user has to copy to the shared folder, i prefere to use the impersonate, only when is necessary i do the impersonate and do whatever i most do.
On a fresh CentOS application;
How can I create a separate user other than root, to store the
website hosting files?
How can I lock this user down to prevent malicious or bad things from happening?
How can I further protect the php file containing the DB connection strings?
What other security measures shall I take to protect a such server which is only used to server a web-app? (or two)
What other ways shall I employ for sand-boxing the web-app?
I am running Centos on a VPS and want to use Apache or Lighttpd as the web server.
Thank you.
One best practice is always to only run services you actually need on a box facing the internet. So if you only need apache and a database, run only apache and the database on that machine. Long, random passwords for maintenance user, do not allow direct root login.
Regarding the user: add a user with useradd and block shell access for that user (usermod -s, set login shell to /sbin/nologin). Usually a service account for running the web server is created after installing the web server. If you restrict permissions for that account to the web server home and logging directories, you should be fine.
Regarding protecting the database: you can create a db user account that doesn't have drop or create privileges, but as your application needs access to the database, someone acting with the privileges of your web server or application will have access to the data in the database as well.
We have an instance of IIS6 running an intranet website with Windows Authentication and Impersonate = true so that it uses the NT credentials passed in by the clients browser.
The AppPool is set to run as a network service user: serviceAcctX so that we can undo impersonation in rare cases (to read or write a resource that the client user does not have access to)
It works perfectly when the source of the virtual directory is on a local drive. The logged in user is authenticated and page content is customized based on authorization settings.
Our infrastructure team is trying to move the virtual directory source to a file share on a remote server. We have already gotten past the issue with changing the .Net security policy by adding a full trust for that specific file share path. We have set the Connect As property to the same serviceAcctX, the same one that the AppPool is running as.
The site starts fine. However, the client user is not impersonated. The request is processed using the default serviceAcctX credentials instead of with the client's NT credentials as before.
Is there a way to have the client impersonation still work as before and still have the virtual directory on a file share? Any pointers are greatly appreciated.
I'd put this in the category of Not A Good Idea.
There are a number of potential problems that crop up and you are introducing a lot of dependent complexity.
Instead, I'd go for something a little more "offline" than this. Use File Replication to keep the files in sync between your web server(s) and remote server.
Although slightly complex, it increases the survivability of your application. Meaning, if the remote server reboots, goes down, or there is a network problem between the two, your app is still functional. Further, you are still able to have the files on the remote server.
You may have to check the "trust this computer for delegation" check box in Active Directory for the web server in order for the user's token to be passed on.
IIS5 is running on SERVER1.
One of the virtual directories in IIS, myfiles, is pointing to "A shared location on another computer", //SERVER2/myfilesshare
When I try to access the page:
http://SERVER1/myfiles
... I get the error:
You are not authorized to view this page
HTTP 401.1 - Unauthorized: Logon Failed
Internet Information Services
I have triple-checked the "Connect As..." settings in IIS. The credentials I'm using to access the share are correct-- they work when connect to the share in Windows Explorer, but not through the IIS virtual directory.
I've tried granting full permission to Everyone on the folder in SERVER2, but no luck.
Any thoughts?
This was how I solved my problem, might help you.
By default, IIS uses local user called IUSR for virtual directories when using anonymous authentication. It does not use application identity, which should be obvious, if you use procmon.
How can you force it to use application identity?
Easy, under IIS manager:
1) go to Authentication
2) Edit "Anonymous authentication"
3) Select "Application pool identity"
4) Restart IIS & it should work.
The same accomplished with PS: Set-WebConfigurationProperty -filter /system.WebServer/security/authentication/AnonymousAuthentication -name username -value ""
This link contains the pros/cons: http://blogs.technet.com/b/tristank/archive/2011/12/22/iusr-vs-application-pool-identity-why-use-either.aspx
Permission issues can be tricky. Try running filemon on the 'other computer' It can be downloaded over here: http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx
(it's not a big application just a tiny lightweight tool)
After you've started filemon, stop the monitor process (I believe it's turned on by default when you start the application), clear the logged data, create a filter for the folder you have trouble getting access to. Start the monitor process. Request your webpage. Stop the monitor process and look for "access denied" messages in filemon. When found, filemon will also mention the name of the actual user which is trying to get access. This might help you to get to a solution.
Btw when using Windows Server 2008 you will need processmon instead: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Imagine a scenario where for whatever reason you want to have your IIS Server access a Share on a File server and they are not on the same domain.
If you can follow and get this to work for you (I have done it Win2008-R1 32-bit File Server and Win2008-R2 64-bit with IIS 7), then you should be in good shape for any scenario.
Same name local account on both servers with same password
On IIS, use aspnet_regiis -ga MyAccount to give local account access to IIS guts
Now use that as the Application Pool Identity of the Website
Using Local Security Policy (Admin Tools) enable trust for delegation for local account
Restart IIS server
On File Server, use Local Security Policy to enable access from network for local account
Create Share granting desired permissions to local account (also Security tab permissions as needed)
Open up File & Print Sharing ports on both (as restrictive as possible) to point where it works for you when you are using Windows Explorer between the two
Back to IIS, create Virtual Directory using UNC path to Shared folder from File Server
Just use Pass-through authentication (which would use your local account)
You can tell Anonymous Authentication setting of the Virtual Directory to use Application Pool Identity as well
Use something that will test/verify. The key really is trust for delegation using a Service Account (domain or otherwise), and having IIS use the account you want it to use instead of Local Server or Network Service.
This took me all day to figure out. Various threads in StackOverflow and other Internet sources helped point me to various resources me but didn't find my exact answer anywhere. Hopefully next person stuck with this problem will get a speed boost on the path to resolving with my description of what worked for me.
try enabling windows authentication on the virtual directory security tab (in IIS).
I have a webservice running under sharepoint, on a bog-standard Server2003/IIS6 setup. This webservice needs to open and read a file from a share on another machine in the same domain. At the moment I am getting a
System.UnauthorizedAccessException: Access to the path '\strand\DROPBOXES\MattTrinder\SharepointShared\bd116dfa-be0e-4c58-93e6-3fb93fa0ef22.tmp' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
What permissions do I need to grant to which accounts to allow this webservice to open and read the file ?
Using "\\sharepointserver\c$" works fine...
Thanks
Matt
The account you grant access to, has to exist on the target (where the share exists) as well (either the same domain account, or a local account with the same password). Since the IIS-user normally has an auto-generated password and is local, this is hard.
The way we solve this, is to run the website as a different user (that we created ourselves), and grant this user permissions to access the share on the remote PC. Note that both the sharing permissions have to be correct, and the file system permissions.
You need to grant read access in the file system level and in the share. The problem is that sharepoint runs (probably, because it can be changed) under network service account that has no access to the network.
options:
If you are using integrated authentication for the web service. Then you have to grant the permissions to the users that the web service client runs under. But don't go this dark path. Because delegation is very hard to configure.
If you have anonymous access to the web service, make sure that the application pool that the web service runs under run with user permission of explicit user that have access to that said file. This can be configured with the sharepoint administration site. Or with computer management mmc.
Classic asmx web services by default run as the IUSR_ account. This may not have permission to access the network path. You can change this to a domain account by changing the application pool identity.