I tried to access the username DomainControlle
I succeeded with the following code
Request.ServerVariables.Get("logon_user");
System.Security.Principal.WindowsIdentity.GetCurrent().Name;
System.Security.Principal.WindowsPrincipal(System.Security.Principal.WindowsIdentity.GetCurrent()).Identity.Name;
with web.config
<authorization>
<deny users="?"/>
<allow users ="*" />
</authorization>
</system.web>
If the configuration code is not in the server, the code will not work
My problem is this. Internal users of the domain are working. Users outside the domain give an error. Unauthorized
I want to direct the domain's internal users to the next login page. And users outside the domain can see the login page
Thanks for your help
Related
We recently converted a Framework 4.8 WebForms project that was using Forms Authentication to use Identity 2.0 Authentication and now we can't access default documents or images without allowing anonymous access.
Once authenticated with Identity, if you browse to a folder such as http://mysite/dashboard/default.aspx it works fine. However, if the default page is not in the path as in http://mysite/dashboard/ it returns 401.2 as though IIS needs permissions to server the page :
*Access is denied. Description: An error occurred while accessing the resources required to serve this request. The server may not be
configured for access to the requested URL.
Error message 401.2.: Unauthorized: Logon failed due to server
configuration. Verify that you have permission to view this directory
or page based on the credentials you supplied and the authentication
methods enabled on the Web server. Contact the Web server's
administrator for additional assistance.*
We have <authentication mode="None"> which I understand is correct for this situation. IIS is configured to use default documents just as it was when we were using Forms Authentication.
We also deny unauthenticated users with the System.Web.Security.UrlAuthorizationModule:
<authorization>
<deny users="?" />
</authorization>
If we allow anonymous on the folder it does work but we don't what anonymous access on these locations.
<location path="Dashboard">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
So, how do you configure IIS to access default documents without 'allow anonymous' so it works like it did under Forms Authentication.
Thanks!!!
Try to add this to the System.Webserver section
<modules>
<remove name="FormsAuthentication"/>
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
</modules>
The key seems to be to remove the managedHandler Precondition from the FormsAuthentication module. As I understand it this is only supposed to optimize serving of static content.
Found that adding <modules runAllManagedModulesForAllRequests="true"> to the web.config resolved the issues. Not really sure why at this point. I did notice that the request for a static file did not include the user identity which was working before removing Forms Authentication. After adding this, the user identity started showing up in the request.
I have a controller with [AuthorizeWebForm] attribute.
Now, If I am not login and I want to access that page, then it gives me
HTTP Error 401.0 - Unauthorized.
You do not have permission to view this directory or page.
Now, How can I Handle that with using [AuthorizeWebForm] attribute? If I am not logged-in and try to access that page, then it should redirect to Login page.
I got solution. I just put below code to my web.config. the session was already checked in custom error class. if session is null, then it is redirecting to login page.
<authentication mode="Forms">
<forms name=".SomeLoginCookie" loginUrl="~/Account/Login" timeout="2880" protection="All" enableCrossAppRedirects="true" />
</authentication>
I want to do this via code if possible, I want to allow glimpse to be accessed only by administrative users, how can this be achieved?
The website states it is possible - cant seem to find the exact link though
http://getglimpse.com/
You could turn glimpse off by default and restrict the /glimpse.axd config panel to administrators only:
<location path="glimpse.axd">
<system.web>
<authorization>
<allow roles="Admin"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
In Glimpse 1.4.1, they provide a GlimpseSecurityPolicy.cs that will easily allow you to set authorization in code instead of using the element.
I have given anonymous access to my service. And I m able to access with out establishing credentials.
I wanted to make use session in wcf service, for this I m trying to use aspNetCompatibility Enabled to true in system.serviceModel. When I included this line, it is redirecting me to login page whenever I m requesting service.svc file. Any guess as to why it aspNetCompatibility Enabled overriding access policy? What should I do to overcome this?
Once the aspNetCompatibilityEnabled is true, the ASP.NET pipeline comes into the play and its authentication and authorization is dome. Check the system.web/authorization section in the web.config. Do you have deny users? If so, remove it. you may also try to add
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
I'm having reports and complaints from my user that they will be using a screen and get kicked back to the login screen immediately on their next request. It doesn't happen all the time but randomly. After looking at the Web server the error that shows up in the application event log is:
Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket supplied has expired.
Everything that I read starts out with people asking about web gardens or load balancing. We are not using either of those. We're a single Windows 2003 (32-bit OS, 64-bit hardware) Server with IIS6. This is the only website on this server too.
This behavior does not generate any application exceptions or visible issues to the user. They just get booted back to the login screen and are forced to login. As you can imagine this is extremely annoying and counter-productive for our users.
Here's what I have set in my web.config for the application in the root:
<authentication mode="Forms">
<forms name=".TcaNet"
protection="All"
timeout="40"
loginUrl="~/Login.aspx"
defaultUrl="~/MyHome.aspx"
path="/"
slidingExpiration="true"
requireSSL="false" />
</authentication>
I have also read that if you have some locations setup that no longer exist or are bogus you could have issues. My path attributes are all valid directories so that shouldn't be the problem:
<location path="js">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="images">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="anon">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="App_Themes">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="NonSSL">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
The only thing I'm not clear on is if my timeout value in the forms property for the auth ticket has to be the same as my session timeout value (defined in the app's configuration in IIS). I've read some things that say you should have the authentication timeout shorter (40) than the session timeout (45) to avoid possible complications. Either way we have users that get kicked to the login screen a minute or two after their last action. So the session definitely should not be expiring.
Update 2/23/09: I've since set the session timeout and authentication ticket timeout values to both be 45 and the problem still seems to be happening.
The only other web.config in the application is in 1 virtual directory that hosts Community Server. That web.config's authentication settings are as follows:
<authentication mode="Forms">
<forms name=".TcaNet"
protection="All"
timeout="40"
loginUrl="~/Login.aspx"
defaultUrl="~/MyHome.aspx"
path="/"
slidingExpiration="true"
requireSSL="true" />
</authentication>
And while I don't believe it applies unless you're in a web garden, I have both of the machine key values set in both web.config files to be the same (removed for convenience):
<machineKey
validationKey="<MYVALIDATIONKEYHERE>"
decryptionKey="<MYDECRYPTIONKEYHERE>"
validation="SHA1" />
<machineKey
validationKey="<MYVALIDATIONKEYHERE>"
decryptionKey="<MYDECRYPTIONKEYHERE>"
validation="SHA1"/>
Any help with this would be greatly appreciated. This seems to be one of those problems that yields a ton of Google results, none of which seem to be fitting into my situation so far.
It may also be worth checking the Maximum Worker Processes property for your application pool. If you are using in memory session and have more than one as the max worker process you can find session issues as a users request is handled by a different thread that is unaware of their session.
Since you have noted that you are using a very specific FQDN for your site, do you have any other .Net applications running under the same FQDN just different virtual paths? The name of the auth cookie might be the same for both applications, but the token will be different. So if I log into www.domain.com and then to www.domain.com/app2, I will no longer have correct authentication for app1.
1.) Check how often your iis process gets recycled. (Turn on logging and check your settings). After a recycle, using the default in proc session store, the session is lost.
2.) Does your application spawn Threads that may throw an Exception (which are btw not displayed to the user)? Because if that situation exists the iis recycles processes far more often.
I have just finished dealing with this precise problem, exactly as described in the question and the issue was some missing config in web.config.
When using formsAuthentication, you need to stop having the session handle authentication, as the cookie is now responsible for it.
This line needs to be added (or updated) in your web config, in the "system.web" element
<sessionState mode="Off">
sessionState and formsAuthentication should not both be active. I don't understand the fine details of how they interfere with each other, but in this case, it produced random log outs of random users at random times.
Our site has stumbled with the same problem for years, but yesterday we found a fix, see my question. As a commenter suggested, I tried adding this to web.config:
<sessionState mode="InProc" timeout="60" />
Apparently, the timeout must be set both in sessionState and in the ticket. See also ms docu in https://msdn.microsoft.com/en-us/library/ms178586.aspx
To more accurately measure the actual timeout while in debug mode, I found it handy to add Debug.WriteLine calls in file Global.asax.cs in methods Session_Start() and Session_End(), with millisecond time added using
string.Format("{0:HH:mm:ss.fff} - {1}", DateTime.Now, strMessage);
so that you can login, go for lunch, let the session time out, and read the time stamps at some convenient moment in the VisualStudio Output window.