Beim Zusammenschluss von Unternehmen wird in vielen Fällen mit einer Active Directory Vertrauensstellung zwischen Domänen aus unterschiedlichen AD-Gesamtstrukturen gearbeitet.
Um das Arbeiten mit Ressourcen in beiden Strukturen zu ermöglichen, verfügen Active Directory Objekte über das Attribute sIDHistory. In diesem Attribut in Zieldomäne A wird die SID aus der Quell-Domäne B eingetragen. Hierdurch ist es möglich, dass ein in Domäne A migrierter Benutzer weiterhin auf Ressourcen in der "alten" Domäne B zugreifen kann.
Dies funktioniert allerdings nur, wenn die Active Directory Vertrauensstellung zwischen beiden Domänen die Nutzung der sIDHistory aktiviert ist. Aus Sicherheitsgründen ist diese Funktionen im Normal ausgeschaltet. Dies nennt man auch SID-Filterung.
Die Aktivierung der SID-History bzw. die Deaktivierung der SID-Filterung erreicht man durch folgenden Kommandozeilenbefehl:
netdom trust LOKALEDOMAIN.tld /domain:REMOTEDOMAIN.tld /enablesidhistory:yes
Wenn Sie den o.g. auf einem deutschsprachigen Windows Server Betriebssystem ausführen, erhalten Sie u.U. folgende Fehlermeldung:
"Der SID-Verlauf ist für diese Vertrauensstellung deaktiviert."
Die Lösung ist sehr trivial. Verwenden Sie anstatt yes ein ja, um die SID-History zu aktivieren. Der folgende Kommandozeilenaufruf bringt Sie ans Ziel:
netdom trust LOKALEDOMAIN.tld /domain:REMOTEDOMAIN.tld /enablesidhistory:ja
Viel Spaß mit Active Directory.
Die Aktivierung der Kerberos Authentifizierung für Exchange Server 2013/2016 wird in diversen Artikeln im Internet beschrieben. In diesem Blogartikel geht es heute um ein Phänomen, das mir in einer Exchange Server 2013 Umgebung (8 Server DAG) begegnet ist.
Alle Outlook 2010 Clients verwenden OutlookAnywhere für den Exchange Server Zugriff aus dem internen Netz. MAPI over Http ist sowohl auf der Organisationsebene als auch auf Postfachebene deaktiviert, da noch ein Problem mit der Kompatibilität einer Drittanbietersoftware existiert.
Nach der Aktivierung der Kerberos Authentifizierung verwenden alle Outlook Clients weiterhin nur die NTLM Authentifizierung, um sich am OutlookAnywhere Endpunkt anzumelden. Und dies, obwohl die Schritt-für-Schritt Anleitung aus dem TechNet befolgt wurde. Kerberos war für die Outlook Clients kein Thema.
Ein Blick in die Übersicht des Outlook Verbindungsstatus (Strg + Rechter Mausklick auf des Outllok Symbol im System Tray) zeigt die Verwendung von NTLM.
Die Umstellung der Authentifizerung auf Kerberos für OutlookAnywhere erfolgt auf jedem CAS Server über das folgende PowerShell Cmdlet:
Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
Alle acht Exchange 2013 Server boten auch nach gebotener Zeit keine Nego Authentifizierung an. Die Überprüfung der OutlookAnywhere Konfiguration mit Hilfe der PowerShell zeigte die korrekten Konfigurationswerte. Aber was nun?
Ein Kontrolle der Authentifizerungseinstellungen für das \Rpc virtuelle Verzeichnis der Front End Website in der IIS Management Console zeigte, dass das virtuelle Verzeichnis nur für NTLM konfiguriert war.
Mit Hilfe der IIS Management Console wurde der Negotiate Authentifizierungsanbieter hinzugefügt in der Reihenfolge der Anbieter an die erste Stelle gesetzt..
Nach Anpassung der Authentifizierungsanbieter in der Front End Wesbite können sich Outlook Clients mit Kerberos Authentifizerung an den OutlookAnywhere Endpunkt verbinden.
Im Normalfall sollte die IIS Management Console nicht für die Konfiguration der virtuellen Verzeichnisse einer Exchange Server INstallation verwendet werden. Die Anpassung der Konfigurationen mit Hilfe IIS MMC sollte nur im Troubleshooting-Fall verwendet werden, wenn einem unerklärliche Phänomene begegnen.
Die bevorzugte Methode zur Konfiguration von Exchange Server Einstellungen für virtuelle Verzeichnisse ist die Exchange Management Shell.
Weiterhin viel Spaß mit Exchange Server
Die Installation des Windows Features Active Directory Domains Services (AD DS) kann fehlschlagen.
Bei der Installation per PowerShell kommt es zu folgendem Fehler:
Install-WindowsFeature -Name AD-Domain-Services Install-WindowsFeature : The request to add or remove features on the specified server failed. The operation cannot be completed, because the server that you specified requires a restart. At line:1 char:1 + Install-WindowsFeature -Name AD-Domain-Services + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exce ption + FullyQualifiedErrorId : DISMAPI_Error__Failed_Reboot_Required,Microsoft.Windows.ServerManager.Commands.AddWindow sFeatureCommand Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- False No Failed {}
Das ganze sieht erstmal danach aus, dass es sich um ein VMWare Problem handelt. "+ CategoryInfo: DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exception" und das noch ein Reboot aussteht "because the server that you specified requires a restart."
Dem ist leider nicht so. Auch nach mehrfachem Neustart des Servers, bleibt es bei der gleichen Fehlermeldung.
Ein Blick ins EventLog zeigt, es gibt eine Abhängigkeit zwischen dem Dienst "DFS Namespace" und "Remote Registry".
Der "Remote Registry" Dienst konnte nicht gestartet werden, da dieser deaktiviert war.
Dieser Dienst war in der VM Vorlage deaktiviert.
Nach Umstellung auf Automatisch und einem Reboot ließ sich das Windows-Feature AD DS fehlerfrei installieren und der Server zum Domain Controller hochstufen.
Wenn Sie CRM Online verwenden, möchten Sie ebenfalls den CRM 2013 Client für Outlook verwenden. Bei der Konfiguration der Client Integration kann es zu einem Fehler kommen, der ursächlich mit dem Office 365 Single-Sign-On Client und den Internet Explorer Einstellungen zusammenhängt.
Nach dem Download des Microsoft Dynamics CRM 2013 for Microsoft Office Outlook, müssen Sie die Outlook Verbindung zu Ihrem CRM Online Tenant mit Hilfe des CRM Konfigurationsassitenten konfigurieren.
Zu diesem Zeitpunkt der Konfiguration konnte sich der Client mit CRM Online verbinden, da das Outlook Add-In den Organisationsnamen und Anzeigenamen der Organisation erfolgreich abfragen konnte. Wenn Sie nun mit der Konfiguration fortfahren möchten, kommt es zu einem Fehler in der Kommunikation mit dem CRM Online Server.
Beispiel der Fehlermeldung: Exception : Object reference not set to an instance of an object. at Microsoft.Crm.Passport.IdCrl.OnlineServicesFederationLogOnManager.GetBrowserClientAuthInfo(String redirectEndpoint, String partner, String policy, String& postData) at Microsoft.Crm.Outlook.ClientAuth.PassportAuthProvider`1.SignIn() at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.SignIn(Uri endPoint, Credential credentials, AuthUIMode uiMode, IClientOrganizationContext context, Form parentWindow, Boolean retryOnError) at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.GetAuthProvider(Uri endPoint, Credential credentials, AuthUIMode uiMode, Uri webEndPoint, IClientOrganizationContext context, Form parentWindow) at Microsoft.Crm.Application.Outlook.Config.ServerInfo.LoadUserId() at Microsoft.Crm.Application.Outlook.Config.ServerInfo.Initialize(Uri discoveryUri, OrganizationDetail selectedOrg, String displayName, Boolean isPrimary) at Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadDataToServerInfo() at Microsoft.Crm.Application.Outlook.Config.ServerForm.<InitializeBackgroundWorkers>b__2(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
Quelle: SF-Tools, CRM 2013 for Outlook configuration fails
Die Anpassung und Konfiguration einer Exchange Organisation ist seit Jahr und Tag tägliche Arbeit für Exchange Administratoren. In einer lokalen Exchange Organisation muss die Exchange Organisation für eine Anpassung nicht vorbereitet werden. In Exchange Online sieht es anders aus.
Um den Exchange Online Cloud-Dienst optimal und effizient zu betreiben, werden ausgewählte Einstellungen in einer konsolidierten Konfiguration betrieben. Diese Konsolidierung spart zusätzlich auch Speicherplatz. Microsoft geht davon aus, dass diese Einstellungen nicht unbedingt eine individuelle Konfiguration erfordern. Dies bedeutet im Umkehrschluss nicht, dass Sie diese Einstellungen nicht konfigurieren können, sondern nur, dass Sie die Konfiguration dieser Objekte aktivieren müssen. Ohne die Aktivierung der Organisationsanpassungen erhalten Sie beim Versuch einer Konfiguration eine Fehlermeldung.
Leider existiert aktuell keine vollständige Liste der Objekte, für die eine Aktivierung der Organisationsanpassungen erforderlich ist. Microsoft selbst führt einige Beispiele an:
Betroffen von dieser Anpassung ist aber z.B. auch die Aktivierung der einheitlichen Audit-Protokollierung oder die Anti-Spam-Filterung.
Die Aktivierung der Organisationsanpassungen für Ihren Exchange Online Mandaten ist einfach, kann jedoch nicht rückgängig gemacht werden.
Melden Sie sich mit Hilfe der Exchange Online Management Shell v2 an Ihrem Exchange Online Mandanten an. Nutzen Sie hierzu ein Konto, was Mitglied der Rolle Globaler Administrator oder Exchange Dienstadministrator ist. Führen Sie anschließend folgenden Befehl aus:
Enable-OrganizationCustomization
Bei der Aktivierung der Organisationsanpassungen sehen sie genau, welche Objekte in Ihrem Exchange Online Mandanten für die Anpassung eingerichtet werden. Wir dürfen davon ausgehen, dass über die Zeit weitere Standard-Objekte von dieser Anforderung betroffen sein werden. Eine erneute Ausführung des Cmdlets führt zu einer Fehlermeldung und teilt Ihnen nur mit, dass der für den Mandanten die Organisationspassung aktiviert wurde. Eine Zurücksetzung der Einstellung auf einen Standardwert ist nicht möglich.
Sie können die Aktivierung der Organisationsanpassung für Ihren Mandanten in den Organisationseinstellungen überprüfen. Führen Sie hierzu folgenden Befehl in der Exchange Online Management Shell v2 aus:
Get-OrganizationConfig | FL IsDehydrated
Der Wert besagt:
Ein Wort der Warnung Nach der Aktivierung der Organisationsanpassungen haben Sie die Möglichkeit, Ihren Exchange Online Mandanten nach Ihren Wünschen zu konfigurieren. Dies ist aber nicht gleichbedeutend mit einer besseren oder gar sichereren Konfiguration.
Führen Sie eine Anpassung der Exchange Online Einstellungen nur durch, wenn Sie wissen, was Sie tun. Nach der Anpassung profitiert Ihr Exchange Online Mandant nicht mehr von den zentral verwalteten Einstellungen.
Viel Spaß mit Exchange Online.
Wenn Sie versuchen, die Mitglieder einer E-Mail-aktivierten Sicherheitsgruppe im Exchange Admin Center bearbeiten und anschließend speichern möchten, kann es zu folgender Fehlermeldung kommen.
Eine E-Mail-aktivierte Sicherheitsgruppe erlaubt das selbständige Verlassen oder Beitreten durch Anwender nicht. Diese Funktion ist Verteilergruppen vorbehalten. Die Konfiguration dieser Einstellung ist im Exchange Admin Center für E-Mail-aktivierte Sicherheitsgruppen nicht möglich. Diese Einstellungen können nur per Exchange Management Shell durchgeführt werden.
Fragen Sie die Einstellungen der E-Mail-aktivierten Sicherheitsgruppe per PowerShell ab.
Get-Distributiongroup SECURITYGROUPNAME | FL Name, GroupType, RecipientTypeDetails,*Restriction
Wenn Sie dem Hinweis der Fehlermeldung folgen und nur einen der beiden Parameter zum Beitreten oder Verlassen einer E-Mail-aktivierten Sicherheitsgruppe per Exchange Management Shell auf Geschlossen (Closed) setzen, erhalten Sie ebenfalls eine Fehlermeldung.
Setzen Sie immer beide Parameter gleichzeitig.
Set-DistributionGroup SECURITYGROUPNAME -MemberJoinRestriction Closed -MemberDepartRestriction Closed
Nach dieser Anpassung der E-Mail-aktivierten Sicherheitsgruppe ist es wieder möglich, die Mitglieder der Sicherheitsgruppe über das Exchange Admin Center zu pflegen.
Dieser Fehler trat in einer Active Directory Umgebung auf, in der vorübergehend die Exchange Organisation in einer Split-Permission Konfiguration betrieben und wieder auf Shared-Permission zurückgestellt wurde.
Viel Spaß mit Exchange Server.
Der browserbasierte Zugriff auf ein Exchange Postfach mit Hilfe von Outlook on the Web (OWA) ermöglicht Ihren Anwendern die Anzeige und Bearbeitung von Office-Dateianhängen ganz ohne Medienbruch in eine andere Applikation.
Für Kunden von Microsoft 365 und Exchange Online sind hierzu keine weiteren Konfigurationen notwendig. Die Integration von Office Online mit Outlook on the Web ist standardmäßig aktiviert. Jedem Anwender wird automatisch eine Standard-Richtlinie zu gewiesen. Zu den Betriebsrisiken später mehr.
Wenn Sie diese Funktion auch für Ihre lokale Exchange Organisation bereitstellen möchten, müssen Sie zuerst eine Office Online Server Umgebung aufbauen und, falls erforderlich, aus dem Internet erreichbar machen. Die Anforderungen und Implementierungsoptionen einer Office Online Umgebung schauen wir uns in einem der nächsten Artikel an.
In Outlook on the Web wird die Möglichkeit einer Anzeige im Browser im Auswahlmenü eines Dateianhanges anzeigt:
Ebenso ist das Öffnen des Anhanges das Standardverhalten bei einem Klick auf den Dateinamen.
Im Rahmen einer betrieblichen Anforderung kann es notwendig sein, dass bestimmten Anwendergruppen der Zugriff auf Office Online aus OWA heraus zu unterbinden und stattdessen das Herunterladen von Office-Dateianhängen zu erzwingen.
Die Gründe hierfür können sehr unterschiedlich sein.
Je nachdem, ob Sie Office Online als SaaS-Lösung in Microsoft 365 nutzen, oder aber Ihre eigene Office Online Server Umgebung betreiben, stehen Ihnen unterschiedliche Lösungen zur Verfügung. DIe von Office Online (Server) bereitgestellten Funktionen werden nciht nur von OWA verwendet.
Die Option einer neuen OWA-Postfachrichlinie (OwaMailboxPolicy) steht Ihnen für Microsoft 365 und die lokale Exchange Organisation zur Verfügung. Die Erstellung einer neuen OWA-Postfachrichtlinie ist zwar auch über das Exchange Admin Center, jedoch ermöglicht dieser Weg anschließend nur eine sehr rudimentäre Konfiguration. Daher empfehle ich Ihnen, OWA-Postfachrichtlinien immer mit Hilfe der Exchange Management Shell (EMS) zu erstellen und zu verwalten. Wenn Sie mit Exchange Online arbeiten, stellen Sie bitte sicher, dass Ihr administratives Konto mit einer Multi-Faktor-Authentifizierung (MFA) geschützt ist und Sie das speziell hierfür zur Verfügung gestellte PowerShell Modul verwenden.
Die Erstellung einer neuen OWA-Postfachrichlinie gliedert sich immer in zwei Schritte:
Im folgenden Beispiel erstelle ich in Exchange Online eine neue OWA-Postfachrichlinie für das fiktive Unternehmen Contoso. Der Name der neuen Richtlinie ist Contoso-Restricted-OWA-Policy.
# Aktivierung der PowerShell-Protokollierung (Transkript) Start-Transcript # Uneingeschränkte Anzeige von Array-Inhalten $FormatEnumerationLimit=-1 # Erstellung der neuen OWA-Postfachrichtlinie New-OwaMailboxPolicy -Name 'Contoso-Restricted-OWA-Policy' # Auflistung der Namen der vorhandenen OWA-Richtlinien Get-OwaMailboxPolicy | ft Name
Nach der Erstellung der neuen Richtlinie wurden alle Standard-Einstellungen der Richtlinie im PowerShell-Fenster ausgegeben. Dank der aktivierten Protokollierung haben Sie diese Einstellungen in der Transkript-Textdatei festgehalten.
In diesem Artikel interessieren wir uns für die relevanten Einstellungen zu Office Online (Server). Diese Einstellungen verbergen sich in den Parametern mit dem Kürzel Wac.
# Auflistung der Wac-relevanten Parameter der OWA-Richtlinie Get-OwaMailboxPolicy 'Contoso-Restricted-OWA-Policy' | FL *wac* WacEditingEnabled : True WacViewingOnPublicComputersEnabled : True WacViewingOnPrivateComputersEnabled : True ForceWacViewingFirstOnPublicComputers : False ForceWacViewingFirstOnPrivateComputers : False WacExternalServicesEnabled : True WacOMEXEnabled : False
Die gewünschte Deaktivierung von Office Online erfolgt über die Parameter WacViewingOnPublicComputersEnabled und WacViewingOnPrivateComputersEnabled. Mit diesen beiden Parametern wird festgelegt, ob für den Anwender, dem diese Richtlinie zugewiesen ist, eine Anzeige des Anhanges in Office Online möglich ist oder nicht. Die Möglichkeit zur Anzeige wird für öffentliche und private Computer getrennt konfiguriert. Seit Exchange Server 2013 werden Zugriffe per OWA immer als Zugriffe von einem privaten Computer gewertet.
Die Bedeutung der Wac-relevanten und aller anderen Parameter ist auf der Hilfe-Seite des Cmdlets Set-OwaMailboxPolicy bestens beschrieben.
Nach der Erstellung muss die neue Richtlinie noch einzelnen oder allen Anwenderkonten zugewiesen werden.
# Zuweisung der neuen OWA-Richtlinie an ein einzelnes Anwenderkonto Get-CASMailbox AllanD | Set-CASMailbox -OwaMailboxPolicy 'OwaMailboxPolicy-Default' # Zuweisung der neuen OWA-Richtlinie an alle vorhanden Anwenderkonten Get-CASMailbox | Set-CASMailbox -OwaMailboxPolicy 'OwaMailboxPolicy-Default' # Optionale Konfiguration der neuen OWA-Richtlinie als Standardrichtlinie Set-OwaMailboxPolicy 'Contoso-Restricted-OWA-Policy' -IsDefault:$true
Nach der Zuweisung der neuen OWA-Postfachrichtlinie wird die Möglichkeit zur Vorschau eines Dateianhanges nicht mehr angezeigt.
Wenn Sie die neu erstellte OWA-Postfachrichlinie Anwendern zuweisen, die zu diesem Zeitpunkt in OWA angemeldet sind, so haben die neuen Einstellungen noch keine Wirksamkeit. Die Einstellungen der neu zugewiesenen Richtlinie werden erst nach einer Ab- und Anmeldung an OWA wirksam.
Auf den ersten Blick erscheint die Deaktivierung der Office Online Lizenz im Rahmen eines Office 365-Lizenzplanes auch eine Möglichkeit zu sein, um die Nutzung von Office Online zu verhindern.
Sie deaktivieren die Office Online Lizenz direkt in der Lizenzzuweisung eines Anwenders im Microsoft 365 Admin Center oder über die gruppengesteuerte Lizenzzuweisung in Azure AD.
Aber führt diese Anpassung der Lizenzzuweisung zum gewünschten Ergebnis? Nein, leider nicht.
Die Deaktivierung der Lizenzzuweisung von Office Online hat keine Auswirkungen auf
Damit scheidet die Option zur Zugriffssteuerung von Office Online über die Lizenzzuweisung für einen Anwender aus.
Wie bei vielen anderen Richtlinien von Exchange Online und Exchange Server existiert nach der ersten Einrichtung des Office 365 Tenants bzw. der Exchange Organisation eine Standardrichtlinie zur Konfiguration der Outlook on the Web (OWA) Einstellungen für alle Anwender. Da der Zugriff auf OWA ebenfalls standardmäßig für alle Anwender aktiviert ist, müssen Sie sich mit der Konfiguration der Standardrichtlinie auseinandersetzen.
Verschaffen Sie sich einen schnellen Überblick über all die Zusatzfunktionen, die im Rahmen einer OWA-Richtlinie gesteuert (*enabled) werden.
# Beispielhafte Abfrage der Parameter einer OWA-Richtlinie, die eine Zusatzfunktion steuern Get-OwaMailboxPolicy 'OwaMailboxPolicy-Default' | FL *enabled*
Diese Abfrage liefert Ihnen eine Grobüberischt der vorhandenen Einstellungen und deren Standardkonfigurationen. Überprüfen Sie alle Einstellungen für OWA-Postfachrichtlinien, ob sie den Compliance-Anforderungen Ihres Unternehmens entsprechen. Sie finden dieser EInstellunge in der Dokumentation für das Cmdlet Set-OwaMailboxPolicy.
Denken Sie beim Thema Office Online auch daran, dass Office Online auch Dokumente öffnen kann, die bei externen Speicheranbietern liegen. Die Nutzung von externen Speicheranbietern, aus Sicht von Office 365, kann im Microsoft 365 Admin Center ausgeschaltet werden.
Wählen Sie im Menüpunkt Einstellungen > Dienste und Add-Ins den Punkt Office Online aus.
Setzen Sie den Schieberegler für die Konfiguration Personen die Verwendung von gehosteten Speicherdiensten von Drittanbietern gestatten aus Aus und speichern Sie die Einstellung.
Viel Spaß mit Microsoft 365 und Exchange Server!