Active Directory over multiple subnets

[hx009]

Anyone here an Active Directory guru? I have a building with a single Windows Server 2003 domain (we'll call it HOMEOFFICE) with 50 computers on a subnet 172.16.0.0/255.255.0.0. I then have a VPN linked to a remote office with subnet 10.10.1.0/255.255.255.0. The firewall VPN tunnels handle all the NAT and as far as TCP/IP goes, it all seems happy. I can sit at the remote office and ping any servers at the main location. I can hit the http and ftp services on the servers as well. The problem is Active Directory authentication just WILL NOT WORK. I've tried everything I can think of. Doing something like

NET VIEW \\SERVER

Results in:

System error 5 has occurred.

Access is denied.

Logons also take excrutiatingly forever. I assume this is because the machine is sweeping the entire local subnet for a domain controller and not finding one. This very same laptop which is a member of the remote domain and logged in with a domain user works 100% if I put it on the network inside the main office. Googling endlessly brings up nothing but people saying "yah, I put a domain controller in the remote office". That is not going to happen. It is not in our budget to buy a domain controller for a two PC satellite office. Someone on AT has had to run across this, I can't possibly be the first sysadmin to attempt to link remote offices!

 

[netsysadmin]

My first thought would be that you do not have the DNS settings of the remote office machines pointed to the DNS server in the main office which can definately scew up some stuff. Though you mention something about a remote domain can you explain more about this part?

John

 

[hx009]

Originally posted by: netsysadmin
My first thought would be that you do not have the DNS settings of the remote office machines pointed to the DNS server in the main office which can definately scew up some stuff. Though you mention something about a remote domain can you explain more about this part?

John

There is only one domain, and DNS is setup correctly. In the HOMEOFFICE domain there is a sole Win2k3 server (we'll call it MAINSERVER), which is Active Directory, DHCP, and DNS. The IP is 172.16.0.100. From the remote offices (remember, subnet 10.10.1.0) I can ping it by name (ping MAINSERVER). So DNS is setup properly. I can also reach the IIS server, ftp server, and any other TCP/IP based service I setup on it. Just not anything to do with windows authentication. The VPN connection is wide open (I know this for a fact.. I set them up), so there is no port blocking going on (like on 139 etc..).

 

[nweaver]

\\server uses netbios. Is your VPN forwarding broadcasts (or translating broadcasts?)

I agree, this is most likely DNS. I have used AD over normal (aka non VPNed, standard TCP/IP) subnets.

 

[EatSpam]

Are these remote workstations joined to the domain?

 

[netsysadmin]

Do the workstations in the remote office have the DNS setting 172.16.0.100? If not that would be the cause of of your issues.

John

 

[hx009]

Originally posted by: nweaver
\\server uses netbios. Is your VPN forwarding broadcasts (or translating broadcasts?)

I agree, this is most likely DNS. I have used AD over normal (aka non VPNed, standard TCP/IP) subnets.

I don't think it's forwarding broadcasts (generally a bad idea). I'll have to find a way to check this out. Are you saying that unless I do forward broadcasts I can't use UNC paths?

 

[hx009]

Originally posted by: EatSpam
Are these remote workstations joined to the domain?

Yes. If they weren't, I'd get a popup window asking for valid credentials. As it is, I'm flat out getting refused.

 

[hx009]

Originally posted by: netsysadmin
Do the workstations in the remote office have the DNS setting 172.16.0.100? If not that would be the cause of of your issues.

John

Yes. If that wasn't the case, they wouldn't even be able to ping the server by name.

 

[netsysadmin]

Have you verified the DNS settings on the machine for sure?

John

 

[hx009]

Originally posted by: netsysadmin
Have you verified the DNS settings on the machine for sure?

John

????

Yes.

 

[nweaver]

You can use UNC paths, you cannot use netbios (i.e. \\ip.address.of.server would work, \\servername would not

 

[hx009]

Originally posted by: nweaver
You can use UNC paths, you cannot use netbios (i.e. \\ip.address.of.server would work, \\servername would not

Do interactive logins use NetBIOS? That is my main problem... when a domain user on a domain machine attempts to logon, the system sits at "Applying your personal settings" FOREVER. We're talking a solid 3-5 minutes. When it finally lets the user into windows, they have no access to any domain machines (they can ping them and reach their other services, just not network shares). And actually, doing \\ip_address results in an access denied message as well.

 

[spidey07]

do you have those subnets listed in AD sites and services?

 

[hx009]

Originally posted by: spidey07
do you have those subnets listed in AD sites and services?

I do, but I'm not sure that I need to. It seems that you really only need to do that if you have a domain controller going into that subnet (I could be wrong on this). After adding the site, AD even warns "Install one or more domain controllers in SITENAME, or move existing domain controllers into this site".

 

[nweaver]

the long time at that screen during login is a DNS issue, I have seen this during subnetted domains in the lab. Check your DNS zones, you might need to manually add a reverse lookup zone.

 

[spidey07]

Originally posted by: nweaver
the long time at that screen during login is a DNS issue, I have seen this during subnetted domains in the lab. Check your DNS zones, you might need to manually add a reverse lookup zone.

hahahah....

I'm not a server OS guy, but with windows it almost always a DNS problem. most always.

Been through enough "its the network's problem", no Mr. MCSE and have not clue - your name resolution and DNS isn't working.....now away with you.

 

[hx009]

DNS has nothing to do with it. As it turned out Kerberos was running over UDP (which does not work over our VPN link) and causing authentication failures.

How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000

The long time at the login screen was due to Kerberos constantly bouncing UDP all over the place trying to reach a domain controller and never getting one.

/thread

 

[stash]

hahahah....

I'm not a server OS guy, but with windows it almost always a DNS problem. most always.

Been through enough "its the network's problem", no Mr. MCSE and have not clue - your name resolution and DNS isn't working.....now away with you.

lol. Stick with what you know, man. Access denied is almost never a name resolution problem.

In fact, the first thing that pops into mind when I hear 'Active Directory' and 'VPN' in the same sentence is Kerberos fragmentation. Which is exactly what hx009 discovered the issue to be.

 

[EatSpam]

Originally posted by: STaSh

hahahah....

I'm not a server OS guy, but with windows it almost always a DNS problem. most always.

Been through enough "its the network's problem", no Mr. MCSE and have not clue - your name resolution and DNS isn't working.....now away with you.

lol. Stick with what you know, man. Access denied is almost never a name resolution problem.

In fact, the first thing that pops into mind when I hear 'Active Directory' and 'VPN' in the same sentence is Kerberos fragmentation. Which is exactly what hx009 discovered the issue to be.

Never would have guessed, and I have a Active Directory set up over 3 sites connected with a VPN.

 

[hx009]

Originally posted by: STaSh

hahahah....

I'm not a server OS guy, but with windows it almost always a DNS problem. most always.

Been through enough "its the network's problem", no Mr. MCSE and have not clue - your name resolution and DNS isn't working.....now away with you.

lol. Stick with what you know, man. Access denied is almost never a name resolution problem.

In fact, the first thing that pops into mind when I hear 'Active Directory' and 'VPN' in the same sentence is Kerberos fragmentation. Which is exactly what hx009 discovered the issue to be.

Almost never? Try never. Access denied means "I reached the server, its sees you, but its not letting you in because you have invalid credentials". It's not a "host not found" or "name cannot be resolved" issue. Which is why it was getting annoying having three different people telling me its my DNS. I just didn't want to be a dick about it and say "shut up! it's not the DNS!" in a thread where I was the one asking for help

 

[GeekDrew]

Say what you will about "Access Denied" only being presented when DNS is working properly (and thus, communication to the server), but I've seen otherwise.

 

[spidey07]

Originally posted by: STaSh

hahahah....

I'm not a server OS guy, but with windows it almost always a DNS problem. most always.

Been through enough "its the network's problem", no Mr. MCSE and have not clue - your name resolution and DNS isn't working.....now away with you.

lol. Stick with what you know, man. Access denied is almost never a name resolution problem.

In fact, the first thing that pops into mind when I hear 'Active Directory' and 'VPN' in the same sentence is Kerberos fragmentation. Which is exactly what hx009 discovered the issue to be.

Fair enough. There could be fragmentation problems.

But enough us network guys know that most active directory problems are rooted in DNS not being setup correctly, no matter what the error message.

 

[stash]

But enough us network guys know that most active directory problems are rooted in DNS not being setup correctly, no matter what the error message.

It's true that a lot of AD problems are related to improper DNS configuration, but to me it was clear that the OP had DNS configured correctly. I did enterprise directory services support for PSS for awhile, which is why Kerb fragmentation popped into my head at first.

 

[spidey07]

Originally posted by: STaSh

But enough us network guys know that most active directory problems are rooted in DNS not being setup correctly, no matter what the error message.

It's true that a lot of AD problems are related to improper DNS configuration, but to me it was clear that the OP had DNS configured correctly. I did enterprise directory services support for PSS for awhile, which is why Kerb fragmentation popped into my head at first.

I've heard about the kerberos fragmentation problems...I think its a known issues with MS. There may even be a workaround, but I've never looked into it.

there's a link on MS somewhere about it?