cj_berlin

Moin, ad 1. Es ist immer zu unterscheiden zwischen Authentifizierung und Autorisierung. Vertrauen bedeutet lediglich Authentifizierung, sprich: User aus Domäne A kann sich gegenüber Ressourcen aus Domäne B ausweisen. Ob die Ressource ihm den gewünschten Zugriff erlaubt, ist eine Frage der Berechtigungen. Genaugenommen, kannst Du ja auch innerhalb einer Domäne mit Benutzerrechten erreichen, dass ein Benutzer auf gewisse Ressourcen nicht zugreifen kann. Ein wichtiges Stichwort hier ist die Gruppe "Authentifizierte Benutzer". Wenn dieser Gruppe Zugriffe erteilt werden, gelten sie auch für Benutzer, die in vertrauten Domänen authentifiziert wurden. Da diese Gruppe per Default einige Berechtigungen zugewiesen bekommt, entsteht der Eindruck, dass Vertrauensstellungen automatisch auch für Autorisierung sorgen. Er ist aber falsch. ad 2. Zusätzlichen Forest (Resource Forest) nur für Exchange. Bei neuen Implementierungen ist es aus Security-Sicht ohnehin die einzig vernünftige Variante. zu Frage zwei aber noch dies: Schemaänderungen (wenn es nicht um Berechtigungen für vorhandene Attribute geht, sondern um Schemaerweiterungen) sind nicht sicherheitsrelevant. Exchange auf einem Domain Controller zu installieren ist zwar leider nicht unsupported, sollte aber in einer wohlgemanagten Umgebung dringend vermieden werden.

Moin, um die Lizenzierung von welchem Produkt geht es? Was hat der Host physisch drin? Falls HT für Hyperthreading steht, so spielt es für die Lizenzierung keine Rolle - entweder physisch vorhandene Cores (Windows Server) oder vCPUs (SQL) sind zu zählen. Deaktivierte, aber physisch vorhandene Cores sind ein altes Streitthema, nicht nur bei Microsoft. Spätestens wenn es möglich ist, Cores zu de- und wieder zu aktivieren, ohne den Host herunterzufahren, ist es eindeutig und man muss definitiv alle lizenzieren. Ergänzung: Wenn Du ganze CPUs (Sockets) abschaltest, müssen sie nicht lizenziert werden.

Das ist jetzt vielleicht polemisch, aber gilt das nicht für den bisher erreichten technischen Stand der Büro-IT generell, und zwar durchaus herstellerübergreifend? Damit argumentiert MSFT ja, nicht ganz zu unrecht, für die (eigene) Cloud - dabei natürlich geschickt ausblendend, dass sie für den zitierten Grund ja mit verantwortlich sind

CBS.log lesen und schauen, wo es geknallt hat.

Was in solchen Fällen *manchmal* hilft ist, wenn man den Spieß umdreht und den Kunden bittet, alle Stellen aufzuzeigen, an denen Otto User mit dem Domainnamen in Berührung kommt. Und dann verrät man ihm noch, dass es mehr als einen UPN-Suffix in einer Domäne geben kann, und sich die User eigentlich überall "mit ihrer e-Mail-Adresse" anmelden können. Aber viele sog. Entscheider sind tatsächlich beratungsresistent...

Moin, in aller Regel hat es mit Language Packs auf dem System zu tun. Präzisere Antworten findest Du im "C:\Windows\Logs\CBS\CBS.log". Im Zweifel alle LPs runter schmeißen, braucht ein Server, sofern er kein Terminalserver ist, sowieso nicht, wenn das OS darunter englisch ist.

Nein, denn die CA hat ja nicht den Private Key.

Wir haben einfach unterschiedliche Kunden

Da gibt es nichts zu rätseln: Die Anwendung nutzt ein ActiveX-Control, um auf die Key Stores zuzugreifen. Soweit ich weiß (und ), erreicht man diese Systemnähe nicht mit HTML5. Man braucht also ein Browser-Plug-In, und da kommt es wieder darauf an, welcher Browser, in welchem Modus usw. Klar, um einen fertigen CSR zu signieren und das ausgestellte Zertifikat herunterzuladen, könnte man eine abgewandelte Version anbieten, aber das Erzeugen des CSR fällt halt mit HTML5 flach...

Moin, dazu kann ich aus der Erfahrung mit unzähligen VMware Support-Calls, die meisten davon mit Storage-Anteil, nur eins sagen: Solange sich in der unteren Zeile da nichts ändert, bleibt's Gebastel, was im Zweifel durch den Errichter (Dich) zu supporten ist.

...und wenn man sehr kreativ beim privaten Teil (vor dem @) war, muss man sich des Alias bedienen, und den privaten Teil dort versenken. Evtl. Korrigieren geht per PowerShell, falls nötig.

Nicht zwangsläufig.

Du sollst auch nicht tagsüber schlafen

Noch Fragen hierzu?

Naja, bis inklusive 2003 (FL, nicht Jahr ) war es ja auch nicht wirklich supported, das Kennwort des KRBTGT zurückzusetzen...

wieso, funktioniert doch? Nur nicht beim ersten Mal... Ich lese das jetzt so, dass 192.168.0.2 der DC für die ausgegraute .local Domain (Domain B) ist, richtig?

Nachdem Du den konkreten Troubleshooting-Hinweis ignoriert hast, kann man ihn nur wiederholen: Kannst Du vom DC B einen nslookup auf etwas in A, ausgeführt gegen DC A, erfolgreich durchführen?

Ach, und ich hatte "Kind Santas" gelesen

P.P.P.S. Das ist genaugenommen nicht supported, auch wenn's meistens funktioniert

Moin, zwischen dem ersten Pass-the-Hash und dem Golden Ticket liegen meist ein paar (Zeiteinheit je nach Paranoia/Optimismus einfügen). Das kannst Du in der Zeit mit der Änderung des KRBTGT-Kennworts abschneiden.

Moin, was sagt denn RESTORE HEADERONLY dazu?

...aber wird sie auch NTLM-Versuche ablehnen? Der Angreifer verwendet ja nicht das, was ihr verwendet, sondern das, was möglich ist

https://www.cosmopolitan.de/numerologie-das-sagt-euer-hochzeitsdatum-ueber-eure-ehe-aus-80531.html

[int[]]((Get-Date -Format ddMMyyyy) -split "") | Measure-Object -Sum | Select-Object -ExpandProperty Sum

Ich habe mich sehr über die dazugehörige Sicherheitslücke gefreut, denn das gab mir den Anlass, bei einigen Kunden diesen antiquierten Dreck endlich zu deinstallieren...