Active Directory for Internal and External Users

System.Web.HttpContext.Current.Request.LogonUserIdentity.Name.ToString should tell you if a person is logged in to the domain or not.  If not, redirect the user to a page where they can log in via forms authentication.

In order to access your IIS, you  must be logged in with a valid Windows  user account. If you
choose to allow anonymous access, your users will access your website through a user account
called IUSR_
computername
. This user account is created when you install IIS, and can be
viewed and managed through Active Directory Users And Computers.
The IUSR_
computername
user account is limited in that it only has guest access permissions
(this account is added to the local group Guests on the computer that has IIS installed).
The IUSR_
computername
account is restricted so that it can only log on locally to the IIS
server and is not able to access other computers within the Windows 2003 domain. The use
of the IUSR_
computername
user account allows anonymous users to access your web server
without needing a unique Windows username and password.

You can then build the account redirection into your secure  external site.

Dont forget to configure your security firewalls/ISA server.

One way to ensure that you have a secure communication channel when communicating with
a website via the Internet is to take advantage of Secure Sockets Layer (SSL).
SSL provides the following advantages:
_
There is a secure path created between the client and the web server so that data can’t be
diverted to another computer


Alternatively you can use a third part app theat runs on IIS and talks back to AD such as Citrix, a cheaper solution is to use DotNet Nuke to handle the external website login.

Wizard -- This does not work since the Request.LoginUserIdentity.Name is the Anonymous User name if we do NOT use windows auth.  If we use windows auth, external users can’t get in.

Technocity - If I follow correctly, it has the same issue as Wizard's post - there is no way to authenticate internal users as there identify will be USR_ServerName.

How about this then:

If Not Request.ServerVariables("REMOTE_ADDR").ToString.StartsWith("192.168.") Then
     Response.Redirect("/formslogin.aspx")
Else
     Response.Redirect("/adlogin.aspx")
End If

Inject this into the Page.Load and anyone on the local network (replace "192.168." with whatever you're using) will go to one page, non-local users to another.

The problem we are running into is I.E. does not pass credentials to web pages that are not A) using Windows Authentication and B) On the intranet: http://support.microsoft.com/kb/258063
"Internet Explorer must consider the requested URL to be on the intranet (local). If the computer name portion of the requested URL contains periods (such as http://www.microsoft.com and http://10.0.0.1), Internet Explorer assumes that the requested address exists on the Internet and does not pass any credentials automatically. Addresses without periods (such as http://webserver) are considered to be on the intranet (local); Internet Explorer passes credentials automatically. The only exception is addresses included in the Intranet zone in Internet Explorer. "
So while I can make a landing page that uses Windows Authentication, if the start page is available to external users, the URL is of a form that doesn't pass credentials, and windows authentication fails.  Is there any way to force I.E. to pass the network credentials?  Can we have the SAME website be accessed by an internal and external address?

thanks

I added the domain to the intranet as you mention above.  So my landing page uses forms authentication.  It checks the Request URL and if it is internal, it does a response.Redirect to a new landing page that has Windows Authentication set in IIS.  This page does the auth and takes me to the main page, BUT now whenever I click on any menu item on the main page, I get this error:
Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.6; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8; .NET CLR 1.1.4322)
Timestamp: Thu, 10 Mar 2011 19:18:23 UTC


Message: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
<!DOCTYPE html PUB'.
Line: 4723
Char: 21
Code: 0
URI: http://devserver.yorklabel.com/YourAccount/ScriptResource.axd?d=bDeE3mvBcnJhlLvnK03o-d3Kmx5PKjYTidZaC9lfZiL70rtUFvDq-u-CSwWCN-Gp1NjwYUkU7mn26ktHTZ2uVOvRHO9rkkuXg_fKNuwKkvGQ28oID3jmoAXRZqzF5G_-V7uNqjJ_Ltbk4cv-AwLsGOskDND5UoDR3x30vJWMpZPFujoy0&t=7adc1b3f

Seems like I am getting close, but I am not quite done yet.
thanks

Are the menu items (each page, I guess) keyed to one type of authentication or the other?  Does it work if you log in as a non-domain user?  Is there some value (session variable?) that gets set if you authenticate as one type of user versus another?

The website itself is Forms Authentication.  I added a single page of windows authentication for the intranet users.  When I login from the Window Auth page and go to the (form auth) main page (that has been in production for 6 monthes now) I get the error above when I click on a link on the SiteMenu and it doesn;t leave the page.

I guess my question is: If a person logs in via Forms Authentication, is there some value (a session variable or some such) that gets set?  If so, does the same thing happen when you log in via Windows Authentication?  There seems to be some process that's taking place in one scheme that isn't taking place in the other.

I modified the Forms Authentication landing page to NOT forward internal request IP’s to the windows authentication page and then re-logged in using forms authentication.  The menu worked correctly.

Here is the code from the page load of the Windows Authentication page:
            if (!IsPostBack)
            {
                string userName = this.Request.ServerVariables["LOGON_USER"];
                GetUser(userName);
                Response.Redirect("~/Default.aspx");
            }

I do not see how this can be breaking the asp:Menu on the default page.

thanks

Me, either, but there may be some code behind the menu to turn on and off menu items based on who is logged in.  That code may be breaking because something it needs doesn't get configured when you log in via Windows Authentication.  Your testing seems to bear that out.  A good example of that might be simply putting the user's name at the top of the page...

The menu is built dynamically based on the credentials of the user.  Unfortunately I can not recreate this issue in the debugger.  I will do a step through on localhost and see if anything looks suspicous.  Do you have any suggestions on what I should be looking for?

thanks

Yes - see if you can determine what the menu is using as the basis for the user's credentials.  I'd guess that's what's breaking when you log in via Windows Authentication.  

Loggging in via Forms Authentication sets some value(s) the site needs to generate the menu.  You need to replicate that (those) value(s) on the WIndows Authentication side.

FYI: The menu is dynamically built using OleDBCommand call to a stored procedure.  We are not using the Active Directory roles/users for validation since we have external customers that can not be setup in A.D.  I stepped through both paths and the content of the menu does not appear different when coming from the Forms page or the AD page.  I have done a lot of searching on the error that I am seeing, and most cases mention that a Response.Write causes an error doing asynchronous postback (I am not doing a response.write, just response.redirect).  Is there a way to mimic the asynch postback of the menu synchronously?  I tried using PostBackTrigger rather than:
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
        <Triggers>
            <asp:AsyncPostBackTrigger ControlID="SiteMenu" EventName="MenuItemClick" />
        </Triggers>

But while that caused a postback, postbacktrigger doesn’t have an eventname so nothing called my event to do the redirect from the page.

"The menu is built dynamically based on the credentials of the user."  My question is:  How does the menu know what the user's credentials are and are those credentials being set the same way regardless of how they are authenticated.  

You know the menu works when you log in via Forms Authentication, but breaks when you use Windows Authentication.  So what's different - from the menu's point of view - between those two types of logins?

Ok, I just commented out the jump to the A.D. page, logged in from the forms auth page and then did a View Source/Save on the default.aspx page.  Then I uncommented out the jump to the AD page, went back to the default.aspx page and did a View Source/save.  I compared the files using Visual Source Safe and they are identical.  So the issue must be with a cookie or something.  Any ideas?

thanks

Okay, let's go a step further.  Since the site breaks when you click a menu item, can you determine what it might be on the destination page that's breaking?  Or maybe it's something in the menu itself, since it's being built dynamically.  

Something about the environment is different (and it's likely something you won't see by looking at the page source) when you log in via Forms Authentication versus Windows Authentication.  You need to figure out what that difference is and replicate it on the Windows login side.

Now my ASP:Menu is not working correctly, but Active Directory is auto-logging in on intranet w/o IIS prompt on extranet.