DNS Name kann nicht bei der RED aufgelöst werden (Bin Anfänger)

Hallo,

in den DHCP Einstellungen für die RED (Network Services / DHCP) muss die lokale Domain und am besten der lokale DNS-Server eingetragen sein

In den Firewall regeln muss zwingend die Kommunikation zwischen Standort hinter der Red und dem DC, welcher DNS machen soll erlaubt sein.

Auf keinen Fall einen DNS-Server wie 8.8.8.8 nutzen - der kann natürlich nicht korrekt antworten - woher soll der das interne Netz kennen.

freundliche Grüße

L.Zimmermann

Hi,

der lokale DNS Server ist eingetragen und kein globaler ich habe zusätzlich zum testen auch mal als sekundären den Domaincontroller eingetragen, aber ohne besserung.

In dem Firmennetz gibt es eine Domäne aber dort ist der Server nicht drin, weil er nur kurz genutzt wird.

Im Install Netzwerk gibt es keine Domäne das soll nur ein Stumpfer zugang zum Firmennetzt / der AD sein für z.B. die ThinClients das funktioniert auch einwandfrei.

Im Firmennetzt gibt es eine Domäne, aber um den Server den es sich handelt ist nicht in der Domäne also im Prinzip kann man ihn auch als Client sehen.

Was meinst du mit Host Datei bearbeiten? Wo man ich das ? Danke dir 

Fang bloß nicht mit der Hosts-Datei an. ... und schon gar nicht in einem Install-Netz. Was du dann auslieferst, ist "defekt".

Siehe jprusch:  ...NetBIOS-Namen in Freigaben verwenden und dann DNS-Auflösung ...

Sauber wäre, du baust die Installation auf Vollqualifizierte Servernamen (DNS-Tauglich) um.

Ein Workaround, welcher funktionieren könnte: Trage den fehlenden Domänen-Teil im DHCP unter Domäne ein.
DHCP bietet diesen dann den Clients an (unter Windows wird das zum "Verbindungsspezifischen Domänen-Suffix") und wenn alles mitspielt, versuchen u.U. Betriebssystem und Anwendung, ob der "kurze" Name (NetBios-Name) evtl. aufzulösen geht, wenn man dieses Suffix anhängt. Erfolgschancen gibt es durchaus, wobei ein Install-mini-OS da schon mal etwas anders reagiert, als ein volles Windows.

Wir sind uns da wohl einig:  "hosts" Dateien gehören verboten, weil nicht wartbar und sowieso eine furchtbare Krücke als Notlösung.

Zu der Frage: Was kann man auf dem Server "DMPSRV" tun?

Du kannst den DNS-Dienst auf einem Windows-Server installieren, völlig unabhängig von einem ADS. Das ADS hängt zwar von DNS ab und installiert diesen immer mit, aber umgekehrt kannst du den DNS-Dienst alleine installieren, wenn du keine ADS-Dienste benötigst.
Wir machen das in unserer "Labor-Umgebung" immer so, wenn wir Systeme für Kunden vorkonfigurieren..

Dort legst dur dir eine "Forward-Lookupzone" und eine "Reverse-Lookupzone" nach den Gegebenheiten deines Zielnetzes beim Kunden ein. Diesen Server verwendest du dann bei deinen Clients als den lokalen DNS-Server. Diese Einstellung kann dann auch per DHCP verteilt werden, die Luxus-Variante mit allem Komfort wäre dann den DHCP und den DNS auf demselben Windows-Sever zu betreiben und dann die dynamische Registreiung zu verwenden...aber da müsste man jetzt weiter in die Tiefe gehen.

Wichtig ist, dass dieser DNS ein forwarding für die DNS-Requests betreiben sollte, die er nicht auflösen kann.

Hi Philipp,

ich denke sein DNS tut irgendetwas von dem, was es soll.

Wenn er den FQHN verwendet, wird dieser ja aufgelöst.

Schönes WE.

Hi Phillip,

ich konnte mit der Pfusch Lösung im DHCP vom install Netzwerk die Domäne.local einzutragen immerhin einen Ping nur mit DPMSRV ausführen und eine richtige Antwort bekommen.

Die Software die wir nutzen ist Windows Deployment Toolkit, nun verbindet er sich und sagt auch Verbindung ok.

Nur leider sagt er nun falsche Credentials, er meldet sich mit dem Benutzer vom Server an. Ich vermute nur das er sich nun als User.Domain.local anmeldet und der DPMSRV sagt: hau ab Dich kenn ich nicht.

Könnte ich das austricksen, wenn ich dem DPMSRV als DNS-Suffix Domain.local gebe? Weil dann müssten die Credentials ja wieder gleich sein oder?

Zu deiner Antwort Phillip:

Das bei einem ADS die DNS Rolle mit installiert weiß ich und auch das man es auch separat installieren kann.

Nur meinst du ich soll nun die Forward und Reverse Lookupzone auf dem ADS konfigurieren?

Weil dort habe ich zum Testen schon in der Forward einen A Eintrag mit dem DPMSRV eingerichtet, hatte aber nichts gebracht.

Oder brauch ich dafür zwingend auch einen Eintrag in der Reverse Lookupzone?

Du meinst also das ich in der Reverse Zone z.B. als NetzID das Kundennetz angebe z.B. 192.168.130 und dann per DHCP in dem Fall den Domaincontroller verteilen lass also z.B. 192.168.120.10

Somit wäre im Install Netz der DNS … 120.10 und das Gateway die RED 192.168.130.1

Ich danke dir und euch :)

Das ist das Problem mit Microsoft-Windows-lastigen Umgebungen: der Begriff "Domäne" ist hier mehrdeutig oder mißverständlich.

In der Windows-Welt redet man von einer Domäne, meint damit aber die "Windows-Domäne" für ein ADS.

Im Rest der Welt ist eine "Domäne" eine DNS-Domäne (DNS = Domain Name Service), also ein Bestandteil eines FQDN (Fully Qualified Domain Name).

Du kannst dein ADS (ich sage dazu dann "Windows-Domäne" bei der Ausbilung meiner Azubis) zum Beispiel "hans.local" nennen, dein DNS aber intern auf die DNS-Domäne "hanswurst.intern" auflösen lassen. Oder, wenn du die Domäne "hanswurst.de" tatsächlich besitzt, wäre es schlauer, dann intern auch auf "hanswurst.de" aufzulösen. Dazu kann man dann in der ADS alternative "UPN-Suffixe" setzen, die diese DNS-Domänen zusätzlich zur ADS-Auflösung nutzen usw. usf.

Du siehst, du kannst da ruhig "Workgroup" drin stehen lassen, das hat miteinander nix zu tun.

Wichtiger ist das, was Lars schon erwähnt hat: der DNS-Suffix, der an die NetBIOS Namen der Rechner automatisch von Windows angehängt wird, sollte derjenige von deiner intern genutzten DNS-Domäne sein.

Ich würde bei VPN-Verbindungen jedoch immer auf eine reine DNS-Namensauflösung setzen, die dann FQDN benutzt.

Ahhh! jetzt kommen wir zu den Anmeldenamen!

Beispiel:

ADS NetBIOS-Name= hansdom

ADS DNS Name = hanswurst.local

Anmeldung möglcih mit folgenden Namen:

"Alte Form" (NetBIOS) :    hansdom\benutzername
"neue Form" (DNS):          benutzername@hanswurst.local

Ich habe aufgrund deiner Info jedoch noch nicht verstanden, wie das Szenario bei euch aussehen soll.

Das Deployment soll über euren Server laufen, der sich in eurer Firmen-Domäne befindet?
Und in der Testumgebung habt ihr eure Domänenkonten zur Authentifizierung verwendet?

Also der Server DPMSRV ist im Domänen Netzwerk vom Kunden aber nicht in der Domäne.

Durch die RED bekommen wir ein Install Netzwerk, was aber in keiner Domäne ist. In diesem Netz befinden sich die Clients die probieren den DPMSRV zu erreichen.

Die Clients probieren auf den Pfad: \\DPMSRV\share$ zuzugreifen mit Erfolg.

Nur jetzt bringen die einen credentials Fehler, ich vermute da ich dem Install (Client) Netz die Domäne domain.local gegeben haben und damit DPMSRV richtig aufgelöst werden kann, das er nun die Authentifizierung mit der Domäne probiert.

Also sprich:

domain\Administrator

Damit würde die Authentifizierung fehlschlagen, weil die Clients melden sich mit dem lokalen Admin vom Server an.

Würde es etwas bringen dem DPMSRV als DNS Suffix die Domäne zu geben damit die Anmeldung wieder funktioniert, oder ist mein Gedankengang falsch?

Mir ist am Wochenende aufgefallen, das ich in dem Windows Deployment Tool auch im Freigabepfad mal die IP vom Server hätte testen können, damit hätte ich mir den Namen und die Domain sparen können.

Danke dir

Update:

Also keine Ahnung woran es liegt, Windows Deployment Toolkit sagt es wären die falschen credentials.

Wenn ich dann über die Konsole gehe kann ich per ping alles auflösen in jeder Form.

Sollte ich einen Schritt weitergehen und per net use mir das Laufwerk mit den Credentials funktioniert es einwandfrei.

Auch per cmd + cd browse komme ich in jede Struktur also rechte passen.

Nun habe ich eine Freigabe ohne Kennwort gemacht und teste es nochmal, leider sehe ich nicht was passiert.

Auch im Ereignislog des Server sehe ich nichts Interessantes außer ein Zugriff von Administrator mit der Domain: domain.local

Da ich aber die Freigabe ohne Kennwort gemacht habe, sollte er ja theoretisch in der Lage sein sich mit allem anzumelden.

In der Firewall kann es nicht liegen, da der prinzipielle Verbindungsaufbau funktioniert.

Ich habe zusätzlich das ganze komplett in einem eigenen Netz + virtuellen Server lokal dargestellt und da funktioniert es ohne Probleme.

So langsam gedenke ich es damit aufzugeben und es mal in einem anderen Szenario zu testen.

Grüße

Hallo Luis,

es wäre einfacher, wenn du uns einmal mitteilst, wie deine Zielkonfigration aussehen soll.

Bisher haben wir immer nur Teilausschnitte, die du getestet hast und dazu dann dein Ergebnis und deine Überlegungen dazu.

Damit kommen wir nicht weiter.

Meine Erkenntnise zum Thema "Windows-Berechtigungen" und "Credentials" habe ich versucht dir mitzuteilen.

Es ist auf jeden Fall nicht os, dass Windows "irgendwie" vesucht sich eine Anmeldung zusammen zu basteln.

Solange die Cliet-Maschinen sich nit in einer Windows-Domäne befinden, versuchen sie auch nicht, sich mit Domain-Logins anzumelden. Woher sollten Sie die Windows-Domäne auch kennen? Mit den DNS-Einstellungen hat das GAR NICHTS zu tun.

Für die DNS-Auflösung setzt ein Windows-Client seinen eigenen "DNS-Suffix" hinter einen hostnamen, wenn kein FQDN angegeben wird. Für den Anfänger ieht das manchmal so aus, als wenn der Windows-Client versucht,  eine Windows-Domäne zu finden.

Macht er aber nicht, er klappert lediglich seine Möglichkeiten im DNS durch.

Hallo Luis,

es wäre einfacher, wenn du uns einmal mitteilst, wie deine Zielkonfigration aussehen soll.

Bisher haben wir immer nur Teilausschnitte, die du getestet hast und dazu dann dein Ergebnis und deine Überlegungen dazu.

Damit kommen wir nicht weiter.

Meine Erkenntnise zum Thema "Windows-Berechtigungen" und "Credentials" habe ich versucht dir mitzuteilen.

Es ist auf jeden Fall nicht os, dass Windows "irgendwie" vesucht sich eine Anmeldung zusammen zu basteln.

Solange die Cliet-Maschinen sich nit in einer Windows-Domäne befinden, versuchen sie auch nicht, sich mit Domain-Logins anzumelden. Woher sollten Sie die Windows-Domäne auch kennen? Mit den DNS-Einstellungen hat das GAR NICHTS zu tun.

Für die DNS-Auflösung setzt ein Windows-Client seinen eigenen "DNS-Suffix" hinter einen hostnamen, wenn kein FQDN angegeben wird. Für den Anfänger ieht das manchmal so aus, als wenn der Windows-Client versucht,  eine Windows-Domäne zu finden.

Macht er aber nicht, er klappert lediglich seine Möglichkeiten im DNS durch.