Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.135
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von NilsK

  1. Moin,

     

    in AD-Fragen darf ich Evgenij ja zustimmen. :lol3:

     

    Ein RODC trägt in fast* keinem Szenario zum Schutz des AD bei, macht dafür aber den Betrieb fehleranfälliger und das Troubleshooting schwerer. Dieser Thread ist ein weiterer Beleg, zumindest für den zweiten Teil der These.

     

    Ernst gemeinter Rat: Verabschiedet euch von der RODC-Idee.

     

    Gruß, Nils

    PS. * tatsächlich habe ich noch nie ein Design gesehen, in dem ein RODC sinnvoll gewesen wäre. Da Microsoft aber ohne Anlass sowas nicht entwickelt hätte, mag es sein, dass es mal Anforderungen gab, die sich damit haben lösen lassen. Nur deshalb steht in meinem Satz die Einschränkung "fast".

    • Like 1
  2. Moin,

     

    das Konzept gibt es durchaus, das ist dann "Windows Hello". In dem Fall besteht der Witz aber darin, dass man sich eben nicht mit Username + Kennwort an dem Rechner anmeldet, sondern mit einem separaten Login, der nur auf diesem Rechner existiert. Idealerweise Biometrie (also typischerweise Hello-Kamera oder Fingerabdruck), zur Not eine PIN.

     

    Auf dem Weg kann man sich durchaus auch bei Webseiten oder Applikationen anmelden, aber nicht an "irgendwelchen" und auch nicht als Ersatz für ein herkömmliches MFA. Die Anwendungen müssen das ausdrücklich können.

     

    Es führt also kein Weg drumrum, dass wir uns entweder über den konkreten Anwendungsfall unterhalten oder so schwammig bleiben. "Den MS Authenticator auf dem Desktop", der sich so verhält wie ein Smartphone, gibt es so jedenfalls nicht.

     

    Gruß, Nils

     

    • Like 2
    • Danke 2
  3. Moin,

     

    vor 15 Stunden schrieb PeterchenFrost:

    ich habe einen neuen Dc installiert und diesen auch soweit angepasst, dass er den Job vom alten DC übernehmen könnte.

    was genau hast du denn da gemacht? Du hast einen Windows-Server in die bestehende Domäne aufgenommen und ihn dann zum zusätzlichen DC dieser Domäne hochgestuft? Oder bist du anders vorgegangen?

    Und was meinst du mit "soweit angepasst, dass er den Job vom alten DC übernehmen könnte"? Was für Änderungen hast du da vorgenommen?

     

    Abgesehen von der derzeitigen Fehlersituation, ist ein einziger DC für fast alle Netzwerke zu wenig. Von wie vielen Usern sprechen wir denn in der Domäne?

     

    Gruß, Nils

     

  4. Moin,

     

    naja, deiner Aussage nach bist du jetzt seit gut einem Tag dabei und du bist mit einem ziemlich komplexen Thema beschäftigt. Das braucht schon seine Zeit.

     

    Im Screenshot vom Client sieht man das Problem sehr schön. Zwar steht die IP-Adresse des Servers korrekt als DNS-Server drin, aber eben auch noch vier weitere Adressen. Die haben da in einem Domänen-Szenario nichts zu suchen. In diesem Fall wirst du die vermutlich am einfachsten los, indem du IPv6 erst mal abschaltest. In einem echten Netzwerk würde man das Drumrum lieber richtig konfigurieren, aber darum geht es hier ja nicht.

     

    Ich komme dann noch mal auf den Vorschlag von Jan zurück. Für das, was du vorhast, solltest du dir ein völlig separiertes Testnetz innerhalb von Hyper-V aufbauen. Heißt: Sowohl der DC als auch alle Clients und alle weiteren Server sollten VMs innerhalb von Hyper-V sein. Der physische PC hat dann ausschließlich die Rolle Hyper-V installiert und sonst nichts. Die VMs bindest du dann alle an einen internen Switch in Hyper-V an, so umgehst du die Einflüsse des "echten" Netzwerks. Auf die Weise kannst du dich auf das konzentrieren, was du zum Lernen von Windows Server und Active Directory brauchst.

     

    Gruß, Nils

     

    • Danke 1
  5. Moin,

     

    bei sowas ist es am besten, erst die Anforderungen zu definieren und dann die Technik festzulegen. Ich nehme mal an, dass die Benutzer nur über den Proxy auf das Web zugreifen können sollen. Wenn du das wirklich sicher einrichten willst, sind die Proxy-Einstellungen auf dem System nur ein Teil der Lösung. Der wichtigere Teil wäre die Firewall, die den öffentlichen PCs keinen direkten Zugriff auf das Internet zulässt, sondern nur dem Proxy.

     

    Was die Proxy-Einstellungen anbelangt, solltest du den Kiosk natürlich so einrichten, dass der Anwender das nicht einfach ändern kann. Falls es ihm aber doch gelingt, kann er eben nicht am Proxy vorbei.

     

    Gruß, Nils

     

    • Like 2
  6. Moin,

     

    vor 23 Stunden schrieb testperson:

    Da ich bis lang nicht an wirkliche Neuerungen im AD Bereich geglaubt habe

     

    gibt ja auch keine. :lol3:

     

    Das einzige "Feature" sind die 32-K-Datenbankseiten, für die es auch den neuen Modus braucht. Interessant nur für wenige Enterprise-Szenarien und dort auch kaum sichtbar. Der Rest ist so sehr Kleinkram, dass schon "Produktpflege" ein zu großes Wort wäre. ;-)

     

    Gruß, Nils

     

    • Like 2
    • Haha 2
  7. Moin,

     

    nein, so wäre der Zusammenhang nicht. In deinem Fall fielen keine CALs an, weil du ja über den Admin-Zugriff (oder über einen anderweitig lizenzierten Zugriff) den CSV-Export machst. Was dann hinterher mit dem Export geschieht, ist lizenzrechtlich egal. Ebenso ist es für die Lizenz egal, wo die CSV-Datei herkommt, die du mit deinem Admin-Zugriff importierst.

     

    Anders könnte es aussehen, wenn du dir jetzt was bauen würdest, das jede einzelne Transaktion für einzelne nicht lizenzierte User per Ex- und Import übermitteln würde, du dir also quasi dein eigenes Zugriffsprotokoll baust. Das wäre dann evtl. ein Fall für das Multiplexing, das lizenzpflichtig ist. Das ist jetzt aber ein konstruierter Fall. 

     

    Es geht einfach nur darum, dass der typische Applikationsserver mit SQL-Zugriffskonto keine CALs einspart. Wenn 400 Leute die Dienste eines SQL Servers nutzen, dann müssen auch 400 Zugriffe lizenziert werden, auch wenn alles formal nur über ein Anmeldekonto geschieht. Das ist der Punkt. Ob diese User Mitarbeiter oder Kunden sind, spielt dabei keine Rolle.

     

    Gruß, Nils

     

    • Like 1
  8. Moin,

     

    ... zumal es die Faustregel gibt, dass man in einer Hyper-V-Clusterumgebung immer das "höchste" Tool nutzen sollte, also für Aktionen, die über den FC-Manager oder über den HV-Manager durchführbar sind, immer den FC-Manager. In dem Fall kann es nämlich sein, dass der HV-Manager die Cluster-Besonderheiten nicht berücksichtigt. Ist die Umgebung per VMM verwaltet, dann gilt es entsprechend, in dem Fall ist der VMM das "höchste" Tool.

     

    Für mich klingt es auch so, als sei mitnichten alles in Ordnung. Da man einen Cluster hat, um sich auf ihn verlassen zu können, rate ich auch dazu, externen Sachverstand dazu zu holen und das Cluster-Upgrade nicht irgendwie zu basteln, sondern ordentlich zu machen. Hochverfügbarkeit und Sparsamkeit gingen noch nie zusammen.

     

    Gruß, Nils

     

    • Like 1
  9. Moin,

     

    zunächst mal ist völlig unklar, an welcher Stelle du überhaupt nachsiehst - im Server-Manager, im Failover-Cluster-Manager oder wo?

    Dann verstehe ich das Konstrukt nicht. Warum baut man einen Cluster, in dem ein Node mit einer Eval-Lizenz läuft? Davon abgesehen, dass das ziemlich sicher ein Lizenzverstoß ist, ist es auch technisch nicht sinnvoll.

     

    Und was heißt

    Zitat

    Den HV 4 (der sich nicht im Cluster befindet) kann ganz normal hinzugefügt werden und wird angezeigt

     ? Wenn er nicht im Cluster ist, wo fügst du ihn hinzu?

     

    Und schließlich: Warum betreibt man heute noch einen Cluster mit Windows Server 2012? Ein Node ohne Support widerspricht irgendwie dem Konzept eines Clusters.

     

    Gruß, Nils

     

×
×
  • Neu erstellen...