I'm looking for just some orientation about how to control that an ASP.NET web site could be only loaded from specific IP client addresses. I mean: the user is only allowed to load web app from its PC at office, but can not load web app from other PC.
It seems obvious that the login web page should get the IP address or PC name from the client and check with a database query if that IP address plus the userid account match its database record.
However, catching the IP address with
Request.ServerVariables("REMOTE_ADDR")
could get a IP address distorted by a firewall, NAT or router configuration. So that option is discarded.
Other option that I've heard is about creating a dll file with a name like "license.dll", and store inside that dll file some credential or IP address or serial number. That data plus the userid account have to be stored in database . When user loads the web page, it should read first that dll file and get the credential inside it, make a query to database and match userid account and dll credential. If matching is correct, then web page is loaded.
Is it possible to store some credential in a dll file and make the web page able to read that dll?
EDIT:
There is a web app that works in the same way I explained:
In order to access that web app with userid and password, for the first time, you have to install at your PC a client side certificate and a dll file. After that, you can only access this web app from that PC and is not possible to get access with your userid and password from other PC.
Setup a DMZ around the server. Only those machines that are part of the DMZ will be able to connect to the server. Another option is NTML with Windows Authentication. I don't think the IP address solution is a good option.
Related
We have 2 servers in DMZ. First one is application server, let's call it APP machine. The other is a file server, let's call it FILE. Web site running on APP machine under IIS is trying to create a file in a shared directory located at FILE server.
When application pool is running with some user in IUSR_IUSRS or NETWORK SERVICE writing to remote location fails. I cant authorize this user in shared folder, because that FILE machine can only see local users.
I created a user X on APP machine (APP/X) and another one with the same username on FILE (FILE/X). Then I added FILE/X user to credential manager on APP machine. When APP/X and FILE/X users have different passwords writing fails again. But when passwords are the same then writing just works.
I cant understand why passwords matter. At the end of the day they are two different users APP/X and FILE/X. Could someone clarify this phenomenon?
When the local user account on APP attempts to connect to the FILE server it passes it's credentials (username and password). If that combination isn't an exact match against a user on the FILE machine then it will fail.
There are multiple ways to do this "correctly". The most common would be to have a domain setup in which the site on the APP server runs under. That way you could just authorize the user to have rights on the FILE server.
If you can't have a domain controller, then the username and passwords must be kept in sync on the two machines.
I have an ASP.NET web forms application that requires that requires that a user log in.
I have had the application running on a live server with an IP address pointing at it, to allow external customers to test it. e.g. http://1.2.3.4/application
Last week the customers decided that they were happy to switch their users to my application, and asked us to switch the existing URL across to it e.g. http://www.applicationurl.com
As soon as we did this, the login page stopped working:
- if you log in with an incorrect username or password, it correctly tells you that you have made a mistake
- if you log in with a correct username and password, no error message displays, but instead of redirecting to the next page, the user is redirected back to the login page
Just to be clear, no changes were made to the application - it is still running on the same server with the same config settings. If I log on using either the internal or external IP address then the application works fine - once logged on I am redirected to the default page; it is only when using the external URL that I keep getting redirected back to the login page. The .css and images all load correctly for the login page.
This is .NET 3.5 running on IIS7 on Windows Server 2003.
Could you check web.config file's forms Element for authentication:
Check the path attiribute. is it "/".
Check the domain (if set).
On consultation with our IT team, I learned that the company that supplies us with DNS names was proxying the calls to our web server. When we switched the domain name to directly calling our IP address, the issue was resolved. I guess the proxy must have been modifying the HTTP calls or blocking cookies or something.
The way to check whether this is happening is to ping your domain - in our case, it was returning the IP address and domain name of our DNS supplier rather than the IP address of our web server.
We have a web application developed for use on the intranet of our client. There is no login page, hence there is no Forms authentication.
The application creates a number of records which have to be stored in the DB along with the name of the currrently logged in user. For this we have enabled windows authentication which works just fine in our development environment - and I assume, that when this is deployed on the envinronment of the client, it will work too.
The problem is, that when we host this on a test server, we need to give public IP access to the clients to check it out - and hence the virtual directory is configured to allow "anonymous access". This obviously causes a problem for us while storing the records since we are not able to capture the login name for the person who is creating/testing this application.
If we enable windows authentication for the test machine, then anyone who tries to access the app through the public IP gets a login window popup which we dont want.
Any ideas on how to capture the logged in user name for this scenario ?
Based on your design, user should log on a windows machine in your network the server is located. For that scenario, VPN would serve best and simulate real environment.
My ASP.NET MVC 2 application runs under built-in local NETWORK SERVICE account. I want to set up access permissions for the folder which resides in another computer, but in the same domain. I located that folder right-clicked to open its properties form, clicked to Security tab and pressed Add button which displayed Add user form with correct domain name in the location field. I referred to the account with following syntax:
<domain name>\<server name>$
because I learned that NETWORK SERVICE account uses machine account when connected to other computers in the domain.
However, the system couldn't find the account, so refuses to add the account. Without the domain name it adds a user, but that user seems to be local user, not web server's NETWORK SERVICE account. What am I doing wrong?
By the way, the above syntax worked when I created login for the sql server which is different computer from the web server.
OK, I will answer my own question. The above syntax \$ was correct. Just make sure to select computers checkbox in the object type, when adding user permissions.
I have been in this same situation before. I don't think I got it to work with the Server/Network Service but this might be worth a try.
Figure out the account network service is using to access the network resource.
Configure windows auditing (on the server the folder is located) to log the failed security events of the folder.
or monitor the folder with something like filemon.exe
.. from here you can try and add the account to the security settings of the forlder. (IIRC I did'nt ever get this to work)
Alternatively you can ensure the action is performed under the context of a domain user. Either by:
Impersonating the user in code and performing the action (my preference)
Setting the impersonation settings in web.config to a named user
setting the application pool to run as a domain user.
I have an ASP.NET website on a Windows 2003 Server, that needs to access files from a network share. The network share is password protected and needs a username and password to be provided.
I use forms based authentication on the website and not windows based.
So my problem is, when I try to read any file from the networkshare using the code below, it throws access denied
DirectoryInfo networkShare = new DirectoryInfo("\\TestServer\Share");
So I tried using Impersonate by providing the username and password of the network share to the impersonate function call, however the call obviously fails since that username does not exists on the ASP.NET webserver. So then I passed the username and password of a login that does exist on the webserver, so this time the impersonate call works however it still can not access the network share 'cuz the network share username and password are different.
So finally, I created the exact same username/password on the webserver which matches the network share. This time impersonate function call works and so does network share. I'm able to successfully read from the share.
So my question is, is there a way I can read the network share without adding the username in the webserver. 'Cuz everytime the network share login changes, I'll have to again make a new username in the webserver too. Which is not ideal.
Any ideas?
The "right" way to do this is to run the webserver's AppPool as the identity that can access the share. That way, the only credential storage is done securely in the IIS config (rather than in your code or in readable config files). Putting the webserver and fileserver in the same Windows domain (or different domains with trust) is the easiest way, but the "same username/password" thing should work there as well.
If you don't care about putting usernames/passwords in your code or config, you can P/Invoke to WNetAddConnection2 and pass the username/password- then you should be able to access the share. This doesn't require the webserver to have a matching account, but you really should secure the password (look into System.Security.Cryptography.ProtectedData for encrypted registry storage).