Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    13.292
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

624 Exzellent

5 Benutzer folgen diesem Benutzer

Über NilsK

  • Rang
    Expert Member
  • Geburtstag 07.08.1970

Webseite

Letzte Besucher des Profils

2.870 Profilaufrufe
  1. Replikationsfehler zwischen den DCs

    Moin, ein Turnus zum Kennwortwechsel ist ein komplett falscher Ansatz. Die Erkenntnis hat sich nur noch nicht überall durchgesetzt. Entweder ist ein Kennwort "sicher" bzw. stark, dann muss man es nie wechseln. Oder es ist schwach, dann bringt aber auch ein turnusmäßiger Wechsel nichts. Ein Kennwort muss man dann wechseln, wenn es kompromittiert wurde (bzw. der Verdacht besteht) - und nicht ein paar Wochen danach zum festgelegten Termin. Regelmäßige Kennwortwechsel verringern in der Praxis die Kennwortsicherheit, weil 100 Prozent der Anwender dann simple Mechanismen verwenden (hochzählen, Zahl des Monats usw.), die das Kennwort leicht vorhersagbar machen. Das krbtgt-Kennwort wird nicht vom Admin gesetzt (auch wenn das so aussieht), sondern vom System (= egal, was der Admin einträgt, das System generiert ein Kennwort, das es nirgends anzeigt). Das ist von einer Qualität, die als "sicher" gelten kann. Hier gilt das Gesagte: Es hat keinen Sinn, das regelmäßig zu wechseln. Die Kunst bestünde darin, eine mögliche Kompromittierung aufzudecken - da das faktisch unmöglich ist, muss man die verhindern. Ein Angreifer, der das Kennwort einmal kompromittiert hat, ist aber kaum aus dem System zu werfen, weil er dann eine ganze Reihe von Möglichkeiten hat, sich festzusetzen und einen erfolgreichen Angriff auf das neue Kennwort auszuführen. Wer sich näher dafür interessiert, nimmt sich ein paar Tage Zeit und sucht nach "Golden Ticket" und "Silver Ticket". Gruß, Nils
  2. Identitäten und Berechtigungen / IAM Rollen

    Moin, ja, das Dilemma ist richtig beschrieben. Der Umstand ist auch ein Grund dafür, dass man in sehr großen Umgebungen versucht, von Gruppen wegzukommen und mit Claims zu arbeiten. Das führt aber zu einem neuen Dilemma, weil die Komplexität dadurch noch mal ansteigt. Gruß, Nils
  3. Replikationsfehler zwischen den DCs

    Moin, einen festen Turnus gibt es dafür nicht. Der ist auch obsolet. Sollte jemand das ausgespäht haben, dann muss man es sofort ändern. Das grundsätzliche Dilemma. Die Änderung muss zweimal erfolgen, weil das Vorgängerkennwort ebenfalls noch gültig ist. Das ist Absicht, damit auch in komplex replizierten Umgebungen die Kommunikation sichergestellt ist. Erster Wechsel - Warten (maximale Replikationszeit der Umgebung plus Puffer) - zweite Änderung. Gruß, Nils
  4. Opa und Oma erzählen von früher

    Moin, Textomat von Data Becker. Gruß, Nils
  5. Moin, richtig, im Fall von VMware gibt es das Thema gar nicht. Da lizenziert man mit einer Standard-Lizenz zwei VMs mit Windows Server. Das Thema der "dritten" Lizenz auf dem Host existiert nur bei Hyper-V. Dort auf dem Host noch andere Software zu betreiben, verbietet sich aber schon technisch: Ein Host ist ein Host und nichts anderes. Niemand würde direkt auf einem VMware-Host noch Anwendungssoftware installieren, selbst wenn es ginge. Genauso ist das auch bei Hyper-V. Gruß, Nils
  6. Batch – bestimmte Werte löschen

    Moin, Vorschlag: Entweder du definierst mal, was du eigentlich vorhast. Dann kann man dir passende Vorschläge machen. Oder (vermutlich viel besser): Du nimmst dir Zeit, dich mit Grundlagen zu befassen und in Ruhe Dinge zu probieren. Dann meldest du dich, wenn du konkrete, beschreibbare Probleme hast. Ein Board wie dieses eignet sich nicht als Lern-Chat. Gruß. Nils
  7. Best Practice bei User Änderungen

    Moin, die Aussage klingt nach wilden Vermutungen ohne Sachkenntnis ... sorry. Maßgebend zur Identifikation eines User-Objekts ist die Security ID (SID). Diese wird in Berechtigungslisten, bei der Zuordnung von Exchange-Mailboxen usw. verwendet. Die SID ändert sich nie und wird nach dem Löschen eines Objekts nie erneut verwendet. (Nahezu) alle anderen Attribute kann man ändern. Da beim Umbenennen eines Users (dito Gruppe, Computer) die SID gleich bleibt, bleiben Berechtigungen usw. für dieses Objekt unverändert erhalten, ebenso Gruppenmitgliedschaften. Man kann auch sämtliche Attribute eines Objekts einsehen, spätestens mit ADSI Edit. Daher gibt es auch keine "verborgenen" oder "vergrabenen" Attribute. Ändert man den Namen eines Users, so passt ADUC mehrere Felder gleich mit an. Reicht das nicht aus, dann kann man weitere Felder auch anpassen. Was nicht angepasst wird, sind separate "abhängige" Werte wie etwa der Name des Profilordners. Den kann man bei Bedarf manuell anpassen. Gruß, Nils
  8. Moin, doch, natürlich. Der Suchbegriff "DC Locator" sollte dich weiterbringen. Gruß, Nils
  9. Batch – bestimmte Werte löschen

    Moin, wenn man es wirklich will, kriegt man das sicher auch per Batch hin. Da die "Sprache" aber eigentlich keine ist und auch für sowas nie entworfen wurde, wird das aber sehr umständlich. Die PowerShell hingegen ist ausdrücklich auch für komplexere Aufgaben gemacht und hat ein gutes Handling von Variablen, Schleifen, Strings usw. Auf jeden Fall müsstest du für dich erst mal die Logik genauer definieren. Unter welchen exakten Umständen soll exakt was passieren? Mit so einer Definition ist man dann oft schon nah an der Lösung. Gruß, Nils
  10. Batch – bestimmte Werte löschen

    Moin, Schulaufgabe? Gruß, Nils
  11. Best Practice bei User Änderungen

    Moin, interessante Behauptung - was hat denn die Person genau gesagt? Gruß, Nils
  12. Replikationsfehler zwischen den DCs

    Moin, nein, das sind unterschiedliche Dinge. Das krbtgt-Kennwort ändert man nur manuell, die Computerkennwörter handeln die Rechner regelmäßig mit dem AD aus. Gruß, Nils
  13. Replikationsfehler zwischen den DCs

    Moin, ein DC darf maximal so lange offline sein, bis die Tombstone Lifetime erreicht wird. Das sind entweder 60 oder 180 Tage. Ich weiß nicht, von was für einem Kerberos-Passwort du sprichst. Vielleicht ein Missverständnis? Kerberos akzeptiert keine Zeitabweichung zwischen DC und Client von mehr als 5 Minuten. Das hat mit deinem Problem aber nichts zu tun. Bei dem Phänomen, das anscheinend bei dir vorlag, geht es um das Computerkennwort des DCs. Wie es zu der Versionsabweichung kommt, kann ich grad nicht aus dem Kopf sagen, aber es ist ein eher unübliches Phänomen. Kann es sein, dass die Verbindung zwischen den Standorten nicht ausreichend zuverlässig ist? Gruß, Nils
  14. Replikationsfehler zwischen den DCs

    Moin, Lass die Replikation in Ruhe. Die berechnet das AD selbst. Wenn es die nötigen Informationen dazu hat, klappt zuverlässig. Dass ab vier DCs nicht jeder mit jedem repliziert, ist normal. Gruß, Nils
  15. Hyper-V Cluster - Storage Optionen?

    Moin, erstens würde ich mit 2019 noch warten. Das macht noch einen ziemlich unausgegorenen Eindruck. Und zweitens würde ich immer was vom Hersteller unterstütztes nehmen, also entweder Hyperconverged von einem "Komplettanbieter" oder ein herkömmliches Server-und-SAN-System mit definiertem Support. S2D ist von der Idee her nett, aber in der Praxis hat man eben selbst die Support-Sorgen damit, weil es am Ende meist ein Eigenbau ist. Uns haben in den letzten Monaten mehrere Kunden angerufen, denen ein in der Community bekannter S2D-Verfechter sowas gebaut hat, der es jetzt aber nicht mehr supporten kann, weil er die Leute (besser: den Leut) nicht mehr hat. Wir fassen so ein System aber nicht an - und dann stehen die Kunden halt da ... da mag man von Hersteller-Support halten, was man will, aber damit hat man wenigstens eine definierte Grundlage, wenn mal was ist. Gruß, Nils
×