Nimmt man Windows 10 in eine bestehende Domäne auf, kann es passieren, dass Gruppenrichtlinien darauf nicht wirken. Die Ursache ist oft das UNC-Hardening, das als Sicherheitsfunktion vor einiger Zeit eingeführt wurde. Anders als Windows 7 aktiviert Windows 10 diese Funktion standardmäßig.

Im Web findet man als “Problemlösung” dazu häufig die Empfehlung, das Feature abzuschalten. Das ist aber eine weniger gute Idee – wie bei jeder Sicherheitsfunktion ist es auch hier besser, sie zu konfigurieren. Hinweise dazu gibt es hier:

[Demystifying the UNC Hardening Dilemma – Lee Stevens: Technical Blogs]
https://blogs.technet.microsoft.com/leesteve/2017/08/09/demystifying-the-unc-hardening-dilemma/

[MS15-011 & MS15-014: Hardening Group Policy – Security Research & Defense]
https://blogs.technet.microsoft.com/srd/2015/02/10/ms15-011-ms15-014-hardening-group-policy/

Setzt man den Microsoft Identity Manager (kurz MIM, ehemals Forefront Identity Manager/FIM) ein und hat in seiner Umgebung sowohl Linked Mailboxes als auch normale Accounts, die Mailboxes besitzen, so steht man sehr schnell vor einem entscheidenden Problem.

Anforderung:

• Verteilergruppen müssen über MIM verwaltet werden, der Anwender darf nicht in die Pflicht gebracht werden, den richtigen Account (Linked Mailbox/normalen Account) auszuwählen, sondern darf jeden Benutzer exakt einmal sehen
• Sicherheitsgruppen müssen ebenfalls über MIM verwaltet werden, alle Sicherheitsgruppen liegen in der contoso.com und müssen ggf. Mitglieder aus der contoso.com und der faq-o-matic.de beinhalten, somit normale User und Foreign Security Principals

Kurz zum Demo-Szenario:

• Zwei Domänen in separaten Forests (contoso.com und faq-o-matic.de)
• Exchange 2016 Cluster in contoso.com
• Native Mailboxen für User aus der contoso.com, Linked Mailboxes für User der faq-o-matic.com
• In der contoso.com existiert eine MIM Installation samt MIM Service & Portal
  • Es sind bereits beide Forests und dessen Domänen gemäß Microsofts Vorgaben im MIM Portal angelegt und die Foreign Security Principal Sets so wie Sync Rules für die „richtigen“ User Accounts aus beiden Domänen angelegt
  • Die Linked Mailboxes wurden über den Inbound Sync Filter der User Sync Rules ausgeschlossen

Der Identity Manager ist bereits von Haus aus in der Lage, Foreign Security Principals in Richtung Active Directory zu synchronisieren, sofern die Konfiguration der Domänen und Trusts vollständig ist, somit ist die Anforderung für die Sicherheitsgruppen bereits mit wenig Aufwand gedeckt.

Schwieriger wird es, wenn man auch Verteilergruppen verwalten will, denn hier müssen wir MIM beibringen, nicht die distinguishedNames der jeweiligen Quell Accounts in das Member Attribut der Gruppen zu synchronisieren, wie es für Sicherheitsgruppen richtig ist, sondern je nach Typ entweder den distinguishedName der vollwertigen Mailbox oder im Falle eines Users aus der faq-o-matic.de den distinguishedName der zugehörigen Linked Mailbox. … weiterlesen

Bei der Delegation von FullAccess-Berechtigungen auf einer Mailbox oder einer Shared Mailbox ist dem einen oder anderen sicher bereits aufgefallen, dass sich das Automapping nicht konsistent verhält. Untersucht man dies genauer, so fällt auf, dass lediglich die beim Erstellen der Mailbox vergebenen Delegationen auch Automapping aktiviert haben, nachträglich hinzugefügte haben dies nicht, zumindest sofern sie per Exchange Control Panel erteilt wurden.

Für das Automapping ist das Attribut „msExchDelegateListLink“ auf dem Active-Directory-Konto der freizugebenen Mailbox verantwortlich. Dieses Attribut beinhaltet die DistinguishedNames aller Mailboxen, welche beim Start von Outlook dieses Postfach automatisch eingebunden kriegen sollen. Das Attribut an sich hat zuerst jedoch nichts mit der eigentlichen FullAccess-Berechtigung zu tun, es reicht also nicht, die zu autorisierenden DistinguishedNames dort einzutragen. Möchte man alle Mailboxen, die nachträglich mit FullAccess für ein Postfach über das Exchange Control Panel autorisiert wurden, auf Automapping umstellen, so schafft einem PowerShell wie gewohnt Abhilfe.

Hier könnte man meinen, dass der Befehl „Get-Mailbox -Identity „xyz“ | Get-MailboxPermission“ auch ein Attribut zurückliefert, welches die Automapping Einstellungen pro Freigabe anzeigt – tja, das wäre wohl auch zu einfach. Der einfachste Weg, sich per Powershell alle auf Automapping gestellten Freigaben eines Postfaches anzuzeigen, ist der folgende Befehl:

Get-ADUser -Identity (Get-Mailbox -Identity „xyz“ | Select-Object -ExpandProperty userPrincipalName) -Properties msExchDelegateListLink | Select-Object -ExpandProperty msExchDelegateListLink

Möchte man nun alle bereits erteilten FullAccess-Berechtigungen auf Automapping umstellen, so hilft dieses von mir geschriebene Script aus:

https://github.com/RobinBeismann/PowerShell-Scripts/blob/master/Scripts/MS-Exchange/Fix-Automapping.ps1

Eine kleine Schwierigkeit ist, dass Get-MailboxPermission lediglich die objectSID der berechtigten Mailboxes anzeigt. Über Get-ADUser kann man diese aber auf ihre Mailboxes auflösen und die DistinguishedNames für das msExchDelegateListLink Attribut sammeln. Wichtig zu wissen ist, dass es sich um die SID des tatsächlichen Postfaches handelt, im Falle einer Linked Mailbox ist dies also nicht die ObjectSID sondern die msExchMasterAccountSid, diese Besonderheit wird von dem oben verlinkten Script bereits berücksichtigt.

Noch eine Randnotiz: Erstellt man die Mailbox Berechtigungen direkt per Add-MailboxPermission, so kann man das Automapping über den Parameter „-AutoMapping <$true | $false>“ steuern.

Hat man in der heutigen Zeit mit einer Active-Directory-Migration zu tun, so ist meist die eigentliche Migration der Computer und User das kleinste Übel. Durch die Anbindung diverser Systeme muss aber jede Identität eines Users in jedem angebundenen System berücksichtigt werden. Ein sehr gutes Beispiel hierfür ist Office 365, respektive die Azure-Active-Directory-Identität eines Benutzers, an der in der durchschnittlichen Umgebung mindestens eine Mailbox, ein Sharepoint-Profil und ein Skype-for-Business-/Teams-Account hängt.

Ein praktisches Verfahren hierzu mit einer PowerShell-Funktion habe ich hier beschrieben:

[Azure AD Identity umziehen – michael wessel Blog]
https://blog.michael-wessel.de/2019/02/14/azure-ad-identity-umziehen/

Wir haben unserer Liste “lustiger Namen” eine neue Portion hinzugefügt. Mittlerweile sind 366 Exemplare zusammengekommen. Wie immer gibt es die Namen als Skript, um daraus schnell eine Struktur mit Test- und Demo-Konten für Activ Directory zu erzeugen.

Hier geht’s lang:

[AD-Testuser mit Details und lustigen Namen (reloaded) | faq-o-matic.net]
https://www.faq-o-matic.net/2014/02/17/ad-testuser-mit-details-und-lustigen-namen-reloaded/

Und auch weiterhin gibt es die Liste für das kleine Lächeln zwischendurch in Einzeldosen:

https://www.faq-o-matic.net/namen/

Quelle: https://docs.microsoft.com/de-de/Exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-office-3?redirectSourcePath=%252farticle%252fHow-to-set-up-a-multifunction-device-or-application-to-send-email-using-Office-365-69f58e99-c550-4274-ad18-c805d654b4c4

Vielen Dank an -nin auf www.mcseboard.de.

In einem Migrationsprojekt brauchte ich eine Ordnerstruktur mit je mindestens einer Datei, um diverse Dinge zu testen. Die Ordnerstruktur habe ich nach einem Export des Originals nachgebildet. Die ganzen Dateien wollte (und durfte) ich von dort aber nicht mitschleppen. Also behalf ich mir mit folgendem Skript, das je eine Datei pro Ordner erzeugt:

$FolderPath = 'E:\'
$Folder = Get-ChildItem -Path $FolderPath -Recurse
$Count = 0
foreach ($ThisFolder in $Folder.GetEnumerator()) {
  $Name = $ThisFolder.Name
  "I am a placeholder in folder $ThisFolder" | Out-File -FilePath ($ThisFolder.FullName + "\$ThisFolder-File.txt")
  $Count += 1
}
"$Count Dateien erzeugt."

Thunderbird hat ein sehr interessantes Icon zum Speichern von Anhängen … passenderweise ganz rechts unten …

Active Directory kennt verschiedene Gruppentypen, unter anderem Globale, Domänenlokale und Universale Gruppen. Der Typ ist im Verzeichnisdienst als Bitcode gespeichert, wobei verschiedene Bits für unterschiedliche Eigenschaften stehen. Die Werte dazu listet z.B. folgender Artikel unter “Remarks” auf:

[Group-Type attribute – Windows applications | Microsoft Docs]
https://docs.microsoft.com/en-us/windows/desktop/adschema/a-grouptype

Mit Excel kann man die Gruppentypen etwa aus einem CSV-Export mit einer Formel auflösen. Ein Export könnte etwa so aussehen:

DN,objectClass,description,name,sAMAccountName,groupType,mail
"CN=Exchange Organization Administrators,OU=Microsoft Exchange Security Groups,DC=demo,DC=zz",group,Users in this group will have permission to read and modify all Exchange configuration. This group should not be deleted.,Exchange Organization Administrators,Exchange Organization Administrators,-2147483640,
"CN=Exchange Recipient Administrators,OU=Microsoft Exchange Security Groups,DC=demo,DC=zz",group,Users in this group can manage Exchange user attributes in the Active Directory and perform select mailbox operations. This group should not be deleted.,Exchange Recipient Administrators,Exchange Recipient Administrators,-2147483640,
"CN=Exchange View-Only Administrators,OU=Microsoft Exchange Security Groups,DC=demo,DC=zz",group,Users in this group will have permission to read all Exchange configuration. This group should not be deleted.,Exchange View-Only Administrators,Exchange View-Only Administrators,-2147483640,
"CN=Exchange Public Folder Administrators,OU=Microsoft Exchange Security Groups,DC=demo,DC=zz",group,Users in this group can manage Exchange public folder attributes in the Exchange Information Store and perform select public folder operations. This group should not be deleted.,Exchange Public Folder Administrators,Exchange Public Folder Administrators,-2147483640,
"CN=DEMO-Hotline-Exch,OU=Microsoft Exchange Security Groups,DC=demo,DC=zz",group,"Mitglieder dieser Rolle können Postfächer Migrieren, Benutzer-Einstellungen der Postfächer anpassen und Mobil-Geräte zulassen oder blockieren.",DEMO-Hotline-Exch,DEMO-Migrations-Admins,-2147483640,
"CN=Netzwerkkonfigurations-Operatoren,CN=Builtin,DC=demo,DC=zz",group,Mitglieder dieser Gruppe verfügen über einige Administratorrechte zum Verwalten der Konfiguration von Netzwerkfunktionen.,Netzwerkkonfigurations-Operatoren,Netzwerkkonfigurations-Operatoren,-2147483643,

Öffnet man dies in Excel, so hilft folgende Formel, den Gruppentyp zu entschlüsseln:

=WENN(BITUND(ABS(F2);2);"global";WENN(BITUND(ABS(F2);4);"domain local";WENN(BITUND(ABS(F2);8);"universal";"other")))

Da der CSV-Export die Werte negativ ausgibt, sorgt ABS() dafür, das Vorzeichen zu entfernen. Dann prüft BITUND() auf das Vorhandensein der Bit-Schalter. Die obige Formel wertet die drei wichtigen Gruppentypen aus, natürlich sind auch noch andere Prüfungen möglich.

Microsoft hat seit Windows Server 2016 einige Änderungen am Scheduler von Hyper-V vorgenommen, der für die CPU-Versorgung virtueller Maschinen zuständig ist. Diese Neuerungen sind weitgehend unter der Haube geschehen und betreffen die Systemsicherheit sowie in einigen Situationen die Performance des Systems. Mit Windows Server 2019 und der zugehörigen Windows-10-Version gibt es weitere Änderungen.

Praxisnahe Empfehlungen haben sich zu den neuen Modi noch nicht herausgebildet. Einstweilen sollte man für ein technisches Verständnis der Hintergründe folgende Artikel heranziehen:

[Understanding and using Hyper-V hypervisor scheduler types | Microsoft Docs]
https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types

[About Hyper-V hypervisor scheduler type selection | Microsoft Docs]
https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/about-hyper-v-scheduler-type-selection