cj_berlin

Was passiert denn, wenn Du bei einem betroffenen User das Häkchen setzt bei "Account supports AES256 encryption" bzw. msDS-SupportedEncryptionTypes auf 0x10?

Moin, ich weiß, dass sich hier einige sehr eingehend mit den SOPHOS Firewall-Produkten beschäftigen. Ich hätte hier einen Fall für Schwarmwissen, da der Hersteller es sich einfach macht. Im Dokument "Best Practices for STAS" steht Event Viewer-Abfrage kann ich mit "Event Log Readers" abfackeln. Sophos Dienst starten kann ich explizit delegieren. WMI zu Workstations kann ich durch lokale Adminrechte dort oder vielleicht sogar noch dediziertere Berechtigungen ermöglichen. Ich möchte den Service-User aus DA raus haben. Und nun die Frage: Hat das hier schon jemand getan und wäre er/sie bereit, das gewonnene Know-How zu teilen? 1000 Dank im vorab!

Umsonst oder nur vergebens? Was ich vermute, ist, dass dort Einstellungen wirken, die sich mit denen auf den DCs nicht überschneiden. Somit kann kein EType ausgehandelt werden, nach dem das Passwort gehasht werden soll. Du kannst die effektive Einstellung auf dem Client auch in der Registry sehen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters SupportedEncryptionTypes

Oh, AES128 ist auch nicht mehr sicher genug? Wow, das ist schon hart. Andererseits wüßte ich auf Anhieb kein System, das AES128 könnte und AES256 nicht...

Dann eben nicht philosophisch, sondern ganz konkret: Habt ihr ein lückenloses und vor allem wirklich gelebtes SIEM? Falls nein, hat der externe Sicherheitsberater recht, und ihr seht es alle falsch. Und in der Sache: Was steht bei den betroffenen Usern im Attribut msDS-SupportedEncryptionTypes? Was steht bei den Domain Controllern in diesem Attribut? Was steht in der effektiv auf die Clients wirkenden Policy (GPRESULT hilft übrigens, nicht 172 GPOs durchuschen zu müssen ) unter ...und das gleiche für Domain Controller?

Das ist jetzt vielleicht philosophisch, aber diese Argumentation gilt ausschließlich für Umgebungen, in denen Mittel (Technik *und* Manpower) vorhanden sind, um den Verdacht überhaupt erst schöpfen zu können, dass ein Account kompromittiert worden ist. Solange diese Mittel nicht am Start sind und NTLM + RC4 in der Umgebung aktiv ist, ist der regelmäßige Kennwortwechsel immer noch das einzige, was hilft, einen bereits erbeuteten NTLM-Hash nutzlos zu machen. Wenn der User selber merkt, dass mit seinem Account Schindluder getrieben wird, ist das Kind vermutlich aus dem Brunnen wieder herausgeklettert und fällt bereits in den nächsten Brunnen.

Portable Apps Container Sequencing (App-V, ThinAppp etc.) MSIX AppAttach nichts davon wird 100% der Anwendungsfälle abdecken.

Mit welchem Befehl hast Du die Berechtigungen denn rausgezogen? Normalerweise hat das zurückgegebene Berechtigungsobjekt zwei boolesche Properties: Deny und Inherited...

Moin, ist eines davon von einer anderen Stelle geerbt als das andere?

Moin, IIS Logs geben Dir die Info (Client-IP >> Rechner, Username >> Konto). Zumindest für Autodiscover, EWS, MAPI/HTTP...

Wir hatten damals einen Dozenten an der Uni, der kam die Treppe herunter, schaute sich die Schlange vor dem Kaffeeautomaten an und fragte dann "könnt ihr machen, dass da Bier rauskommt?". Ein Jahr später hatte ich bei ihm ein Hauptseminar. Es hat meist entweder im Irish Pub oder in der Destille stattgefunden

Laut Website nicht. Ich würde Prüfungen aber generell immer in Englisch machen - sehr viel ist "lost in translation"...

Achtung, Verwirrungsgefahr RDSCALs kannst und sollst Du wählen, wie es für Dich passt. Was aber stimmt, ist, dass Office stets nach dem zugreifenden Endgerät lizenziert ist. Wenn Du also 50 User hast, die sich 500 Workstations teilen und von dort auf Terminalserver mit Office zugreifen, brauchst Du 50 User CALs, 50 User RDSCALs, aber 500 Office-Lizenzen.

...und das ist jammerschade

Moin, bei P2V und V2V besteht die Gefahr immer, dass irgendwas nicht tut. Wichtig ist, gerade für Netzwerkdienste wie SQL, SharePoint etc., dass Du die Bereinigung der dann nicht mehr vorhandenen Netzwerkkarten zeitnah und sauber durchführst. Domain Controller würde ich gar nicht migrieren, sondern einfach auf die neue Plattform durchrotieren. Kann man ja dann zum Anlass nehmen, auch das Betriebssystem zu erneuern

Das Vertrauen zwischen Domäne und ihrem Member hat ja zwei Seiten. jeder User - kann auch ein lokaler sein! - der Admin auf dem Member ist, kann das Vertrauen seitens des Members aufkündigen, d.h. dem Member sagen, dass er nicht länger Domänen-, sondern nunmehr Workgroup-Mitglied ist. Dafür ist noch nicht einmal die Konnektivität zu der Domäne erforderlich, das ist ein komplett lokaler Vorgang auf dem Member. um das Gegenstück davon in der Domäne durchzuführen, was letztlich zur Deaktivierung des Computer-Objektes führt, muss der User über das Recht im AD verfügen, das zu tun, wie ihr schon festgestellt habt. Wenn Du dir Remove-Computer anschaust, da kann man separate Credentials für den lokalen und den Domain-Part angeben.

@daabm darüber spreche ich ja dieses Jahr auf der PSConfEU

So ist es. Aber wenn Du "einfach" AD-User und Exchange-Mailbox entkoppeln willst, hilft die Installation von Exchange im separaten Resource Forest und Arbeiten mit Linked Mailboxen. Oder gleich nach M365

Nein, wie @mikro schon sagte. Man kann höchstens per Cmdlet Extension Agent erreichen, dass die alte Adresse wieder in das mail-Attribut reingeschrieben wird. Allerdings kann es alle möglichen Arten von Weirdness in Exchange verursachen, und unsupported ist es allemal. Besser man wandelt einen MailboxUser in einen MailUser. Dann bleibt er ein valider Exchange-Empfänger, hat aber dann kein Postfach.

Moin, AADDS ist ein Offering, das ein bestimmtes Nutzungsszenario hat: User Forest: Du hast eine Application in der Cloud, die nichts besseres als einen LDAP Bind zur Authentifizierung (oder zum Nachschlagen von Benutzer-Infos) beherrscht. Du hast entweder gar kein On-Prem-AD oder möchtest vermeiden, dass aus der Wolke per LDAP ins On-Prem-AD kommuniziert wird. Resource Forest: Du hast eine Web Application in der Cloud, gegen welche sich on-Prem-User gern per NTLM oder Kerberos authentifizieren würden. Du hast ein On-Prem-AD und ein VPN, durch das AADDS eine einseitige Vertrauensstellung zum On-Prem-AD unterhalten könnte. Wenn Du exakt diese Use Cases hast, kann es passieren, dass AADDS gut auf Deine Anforderungen passt. Geht Dein Use Case über die oben beschriebenen Varianten hinaus, wirst Du es mit AADDS vermutlich nicht abdecken können.

Dann Big Bang mit allem, nicht nur Exchange. Ist ein langes Wochenende, aber dann hast Du es hinter Dir. Brauchst keinen Cross-Forest-Zugriff, keine Koexistenz usw.

Forest Trust Linked Mailboxes Autodiscover SCP in die alte Domain übertragen Mailflow umstellen Veröffentlichung für externe Clients (z.B. ActiveSync-Smartphones) umstellen, falls vorhanden Wenn nur einer der Begriffe bei Dir die geringste Unsicherheit auslöst, ist das Thema für ein freies offenes Internet-Forum zu komplex.

Ja, so etwas ist möglich. Das ist eine Cross-Forest-Migration, die Du vorhast, und beinhaltet einige Schritte: Vertrauensstellung zwischen den beiden Forests, damit a. Inhaltsumzug mit Bordmitteln möglich ist und b. die User mit Accounts aus "alt" auf ihre Postfächer und andere Ressourcen in "neu" zugreifen können. Mailflow --> Mails, die nach "alt" eingeliefert werden, müssen bis zur Umstellung aller Benutzer entweder in alt oder in neu ankommen, und nicht-migrierte Benutzer müssen an die Migrierten Mails schicken können und vice versa. [entfällt, falls Big Bang-Umstellung] Organisationsvertrauen, damit migrierte und nicht migrierte User gemeinsam Free-Busy haben und Termine planen können [entfällt, falls Big Bang-Umstellung] Autodiscover in "alt"-AD in Richtung "neu"-Exchange. Je nachdem, ob Big Bang, ist es einfach oder weniger einfach Fazit: Wenn Du so etwas noch nie gemacht hast, hol Dir Hilfe.

Moin, läuft Mailstore denn mit auf dem Exchange Server?