Es tritt manchmal das Problem auf, das ein gelöschtes AD-Objekt (Benutzer) aus dem lokalen („OnPremises“) ActiveDirectory (EXAMPLE.LOCAL) nicht in das AzureAD synchronisiert wird, also dort nicht ebenfalls entfernt wird. „Normalerweise“ sollte das aber der Fall sein.
Das Objekt ist in diesem Fall weiterhin in Microsoft 365 sichtbar, kann aber auch im Portal (https://portal.office.com) nicht entfernt werde. Das passiert dann, wenn die Verzeichnissynchronisierung ein bestimmtes Cloud-Objekt „unerwartet“ nicht löschen kann und führt zu einem verwaisten Azure AD-Objekt, das von einem Administrator direkt entfernt werden muss.
Lösung (Windows 10+)
Wenn nicht vorhanden, AzureAD/MSOnline PowerShell Modul installieren
Install-Module -Name MSOnline
Mit dem AzureAD (Microsoft 365 Tenant) als „Globaler Administrator“ verbinden
Office 365 wurde korrekt und mit aktiviertem „Shared Computer Activation“ installiert. Nach einer Weile berichten Benutzer von „unlizenziertem Office“ und das man seine Lizenz nicht mehr aktivieren könne.
Das Anmelde-Feld erscheint zwar, man kann hier seine E-Mail Adresse auch eingebene, aber dann verschwindet es wieder und Office wird nicht aktiviert. Es gibt keine Fehler und sogar die Ereignisanzeige bleibt leer.
Lösung
Standardmäßig verwendet Microsoft Office 365 ProPlus (seit Version 2016) die Frameworkbasierte Authentifizierung der Azure Active Directory-Authentifizierungsbibliothek („ADAL“). Nach der Umstellung auf die neue „modern Authentication“ via „WAM“ passieren aber leider häufiger mal Fehler.
Es hilft zuverlässig, WAM und ADAL einfach zu überspringen:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableADALatopWAMOverride"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableAADWAM"=dword:00000001
Das geht natürlich auch per Gruppenrichtlinie (GPO) im Benutzerkontext (Benutzerkonfiguration) und benötigt nicht mal einen reboot.
Erlärung
Ab Build 16.0.7967 verwendet Office nun den „moderneren“ Web Account Manager („WAM“) für Office-Anmelde-Workflows. Es war auch mal wieder Zeit für neue TLAs. Selbiger bringt, wie immer, einige spannende neue „Eigenheiten“ mit.
WAM sucht beim Start nach den neuen Voraussetzungen für den Identity Providers (IdP), die beim Zusammenführen von Office 365 Konten verwendet werden (IdP IDReg_Match). Für synchronisierte Domänen an sich ein segen – es funktioniert nun auch der lokale UPN. Theoretisch.
Wenn Windows 10 oder Windows Server 2019 mit einem lokalen Active Directory verbunden ist, muss der IdP für WAM/O365 nun aber das sogenannte „WS-Trust-Protokoll“ (respektive Flag) unterstützen. Dies geschieht aber nicht automatisch in allen Konfigurationen; warum das oft nicht der Fall ist, haben wir noch nicht herausgefunden. Wenn beispielsweise das Authentifizierungstoken eines Benutzers ungültig wurde, zum Beispiel beim Kennwort-Zurücksetzen oder deaktivieren eines Nutzers, versucht das WAM den Benutzer erneut zu authentifizieren. Soweit idst das ja auch richtig – aber man erwartet hier nun das altbekannte Popup-Fenster des IdP, das bei einem fehlgeschlagenen Zugriff aber nur kurz geöffnet und dann sofort wider geschlossen wird wenn das Flag nicht korrekt/lesbar/vorhanden ist.
Nach der „Kennwort zurücksetzen“ Aktion der Administrators einer lokalen Domäne wird das neue Kennwort eines Benutzes nicht automatisch in das Azure AD (Office 365) synchronisiert.
Der Benutzer kann sich zwar in dem lokalen AD mit seinem neuen Kennwort anmelden, in Office 365 aber weiterhin nur mit dem alten.
Ändert ein Benutzer selbser sein Kennwort (STRG+ALT+ENTF), wird das neue Kennwort sofort (max 120 Sekunden) synchronisiert.
Lösung
Von manuellen Datenbank-Änderungen an der Client-API „vorbei“ bekommt AADConnect (ADsync) nichts mit. Da es (ohne weiteres) nicht möglich ist, Kennworthashes aus dem AzureAD für einen Vergleich zu exportieren, bleiben die Kennwörter bis zur nächsten Änderung unterschiedlich.
Das Kennwort kann aber einfach manuell (nachträglich) neu synchronisiert werden.
PowerShell auf der AADConnect Maschine öffnen („Als Administrator“, mit ExecutionPolicy auf mindestens „RemoteSigned“)
Distinguished Name (DN) des Benutzers besorgen:
Get-ADUser NAME | select D*
Assistenten zur Synchronisation des Kennworthashes des DNs starten:
Exchange-Absenheitsbenachrichtigungen (Out of Office replys) sind traditionell ein schwerwiegender Punkt interessanter Diskussionen. Technisch simpel umgesetzt, birgt das Konzept viele Gefahren für schweren Mißbrauch (Amplification-Attack, Spam, Datenschutz, Überwachung, Einbruch …).
Ein oft eingesetzer Kompromiss ist der Versand nur an „bekannte“ Absender. Da dem Exchange aber nicht alle Absender „bekannt“ sind (Exchange kann nachvollziehbarerweise nicht in Echtzeit alle Kontakte in allen Mailboxen durchsuchen) muss das pro Mailbox passieren. Outlook sieht diese Möglichkeit sinnvollerweise auch (als Mailboxsetting) vor. Leider bleibt die Auswahl weiterhin dem „fehleranfälligen“ Benutzer überlassen.
Nur in Outlook: „Jeder außerhalb meiner Organisation“ ist weiterhin anwählbar
Lösung
Die die Einstellung Serverseitig, also pro Mailbox, definiert ist, hilft hier eine Gruppenrichtlinie (GPO) nicht weiter. Diese würde vielleicht Outlook betreffen, aber von OWA und allen anderen E-Mail-Clients ignoriert werden.
Da diese Einstellung aber Pro-Exchange-Mailbox gesetzt wird, kann man via Powershell die gesetzte Einstellung relativ einfach „korrigieren“. Wir haben dazu dieses Script erstellt, das nebenbei auch den „Powershell state: busy“ Fehler umgeht, der auftritt wenn man zu viele Requests an die Exchange-API gleichzeitig sendet (foreach statt einfach |set).
Das Script wird einfach regelmäßig via „Geplante Aufgaben“ ausgeführt und rediziert so die Angriffsfläche auf einen (relativ) kleinen zeitlichen Versatz.
Mit der coolen Archivierungsfunktion in Microsoft Outlook kann man sein Postfach bereinigen und alte Objekte (beispielsweise Dinge im Ordner Gesendete Objekte oder dem Posteingang) in eine Archivdatei verschieben.
Dies ist öfters notwendig, wenn man ein Exchange-Postfach mit Größenlimitierung verwendet.
Problem
Outlook archiviert (scheinbar) nicht „korrekt“, oder vielmehr wie erwartet. Man möchte Beispielsweise Mails eines Jahres (… von 1. Januar bis 31. Dezember …) archivieren, aber einige (wenn nicht alle) Mails verbleiben standhaft im Quellordner.
Vielen Admins ist dabei vermutlich aufgefallen, dass Outlook trotz der Vorgabe, Objekte bis zu einem bestimmten Datum zu sichern, einige alte Objekte wie Mails trotzdem nicht ins Archiv verschiebt.
Lösung
Der Grund ist die Umstellung, dass Outlook nicht (mehr) vom Datum des Objektes ausgeht, sondern vom Änderungsdatum. Selbiges ist natürlich weder offensichtlich noch überhaupt ohne weiteres einsichtig.
Zudem wird das Datum bei jedem Zugriff auf das Element gesetzt, sodaß ein simples öffnen einer Nachricht oder das Verschieben in einen anderen Ordner das Änderungsdatum aktualisiert. Natürlich tut das ein guter Virenscanner auch regelmäßig.
Dieser Registry-Key stellt das Verhalten wieder zurück:
Fact: Interessanterweise lautet die Archivierungsrichtlinie im „Exchange Online Archive“ vermutlich daher auch korrekt, wenn auch etwas holperig: „Elemente die länger als … im Ordner … gespeichert waren ohne benutzt worden zu sein“.
