Kein Computerkonto wenn DC ausfällt?

[Nobbyaushb 1.464]

vor 2 Minuten schrieb TimS:

Und wenn das nicht geht? Es wird doch sicher grosse Netze geben wo eben der DC nicht auch der DNS-Server ist.

Ich habe Kunden mit großen Netzen - in keinem ist ein DC kein DNS und GC - man kann durchaus in Coexistens mit BIND Severn arbeiten - aben eben zusammen, dann klappt das

(>= 25.000 User)

[TimS 11]

vor 1 Minute schrieb Nobbyaushb:

Ich habe Kunden mit großen Netzen - in keinem ist ein DC kein DNS und GC - man kann durchaus in Coexistens mit BIND Severn arbeiten - aben eben zusammen, dann klappt das

(>= 25.000 User)

Dann muss ich das Projekt eben begraben. Wir haben keine Möglichkeit einen eigenen DNS-Server zu betreiben. DHCP macht auch das HRZ. Ich kann mir nur nicht vorstellen das der BIND von unserem HRZ nicht das kann was der Microsoft DNS macht. Fragt sich nur wie.

[cj_berlin 1.306]

vor 14 Minuten schrieb TimS:

Und wenn das nicht geht? Es wird doch sicher grosse Netze geben wo eben der DC nicht auch der DNS-Server ist. 

Du musst unterscheiden zwischen "DNS läuft nicht auf DC" und "DNS, was auf DC läuft, wird nicht von Hinz und Kunz zur Namensauflösung angesprochen".

 

Und ja, DCs ohne DNS und DNS auf anderen Servern ist eine unterstützte Konfiguration und von Microsoft dokumentiert. "Dokumentiert" und "unterstützt" ist aber etwas anderes als "empfohlen" und stammt aus einer Zeit, wo Du auf einem Uni-Campus 5000 Knoten im UNIX-DNS hattest, und daneben war noch ein Windows-Bereich mit AD und 50 Rechnern.

Am 2.9.2021 um 12:39 schrieb TimS:

Wie sollen sonst mehr als 50 PCs sinnvoll verwaltet werden?

Mit einer Konfigurationsverwaltung und Software-Verteilung. Die meisten Produkte, die nicht von Microsoft sind, benötigen dafür kein AD.

vor 27 Minuten schrieb TimS:

Ich frage mich nur WARUM sich nicht herausfinden lässt WO der Fehler ist. Irgendwo müsste es doch eine Logdatei geben - wie unter Linux - wo genau drin steht was da schief läuft während der Client in die Domain aufgenommen wird???

Steht alles in den Event Logs. Attribute am AD-Objekt des Clients können auch bei der Diagnose helfen.

[NorbertFe 2.027]

vor 44 Minuten schrieb TimS:

Das habe ich ja verstanden! Es geht bei uns an der Universität aber nicht.

Bis jetzt ging das in allen Hochschulen die ich (von innen) gesehen habe. ;)

 

vor 45 Minuten schrieb TimS:

Und wenn das nicht geht? Es wird doch sicher grosse Netze geben wo eben der DC nicht auch der DNS-Server ist.

Da sitzen dann Leute die ad und DNS können. ;) scnr.

[NilsK 2.930]

Moin,

 

um das noch mal zusammenzufassen:

1. Active Directory ist auf funktionierende DNS-Auflösung angewiesen. Das gilt für alle Clients und alle Server, die Mitglieder sind.
2. Das DNS kann durchaus "separat" laufen. Das erfordert dann aber erheblich mehr Aufwand und Mitarbeit der DNS-Administratoren.
3. Es gibt eine ganze Reihe von Möglichkeiten, zu einer Koexistenz beider "Welten" zu kommen. Das funktioniert erfahrungsgemäß auch in großen Hochschulnetzen sehr gut.
4. Natürlich protokolliert Windows Fehler, sehr ausführlich sogar. In komplexen Fehlersituationen kann es aber hohen Aufwand erfordern, die Logs auszuwerten und zu interpretieren, um den Fehlern auf die Spur zu bekommen. Das gilt für alle Betriebssysteme.
5. Wir sind hier in einem Forum und können daher nur begrenzt unterstützen.

Meiner Interpretation nach liegt dein Problem bei Punkt 2. Das kommt an Unis (leider) oft vor, aber erfahrungsgemäß ist es meistens möglich, von Punkt 2 zu Punkt 3 zu kommen. Reden hilft, unterstützen kann dabei jemand, der die technischen Hintergründe kennt und darstellen kann.

 

Gruß, Nils

 

[TimS 11]

vor 39 Minuten schrieb NilsK:

Moin,

 

um das noch mal zusammenzufassen:

1. Active Directory ist auf funktionierende DNS-Auflösung angewiesen. Das gilt für alle Clients und alle Server, die Mitglieder sind.
2. Das DNS kann durchaus "separat" laufen. Das erfordert dann aber erheblich mehr Aufwand und Mitarbeit der DNS-Administratoren.
3. Es gibt eine ganze Reihe von Möglichkeiten, zu einer Koexistenz beider "Welten" zu kommen. Das funktioniert erfahrungsgemäß auch in großen Hochschulnetzen sehr gut.
4. Natürlich protokolliert Windows Fehler, sehr ausführlich sogar. In komplexen Fehlersituationen kann es aber hohen Aufwand erfordern, die Logs auszuwerten und zu interpretieren, um den Fehlern auf die Spur zu bekommen. Das gilt für alle Betriebssysteme.
5. Wir sind hier in einem Forum und können daher nur begrenzt unterstützen.

Meiner Interpretation nach liegt dein Problem bei Punkt 2. Das kommt an Unis (leider) oft vor, aber erfahrungsgemäß ist es meistens möglich, von Punkt 2 zu Punkt 3 zu kommen. Reden hilft, unterstützen kann dabei jemand, der die technischen Hintergründe kennt und darstellen kann.

 

Gruß, Nils

 

Guten Morgen! Vielen Dank für die ausführliche Antwort! Ich kriege das schon hin, koste es was es wolle :)

[daabm 1.348]

Um Nils bei seinem Punkt 2 zu unterstützen: Auch bei uns läuft DNS nicht (bzw. größtenteils nicht) auf den DCs mit. Unser Netz hat vermutlich über 10^6 DNS Clients und eine 4stellige Anzahl AD-Domänen.

[TimS 11]

vor 27 Minuten schrieb daabm:

Um Nils bei seinem Punkt 2 zu unterstützen: Auch bei uns läuft DNS nicht (bzw. größtenteils nicht) auf den DCs mit. Unser Netz hat vermutlich über 10^6 DNS Clients und eine 4stellige Anzahl AD-Domänen.

Das ist bestimmt sehr interessant! Bei uns ist es so das ein AD vom Rechenzentrum nicht unterstützt wird. Ich kann über ein Webinterface für die Subdomain unseres Instituts die Host und SRV Records eintragen und hoffen es klappt.

Bin mittlerweile so weit das es wohl an der Firewall liegt. Die beiden DCs sind der Domain ohne Probleme beigetreten und replizieren sich. Beide sind in selben Subnetz (virtuelle Maschinen). Die Clients in einem anderen Netz 

[daabm 1.348]

vor 2 Stunden schrieb TimS:

Bei uns ist es so das ein AD vom Rechenzentrum nicht unterstützt wird.

Da könnte man ja mal mit dem RZ reden über "Kunde" und "Angebot trifft Nachfrage" Ich weiß, daß das relativ platt klingt, aber viele RZ-Betreiber (ich nehme uns da nicht aus) sind zu sehr selbstorientiert und arbeiten zu wenig zu Gunsten der Kundenanforderungen.

[TimS 11]

vor 14 Stunden schrieb daabm:

Da könnte man ja mal mit dem RZ reden über "Kunde" und "Angebot trifft Nachfrage" Ich weiß, daß das relativ platt klingt, aber viele RZ-Betreiber (ich nehme uns da nicht aus) sind zu sehr selbstorientiert und arbeiten zu wenig zu Gunsten der Kundenanforderungen.

Keine Chance - leider. Zu wenig Personal, kein Interesse, keine Notwendigkeit...

Daher die Frage ob jemand eine Link kennt wo etwas über Active Directory und Fehlersuche zu finden ist und Active Diretory ohne DNS auf dem DC.

[cj_berlin 1.306]

Hier zum Einstieg: https://www.infoblox.com/wp-content/uploads/infoblox-white-paper-ad-dns-facts-and-fiction-1.pdf 

[NilsK 2.930]

Moin,

 

vor 39 Minuten schrieb TimS:

Zu wenig Personal, kein Interesse, keine Notwendigkeit...

auch wenn ich mich wiederhole ... dann könnte der Vorschlag, dass das HRZ DNS-Zonen bzw. Subdomains an Institute delegiert, doch helfen. Minimaler Aufwand für das HRZ, hoher Nutzen für die Institute. Dann können die Institute ihr AD-DNS selbst betreiben und es gibt an der Stelle keinen weiteren Supportbedarf für das HRZ.

 

Schwieriger dürfte da das Firewallthema sein, das nach deiner jüngsten Schilderung wohl eher der Kern des Problems ist.

 

Gruß, Nils

 

[TimS 11]

Am 8.9.2021 um 13:52 schrieb NilsK:

Moin,

 

auch wenn ich mich wiederhole ... dann könnte der Vorschlag, dass das HRZ DNS-Zonen bzw. Subdomains an Institute delegiert, doch helfen. Minimaler Aufwand für das HRZ, hoher Nutzen für die Institute. Dann können die Institute ihr AD-DNS selbst betreiben und es gibt an der Stelle keinen weiteren Supportbedarf für das HRZ.

 

Schwieriger dürfte da das Firewallthema sein, das nach deiner jüngsten Schilderung wohl eher der Kern des Problems ist.

 

Gruß, Nils

 

Vorweg: es funktioniert jetzt :) Problem war tatsächlich die Firewall. Ob DNS läuft lässt sich ja mit dcdiag testdns testen. Bei der Suche nach der Fehlermeldung mit dem RPC-Server bin ich dann auf diese Webseite gestossen: Firewall Ports Required to Join AD Domain - AventisTech habe das HRZ gebeten zu gucken ob in der Firewall irgendwas zwischen DC und Client geblockt wird. Die haben dann die Ports tcp 67, tcp 49674 udp 123 als geblockt gefunden und freigeschaltet. Jetzt kann ich Clients der Domain hinzufügen und mit Domain-Benutzern anmelden.

Mir wurde gesagt dass das HRZ ja eben dafür da sei nichts zu delegieren. Jeder Dienst der delegiert wird kann für Störungen sorgen. Dann würde unser ganze Instituts-Netz ausfallen. So wie es jetzt ist können die Clients weiterarbeiten auch wenn die DCs mal komplett ausfallen. Die Clients bekommen ihre IP per DHCP vom HRZ und DNS auch. Anmelden können sich die Benutzer da die Passwörter angeblich gecacht werden. Hat sich ein Benutzer einmal angemeldet würde das Kennwort lokal hinterlegt.

[NilsK 2.930]

Moin,

 

Nun ja, die Antwort vom HRZ ist zu Teilen korrekt, aber eigentlich eine Nebelkerze. Dass die Clients weiter arbeiten könnten, ist nicht die Leistung des HRZ. Aber lassen wir das.

 

Schön, dass es jetzt geht, danke für die Rückmeldung. 

 

Gruß, Nils

[daabm 1.348]

vor einer Stunde schrieb TimS:

Mir wurde gesagt dass das HRZ ja eben dafür da sei nichts zu delegieren.

Siehe oben - "Kunde und Angebot" und "zu wenig zu Gunsten der Kundenanforderungen"... jm2c