Internet vs Intranet

[Jawahar Rajan]

All,
I am working on a project that requires the companies clients to login to
our web site.
however for employees of the companies they do not want to have a login. But
a lot of the asp pages that I have depend on the login being successful
because it return some values about the user privileges etc.

I am thus allowing company employees to by pass the login and get access to
everything!.
But to do this I need effectively set up behind the scene login to the
database.
I thought that I could trap the IP address of each request to our IIS server
and based on the IP address I will force a login or if from the company
itself I can do a behind the scene login.

Is this a good approach>
I am trying servervariables("REMOTE_ADDR") and
ServerVaraibles("REMOTE_HOST")
both return only IP Address.
can I actually get the name of the server name ( The server that makes the
request) this way It is easy to tell if it is Intranet or internet

Any thoughts?

Thanks
Jawahar Rajan

 

[Andy Sutorius]

Your solution may not be the best if your organization is using DHCP. For instance what if a contractor came into your organization and
connected their laptop to your network? They would get the same server name as the employees, yes?

How about this? I assume all employees are logging onto the workstations in the morning which then authenticates them as "Domain Users".
Depending on if you have your intranet in a seperate domain you could make the folder with all of you webpages "Integrated Windows
Authenticated" instead of "Anonymous Access". Then set your web server to allow "Domain Users" from their workstation domain.

That would lock out the contractor scenario because, at least in our organization, we don't give contractors domain logon accounts which
prevents them from accessing any of the servers due to lack of authentication. All they have access to is the internet through a proxy
server.

Hope that helps.

Andy Sutorius
www.sutorius.com

 

[Ray at]

Have your employees access your intranet by going to
http://namewithoutanydotsinit and turn off anonymous access for the site.
When the users access the site internally with the internal address, IE will
send the users' network logon credentials automatically. People will not
have to log in, and the server will know who they are.

Ray at home

 

[Dave Anderson]

...turn off anonymous access for the site. When the users access
the site internally with the internal address, IE will send the
users' network logon credentials automatically. People will not
have to log in, and the server will know who they are.

I beg to differ.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Ray at]

Care to elaborate and/or debate? :]

Ray at home

 

[Dave Anderson]

...But, they log in to Novell AND a 2000 domain...

I assume the "automatic" credential exchange comes from the domain
credentials (or perhaps Active Directory), because the exchange is clearly
not automatic on our network (NDS/iChain, but not Active Directory, few
users connected to domains).

In any case, I stand by my assertion. Merely turning off anonymous access is
insufficient for triggering such behavior in Internet Explorer.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Chris Hohmann]

I assume the "automatic" credential exchange comes from the domain
credentials (or perhaps Active Directory), because the exchange is clearly
not automatic on our network (NDS/iChain, but not Active Directory, few
users connected to domains).

In any case, I stand by my assertion. Merely turning off anonymous access is
insufficient for triggering such behavior in Internet Explorer.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

<reply tone="sarcastic">
I must be running the special version of IE reserved for the very
important people, because it works just as Bob advertised.
</reply>

 

[Chris Hohmann]

<reply tone="sarcastic">
I must be running the special version of IE reserved for the very
important people, because it works just as Bob* advertised.
</reply>

*Ray (Ray, Bob, Aaron... you know what I meant, one of those guys in the
know).

 

[Ray at]

he he
Jerry* owes me a beer then. It's a shame that Fredrich° doesn't care about
this anymore though. [:

*Dave
°Jawahar Rajan

Ray at home

 

[Dave Anderson]

Yes it will, with default security settings. When IIS sends back a 401
status with WWW-Authenticate: Negotiate or NTLM, IE will send your NT logon
credentials. Sure, it won't send any Novell logon credentials or anything,
but if you're logged in to Novell, IE doesn't care. It will still send your
NT credentials, unless you have changed your security settings.

The credentials are only sent *automatically* if the client has successfully
logged into the domain. User interaction with an NT Challenge dialog box is
not my definition of "automatic".

http://support.microsoft.com/default.aspx?scid=KB;EN-US;264921


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Ray at]

Well, yeah, if he hasn't logged in, what credentials would there be? Local
accounts? That would mean nothing to the server (possibly in a workgroup
environment with the same names and passwords on both machines), so of
course the user would then be prompted to enter logon credentials for the
server. I don't know if you have a domain or not, but if you do, and you're
getting prompted for logon credentials, something's up. (Assuming you're
using IE.)

Ray at home

 

[Chris Hohmann]

All kidding aside, I'd like to find out why it doesn't
work in your environment.

I think we've established that the reason it doesn't work is [lack of
domain]. However...

My environment sounds similar to your. We have a mixed Novell/Windows
network with no domain. The account information on my workstation
matches my account information on our production web server.
Pass-through NT authentication works when I hit both the production web
server and the web server running on my machine. I am able to pass
through authenticate irregardless of where I am, so long as the client
machine is I'm on recognizes the web server as part of it's intranet as
defined in IE -->Security-->Local Intranet. In fact, I've add both my
workstation and the production server to the Local Intranet site list on
my home computer and am able to pass through authenticate from there as
well. Just thought you'd like to know.

-Chris

 

[Ray at]

This doesn't sound good for a large solution though, because what happens
when a user changes his NT password? I'm really sorry that you don't have a
domain. :[ They make things so much easier...

Ray at home

All kidding aside, I'd like to find out why it doesn't
work in your environment.

I think we've established that the reason it doesn't work is [lack of
domain]. However...

My environment sounds similar to your. We have a mixed Novell/Windows
network with no domain. The account information on my workstation
matches my account information on our production web server.
Pass-through NT authentication works when I hit both the production web
server and the web server running on my machine. I am able to pass
through authenticate irregardless of where I am, so long as the client
machine is I'm on recognizes the web server as part of it's intranet as
defined in IE -->Security-->Local Intranet. In fact, I've add both my
workstation and the production server to the Local Intranet site list on
my home computer and am able to pass through authenticate from there as
well. Just thought you'd like to know.

-Chris

 

[Dave Anderson]

My environment sounds similar to your. We have a mixed
Novell/Windows network with no domain. The account
information on my workstation matches my account
information on our production web server. Pass-through
NT authentication works when I hit both the production
web server and the web server running on my machine. I
am able to pass through authenticate irregardless of
where I am, so long as the client machine is I'm on
recognizes the web server as part of it's intranet as
defined in IE -->Security-->Local Intranet. In fact,
I've add both my workstation and the production server
to the Local Intranet site list on my home computer and
am able to pass through authenticate from there as well.

Even when I do all of the above, I do not have pass-through authentication.
I'm really stumped.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Ray at]

And you setup accounts on your machine and the IIS server with the same
username and password? And neither machine is in a domain, correct?

When you access the server in IE, does it indicate Intranet Zone in the
status bar?

Ray at home

 

[Dave Anderson]

Even when I do all of the above, I do not have pass-through
authentication. I'm really stumped.

[NOTE: The lack of continuity in this message is due to the fact that it was
a work in progress throughout the debugging steps I outline below. Please
forgive any seeming contradictions that may result.]

I think I have a partial explanation for my problem: the Internet Explorer
Enhanced Security Configuration (I'll just refer to it as the IEESC from
here on). I'll return to this in a moment.

The suggestion that I put the server in my local intranet zone got me
thinking. I don't believe I had ever tried that before, but I'm certain that
if I try it now, pass-through authentication fails. But I recently rebuilt
and have been testing Windows Server 2003 as my local OS**, and even though
I removed the IEESC for administrator groups, it *was* part of the original
install, which may be a factor.

On a hunch, I went to a Win2K machine (all updates, most recent IE version),
and tried connecting to my development server, which is Win2K/IIS 5. Instead
of the usual [HTTP 401.2 - Unauthorized: Logon failed due to server
configuration], I was met with an NT Challenge dialog.

This was an improvement, but still did not represent pass-though
authentication. From this different behavior, I inferred that perhaps the
IEESC was to blame for my complete inability to connect, though it's still
possible that some policy or privacy setting is tripping the whole thing up.

I tried another test, applying the same access control settings to an old
web server sitting on the local switch (our actual web servers are a few
miles away in another facility). Both my Win2K machine and my local machine
worked correctly!

I started wondering what might be different about my development server. The
answer turned out to be that it has a DNS entry. When I point my browser to
{ http://machine/application/ }, I get pass the pass-through authentication
I desire from every machine. But when I point to {
http://machine.company.com/application/ }, the Win2K machine puts up an NT
Challenge dialog box and the 2003 machine just rolls to the HTTP 401.2 page.
Pointing to the IP Address causes this second behavior, as well.

This behavior occurs despite the status bar showing Local Intranet zone on
each machine. The reason my test worked on the local switch was that the
local server has no DNS entry, meaning I had to use the machine name only.
When I switched to IP address for the local server, I was again rejected,
even after adding that IP address to the Local Intranet zone.

I find this to be an awfully frustrating "feature". At least it has
generated an interesting discussion.




**I put a lot of tools on my own site and use it as a start page for my web
browsers, and discovered some time back that I don't even generate the
majority of traffic to my own site -- my coworkers use it quite frequently,
necessitating the need for a server version of the OS (Professional limits
IIS to 10 simultaneous sessions, which wasn't nearly enough). Anyway, I've
been evaluating Windows Server 2003, and figured the local machine was the
logical place to start.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

I can't explain why the W2K people are okay. They hit DNS
before WINS, I'd imagine, but there's apparently something
that's different in W2K.

I wish someone would explain why WINS/DNS matters at all within the Local
Intranet zone.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Ray at]

Well, I guess because DNS likes FQDNs. WINS doesn't know about that.

What I hate is the way that IE is not smart enough to see that if a computer
is a member of companydomain.com, and the user is at host.companydomain.com,
that isn't interpreted as the intranet zone. The whole method of using dots
is bogus, I think.

Ray at home