Offsite DNS question

[jsmall]

Hi,

You see this one everywhere.

Q: My logon is slow
A: Use your internal AD integrated DNS, and not your ISP's

Works fine of course. Now imagine, domain.com users take their laptops
offsite, where the only way they can access the Internet is to use
their ISP's DNS.

domain.com's AD DNS server is inside their network, behind a firewall,
whereas externally, domain.com is managed by a Linux BIND DNS server
with totally different domain information (no internal IPs).

There is no reason an external user should resolve or have access to
any of the AD information, and for security I'd like to keep it this
way.

However, we get the painfully slow logon when home users login.

Is there a way around this? Maybe an entry we can add to the external
DNS server?

 

[jsmall]

Just to amend this.
It has been suggested staff user a local logon whilst offsite.

This is very problematic due to staff training issues- it's easier just
using the cached network logon so it's the same no matter where they
are.

 

[Kurt]

So they must be set up for getting a DHCP address, mask and DNS server form
their ISP? What about handing them the required internal ip numbers via DHCP
when they plug into your internal network? If you're worried about security
yo could reserve a scope just for those MAC addresses. How do they get
settings changes now? Or (Oh, I can see the flames coming...), if you must
configure manually, configure your Internal DNS as the primary, and their
ISPs DNS as the secondary. There ARE some issues with this setup, but
compared to 25 laptops taking 20 minutes to log into the local domain every
day, I'd say the former wins.

....kurt

 

[jsmall]

Hi Kurt,

I don't beleive I have been understood correctly.

Whilst onsite, where they actually have access to the Active Directory,
the users receive, from the DC, a DHCP lease which puts the correct IP
and DNS settings on their machine. Effectively, the Internal network is
"technically perfect".

Once a user goes home, they might for example, use a dial up Internet
connection, where the ISP dishes out the IP and DNS server. Therey's no
way around this- simply changing someone's IP address is not something
the ISP is going to go with. Changing DNS servers is unhelpful because
the AD Integrated DNS server discussed above is not accessible from the
Internet.

Whilst using the ISP's DNS servers (as a user at home should do) we
realise of course the user isn't going to authenticate to the Active
Directory which is behind a firewall tucked away. We just don't want
the PC to sit there for 20 minutes trying to find it before timing out.

 

[Andrew Story]

I work from Home regular, and have no issues with DHCP between working at
site and home

Work network = DHCP internaly assigned address and associated IP settings

Home network = DHCP internaly assigned address and associated IP settings

I'm not sure I understand your issue correctly, both are seperately assigned
address, have you had your user run an ipconfig/all before connecting to
thier ISP and tell you the results?

Try a logoff script for your laptop users to force a release of IP settings
when on site.

 

[Kurt]

That shouldn't be a problem. If you want to speed things up a bit, just keep
the network cable unplugged (if Ethernet to a broadband device) while
logging on at home. With no network connection, there will be no attempt to
contact the DC. Dial-up should have no effect whatsoever, unless something
is configured to dial before a logon (like a VPN). I have a laptop that
connects at work and home (logging into the domain properly at work and
using cached credentials at home), and I don't have extended logons.

 

[jsmall]

Hi Andrew,

This isn't a DHCP issue.
Yes you are correct in your statements below:
Work network = DHCP internaly assigned address and associated IP
settings
Home network = DHCP internaly assigned address and associated IP
settings

Yes, this works and yes, in response to Kurt's post below, if you
unplug the laptop whilst logging on at home, things work fine. This
however is not a solution users would be satisfied with.

However, it's the MASSIVE lag during logon from home that is
problematic. Because domain.com a valid domain externally- it's just
not managed by a proper AD DNS server.

You know how people with logon speed issues on their own networks are
always told to use their network's DNS server, and not their ISP's? I'm
thinking along those lines- what does said user do at home, when they
have to use their ISP's DNS server?

 

[Ace Fekay [MVP]]

In

Hi Andrew,

This isn't a DHCP issue.
Yes you are correct in your statements below:
Work network = DHCP internaly assigned address and associated IP
settings
Home network = DHCP internaly assigned address and associated IP
settings

Yes, this works and yes, in response to Kurt's post below, if you
unplug the laptop whilst logging on at home, things work fine. This
however is not a solution users would be satisfied with.

However, it's the MASSIVE lag during logon from home that is
problematic. Because domain.com a valid domain externally- it's just
not managed by a proper AD DNS server.

You know how people with logon speed issues on their own networks are
always told to use their network's DNS server, and not their ISP's?
I'm thinking along those lines- what does said user do at home, when
they have to use their ISP's DNS server?

What Kurt was trying to say is when you connect into using your
infrastructure's VPN server, an IP address, along with the correct
configuration, including using the internal DNS servers will work. Keep in
mind, when using a VPN, the VPN interface becomes the default interface.
I've set this up at many of my client's sites and it works fine, even when
the internal/external zone names are the same because the system is using
the VPN PPP interface as the default (the first one it checks) interface.

I would look at exactly what DNS IP address the client is getting AFTER it
is connected via the VPN. I would also look in the VPN prpperties to insure
it is the default interface when connected, as well as Network & COnnection
window, Advanced menu, Advanced settings, and insure it is at the top of the
binding order.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

If this post is viewed at a non-Microsoft community website, and you were to
respond to it through that community's website, I may not see your reply
unless that website posts replies back to the original Microsoft forum.
Therefore, please direct all replies ONLY to the Microsoft public newsgroup
this thread originated in so all can benefit or ensure the web community
posts it back to the original forum.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Infinite Diversities in Infinite Combinations.
=================================

 

[Kurt]

OK, finally got it (My head gets a little thicker with each passing year!).
There IS a .com public entity, so the computer expects to be able to find a
DC, and none is provided (couldn't get to it even if there were). One of
many good reasons not to name your internal domain the same as your public.
But since it's already done, I don't believe you can have it work from the
outside without the delays and at the same time have no connectivity to a
DC. You'll either have to disconnect completely from any DNS that can
resolve your namespace (which you said is not acceptable), or you'll have to
allow at least DNS and web traffic via your work. Here are some thoughts:

1) Set up a RRAS VPN server on a non-DC and set the laptops up for a PPTP
VPN client connection to work. Basically leave all of the settings alone (I
usually un-check the "use default gateway on remote network" box, but you'll
need to leave this one checked). Then users will be able to check the box
that says "dial a connection" at the logon dialog and they will have access
to the work LAN including DNS. They will be forced to access the Internet
through your company firewall, which is probably a good thing if they're
company laptops. If they want to surf directly, they'll need to suffer the
long logons or use their personal computers (as they should). Yes, they'll
have to remember to check the box when logging on from home and uncheck it
at work.

2) You could give your DC a public IP, add the necessary records to your
public DNS server and let them authenticate that way, but I'd be hesitant to
expose my DC to the public even if hardened.

3) You could bring up a DC just for public access that requires all traffic
to be encrypted and issue certificates to the laptops. That would be pretty
secure. I'm not sure you can configure this exclusively for 1 DC though, and
you'd still need the public DNS records pointing to it. That would allow
logins, without connecting to the network. It'd take some messing with.
Given the choice of options 1 or 3, I'd take one unless you really must keep
them of the network resources when they're at home.

....kurt

 

[jsmall]

Hi Kurt,

Yep, you got it that time.
Most of your solutions sounds correct, and solution number one probably
is the most suitable. However, for user training reasons, solution
number one, on the other hand may not be.

I was hoping someone would have stated something like "put X in the
registry, and you can reduce the timeout" or "put record x in the
public DNS server pointing to the localhost, which will tell the
laptops to just give up" or something to that effect, but I guess no
such answer will work

Thanks for assistance. Of course if anyone does have advice with
reference to the above, it would be equally appreciated.

 

[jsmall]

Ace,

You're assuming we want to go and implement a VPN. For general
political reasons, this is not a feasible solution.

Once again, clients at home use their own ISP and have no link to the
office whatsoever. There's nothing they can contact and we like things
that way. We just don't like lag logging on. Is there seriously no
solution that doesn't repeatedly bring us back to being told to use the
corporations internal DNS servers even when a user is at home?

Is there not some particular DNS record I could put on our public DNS
server to alleviate this issue?

 

[Ace Fekay [MVP]]

In

Ace,

You're assuming we want to go and implement a VPN. For general
political reasons, this is not a feasible solution.

Once again, clients at home use their own ISP and have no link to the
office whatsoever. There's nothing they can contact and we like things
that way. We just don't like lag logging on. Is there seriously no
solution that doesn't repeatedly bring us back to being told to use
the corporations internal DNS servers even when a user is at home?

Is there not some particular DNS record I could put on our public DNS
server to alleviate this issue?

I assumed the clients are using VPNs. Now re-reading some of your posts in
this thread, it appears you are saying people are actually logging on across
the internet without a VPN. And the logong is massively slow. Is that
correct?

Ace

 

[Ace Fekay [MVP]]

In

I assumed the clients are using VPNs. Now re-reading some of your
posts in this thread, it appears you are saying people are actually
logging on across the internet without a VPN. And the logong is
massively slow. Is that correct?

Ace

Just as a followup, the reason I asked is because if there is a NAT device
in between the clients (on the Internet) and the internal network, domain
traffic cannot pass thru a NAT device (since it cannopt traverse Kerberos,
RPC or LDAP traffic). If there is a firewall between the internet clients
and the internal network, then about 29 ports need to be opened to allow
domain authentication trafffic.

Unless I misunderstood, these would be substantial reasons why the long
logon times without using a VPN.

Ace

 

[jsmall]

Just as a followup, the reason I asked is because if there is a NAT device
in between the clients (on the Internet) and the internal network, domain
traffic cannot pass thru a NAT device (since it cannopt traverse Kerberos,
RPC or LDAP traffic). If there is a firewall between the internet clients
and the internal network, then about 29 ports need to be opened to allow
domain authentication trafffic.

Unless I misunderstood, these would be substantial reasons why the long
logon times without using a VPN.

Ace

Please re-read again. Nobody seems to be getting this thread.
The user goes home. He has no VPN. No link to the office whatsoever. He
is not logging on "over" the Internet, he is logging on using cached
credentials.

There is no NAT device to the server, there is no link whatsoever.
Consider, for the purposes of the arguement, that the user's office
does not even have an Internet connection, and we are happy with that.

However, for the purposes of hosting a website, there is a @domain.com
DNS domain accessible from the Internet. It does not run the AD. Yet
all user's machines seem to keep "trying" to look for the DC, and yes,
logon is massively slow.

Two solutions work:

1. Logon inside the office
2. Unplug the home network whilst booting

Neither of these are suitable for home users. How can I convince the
machines that "You are at home now, don't look for the DC, don't try to
logon, just get over it".

 

[Ace Fekay [MVP]]

In

Please re-read again. Nobody seems to be getting this thread.
The user goes home. He has no VPN. No link to the office whatsoever.
He is not logging on "over" the Internet, he is logging on using
cached credentials.

There is no NAT device to the server, there is no link whatsoever.
Consider, for the purposes of the arguement, that the user's office
does not even have an Internet connection, and we are happy with that.

However, for the purposes of hosting a website, there is a @domain.com
DNS domain accessible from the Internet. It does not run the AD. Yet
all user's machines seem to keep "trying" to look for the DC, and yes,
logon is massively slow.

Two solutions work:

1. Logon inside the office
2. Unplug the home network whilst booting

Neither of these are suitable for home users. How can I convince the
machines that "You are at home now, don't look for the DC, don't try
to logon, just get over it".

Many folks do this, and probably why I *assumed* that was not what you
meant. Sure, it take a little bit to logon, but they will logon with cached
credentials. We also allow local logons for some clients.

The intention of putting in SRV records in any DNS for it to use is to point
it to a DC. If behind a NAT or firewall, well, you got that part from my
previous post. Therefore, putting in SRV records on a public DNS ain't going
to help.

Here's some stuff I found, but not about lowering the logon times as you
want.

Cached Logons:
"Windows Server 2003 supports cached logons. The cached credentials of the
last 10 user's who have successfully logged on to a domain account can be
used to log a user on locally if the authenticating domain controller
becomes unavailable." (Same with Win2000.)
http://www.microsoft.com/technet/pr...Ref/779885d9-e5e9-4f27-9c14-5bbe77b056ba.mspx

Description of the Windows XP Professional Fast Logon Optimization feature
http://support.microsoft.com/kb/305293/

User is not alerted when logging on with domain cached credentials
http://support.microsoft.com/kb/242536/EN-US/

Security: Cached Credentials, XP and Server 2003
They were out of the office and attempted to log onto their laptops using
their
cached credentials. They were unable to get past the logon screen and were
....
http://www.experts-exchange.com/Security/Q_21319132.html

Ace

 

[jsmall]

Many folks do this, and probably why I *assumed* that was not what you
meant. Sure, it take a little bit to logon, but they will logon with cached
credentials. We also allow local logons for some clients.

The intention of putting in SRV records in any DNS for it to use is to point
it to a DC. If behind a NAT or firewall, well, you got that part from my
previous post. Therefore, putting in SRV records on a public DNS ain't going
to help.

Our public DNS server had no SRV records at all. I have checked and
triple checked. It's a BIND DNS server and makes no reference to AD.

 

[Ace Fekay [MVP]]

In

Our public DNS server had no SRV records at all. I have checked and
triple checked. It's a BIND DNS server and makes no reference to AD.

As I stated, and I will re-iterate for you, SRV records in a public zone
WILL NOT help since the DCs will NOT be available anyway in your scenario.

Make sense?

Ace

 

[Malevolent]

Lesson here is do not make your internal domain name the same as your
external domain name.

 

[Ace Fekay [MVP]]

In

Lesson here is do not make your internal domain name the same as your
external domain name.

Malevolent, that of course is a design option we always try to avoid do to
administrative overhead, and other security issues, but I do not think that
a split-zone design is the issue in this case, but the frustration of
waiting for a longer logon time with a laptop looking for a DC not connected
to the corporate network. Even if we put in records for the DCs in the
externally hosted zone, what good would they do if the Dcs are not available
anyway?

Maybe fast logons are disabled, which would add to the logon time. If not,
the long times are really not that bad taking up to a minute or more or so
to log on until the cache credentials are used, which most people deal with
it for the most part.

Ace

 

[jsmall]

Malevolent, that of course is a design option we always try to avoid do to
administrative overhead, and other security issues, but I do not think that
a split-zone design is the issue in this case, but the frustration of
waiting for a longer logon time with a laptop looking for a DC not connected
to the corporate network. Even if we put in records for the DCs in the
externally hosted zone, what good would they do if the Dcs are not available
anyway?

Indeed, we run all our sites this way, and I can't think of any
"administrative" overhead which has ever been experienced.
I am more than capable of running split horizon DNS.

Maybe fast logons are disabled, which would add to the logon time. If not,
the long times are really not that bad taking up to a minute or more or so
to log on until the cache credentials are used, which most people deal with
it for the most part.

Unfortunately, a one minute delay is an eternity to a customer sitting
in front of a PC. Yes, it is that bad.

Can you tell me more of this fast logon option?

I really need a fix for this.