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

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.