AD DNS query

  • 235 Views
  • Last Post 04 June 2018
ahobbs posted this 24 April 2018

Hey all

I have a query about AD DNS records.

We are having random connectivity issues with a couple of Domain Controllers with cross forest authentication/lookups.

We have a 2 way forest trust between the two AD Forests, with DNS conditional forwarders configured for name resolution.

In the target forest we have 4 x Windows 2008 R2 Domain Controllers all with AD Integrated DNS installed.

When I do an NSLOOKUP on the TARGET domain or check the Name Servers tab on the DNS Zone, I see 5 records being returned instead of 4 x AD DNS servers.
The extra DNS entry of USDC500 is a legacy AD/DNS server that is no longer on the domain, but a DNS A record was created to point it to NADC001 just in case we had applications hardcoded to use USDC500.

USDC500 192.168.128.11
NADC001 192.168.128.11
NADC002 192.168.128.12
NADC003 192.168.128.13
NADC004 192.168.128.14

This maybe a stupid question but is this an acceptable way to configure our primary DNS zone or handle AD authentication? We have problems enumerating group memberships across Active Directory Forest for authentication and trying to rule out DNS.

Thank you

A

Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Order By: Standard | Newest | Votes
Parzival posted this 04 June 2018

If the two forest domain controllers are wide apart, you might be able to use Cross-Forest DCLocator process optimization:




I still need to revive my cross-forest authentication post, but this one (creating the trusts) uses the exact same methodology

http://blog.azureinfra.com/2010/03/26/cross-forest-authentication-part-2-creating-trusts/








In short, your cross-forest DCLocator process can use site-specific domain controllers - if the site names between the two forests match up. You can control which domain controllers will respond to the first lookup from

forest1, based on the site-location of the querying computer in forest1. If forest2 has a site with the exact same name it will prefer the servers in that site. 




if you look at the query that I took from a WireShark when performing a cross-forest lookup (DClocatorProcess)  




(192.168.x.x is Forest1 - called AzureStack.local - 172.16.5.x is Forest2 - sourcead.local):






192.168.200.67 172.16.5.27      DNS     125      Standard query 0x6eb5 SRV gc.tcp.Default-First-Site-Name.sites.sourcead.local OPT

<if that DC does not respond it will go to global zone>

192.168.200.67 172.16.5.27      DNS     125      Standard query 0x6eb5 SRV

gc.tcp.sourcead.local OPT

172.16.5.36      192.168.200.67 DNS     215      Standard query response 0xb594 SRV _gc.
tcp.sourcead.local SRV 0 100 3268 WIN-8B47PF72NID.SOURCEAD.local SRV

0 100 3268 DC01.SOURCEAD.local A 172.16.5.27 A 172.16.5.36 OPT


192.168.102.5  172.16.5.27      CLDAP 220      searchRequest(56) "<ROOT>" baseObject

 

What we see is that the first name-query was towards a site specific SRV record, if that DC does not respond (or the site itself does not exist), the next query goes to the "global" zone that contains

all writable domain controllers (by default).

 

What I did was create an empty site called “local” in my SourceAD (the target forest):









I enabled auto-site coverage for one of my DC’s in a custom GPO (so i control which DC will respond on the site-specific DNS lookup):



 







This allowed my custom DC (or DC’s) to register the site specific records in DNS (net stop netlogon & net start netlogon - force registration of these records):





 







Inside my sourceForest (forest1), I changed the Default-First-Site-Name to “local” and rebooted the entire thing to ensure all servers would recognize their new site. Obviously waiting

for 8 hours or so would help also. In your case you probably want to name the "local" in the target forest to match the site name where you perform your query from.

 

After that I see the following in the traces:







192.168.200.67

172.16.5.27      DNS     125      Standard query 0x6eb5 SRV _gc.
tcp.local.sites.sourcead.local OPT            





172.16.5.36      192.168.200.67 DNS     162      Standard query response 0x1aa2 SRV _gc.
tcp.local._sites.sourcead.local SRV 0 100 3268

DC01.SOURCEAD.local A 172.16.5.36 OPT
















As you can see, the stack now queries for the specific “local” site and my DNS server responds with the server that is covering this site, and the next calls in the trace are the actual

LDAP binding to that specific DC.




So you can control which domain controller should respond to cross-forest site requests. 




Note that just querying A records on a "domain-name" does not by default implies that the response is

"all the covering domain controllers for the DCLocator process". The fact that the A record for zone sourceAD.local is hosted by all domain controllers, does not imply they have their SRV (kerberos and LDAP) records registered and thus are responding

to DNS queries.. 

in order to validate which domain controllers respond to your LDAP/GC query depends on these SRV records that are inside the _msdcs DNS zone, their record priority and weight. If these

are equal an LDAPPING is sent to all responses and the first/fastest DC to respond will handle the call. 




Roelf









show

barkills posted this 27 April 2018

We have problems enumerating group memberships across Active Directory Forest for authentication and trying to rule out DNS.

show

idarryl posted this 27 April 2018

Check for event id 31, that signals token bloat.  Have you checked MaxTokenSize is the same on each DC, or configured a GPO to apply to all DC's?  
Darryl

show

ahobbs posted this 27 April 2018

Yes, first thing I checked. All replicates fine, all are GCs as single forest single domain.
Used port query to check all the ports and they seem fine, tracert completes the same route as the working DCs.


show

kebabfest posted this 24 April 2018

Is replication working as it should to the 2 unemurating dcs and are they gcs ? 
On Tue 24 Apr 2018, 21:48 Amanda Hobbs, <ahobbslist@xxxxxxxxxxxxxxxx> wrote:
Hello
The group enumeration works

show

ahobbs posted this 24 April 2018

Hello
The group enumeration works

show

kebabfest posted this 24 April 2018

Off the top of my head the right reg key ( the new right one) entry number is 65356. Can't remember the key name. Am I close ?   
On Tue 24 Apr 2018, 21:17 Webster, <webster@xxxxxxxxxxxxxxxx> wrote:
















https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756101(v=ws.10)

 

Maximum is 1015.

 

"Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately

1,015 groups."

 

Thanks

 

 

Carl Webster

Citrix Technology Professional Fellow

| IGEL Tech Community Insider | Parallels VIPP

http://www.CarlWebster.com

The Accidental Citrix Admin

 

show

webster posted this 24 April 2018

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756101(v=ws.10)

 

Maximum is 1015.

 

"Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately

1,015 groups."

 

Thanks

 

 

Carl Webster

Citrix Technology Professional Fellow

| IGEL Tech Community Insider | Parallels VIPP

http://www.CarlWebster.com

The Accidental Citrix Admin

 

show

kebabfest posted this 24 April 2018

Group enumeration sounds more like a problem with token bloat. There a reg update you do on the ad controllers to increase the number of groups allowed. I think the hard limit is 1024. Correct me if I am wrong here.The only other time I have seen this type of problem is if there is replication issue between dcs and not all the dcs are gcs. 
On Tue 24 Apr 2018, 20:16 Amanda Hobbs, <ahobbslist@xxxxxxxxxxxxxxxx> wrote:
Hey all

I have a query about AD DNS records.

We are having random connectivity issues with a couple of Domain Controllers with cross forest authentication/lookups.

We have a 2 way forest trust between the two AD Forests, with DNS conditional forwarders configured for name resolution.

In the target forest we have 4 x Windows 2008 R2 Domain Controllers all with AD Integrated DNS installed.

When I do an NSLOOKUP on the TARGET domain or check the Name Servers tab on the DNS Zone, I see 5 records being returned instead of 4 x AD DNS servers.
The extra DNS entry of USDC500 is a legacy AD/DNS server that is no longer on the domain, but a DNS A record was created to point it to NADC001 just in case we had applications hardcoded to use USDC500.

USDC500             192.168.128.11
NADC001             192.168.128.11
NADC002             192.168.128.12
NADC003             192.168.128.13
NADC004             192.168.128.14

This maybe a stupid question but is this an acceptable way to configure our primary DNS zone or handle AD authentication? We have problems enumerating group memberships across Active Directory Forest for authentication and trying to rule out DNS.

Thank you

A

Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Close