Wird ein Exchange Postfach einem anderen Benutzer per Vollzugriff freigegeben, zeigt Outlook trotzdem als privat gekennzeichnete Mails nicht an. Das macht Sinn, da oft die Postfächer der Vorgesetzten für Mitarbeiter freigegeben werden. Die Vorgesetzten erhalten somit die Möglichkeit den Mitarbeitern bestimmten Mailverkehr vorzuenthalten.
Allerdings muss gesagt werden, dass nur Outlook diese Anzeige unterbeindet. Über OWA und bei anderen Mailclients werden auch die privaten Mails angezeigt. Man sollte sich also nicht blind auf diese Funktion verlassen.
Nun gibt es Fälle, in denen auch die als privat gekennzeichneten Mails eines Postfachs angezeigt werden sollen. Z.B. bei einem zentralen Postfach für die Personalabteilung, in der Bewerbungen eingehen. Diese gehen oft als privat gekennzeichnet ein.
Hierzu muss ein sogenanntes Delegate für einen Benutzer definiert werden. Das geht am besten mit einem PowerShell Script. Besonders, wenn das Delegate für mehere Benutzer eingerichtet werden soll.
Dazu habe ich 2 Blogeinträge gefunden. In folgendem Post muss zuvor die EWS Managed API auf einem Client installiert werden.
ACHTUNG: in dem Skript wird versucht die Mailadresse des angemeldeten Benutzers auszulesen und damit ein autodiscover durchzuführen. Sollte der Admin, mit dem das Skript ausgeführt wird, keine Mailadresse haben, kann man irgendeine existierende Mailadresse aus dem Unternehmen nutzen: $service.AutodiscoverUrl(„irgendwas@domain.de“).
Wichtig ist, dass die Logs auch verfügbar sind, wenn man sie braucht. Das geht entweder über die Retention Policy pro Server und Log oder über eine SIEM-Lösung (Security Information and Event Management). Ein SIEM-Client schickt dabei alle relevanten Logs an einen zentralen Server. Ähnlich wie bei Remote Syslog. Ein SIEM kann normalerweise auch Syslogs direkt empfangen und verarbeiten.
Retention Policy
Um hier alle Logs nach einer Vorgabe zu konfigurieren, sollte man die Retention Policy per PowerShell Script ausrollen. Anleitung hierfür folgt.
Manchmal erlebt man mit Windows kuriose Dinge. Admins die schon länger dabei sind kennen es noch von früher. Eine Datei lässt sich nicht löschen. Meistens liegt das daran, das sich die Datei durch einen Prozess im Zugriff befindet.
Es gibt aber auch den Fall, dass kein Prozess mehr auf die Datei zugreift. Irgendetwas im Dateisystem ist korrupt. Man erhält die Meldung die Datei wurde nicht gefunden oder bereits verschoben.
Früher konnte man sich über dir /X den 8.3 Namen der Datei anzeigen lassen und darüber die Datei löschen. Nun schalten Admins an Fileservern diese 8.3 Namen gerne ab.
Eine KEYTAB-Datei wird verwendet, um einen Principal auf einem Host für Kerberos zu authentifizieren, ohne dass Benutzer eingreifen müssen (SSO). Die Datei ist verschlüsselt, sollte aber gut gesichert sein, da jeder, der Zugriff auf die Datei hat, als dieser Principal fungieren kann.
Mit einer solchen Datei kann also zum Beispiel der Zugang zu einem Webdienst über AD-Konten gesteuert werden. Sind die Brwoser entsprechend konfiguriert, können AD-Benutzer Webdienste sogar ohne die Eingabe von Zugangsdaten über Single Sign On (SSO) nutzen.
Microsoft hat sich dazu endlich mal geäußert. Die Restriktionen fingen wegen der Printingnightmare-Lücke an. Microsoft hat einfach auch Adminrechte für die Treiberinstallation verlangt, obwohl Point and Print konfiguriert ist und die Treiberquellen damit auf die Druckserver beschränkt sind. Das kam mit dem 2. Sicherheitsupdate zu Printingnightmare. Dann haben die einen Registry-Wert eingeführt, mit dem man diese Einschränkung wieder aufheben kann. Und den Wert haben die nun endlich auch mal verraten.
Die Passwort Hashes der ADUser auszulesen, stellt sich leichter dar als vermutet. Natürlich sind diese Hashes nicht in Klartext umzuwandeln, aber diese als Hashes wieder in eine neue/andere Umgebung einzulesen, sollte auf diesem Wege möglich sein.
Zunächst wird ein Abbild der NTDS.dit Datenbank benötigt, in der diese Hashes abgelegt sind. Dies lässt sich über NTDSUtil realisieren. Der entsprechende Befehl lautet:
ntdsutil “ac i ntds” “ifm” “create full c:\temp” q q
Anstelle von C:\Temp können Sie natürlich jedes beliebige Verzeichnis wählen.
Nach Abschluss dieses Snapshots sehen Sie im Temp (oder Ihrem eigenen) Verzeichnis zwei Unterverzeichnisse.
Im Verzeichnis Active Directory befindet sich der Snapshot der NTDS.dit. Im Verzeichnis registry befindet sich unter anderem der sogenannte Boot Key, den Sie zum Entschlüssen benötigen. Die vorhandene Kopie der NTDS.dit können Sie nun mit Get-ADDBAccount aus den DSInternal Tools auslesen. Auf die Beschreibung der Installation der DSInternal Tools verzichte ich hier. Diese sollte im angegebenen Link hinreichend beschrieben sein.
Nach erfolgreicher Einrichtung der DSInternals müssen Sie zunächst den Boot Key auslesen.
GPO Richtlinien werden als Registry Keys auf die zu verwaltenden Systeme ausgerollt. Mit der Zeit kann es vorkommen, dass Einstellungen in Windows oder anderer Software wegfallen (Office, Chrome, etc..). Wenn man nun die neuen ADMX-Dateien nutzt, kann e szu Verwaisten Einträgen in den Gruppenrichtlinien kommen. Das passiert gerne auch in Verbindung mit dem Central Store. Schaut man sich die Einstellungen einer solchen GPO an, steht ganz unten unter „Zusätzl. Reg.-einst.“:
„Office 2016 Für einige Einstellungen konnten keine Anzeigenamen gefunden werden. Eine Aktualisierung der von der Gruppenrichtlinienverwaltung verwendeten ADM-Dateien behebt möglicherweise das Problem.“
Das bedeutet zu der gesetzten Policy wird keine Beschreibung mehr in den aktuell genutzten ADMX-Dateien gefunden.
Man kann das aber mit PowerShell beheben und einzelne Richtlinien aus einer GPO entfernen (hatte so einen Fall bei Office365):