Bei dem Versuch eine vergessene Windows Hello PIN innerhalb eines Domänen-Netzwerkes zu löschen, ist mir aufgefallen, dass der „entfernen“ Knopf ausgegraut war.
Um diese PIN trotzdem entfernen zu können, müssen nur die Inhalte von: %windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC gelöscht werden.
del /f /q C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC\*.*
Anschließend neu starten
Achtung! Alle Zugangsmöglichkeiten von Windows Hello, wie Fingerabdruck, Gesichtserkennung und sonstige sind nicht mehr verfügbar und müssen neu eingerichtet werden.
Da ich ständig vergesse, wie man auf einem VMware standard vSwitch CDP bzw. LLDP konfiguriert um Uplinks von/zu physischen Switches schnell und einfach nachvollziehen zu können:
Per SSH auf den ESXi verbinden und folgenden esxcli Befehl ausführen:
esxcli network vswitch standard set --cdp-status=both -v vSwitch0
--cdp-status=both konfiguriert den vSwitch sowohl für’s empfangen, als auch senden von CDP/LLDP Paketen.
Mit dem Parameter -v <vSwitch> wird der Name des zu konfigurierenden vSwitch angegeben.
Alternativ geht das auch per esxcfg:
esxcfg-vswitch -B both vSwitch0
Das war schon alles, nun kann man ganz einfach auf den physischen Switches die CDP/LLDP Infos abrufen.
Z.B. auf HPE (Aruba) Switches:
show cdp neighbors
show lldp info remote-device
Häufig liest man online, dass es nicht möglich ist (oder zumindest nicht supported) auf standard vSwitches CDP/LLDP zu aktivieren. Über den vSphere Client oder den ESXi Host client geht das auch (soweit ich weiß) tatsächlich nicht. Dort heißt es dann bei den vmnics auch „CDP/LLDP steht auf diesem physischen Netzwerkadapter nicht zur Verfügung.“
Manchmal muss der Admin genau ein einziges Objekt, oder nur wenige ganz bestimmte Objekte von der Synchronisation vom lokalen AD in das Microsoft 365 Azure AD ausschließen.
Das geht überraschend einfach, mann kann exclude-Regeln einfach im „Synchronization Rule Editor“ hinzufügen.
Schritt für Schritt Anleitung um ein Objekt nicht mehr zu synchroniseren
Zeitplan für die Synchronisation abschalten, damit keine automatischen Aufgaben die Änderungen durcheinander bringen:
Set-ADSyncScheduler -SyncCycleEnabled $False
Der Status des ADSyncSchedulers lässt sich jeder überprüfen mittels:
2. „Synchronization Rules Editor“ starten (als Administrator)
3. In der „View and manage …“ Liste die „Direction“ auf „Inbound“ stellen und eine freie Nummer unterhalb der bestehenden „Precedence“ Regeln finden (und merken). In der Regel ist das irgendetwas <100.
4. Oben rechts „Add New rule“
5. Den „Create inbound synchronization rule“ Assistenten nun ausfüllen:
Name: Ein beschreibender Name, z.B. „In from AD – Bernd auslassen“
Connected System: Der lokale AD Forest
Connected System Object Type: user
Metaverse Object Type: Person
Link Type: join
Precedence: Die gemerkte Nummer von oben (z.B. „90“)
„Tag“, „Enable Password Sync“ oder „Disabled“ nicht verändern
Next > …
6. „Add group“ > dann > „Add clause“
7. Als „Attribut“ ein zu filterned Attribut wählen, zum Beispiel den „name“ oder ein anderes Attribut. Bei größeren Mengen an Objekten nutzen wir hier gerne die „Extended Attributes“, die normalerweise solange ungenutzt und leer sind. Der Operator ist im Beispiel „equal“, der „Value“ der zu matchende Inhalt.
8. „Next >“, an den nun angezeigten „Add join Rules“ nichts ändern > „Next >“
9. Bei den „Add join rules“ eine Transformation hinzufügen:
Wenn ein Benutzer in einer Hybrid-Umgebung erstellt wird und ihm dann eine Exchange Online-Lizenz zugeordnet wird, wird für diesen Benutzer ein Cloud-Postfach erstellt.
Der OnPremises Exchange Server erfährt davon aber nichts, daher ist der Benutzer im lokalen ECP nicht aufzufinden und das Mailrouting („Nachrichtenfluss“) von intern nach extern schlägt fehl.
Wenn man Office 365 zum ersten Mal im Hybridmodus verwendet, erstellt man oft neue Benutzer, indem man einfach ein AD-Konto erstellt und dieses via ADConnect synchronisiert. Danach wird der neue User lizenziert und bekommt ein Postfach. Das erzeugt genau das oben genannte Problem – die OnPremises Exchange Adressliste weiss nichts von dem neuen Objekt und routet keine E-Mails in die Cloud.
Beim Verschieben einer solchen Mailbox zurück nach On Premises tritt dieser Fehler auf:
Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ''. --> Cannot find a recipient that has mailbox GUID '<GUID>'
Die „richtige“ Methode zum Bereitstellen neuer Benutzer in Office 365 besteht darin, neue Remotepostfächer zu erstellen.
Lösung
Man kann einen OnPremises-Benutzer auch nachträglich mit seiner „echten“ Exchange-Online Mailbox verbinden.
Man schaltet einfach die Remote-Mailx im Exchgange ein und trägt die Online-GUID des Postfaches ein.
1. In der OnPremises Exchange PowerShell (EMS) die Remote-Mailbox einschalten:
3. In der OnPremises Exchange PowerShell (EMS) genau diese GUID wieder eintragen:
Set-RemoteMailbox <USER> –ExchangeGUID <GUID>
Das funktioniert natürlich in beide Richtungen, also auch für Benutzer-Objekte die in der Exchange Online EMC nicht mehr angezeigt werden. Interessanterweise beschreibt Microsoft in diesem Artikel nur den Weg in die Cloud 😇
Nicht schnell eingerichtet, aber sehr hilfreich: App Kennwörter als Ergänzung zur Multi-Faktor Authentifizierung – als Teil von Microsoft 365 ist ein fundamentaler und sehr gut umgesetzer Schutzfaktor für den Zugang.
Der geneigte Microsoft 365 Administrator kann Multi-Faktor Authentifizierung mit wenigen Klicks (oder via PowerShell) für einzelne oder alle Anwender aktivieren. Wie steht es aber um statische App Kennwörter – Wie erstellt man nun für ältere Programme oder SMTP-Clients (Kopierer, Scanner, CNC-Maschinen …) App-Kennwörter?
Limitierungen bei App Kennwörtern
Pro Benutzer maximal 40 App-Kennwörter
App-Kennwörter funktionieren nur in Microsoft 365, auch bei Hybrid-Szenarien nicht im lokalen Server
Funktioniert nicht bei „bedingtem Zugriff“ mit MFA (und modernern Auth)
App Kennwörter werden generiert (z.B. xmnfgsaofn3DSk) vorgegeben und können nicht geändert werden. Muss ein Kennwort „getauscht“ werden, geht das nur über löschen > Neu
Bei den „Hohen Sicherheitsstandarts“ muss MFA pri User erzwungen sein
Schritt 1 – App-Kennwörter für Benutzer erlauben
Man kann App Kennwörter nur erlauben, wenn die Azure AD Multi-Factor Authentication für den betreffenden Nutzer aktiviert ist.
Ganz Oben (!) unter „diensteinstellungen“ den „Benutzern das Erstellen von App-Kennwörtern zum Anmelden bei nicht browserbasierten Apps gestatten“
Schritt 2 – MFA erzwingen
Ganz oben unter „benutzer“ muss die Verwendung von MFA erzwungen werden, wenn die „Hohen Sicherheitsstandarts“ für das AzureAD eingeschaltet sind (Standard seit 2020).
Die Einstellung wird in aller Regel nicht sofort aktiv, aber man kann die Übernahme erzwingen, indem man als Administrator alle Sitzungen des Nutzers abmeldet und der Nutzer sich neu (in einem Browser) anmeldet
