Jump to content

blub

Moderators
  • Gesamte Inhalte

    7.598
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

115 Exzellent

18 Benutzer folgen diesem Benutzer

Alle Follower einsehen

Über blub

  • Rang
    Moderator

Letzte Besucher des Profils

362 Profilaufrufe
  1. GELÖST IPv6 in Domäne aktivieren?

    Sag mal Nils, soll ich mir jeden Beitrag vorher von dir genehmigen lassen? Was bildest du dir eigentlich ein? :shock: :shock: :shock: Jedesmal geht das so!
  2. GELÖST IPv6 in Domäne aktivieren?

    Zumindest Kapitel 7 und 8 sollte man sich ansehen. https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904
  3. Wielange dauert denn der Bootprozess des physik. Servers? Von früher kenn ich es, dass solange/ sobald die NIC antwortet, der DNS auch Anmeldungen an dessen DC sendet. Dieser kann aber solange nicht antworten, bis das OS wieder komplett oben ist, bzw. erst wenn der Server komplett unten ist, schickt der DNS ihm auch nichts mehr.
  4. Brauchen wir ein Active Directory?

    wie machen es denn die anderen Bereiche der Hochschule? Active Directory ist kein Hexenwerk, aber allein auf weiter Flur, ohne Kollegen mit denen man sich austauschen kann, würde ich es nicht machen wollen. Und wenn, dann zumindest nicht lokal: https://goo.gl/vS1KhR
  5. https://isc.sans.edu/mspatchdays.html?viewday=2017-03-14 https://krebsonsecurity.com/2017/03/adobe-microsoft-push-critical-security-fixes-10/#more-38549 bereits mit Exploit in der freien Wildbahn bitte keine Monate mit dem Patch warten. (ISC Rating: Patch Now)
  6. Schema Erweiterung - Probleme zu erwarten

    Jo, der Punkt geht klar an Dich. Ich denke, dass zumindest bei den 30 DCs ein Changemanagement existiert, welches das Risiko anhand der vorhandenen Informationen sorgfältig einschätzt und nicht einfach Auge mal Pi über das wann entscheidet. Das Risiko besteht außerdem nicht darin,ob eine Re-Indizierung auf jedem DC erfolgt, sondern wielange diese jeweils dauert.
  7. Schema Erweiterung - Probleme zu erwarten

    Meine Antwort ist: Ja, ich habe reproduzierbar -nicht nur einmalig- den oben beschriebenen, bei Microsoft bekannten, technisch nachvollziehbaren Effekt gehabt, so dass ich zu einem Schemaupdate außerhalb der Geschäftszeiten rate. Mehr will ich dazu nicht mehr schreiben, außer der To selbst hat noch Fragen.
  8. Schema Erweiterung - Probleme zu erwarten

    https://technet.microsoft.com/en-us/library/cc756561(v=ws.10).aspx Vielleicht ist Wortwahl "neu aufgebaut und indiziert" in den Ohren eines Datenbank-Experten nicht korrekt. Jedenfalls den möglichen Effekt einer 95-100% igen länger dauernden Prozessorlast auf DCs (2008R2) kann ich dir aus eigener Erfahrung und mit Bestätigung durch Microsoft versichern. Eine Umgebung mit 30 DCs ist auch nicht mehr ganz klein.
  9. Schema Erweiterung - Probleme zu erwarten

    Es wird die lokale AD Datenbank auf jedem DC neu aufgebaut und indiziert. d.h. bei großen ADs mit vielen Objekten bzw. schwächeren DCs können diese DCs mehrere Minuten bis zu ein paar Stunden durch diesen Neuaufbau zu 100% ausgelastet sein. Wenn das auf mehreren DCs unkontrolliert bzw. gleichzeitig passiert, meldet sich in dieser Zeit niemand mehr am AD an. Es gibt zwei Eventlogeinträge auf jedem DC, wenn die Neuinitialisierung der DB beginnt bzw. abgeschlossen ist. Also ja, wenn man sich unsicher ist, besser den Schemaupdate außerhalb der Geschäftszeiten ausführen oder das Update kontrolliert auf einem DC nach dem anderen durchführen lassen. Dafür gibt es Artikel bzw. Regkeys zum Steuern. Einfacher ist es aber, der Umgebung einfach ein paar Stunden Zeit nach dem Update einzuräumen. Dann hast du auch ein Gefühl für das nächste Mal.
  10. Two tier CA

    Nur um mal ein Beispiel der Komlexität zu geben: Bei einem Bankprojekt haben wir wörtlich Monate benötigt, nur um heraus zu arbeiten, ob eine interne (Microsoft) PKI/ CA oder eine fremdgehostete CA besser geeignet war. Trotz vorhandenem sehr großem Banken-RZ-Verbund war letztlich für diese speziellen Anforderungen eine Verisign CA bei einem Drittanbieter die bessere Variante.
  11. Two tier CA

    Überleg mal selbst: Wieviele Personentage haben dein Chef und Du für dieses Projekt beim Kunden veranschlagt und in euer Angebot geschrieben? Was ist euer Tagessatz und wieviele Tage erwartest du, dass dir Boardspezialisten für lau abnehmen? Dafür sind Foren aber nicht da. Tipps und Hinweise, die im Rahmen einer Forendiskussion üblich sind, hast du durchaus bekommen.
  12. Two tier CA

    @smigi, wieiviele Euros werden etwa pro Jahr über diese 2000 Kassen abgewickelt? Wird auch mit Kreditkarten incl. PINs gearbeitet? Ich habe das Gefühl, dass jemand deinen Chef und Dich gehörig über den Tisch ziehen will und kostengünstig die Verantwortung für eine veraltete, mittlerweile ungenügend gesicherte Umgebung, abschieben will. So wie dein Chef es mit dir macht, so geht man doch nicht an ein derartiges Projekt ran! Apropos Nachteil eines Wildcardzeritifikats: Sobald eine deiner Kassen fällt, sind auch die übrigen 1999 gefallen. (*.meineKassen.at)
  13. Two tier CA

    Abseits vom technischen Aspekt: Dein Chef und du betretet offenbar den Bereich Zahlungsverkehr mit seinen ganzen juristischen Besonderheiten und Regelungen, auch für eine PKI. Seid ihr euch dessen bewusst? Ein aktuelles, vergleichbares Beispiel aus den USA mit 3300 Kassen zeigt, welcher Schaden entstehen kann. https://krebsonsecurity.com/2017/02/fast-food-chain-arbys-acknowledges-breach/ Es gibt leider viele böse ITler draußen, die nur auf ähnliche Gelegenheiten warten!
  14. Lies dir doch bitte den Blog mal durch! Der S4uSelf Mechanismus führt dazu, dass Userkonten und Maschinenkonten ihren LastLogonTimeStamp updaten, obwohl niemand die Konten benutzt bw. die zugehörigen User bzw. Maschinen schon längst nicht mehr existieren. d.h. ein uralt, seit ewigen Zeiten, unbenutzter, und sogar disabled Account bekommt trotzdem einen aktuellen Zeitstempel durch das System. das hat mit Genauigkeit überhaupt nichts zu tun! Man kann bei der Verwendung des LLTS durch Laien davon ausgehen, dass irgendwann die Panik aufkommt, weil ein disabled Useraccount oder Maschinenaccount einen aktuellen Zeitstempel hat. (siehe das zitierte Praxisbeispiel). Deswegen "Finger Weg von dieser Property", die hat keine zuverlässige Aussagekraft. Der Blog ist nicht ganz einfach zu verstehen, aber der Sachverhalt ist detalliert beschrieben. Das hat nichts, aber auch gar nichts mit "den meisten Szenarien" ode "unpassender Kritik" zu tun, sondern mit Kerberos Mechanismen. Den Blog lesen und verstehen muss man! (zumindest das bereits zitierte Summary am Ende)
  15. zwei Gründe aus dem oben verlinkten Blog: In welchen Szenarien trifft denn S4uSelf zu und wann nicht?
×