GINA.dll

  • Thread starter Thread starter Craig Barraclough
  • Start date Start date
C

Craig Barraclough

Further to my post on mar 9.
Our VPN clients were having problems browsing the network
and using the exchange server.
I think i have finally found the problem.

I believe it is an authentication problem.

The clients VPN works fine when they connect from the logon
screen, i.e tick "logon using dialup connection" and choose
the vpn connection to use. This brings over their logon
scripts etc.

However, if they log on to their machines first, then open
the VPN they encounter problems, i.e. can't use exchange
server or mapped drives.

From what i have read i think it is a problem with the o/s
(2000/XP) only allowing 1 attempt to send username and
password to a DC.
Our cleints log onto their machines with domain
credentials, therefore when they have logged on and try to
use the VPN they are not being authenticated.

This is the passage from the post i read:-

"A common problem when trying to set up remote access VPN
tunnels involves the ability to both log in to your domain
as well as to browse resources on the central site LAN to
which you are tunneling. Ultimately you want to have the
same functionality present as if you were physically
located on the LAN itself and be able to log in and browse
as you normally would.

One of the most obvious causes of not being able to browse
properly involves Windows NT* or Windows* 2000 remote
systems not logging the remote user into the domain even
though you have followed the same steps as you would if you
were located physically on the network.

This issue arises due to the intrinsic security inherent to
these operating systems, which allows for one attempt, and
subsequent failure, by the remote machine to send user ID
and password to the Central Site Domain Controller located
on a remote LAN. When you start up your Windows NT* or
Windows* 2000 machine remotely and log in, your machine
cannot possibly contact the domain controller to supply
domain login credentials, but regardless of this fact the
machine sends the request out of one of its interfaces and
fails, usually resulting in the message

"No domain controller could be found, you may not be able
to gain access to some resources."

At this point you launch your Internet connection, or if
already connected, launch the VPN Client and tunnel in
successfully but discover that you are not able to browse
nor does your login script run. You find, however, that you
are able to ping machines by IP address as well as find
machines by name and are prompted for login credentials on
a server by server basis. This is because you have not
logged into the domain."

Is there a way around this problem, do i need to alter the
gina.dll?
Any other suggestions.
Thanks
Craig
 
Craig said:
Further to my post on mar 9.

Our VPN clients were having problems browsing the network and using
the exchange server.

I think i have finally found the problem.

I believe it is an authentication problem.

...

Is there a way around this problem, do i need to alter the gina.dll?

The "problem" you are documenting here is the correct behavior. Imagine
this scenario:

You are using a computer connected to a domain. You log on using a
local, non-domain account. Logon scripts don't run, and you don't have
permission to access your usual network resources. The reason is that
you're not logged on with a domain account. One of the purposes for
having a domain is centralized authentication. If you don't log on with
a domain account, you lose that advantage.

The same thing happens with remote VPN users. The best solution is to
make sure your users are correctly trained on how to properly log on to
the domain using a VPN connection.
 
Back
Top