Remote Authentication

  • Thread starter Thread starter Jim Mc
  • Start date Start date
J

Jim Mc

We've got a company intranet web site running on a Win2k member
server. We've poked a hole in the firewall and permit access to the
site from the Internet for employee's who are at home or on the road.
The site is protected using ACLs and employees authenticate against
the domain.

We'll be moving this web server and another server to a data center
soon for better availability, security, etc, but wish to continue to
authenticate users against the domain.

How can we best do this? I assume we'll need a DC on the colocated
network. Should the DC be in the same domain? Can it securely sync
with the local DCs over the Internet or should we use a VPN for this?

Thanks,
Jim
 
If this site is not fore everyone eyes, then
a) Maybe implement custom authentication on the web page with passwords well
encrypted or
b) better solution would be to use VPN and let remote users VPN to your
network and use intranet pages.

--
Regards

Matjaz Ladava, MCSE (NT4 & 2000), Windows MVP
(e-mail address removed)
http://ladava.com
 
If this site is not fore everyone eyes, then
a) Maybe implement custom authentication on the web page with passwords well
encrypted or
Click to expand...

This could be done, but if implemented within the application itself,
it would require a complete rewrite of the app. If I wanted everyone
to use a second password, I'd just continue to user ACLs and just
create employee accounts on the remote network, either within a
domain, or possibly even local accounts on the web server.
b) better solution would be to use VPN and let remote users VPN to your
network and use intranet pages.
Click to expand...

VPN access is a PITA for home users. I already have enough headaches
with supporting employee's home computers every damned time they catch
a virus or screw up installing new software. The site is currently
accessed via SSL, which requires no setup on outside computers.

I'm just looking for a way to continue authenticating against the
domain. If need be, though, I'll create new user accounts on the
remote network and everyone will just have to live with two passwords.
 
I would close the holes in the firewall, and configure a VPN. It's much more
secure.

If I understand you right... The only reason to include a new DC in the data
center is if authentication requests take too long to reach the original DC.
Of course, if you install a new DC, then you have to worry about replication
bandwidth (maybe set up sites), and associated issues.
Click to expand...

Not really. I wasn't aware that I could have the remote web server
authenticate against the original DC. How would this be set up and
what are the security implications? What holes would need to be
opened through the firewall and are any username/passwords exposed in
the communication?

One thing I'm a little leary about, even if this is feasible, is that
the main office Internet connection isn't quite as reliable as I'd
like. Not much can be done about that without spending some bucks on
redundant upstream connections. In fact, this is probably the main
reason for moving the web server to colocation in a quality data
center. If that remote web server was unable to contact the DC to
authenticate a user, would that prohibit the user from logging into
the web site, or would the web server use cached credentials?
 
The web server could use cached credentials, but you would have no control
over which credentials were cached, so this is not a reliable alternative.
Click to expand...

Not so fast...

I said "not quite as reliable as I'd like", not something that will be
offline for days. Say the home network lost it's connection to the
'net for an hour, so that the remote server couldn't contact it to
authenticate. Would that affect the ability for users to login to the
remote network? That's why I asked about cached credentials - just to
cover a 15 minute outage, network problems, routing issues, what have
you.

I don't quite follow what you mean by "no control over which
credentials were cached".
 
Then use web server local accounts + HTTPS only and basic authentication as
NTLM probably won't pass the firewall (depend on the firewall,
settings,...). More secure approach would be SecureCards fro authentication
with the certificates if security is important. You could also leave them to
use domain passwords.

--
Regards

Matjaz Ladava, MCSE (NT4 & 2000), Windows MVP
(e-mail address removed)
http://ladava.com
 
Not so fast...

I said "not quite as reliable as I'd like", not something that will be
offline for days. Say the home network lost it's connection to the
'net for an hour, so that the remote server couldn't contact it to
authenticate. Would that affect the ability for users to login to the
remote network? That's why I asked about cached credentials - just to
cover a 15 minute outage, network problems, routing issues, what have
you.

I don't quite follow what you mean by "no control over which
credentials were cached".
Click to expand...

A domain computer (and this could be your web server) will cache the last X
people to log in (10, by default). If the computer can no longer
authenticate with a DC, only the last 10 people logged in will be able to
login again. If logged in using cached credentials, any non-local resource
requiring domain authentication will be unavailable. (In the words of
Microsoft: "The primary purpose of logging on with cached credentials is to
enable you to access the local workstation.")

When I say you have no control over which credentials are cached, I mean
that any 10 (or 50, I think, is the max) people could log on just before the
connection is lost, and the credentials you want may not be available. Local
accounts will work, DC or no, so you can probably use the web server's local
administrator account to log in if you need to administer the server when a
DC is unavailable.

You may want to peek at KB306150, and other articles that result from
searching the knowledge base for something like "cached logon".

\\ MadDHatteR
 
Back
Top