DNS Problem

[dormi98 15]

Hallo zusammen

Diesmal ein etwas komplizierteres Szenario.

 

Umgebung:

Server 2012R2 (single DC Umgebung, virtualisiert)

Kunde ist eine kleine Abteilung in einer großen Organisation. Der Kunde darf aber eine eigene Domain betreiben (nicht im Forest der Organisation) Die Clients gehören der Organisation und erhalten von der Organisation per DHCP ihre IP Adresse. Das muss auch so bleiben. Der DNS Server ist statisch eingetragen (DC Server der Abteilung) Die Clients erhalten per DHCP offensichtlich auch den Namen der Organisationsdomäne mit.

 

Ein NSLOOKUP von einem Client liefert:
Standardserver: name_dc_abteilung.domäne_organisation.at
Address: IP Adresse DC_Abteilung

 

Da sollte so natürlich nicht sein. Hier sollte ja die Domäne der Abteilung stehen.

Eine GPO die das Suffix entsprechend setzt habe ich bereits angelegt. Bringt aber offensichtlich nichts (oder die GPO greift nicht richtig – gpresult liefert bei Computerkonfiguration keine Daten)

 

Außerdem erhalte ich bei jedem Neustart eines Clients den Fehler 5719 im System Log (Netlogon) Der mir sagt dass für die Domäne der Abteilung kein Anmeldeserver gefunden werden konnte. Das ist insofern spannend, da Logins problemlos möglich sind. (auch von Usern die noch nie an dem Client angemeldet waren)

 

Ich habe schon versucht über die DNS Suffix Einstellungen in den Netzwerkeinstellungen etwas zu verändern, allerdings bisher vergebens.

 

Drauf gekommen bin ich weil die Gruppenrichtlinie Folder Redirection nicht funktioniert. Auf einem virtuellen Testclient der über einen privaten virtuellen Switch mit dem Server verbunden ist geht diese aber. Daher vermute ich dieses DNS Problem als Ursache. 

 

Wie mache ich dem Client klar, dass er nix mit der Domäne der Organisation zu tun hat auch wenn er von dort seine IP bekommt?

Danke schon mal

Gerald

bearbeitet 21. November 2016 von dormi98

[NilsK 2.969]

Moin,

 

eine saubere Lösung wirst du nicht ohne die IT der Organisation hinbekommen. Sprich mit denen, um zu einem funktionierenden Konstrukt zu kommen. Jeder Workaround, der die vorgegebenen Strukturen irgendwie umgeht, fällt dir schnell auf die Füße - so auch der Domainsuffix per GPO, das ist immer wieder eine Fehlerquelle.

 

Gruß, Nils

[dormi98 15]

Das ist mir schon klar. Ich versuche auch nicht etwas zu umgehen sondern mit den mir gegebenen Voraussetzungen klar zu kommen

Die eigene Domäne war schon ein großes Zugeständnis. Voraussetzung war, dass wir die MAC Adressen aller geräte bekannt geben und die IP per DHCP beziehen.

 

Es muss übrigens nicht die GPO sein. Wenn sich das manuell über die DNS suffixe oder die Registrierung machen lässt soll es auch ok sein. Es geht nur um ca. 20 Clients. Zur Not mach ich das auch per Hand.

 

UPDATE:

Ich habe jetzt auch einen Test mit fixer IP am Client durchgeführt. Überraschender Weise ändert sich nichts am Verhalten. Die Domäne der Organisation muss dem Client also andersartig bekannt sein.

[BABA 11]

Warum betreibst Du nicht ein eigenes Netz für die Abteilung? 

In diesem Netz hast Du Deinen DC (eigene Domain), DNS und DHCP Server für die 20 Clients der Abteilung. So zum Beispiel hat die Organisation den Bereich 192.168.0.x und Deine Abteilung hat dann den bereich 192.168.2.x, dann gibts auch keine Probleme mit dem Suffix. Das Gateway kann ja von beiden Netzen genutzt werden.

[Doso 77]

Wieso muss man jetzt für 20 Leute eine eigene Domäne betreiben?

[lefg 276]

Moin,

wie wäre es, diese Domäne in einem VLAN zu betreiben? Mit DC, eigenem DHCP, DNS?

[blub 115]

Bringt aber offensichtlich nichts (oder die GPO greift nicht richtig – gpresult liefert bei Computerkonfiguration keine Daten

Der User ist wahrscheinlich nur mit NTLM angemeldet! Wenn du mit GPOs arbeiten willst, müssen User und Client mit Kerberos am AD angemeldet sein. (daher auch der Fehler 5719). Dann würde gpresult auch keinen Fehler liefern.

[dormi98 15]

Danke für die vielen Rückmeldungen. Da ist viel schlaues dabei. 

 

Ich versuche mal alles zu beantworten.

 

 

Warum betreibst Du nicht ein eigenes Netz für die Abteilung? 

Das wäre natürlich am aller schönsten, ist uns aber leider hier nicht erlaubt.

 

 

 

eso muss man jetzt für 20 Leute eine eigene Domäne betreiben?

Muss man natürlich nicht, Vielleicht könnte man den Primäränforderung (Fileserver) wirklich über eine NAS erledigen. Aber eben so Dinge wie redirected folders, Verbinden von Netzwerklaufwerken, Einstellungen für Browser,... finde ich schon ganz gut in einer Windows Domäne gelöst.
Dazu kommt, dass ausreichend MS Lizenzen vorhanden sind.

 

 

wie wäre es, diese Domäne in einem VLAN zu betreiben? Mit DC, eigenem DHCP, DNS?

Ein interessanter Ansatz. Die Switches kann ich zwar auch nicht verwalten, aber ich werde mal nachfragen, ob die IT der Organisation mir hier entgegen kommt. Fürchte allerdings, dass das nichts wird, da eben eine der Bedingungen war, dass alle Geräte (ja auch der DC) über deren DHCP Server die IP Adressen beziehen. Alle Geräte sind aber reserviert und bekommen entsprechend immer die gleichen IP Adressen.

 

 

 

Der User ist wahrscheinlich nur mit NTLM angemeldet! Wenn du mit GPOs arbeiten willst, müssen User und Client mit Kerberos am AD angemeldet sein. (daher auch der Fehler 5719). Dann würde gpresult auch keinen Fehler liefern.

 

Das klingt gut! Wobei so ganz klar ist es mir nicht. 

Ich hole mal etwas weiter aus. 

 

Wie schon erwähnt ist mein eigentliches Problem ja nicht das DNS (Namensauflösung funktioniert ja offensichtlich) sondern die redirected folders. Alle anderen Gruppenrichtlinien werden einwandfrei übernommen. Das betrifft übrigens sowohl Computerkonfigurationen als auch Benutzereinstellungen.

 

Um der Sache näher zu kommen habe ich bereits am Hyper-V Server einen Test Client installiert und testweise dem Server und diesem Testclient (über einen private virtual Switch) eine fixe IP gegeben. In dieser Konfiguration funktioniert die Ordnerumleitung sofort. Mit meinem physischen Testclient eben nicht. Ursprünglich dachte ich, das liegt am DHCP Server der Organisation und einem daraus resultierendem DNS Problem. Da das Problem aber auch mit fixer IP Adresse auf dem Client auftritt, sieht es nicht danach aus) Daher bin ich mir nun garnicht mehr so sicher, dass hier überhaupt ein DNS Problem besteht. 

 

Die Frage ist was ist anders an dem pysischen Client und dem virtuellen?

 

GPRESULT liefert folgende Unterschiede:

Computerkonfiguration (virtuller Client) - alle Daten vorhanden

Computerkonfiguration (physischer Client) - keine Daten

 

was die folder redirection betrifft so zeigt der physiche Client zwar an, dass die Gruppenrichtlinie angewendet wird, aber beim Komponentenstatus scheint redirected folders nicht auf. 

 

 

 

 

----------------------------------------------------------------------------------------------------------------------

Update!

 

Bin etwas weiter gekommen.

Die Ursache, dass NSLOOKUP einen falschen Namen für den Standardserver zurückgegeben hat war ein fehlender Reverse DNS Eintrag.

Damit denke ich, dass das Thema DNS erledigt ist. 

 

Auch bei der Folder Redirection hat sich was geändert. 

Es werden nun die Ordner am Server tatsächlich angelegt. Also bei der ersten Anmeldung eines Benutzers entstehen am Server nun unter \\server\folderredirection\user die Ordner die umgeleitet werden sollen.

Am Client ändert sich aber nichts. Die Ordnerlocation am Client bleibt im User-Verzeichnis.

bearbeitet 22. November 2016 von dormi98

[dormi98 15]

So, hab eine Lösung gefunden. 

Ich habe die Gruppenrichtlinie jetzt mal dahingehend verändert, dass die Umleitungen nicht auf eine bestimmte Freigabe sondern ins Homelaufwerk zeigen. Damit funktioniert es jetzt. Das sieht natürlich sehr nach einem Berechtigungsproblem aus, Da es aber von meinem virtuellen Test Client mit den vorangegangen Einstellungen funktioniert hat widerspricht sich das aber auch. 

 

Egal - Problem gelöst

[blub 115]

keine 5719 mehr?

[dormi98 15]

Oh Sorry für das Delay!

 

Ja, beim Booten kommt noch immer ein 5719. Aber ich denke das liegt eher daran, dass der NIC Treiber noch nicht bereit ist, da der Fehler immer nur 1x beim Systemstart auftritt. Anmeldeprobleme gibt es keine.

Übrigens könnte es sein, dass die Ursache der Probleme wo ganz anders gelegen ist. Ich habe es jetzt nachträglich zwar nicht verifiziert, aber denkbar ist es schon. 

Mir ist aufgefallen, dass die Leseperformance in der VM über das Netzwerk extrem schlecht war. (im LAN grad mal 200KB/s kopieren möglich). Der Grund dafür war eine Einstellung im NIC Treiber des Hosts. Vielleicht war ja auch diese schlechte Performance mit ein Grund, dass es zu irgenwelchen Timeouts kam. 

 

Jetzt passt aber alles.