I have deployed my asp.net MVC application in a Azure environment behind load balancer. Same web application (simila files) are deployed in two Azure VMs' (cloned VMs). Deployments are identical.
Business logic
Session userID is stored in the cookie (created upon sign in), therefore if the server cannot read the cookie it is directed to sign out.
Issue is that when I send a sign in request from browser, lets say it hits Server A and then it sign in successfully. After few requests, once I hit the Server B directed by the load balancer, it signs out. Similar thing happens if I sign in with server B, then I sign out once I hit server A.
Both servers can be accessed as http and https. I tried with http and https modes, issue exists in both the modes.
I replaced the Server B machine configs (both Framework and Framework64) with machine configs of Server A.
I am still getting the issue.
Here is my configuration,
<authentication mode="Forms">
<forms cookieless="UseCookies" defaultUrl="~/Home" loginUrl="~/user/signin" domain=".mydomain.net" name="FormAuthentication" path="/"/>
</authentication>
<machineKey validationKey="XXXXXXXXXX7E8095B292DFC0984B71212747191E878380CADAA8166B0D9C8E8E7B174AF38897E28F82DXXXXXXXXXXCB0CF7ABA161AAC6D86EDBCAA93704EE7FC" decryptionKey="XXXXXXXXXXDE9EA41A2423A2CD293C01050202746F5650E7" validation="SHA1" compatibilityMode="Framework20SP1"/>
More info - Servers are named like server1.cloudapplicaiton.net, server2.cloudapplicaiton.net. Application domain is like mydomain.net.
Also, I programatically set the cookie name as "mydomain.net" upon Firmsauthentication sign in.
Am I missing something? Why can't a server read the cookie created by another server which has the same machine key and domain?
Related
I have set up an Azure Frontdoor Load Balancer with 2 backends, hosting an Angular app. When looking at the network traffic in the browser's developer tools, I see that only the first few requests for *.html and *.js files go to the loadbalancer. Beginning with the GET options request, all subsequent requests seem to go directly to the backend #2 (in red in the picture below):
This means, if the backend #2 goes down, the client gets 404 errors, and won't be automatically redirected to backend #1, unless the user reloads the browser window with F5.
I'm not sure how the Angular app gets the actual backend host's URL. I cannot see any header or cookie which would provide this information. The headers of the first request for login.html look like this - no sign of the backend URL anywhere:
My questions are
how does the client get the backend host's URL?
is there a way to define that ALL requests go through the loadbalancer?
Would that even be a good idea? Or is this the "intended behaviour", meaning that the user WILL see 404 errors and have to reload the page manually?
It the application that is doing it, not the azure front door. The app must be constructing the url based on where it is hosted and them making a request. The front door will set the host header same as the app service's hostname. In that case, the application would see it's request to come as if the user typed that in the browser. You would typically want to use custom hostname e.g. neonapp-dev.yourcompanyname.com. When you do that both app services and the front door would have the custom host configured. While configuring the front door, you would use this as a host header rather than the default which is app services host name. Then everything would work fine as the app would never see the app services name as host header.
More details https://learn.microsoft.com/en-us/azure/frontdoor/front-door-backend-pool#backend-host-header
I have an Azure Application Gateway sending user (HTTPS) traffic to a single backend web server, which is hosting an ASP .Net Framework 4.8 web application in IIS 10; users sign-into the web application using Windows authentication. The Application Gateway is not using cookie-based affinity (as there is only one web server). ASP .Net is using a SQL Server session state database:
<sessionState mode="SQLServer" stateNetworkTimeout="30" timeout="30" allowCustomSqlDatabase="true" sqlConnectionString="Data source=***********************;Database=ASPState;Integrated Security=SSPI;Persist Security Info=True" />
When users sign into the web application, as it is using Windows authentication, they are automatically authenticated using their Windows credentials, so they do not have to enter their user id and password. However, they will sometimes be signed in as the wrong user (someone else who is already signed-in). This only happens when using Application Gateway, and does not happen if the users go direct to the web service URL (bypassing Application Gateway).
When this bug happens, the application logs suggest that ASP .Net is getting the session id for the wrong user, i.e., the session id of the other user who is already signed-in. In Global.asax.cs, Session_OnStart the following gets logged:
Session.SessionID = sessionId for the wrong user
HttpContext.Current.User.Identity.Name = Windows userid for the wrong user
Session.IsNewSession = True
HttpContext.Current.User.Identity.IsAuthenticated = True (this is to be expected because Windows authentication is being used, so the user is already authenticated by IIS)
My guess is that Application Gateway is not persisting the user's Windows identity correctly between requests.
I have a Nancy rest api that is bound to http://*:12345 and uses windows auth.
When deployed it's being used by services on other servers fine using the DNS of the server (http://dns:12345/api/blah) but for some reason any service sitting on the same host cannot use this URL to access the API but must instead use http://localhost:12345/api/blah.
When I browse in IE on that server to http://dns:12345/api/blah I'm prompted with a credentials dialog. When I enter my credentials they always get rejected (despite having access, as proved by the fact that the same test from another server is fine).
I have build a MVC 5 application. Now is time to publish it to production.
The infrastructure consist of two servers: one that can be accessed on internet and the other that is accessed only in intranet.
Server is Windows Server 2012 R2 and uses IIS 8.5 to host the application.
The application consist of backend and frontend. Backend's functionality are accessible only with login.
The problem that I want to solve is: How can I prevent login to the application from Internet and allow it only in intranet?
I think that might be some configuration on web.config to prevent opening of login page.
I have read a lot articles, but all the results are to prevent pages of unauthorized users. In my case login controller has [AllowAnonymous] attribute and it can be accessed without authorization.
If it can be done with a simple configuration in web.config I am going to add a key in web.config to keep track where it is the server on internet or the server on intranet like:
//for server accessible on intranet
<add key="serverType" value="PUBLIC"/>
// or
//for server accessible on intranet
<add key="serverType" value="Private"/>
And in the corresponding controller for login I will check for the value and if it is ConfigurationManager.AppSettings["serverType"] == "PUBLIC" I will redirect it to site public home page.
Does this solution have any security issue?
In this case, I would change the config with transforms or Parameterization (I prefer this one) to use the appropriate authentication type. For example, Anonymous for public and Windows/Forms Auth for private. You would have a transform/parameterization for each server type.
The following posts provide more specifics around ASP.NET security.
https://msdn.microsoft.com/en-us/library/3yfs7yc7.aspx
https://msdn.microsoft.com/en-us/library/7t6b43z4.aspx
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
My web application production deployment is on 2 servers behind a load-balancer.
I'm using passport (local strategy) with session for authentication.
When the application runs on one server everything works fine, but in production one server doesn't recognize the cookie/session established by the other server (Each request gets randomally sent to a different server, I can't control it).
As a result - i'm redirected to the login page when attempting to access pages that require authentication (even after i login).
How can i get the two servers to create a session cookie that they both recognize (obviously i used the same secret for the express session middleware).
Thanks,
Alon
Option 1
Configure the load-balancer to always route the same ip to the same machine. Might be problematic for users who change network.
Option two
Use a third machine running the database and set up express.session (and any other database connections for that matter) to use that machine as store. This question/answer mentions how to do it with mongoose/mongodb.
I think this is the more common solution but is of course more expensive if you don't need a third machine.