Search results matching tag 'authdiag permissions'

How do I redirect to another web page when a user failed to authenticate through Integrated Windows Authentication?

Ricardo_777 — Wed, 19 Nov 2008 10:18:57 GMT

I am using Integrated Windows Authentication in my web application. Only a few pages are restricted and needs to be authenticated in order to access those pages. Now, what I am trying to implement is, in case a user bypassed the authentication by canceling the login dialog box, I want it to redirect to a default page. In case the user successfully authenticated then the user will get the corresponding page.

Somebody, help me please!

IIS6 - asp.net returns Identity of different user

Bunce — Wed, 13 Aug 2008 10:06:35 GMT

Greetings all – think I've got a rib-tickler for ya:

To get an overall idea of the usage of our in-house web-apps, I add in a bit of code which sends me an email whenever someone logs in (yeah – the apps obviously aren’t that busy)

The email just contains the login time and username (as returned by HTTP Context / Windows Principal etc) -> pretty standard stuff.

I noticed that for one particular user in a particular application, the username returned was not that of the actual user logging in. That is:

- Account that is returned is: “ABC\AdminPhil”
- Account that should be returned: “ABC\Phil”

Now Phil does use the AdminPhil account for administrative tasks on the domain (eg Server Administration), so its not a completely random account - but he is logged in with the Bill account on his workstation when logging into the app.

Application & Environment details are as follows:

- Asp.Net 2.0 web app
- IIS 6 (Win2K3 SP2) – Domain member (SERVERA)
- IIS: Integrated Auth on V.Dir - Anonymous Disabled – (suspect its using NTLM as I’ve not configured Kerberos?)
- Client machine: XP Pro SP2
- Client browser: IE7 (Integrated Auth Selected, but doesn’t alter the outcome either way)

So I initially went through the obvious to make sure it wasn’t an issue on Phil’s workstation (MachineX) or user profile (roaming).

- Ensured iexplore.exe process was running under ‘ABC\Phil’ account
- Forced launch of IE using ‘Run-As’ -> SAME RESULT
- Cleared out old profiles, temp files, etc etc, from MachineX -> SAME RESULT
- Logged Phil onto different MachineY -.> SAME RESULT
- IE Run-As ‘ABC\Phil’ on different box MachineY -> SAME RESULT
- Tried running IE as a different user on Phil's MachineX -> WORKS FINE
- Even RECREATED Phil’s profile! -> SAME RESULT

Ran ADSIEdit to look at the two accounts thinking there might be some type of SID conflict or similar but all looks fine..

This got me thinking it was something in the code on that app, even thought it was identical to

other apps where it returns the correct user string, so I created simple page with the following code:

******************************************************
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

    lblUser.Text = Page.User.Identity.Name
    lblWindow.Text = System.Security.Principal.WindowsIdentity.GetCurrent().Name
    lblThread.Text = System.Threading.Thread.CurrentPrincipal.Identity.Name

End Sub
******************************************************

Adding this to a fresh page within the existing web-app returns (incorrectly):

- ABC\AdminPhil
- NT AUTHORITY\NETWORK SERVICE
- ABC\AdminPhil

So I created a brand new website on the same server / different app pool / port -> SAME RESULT.

I then deployed the same code to a different server (Win2K3 – IIS6 – Domain Member) -> BINGO: It correctly returns:

- ABC\Phil
- NT AUTHORITY\NETWORK SERVICE
- ABC\Phil

So its Server-Specific. What could make a server in a domain believe IE is presenting credentials / ticket of a different user?

Does it cache these details somewhere in the metabase or the server itself and these have somehow become corrupt - Phil may well have logged into the server using his admin account (AdminPhil) to perform server tasks in the past..

I verified that both accounts did not have the same password in case a identical password hash somehow caused the issue..

I’m about to try the IIS AuthDiag tool to see if it picks up anything. I’ve also read that duplicate SPN’s on the domain might cause issues??.

Any other suggestions?

Thanks in advance,

Andrew

Failed Auth in IIS5.1

Cropy — Thu, 29 May 2008 13:10:28 GMT

I am using WinXP Pro SP2, IIS 5.1, .Net 1.1, .Net 2.0, VS 2003 , VS 2005, SQL Express 2005.

Basically I never was aware that there was anything wrong with my IIS settings untill I attempted to view a locally hosted SQL Report.

As you can probably guess (from the vast amount of postings on this subject) I was presented with the seemingly standard Logon Dialog box asking for User ID and Password (I know this is to do with a Loop Back check). I then spent the best part of a week reading through and printing information on the subject. I also downloaded IIS Diagnostic tools - AuthDiag etc.

I have not got anywhere with all the help that is provided, which is down to my lack of experience with IIS and computer admin issues. If anyone can suggest some alternative resources to do with system admin I would be grateful. I feel like I need a few years experience doing system admin just to understand what I need to do that will enable me to look at a very simple SQL Report on my own system.

Thanks

Problems with active server pages on Windows XP

deemurphy — Tue, 19 Dec 2006 02:07:56 GMT

I am running Winows XP Pro Sp2, When I type http://localhost I get the following: No web site is configured at this address. If I just create an asp file and try to view it front pages opens. How can this be fixed. It was working at one time, but I had to re-install all software on my system. I develop in asp.

Thank you

Dee

I am now getting the following and I download IE 7 today:

http: 500.100 error.

Thanks

Dee

Re: 'ASP 0177 : 800401f3'

chrisad — Sat, 07 Oct 2006 05:59:11 GMT

Hey there-

It has been two years since Ulad & I closed the doors on Authdiag 1.0 (Ulad is Dev, Chris the PM) so what I post here is completely on the spectrum of 'guessware'. However, I do believe that during our testing phase that PSS brought up the fact that ASP 0177 doesn't seem to be discoved by AuthDiag's Authmon features. I believe that Authmon will locate these failures if that the permission failure is related to registry (CLSID) or file permissons (NTFS).

Thus, give this a shot for troubleshooting:

My thoughts and\or steps are the following:

Download AuthDiag
Run AuthDiag using %programfiles%\iis resources\authdiag\authdiag.exe
From the drop-down, please choose 'Monitor URL Failures' ...
Enter the URL where you are failing (i.e. http://localhost/app/vdir ..
Click Start Monitor
After the IE opens up (and repros), then click Stop Monitoring
Click Analyze results

If it doesn't succeed or gives any false positives, drop us a mail at authdiag@microsoft.com (or reply here to this thread).

Hope this helps but if not let us know and we will get it added in future releases of Authdiag...

Thanks,

Re: Permission Settings in IIS

chrisad — Sat, 07 Oct 2006 05:23:49 GMT

Hey Dane-

You could possibly locate the problem using Authentication & Access Control Diagnostics (AuthDiag) 1.0 because no matter the locale the underlying source code for permission problems are in English. The particular feature you want to use (which we failed to make exposable enough) is the "Monitor URL Failures" feature that does real-time monitoring of authentication & authorization APIs and determines what is failing.

My thoughts and\or steps are the following:

Download AuthDiag
Run AuthDiag using %programfiles%\iis resources\authdiag\authdiag.exe
From the drop-down, please choose 'Monitor URL Failures' ...
Enter the URL where you are failing (i.e. http://localhost/app/vdir ..
Click Start Monitor
After the IE opens up (and repros), then click Stop Monitoring
Click Analyze results

NOTE: Authdiag does not work remotely, please do this on the Web server itself logged in as Administrator

If the results do not show any results that give you helpful information, please let us know - authdiag@microsoft.com.

Thanks,