AD Integrated DNS Prevents Remote Access

[reldridge]

Attempting to move from 2 x 2000 DCs with AD integrated DNS to 2 x 2003 R2 DCs.
Have managed to create 2 x 2003 R2 member servers and can DCPROMO them to DCs and back to members at will while leaving 2000 DCs unchanged and connected to network.
When adding DNS to both new DCs (or members and then DCPROMO to DCs) we find that within a few hours our external employees have their logon credentials rejected.
If we demote both new DCs, remote access is restored.
Trigger is apparently creation of ForestDNSZones and DomainDNSZones objects in AD, as soon as this was logged in Event logs, remote access stops. Internal users are unaffected.
Remote access is with Aventail VPN appliance, which has been reconfigured to communicate with new DCs but still same result. Have call logged with VPN provider but they're scratching their heads currently.
Can anyone provide further advice? Thanks in anticipation.

 

[Lemon13]

on 2003 u have a domaingroup remotedesktopusers, are the accounts in question added there?

 

[reldridge]

Dear Lemon13,
Thank you for prompt reply.
I've checked this group and it currently has no members whatsoever. When I next promote the DCs and add DNS I'll add a couple of test users to the group and come back to you with the results.
Regards,
Ray.

 

[reldridge]

Dear Lemon13,
Sorry but that did not work.
As soon as the Forest/DomainDNSZones objects are added to AD, remote access stops - adding users to Remote Desktop Users makes no difference - I even waited for the group user addition to replicate to all DCs (2000 and 2003) before trying a remote logon - still rejected username and password.
Regards,
Ray.

 

[TheLad]

Did you prepare AD to accept the new servers as DCs? See the link below and read pagy's post (second post in thread)

thread931-1419486

--------------------------------------
"Insert funny comment in here!"
--------------------------------------

 

[reldridge]

Dear TheLad,
Thanks for your reply.
I did run adprep /forestprep and adprep /domainprep before running dcpromo on the 2003 members.
I did find initially that dcpromo was complaining that AD wasn't ready to receive a 2003 DC but that was resolved by running adprep /forestprep and adprep /domainprep from CD2 of the R2 installation CDs (instead of CD1).
Once CD2 had been run I could easily create 2003 DCs, it seems to be the addition of DNS later that prevents remote login suceeding.
As soon as I use dcpromo to demote both 2003 DCs (which deletes the Application Directory partition data for ForestDNSZones and DomainDNSZones) and reboot them, remote access starts working again.
Regards,
Ray.

 

[reldridge]

Does anyone have any further suggestions? This problem's been bustin' my ass for 4 weeks now so any help is appreciated.

 

[theravager]

I would try isolating the issue.

Try promoting the new servers without dns running on them and see what happens.

 

[reldridge]

Dear theravager,
Thanks for your reply.
I've already tried this - I can promote the 2 new DCs and they operate happily alongside the existing 2000 DCs. Remote logons are unaffected (same as the internal ones).

Once DNS is added we find that initially things are OK for about 24 hours and then remote access is denied.
We've noted that Event ID 4502 is recorded twice on each new DC, advising:

The DNS added the local Active Directory to the replication scope of Application Directory Partition DomainDnsZones.hel.eu. The distinguished name of the root of this Directory Partition is DC=DomainDnsZones,DC=hel,DC=eu

and

The DNS added the local Active Directory to the replication scope of Application Directory Partition ForestDnsZones.hel.eu. The distinguished name of the root of this Directory Partition is DC=ForestDnsZones,DC=hel,DC=eu.

After these events remote access stops.

My hypothesis is that the new DNS stuff is confusing the remote access appliance somehow - all that the appliance logs tell me is that the password was rejected and that SOCKS5 authentication failed.
Regards,
Ray.

 

[theravager]

Is the primary dns on the servers your are promoting set to one of the existing servers.

You can change this after the initial dns replication is synced, this is a very common mistake. I have a couple of other thoughts on what the issue maybe but its probibly this.

 

[reldridge]

Thanks for your reply.

I believe I've tried adding DNS when the DCs Primary DNS was set to itself and to one of the other existing DCs too. The outcome was the same.

However, just to be sure I will give this another try. What's your recommendation?
1) Set Primary DNS to itself, then install DNS
or
2) Install DNS, then set Primary DNS
only I think the DC already has the DNS records by virtue of AD replication, so I may be able to try option 1).

 

[Davetoo]

Option 2, since if the server isn't running DNS then it can't provide DNS information.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

There are no more PDC's! There are DC's with FSMO roles!

 

[reldridge]

OK, I will try option 2 tomorrow morning. Thanks for the info.

 

[theravager]

You have to set primary dns to a existing server not itself when you promote a DC, after replication of ad integrated dns is synced you can then set the new dc to reference itself and everything will work.

The issue is basically if a new server is promoted referencing itself as dns, the existing servers can't replicate the dns records required to replicate the dns partition as they don't have the new servers records and will refuse to replicate. Chicken before the egg basically.

 

[reldridge]

Sorry for the delay in coming back to you - our internet access broke for most of yesterday.

I tried setting the Primary DNS of the 2003 DCs after DNS was installed (before they were pointing at existing DNS servers). Unfortunately remote access stopped again.

I uninstalled DNS and AD from one of the 2003 DCs and still remote access is blocked.

I SHUTDOWN the remaining 2003 DC and Remote Access started working.

When the remaining 2003 DC was started up again remote access stopped once more.

I then uninstalled DNS from this DC - remote access still failed.

I then uninstalled AD (deleting the ForestDNSZones and DomainDNSZones application partitions) and remote access started working again.

 

[theravager]

One of my other first thought was how does the remote access device authenticate users and if there was a firewall rule in between preventing ldap or the dns zone was preventing unsecure updates which you can easily test.

Other then that i am out of ideas, though i am pretty sure an experienced ad/dns admin person could probably work out the issue onsite fairly quick. Could be time to give pss or 3rd party a call to take a look.

Until then i would just let the new dc's run without having the dns service on them, at least this way you have dc services running for whatever reason you were adding them for.

Best of Luck

 

[reldridge]

Thank you for your response.

We're going down the route of upgrading/replacing the VPN appliance - it's nearing end of life anyway.

We'll keep the 2003 DCs as is without DNS for now until we get the VPN sorted - it's a shame because we really want to retire the 2000 DCs a.s.a.p.

I've checked the firewall between the VPN and the DCs - LDAP was not blocked and DNS can accept unsecure updates.

It's my belief that the VPN upgrade will solve the problem or at least the improved logging on it will point to the issue.