Server detecteert netwerk allemaal in hetzelfde domein

[X-DraGoN]

Wij hebben hier verschillende DC's 2008 R2 draaien waarin alles feitelijk gewoon werkt zoals het hoort.
Bij de detectie van de verschillende NIC's verwacht je dat hij de NIC waarop het domein verkeer gaat, dat hij daar de naam van het domein bij zet, en bij de anderen dat niet doet, maar nu is het mij opgevallen dat bij ons alle DC's er als volgt uitzien:


Andere servers (maw geen DC's) zien er als volgt uit:


Vraag: ziet dit er bij jullie servers hetzelfde uit of is hier ergens iets fout aan het lopen?
(DNS is trouwens niet AD-integrated geregeld)

[Linke Loe]

Heb je de NIC configuratie al eens bekeken op de domain controllers? Windows geeft de domeinnaam van het netwerk weer, als het deze kan resolven uit de DNS...

[X-DraGoN]

Linke Loe schreef op woensdag 10 oktober 2012 @ 13:56:
Heb je de NIC configuratie al eens bekeken op de domain controllers? Windows geeft de domeinnaam van het netwerk weer, als het deze kan resolven uit de DNS...

Hij kan de domein naam resolven, die staat namelijk (gedeeltelijk) in de screenshot. het gaat er over dat hij alle NIC's als deel van het domein beschouwd ipv alleen de 'PROD' interface.

[Hero of Time]

Hebben die 'verkeerde' NICs een IP in dezelfde range, of zijn ze anders? Het heeft namelijk geen zin om wallonië.be te verwachten als de range hetzelfde is als vlaanderen.be. Dan dumpt Windows ze in dezelfde domeingroep.

[X-DraGoN]

Ze staan uiteraard in verschillende subnets
PROD is bv: 172.16.140.x
BU is bv. 172.16.181.x
OOB is bv. 172.16.220.x

De service die voor deze detectie in staat is NLA en die zou werken op basis van poort 389:
Orgineel artikel
The Network Location Awareness (NLA) service expects to be able to enumerate the domain’s forest name to choose the right network profile for the connection. The service does this by calling DsGetDcName on the forest root name and issuing an LDAP query on UDP port 389 to a root Domain Controller. The service expects to be able to connect to the PDC in the forest domain to populate the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\IntranetForests

If something hinders the DNS name resolution or the connection attempt to the DC, NLA is not able to set the appropriate network profile on the connection.

Kan ik daar dan uit besluiten dat dat normaal is op DC's aangezien die op elke NIC die DsGetDCName kan doen aangezien die zelf DC is?

[Hero of Time]

De reeks 172.16.x.y is normaal gesproken een klasse B subnet, oftewel, 255.255.0.0 en zouden allemaal in hetzelfde subnet zitten. Ik ga er maar even vanuit dat 't voorbeelden zijn en jij hier niet aan hebt gedacht, of dat het is opgedeeld in een klasse C met een mask van /24 . [/muggenzifterij]

Het is heel goed mogelijk dat je DC, die domein vlaanderen.be serveert, geen NLA uitvoert op andere NICs en z'n eigen domeinnaam op de NIC zet. Dat zeker als je het vaste IP adressen hebt gegeven. In dat laatste geval moet je handmatig de DNS suffix op de interface zetten.

[X-DraGoN]

Ik wou niet teveel in detail treden, maar de PROD is een /25, de rest zijn /24 adressen en worden niet gerouteerd en zijn dmv firewalls afgeschermd. Maar je hebt een punt, wel belangrijke info op dit punt.

Verder ben ik dan in de cache gaan kijken (register key vermeld in de vorige post) en daar staat in dat de PROD interface 131071 keer heeft kunnen verifiëren dat hij in *.vlaanderen.be zit. Bij de BU interface staat 180k keer wel en 344k keer niet terwijl hij sowieso geen toegang heeft tot poort 389 op die interface. Bij OOB interface heeft hij 2147467264 keer negatief gekregen.

Nu, ik vermoed allemaal dart het natuurlijk gedrag is, er is ook niets fout, maar ik was benieuwd of anderen hetzelfde zien in productie servers die ze beheren

[Hero of Time]

Ik niet om het simpele feit dat ik maar 1 domein heb en beheer hier op werk. En als een server in meerdere domeinen zou moeten zitten, en het allemaal interne zijn, geen moeite zou nemen om de servers op dat niveau af te schermen. Ik zou 't dus niet zien dat een interface een verkeerde domeinbenaming krijgt.

Rest je nu alleen nog maar om handmatig de FQDN op de interface te knallen. Zie Connection Status > Properties > TCP/IP version 4 (en 6!) > Advanced > DNS voor alle informatie die je nodig hebt. Daar staat standaard het volgende aan:
• Append Primary and connection specific DNS suffixes
[X] Append parent suffix of the primary DNS suffix

Die laatste geeft je vlaanderen.be, want je primaire suffix is precies dat.