Kategorie: Office 365

Verbindungsversuch / Kontaktaufnahme Excel und Outlook O365

Das Problem

Beim Speichern von Dokumenten in Excel oder Outlook O365 kommt nahezu permanent die lästige Meldung, dass ein Verbindungsaufbau stattfindet, solange man sein Homeverzeichnis / Eigene Dateien in einem Netzwerk-Share umgeleitet hat.

Die Lösung

Seitens Microsoft gibt es derzeit (10/2022) noch keinen Fix. Allerdings gibt es zwei mögliche Workarounds, die wirksam sind.

  1. Aus meiner Sicht der Bessere
    Office 365 Downgraden / Rollbackup auf die Version vom Juli 2022
"C:\Program Files\Common Files\Microsoft Shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.15225.20288

Um später auch wieder auf den Aktuellen Kanal zu kommen oder um manuell die Update durchzuführen (Autoupdate muss dann im Tenanat deaktiviert werden) hier der Link zu den Versionen vom O365

https://learn.microsoft.com/en-gb/officeupdates/update-history-microsoft365-apps-by-date

  1. Funktioniert auch, aber kann andere Nebeneffekte hervorrufen
    Deaktivieren des Dienstes „WebClient“

Als zentrale Lösung wohl sinnvoller über GPO zu steuern.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading... 156 views

S/MIME-Zertifikate zur sicheren E-Mail-Kommunikation

Damit man sicher E-Mail austauschen kann, sollten die Gesprächspartner über S/MIME-Zertifikate verfügen.

Hierüber können Mails mit einem Stempel/Signum versehen werden und bescheinigen einen vertrauenswürdigeren Eindruck, da der Stempel/ Signum bescheinigt, dass die E-Mail auch tatsächlich von der E-Mail-Adresse (Class1) oder der echten Person mit seiner E-Mail-Adresse (Class2) stammt. E-Mails mit Signum können an jede andere Person/ E-Mail-Adresse versendet werden.

Zudem kann man aber auch untereinander verschlüsselte E-Mails schicken. Hierbei wird der E-Mail-Text (Body) und deren Anlagen verschlüsselt und kann nur vom Gesprächspartner geöffnet/ gelesen werden. Zu beachten ist jedoch, dass der Betreff einer E-Mail NIE verschlüsselt wird.

Dies grob zur Verwendung von E-Mail-Zertifikaten. Nun kommt es zum spezifischen …

Egal ob mit eigener CA und über Drittanbieter (z.B. Certum), unter Office 365 lassen sich die .pfx-Zertifikate nicht gleichermassen nutzen.

In Microsoft Office Outlook als Desktop-App ist das Einrichten und Verwenden von S/Mime-Zertifikaten recht schnell und einfach umgesetzt.
Auch das Einrichten auf mobilen Geräten (z.B. iPad/ iPhone) gestaltet sich einfach, solange man dort nur die Apple-Mail-App verwendet.

Möchte ich jedoch die Microsoft Outlook App für iOS oder Android nutzen und soll dort ein S/Mime-Zertifikat zum Einsatz kommen, fangen die Probleme an!!

Wie sehen die Probleme aus?

Zum einem reicht das Installieren eines Zertifikates über die Profile von Apple nicht aus. So installierte Zertifikate werden in der Outlook iOS-App nicht gefunden.

Desweiteren unterscheidet Outlook iOS zwischen Business- und privaten Mail-Accounts. Wer sich bei Microsoft eine *@outlook.com-Adresse privat zulegt, der kommt innerhalb der Outlook iOS-App nie in das Vergnügen ein Zertifikat sich einrichten zu können. Die Installation selbst funktioniert, aber für das Aktivieren fehlt der Menüpunkt „Sicherheit“ unter den Mailkonten-Einstellungen.

Anders bei geschäftlichen Account. Dort steht der Menüpunkt „Sicherheit“ zur Verfügung und man kann beginnen sich das Zertifikat zu Installieren/ Einzurichten.

Zum Installieren in Outlook für iOS muss man sich am besten das .pfx-Zertifikat selbst per Mail an sich selbst senden. Erst jetzt kann man es durch Öffnen der Datei so installieren, dass es in Outlook für iOS zu sehen und einzurichten geht.

Über den Menüpunkt „Sicherheit“ aktiviert man die generelle Funktion S/MIME. Danach sieht man unter Zertifikate alle Zertifikate, welche zu seiner E-Mail-Adresse installiert worden sind. Hier findet demnach ein Abgleich statt, so dass man kein Zertifikat für eine andere ausgestellte E-Mail-Adresse aktivieren kann.

Leider kam nun die nächste böse Überraschung! Das aktivieren von Signieren und Verschlüsseln war nicht möglich, weil im Zertifikat bei Überprüfung „nicht vertrauenswürdig“ stand?

Laut Microsoft und Telekom-Support ist mal wohl gezwungen sich eine Office 365-Liznez zu erwerben, in der Intune mit enthalten ist 🙁
Aus meiner Sicht ist dies aber eine FEHLINFORMATION, weil es mit einem kleinen Zusatzschritt doch möglich wird.

Outlook für iOS prüft das S/Mime-Zertifikat mit seinem in O365 hinterlegten Stamm-Zertifikaten. Passen diese nicht zusammen, so wird IMMER innerhalb der App die Validierung des S/Mime-Zertifikates schiefgehen.

Was muss man also machen?

Man benötigt eine .SST-Datei, in der das Root- & die Zwischenzertifizierungsstellen eingebunden sind. Diese .SST muss dann nur noch nach O365 importiert werden. Den Usern schiebt man noch schnell das öffentliche Zertifikat im O365 unter und fügt bei AD-Connect-Nutzung auch das öffentliche Zertifikat (.cer) über den lokalen Domain-Controller das Zertifikat hinzu. Und dann wird am Client das Zertifikat als gültig angezeigt und kann für das Signieren und Verschlüsseln verwendet werden.

    1. Root- & Intermediante-Zertifikate als .SST-File nach O365 exportieren

Eigene Windows-CA

Hier exportiert man aus dem Zertmanager die erforderlichen Root- und Zwischenzertifikate als .SST

Fremde CA

Hat man Zertifikate von Drittdienstleistern wie Certum, dann schaut man in einem bereits erstellen S/Mime-Zertifikat und analysiert hier die Zischen- und das Root-Zertifikat.

Im Normalfall findet man diese bereits auf jedem Win10/11-PC im Zertifikatsspeicher unter Zwischenzertifikate oder Stammzertifikate. Die gesamte Kette der Zertifikate wird selektiert und als .SST exportiert.

Wenn die Zertifikate nicht im Zertspeicher sind, dann werden die darüber ausgestellten (S/Mime)-Zertifikate bei Nutzung oft nicht als vertrauenswürdig angesehen.

Es hilft hier diese Zertifikate manuell zu importieren/ installieren und dann als .SST zu exportieren.

Unterschiedliche CA’s

Im Prinzip kann man jedes Austellerzertifikat als .SST exportieren. Hat man eine Mischung aus mehreren Anbietern, dann markiert man alle benötigten Stammzertifikate und exportiert diese als Bundle in eine .SST.

Certum

[Root]

Certum Trusted Network CA

S/N 0444c0

22.10.2008 – 31.12.2029

[Zwischenhändler]

Austeller: Certum Trusted Network CA

Certum Digital Identification CA SHA2

S/N 66daef03db8461916b25ba83fb174e13

21.04.2015 – 09.06.2027

[User]

Austeller: Certum Digital Identification CA SHA2

[UserMail-Adresse] (S/Mime-Class2)

S/N 5732e6eaaf1468660cc0d3bd04e29b05

01.02.2022 – 24.01.2025

Import .SST in O365

Mit Exchange verbinden (Powershell)

$sst = Get-Content -path „c:\temp\firmenca.sst“ -Encoding Byte

Set-SmimeConfig -SMIMECertificateIssuingCA $sst

 

    1. Im AD die öffentlichen Zertifikate hinterlegen

Da wir AD-Connect nutzen, sollte bei jedem User das öffentliche Zertifikat (.cer) hinterlegt werden.

Im Attribut-Editor sollte dann auch unter userCertificate ein Eintrag pro hinterlegten Zertifikat stehen.

    1. In O365 die öffentlichen Zertifikate dem User hinterlegen

Mit Exchange verbinden (Powershell)

$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(„D:\_tmp\cert.cer“)

$certArray = New-Object System.Collections.ArrayList

$certArray.Insert(0,$cert.GetRawCertData())

Set-Mailbox -Identity <Mail-Adresse des Users> -UserCertificate $certArray -UserSMimeCertificate $certArray

 

Office 365 Tenant löschen

Wer Microsoft Office 365 nicht mehr nutzen möchte oder von DE-Cloud zu einer EU oder COM-Cloud wechselte, will unter umständen den alten Tenant auch gelöscht haben. Hier eine kleine Anleitung wie das recht zügig von Statten geht.

Zu Beginn sollte man sich Gedanken machen, ob man alle Daten wie Mails, SharePoint, OneDrive etc. sichern muss und entsprechend davon ein Backup erstellen. Hier habe ich mit Veeam Backup Office 365 recht gute Erfahrungen sammeln können.

  • Als gobaler Admin mit PowerShell am „richtigen (alten)“ Tenant anmelden
Install-Module -Name AzureAD 
Import-Module AzureAD
Connect-AzureAD

Install-Module -Name Connect-MsolService 
Import-Module -Name MSOnline
Connect-MsolService

Für DE-Cloud

Install-Module -Name AzureAD 
Import-Module -Name AzureAD
Connect-AzureAD -AzureEnvironment "AzureGermanyCloud"

Install-Module -Name MSOnline
Import-Module -Name MSOnline
Connect-MsolService -AzureEnvironment "AzureGermanyCloud"
  • Sollte AD-Connect/ ADSync konfiguriert worden sein, muss dies deaktiviert werden. Es kann bis zu 72h dauern, bis die User von LocalAD auf CloudOnly wechseln. Erkennbar am Symbol hinter dem User in der Spalte „Synchronisierung“. Die Wolke steht hierbei für CloudOnly und somit kann der User problemlos aus Office 365 heraus gelöscht werden. 
    # DirSync abschalten
Set-MsolDirSyncEnabled -EnableDirSync $false


# Status abfragen
(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled
  • Benutzer bis auf sich selbst löschen. Beim Löschen wird eine Warnung angezeigt, dass man sich selbst nicht löschen kann. Alle anderen User werden aber gelöscht. Danach löscht man alle gelöschten User aus dem Papierkorb.
# Benutzer forciert loeschen
Get-MsolUser | Remove-MsolUser -Force

# Benutzer aus dem Papierkorb entfernen.
Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin -Force
  • Alle vorhandenen aktiven Lizenzen kündigen, so dass dies als Deaktiviert angezeigt werden.
  • Hat man Applikationen oder Subscriptions eingerichtet, dann müssen diese auch vom alten Tenant gelöscht werden.
$ObjIds = (Get-AzureADServicePrincipal).ObjectId
For ($i=0; $i -lt $ObjIds.Length; $i++){Remove-AzureADServicePrincipal -objectid $ObjIds[$i]}
#Listet alle eingerichtete Apps auf z.B. fürs Veeam-Backup
get-azureADApplication | fl

#Löscht eine App aus der Cloud
Remove-AzureADApplication -ObjectID "bc8406cd-14e4-4cef-b334-1ffa83ab6a94"
  • Nun muss man zum „Microsoft Azure“-Portal wechslen und dort unter „Azure Active Directory“ den Button „Mandanten löschen“ anklicken.Mit der Löschung der Daten wird der Tenant selbst noch nicht gelöscht. Der Name „<tenantname>.onmicrosoft.com“ wird erst dann freigegeben, wenn sich 180 Tage niemand mehr am Tenant anmeldet. Nach den oben beschrieben Schritten gibt es nur nochden einen „GlobalAdministrator“.

    Sobald sich dieser Administrator auch nur anmeldet, wird derCounter auf 0 zurückgestellt und die 180 Tage starten von Vorn.

    Dies wird ein Schutz sein, den Microsoft warum auch immer eingebaut hat.

 

Office 365 – Aktivieren von DKIM für Custom Domains

Aktivieren von DKIM

Wenn man unter Exchange Center -> Schutz -> DKIM für seine benutzerdefinierte Domain DKIM nicht aktivieren kann, weil der Button hierfür fehlt, dann hilft in der Regel ein kleiner Powershell-Befehl:
New-DkimSigningConfig -DomainName BeispielDomain -Enabled $true
Wenn bei der Ausführung dieses Befehls die beiden DKIM-DNS-Records schon korrekt existieren, ist DKIM für diese Domain anschließend aktiv. Ansonsten wird jetzt der zuvor fehlende “Aktivieren” Link angezeigt.

Dieser Link zeigt übrigens (wenn die DKIM-DNS-Records noch nicht korrekt existieren) nach Klick in einer warn-Meldung den erwarteten Inhalt der etwas komplexen Records an.

 

Office 365 – Cloud-Umzug von DE zu EU oder COM

Office 365 – Cloud-Umzug

Ein Cloudumzug ist mit entsprechenden Werkzeugen eigentlich kein Problem, aber kann sehr zeitintensiv sein. Ab einer bestimmten Userzahl kommt man strenggenommen nicht um kostenpflichtige Migrationstools drumherum.

Wenn ich etwas mehr Zeit habe, dann verfasse ich hierfür mal einen ausführlichen Bericht. Bis es soweit ist mache ich für den Umzug nur Stichpunkte.

Backups

Aus meiner Sicht kann man bei kleinerer Userzahl „Veeam Backup Office 365“ nutzen.

    • in beiden Clouds muss eine App registriert werden, worüber letztlich die Veeam-Anwendung Backups von Postfächern, OneDrive, SharePoints etc. machen kann
    • Postfächer können auch in andere Tenants zurück gesichert werden, dies half beim Überspeilen der alten Mails der User in die neuen Postfächer auf der neuen Cloud

Einstellungen

    • neuen Tenant buchen und mit Testlizenzen den Tenant konfigurieren, Mailrules einrichten, DIK aktivieren etc.
    • neue User mit entsprechender Lizenz anlegen oder bei Verwendung lokalem Domaincontroller „AD Connect“ nutzen.
    • alle User-Postfächer auf die richtige Sprache und Zeitzone stellen (SharePoint-Befehl) 
      Get-Mailbox -ResultSize unlimited | ? {$_.RecipientTypeDetails -eq "UserMailbox"} | Set-MailboxRegionalConfiguration -Language "de-DE" -DateFormat "dd.MM.yyyy" -TimeFormat "HH:mm" -TimeZone "W. Europe Standard Time" -LocalizeDefaultFolderName
    • Freigegebene Postfächer, Ressourcen- oder Gerätepostfächer erstellen und auch hier die korrekte Sprache einstellen (PowerShell)
    • Die Spracheinstellung ist wichtig für die Rücksicherung der Postfächer, damit es keine Vermischung von „item“ und „Posteingang“ etc. kommt.
    • im alten Tenant alle Bezüge zur abzulösenden Domain trennen.
      Aliases, App-Links, Gruppen-EMails etc.
      In der Regel umstellen auf seine *.xxx.onmicrosoft.de Adresse
    • Domain aus Tenant ablösen
    • Mailrule für das Ablehnen von Mails mit Ablehnungsrund „Wir ziehen um) erstellen
    • DNS-Einstellungen von DE auf EU/COM ändern
    • Backup vom alten Tenant durchführen
    • Domain in neuem Tenant einbinden und diese als Standard definieren
    • User-Stammname/ Login-Name auf [user]@dieneueDomain.de umstellen
    • Backup in neuen Tenant wiederherstellen
    • Kalenderberechtigungen per PowerShell wieder herstellen, wie es im alten Tenant war. Dies gilt ebenso für Stellvertretungen.
    • im neuen Tenant benötigte SharePoint-Seiten neu nachbauen, eine Wiederherstellung inkl. Rechtevergabe geht hier nicht. Im Backup werden nur Daten gesichert.

Office 365 – Azur AD Sync/ Azure ADConnect

Azure AD Connect einrichten

Vorwort

Ich dachte erst AD Connect funktioniert nur, wenn man in seiner lokalen Domain auch einen echten Domainnamen verwendet, aber hier wurde ich damals seitens der Telekom wohl falsch informiert.

Heute nehme ich an (ohne es nochmal getestet zu haben), dass man auch eine lokale AD, die sich zum Beispiel test.local nennt, nach Office 365 synchronisieren kann. In diesem Fall sollten die User in der Cloud nur als Loginname und xxx.onmicrosoft.com enden.

Hat man bereits eine Domain in Office 365 hinterlegt, so kann man in der lokalen AD beim User unter „userPrincipalName“ die echte E-Mail-Adresse eingeben und der User wird dann auch mit dieser Einstellung in der Cloud aufgelistet.

Die Synchronisierung ist zeit gesteuert und erfolgt aus meiner Sicht nicht immer in einem festen Rhythmus. So kann eine lokale AD-Änderung einige Zeit benötigen, bis diese in der Cloud zu erkennen ist.

Anleitung

Azure AD Sync bzw . AD Connect ist hilfreich, wenn man eine eigene lokale Domain pflegt und die User von dort in Office 365 anlegen möchte.

Hierfür muss „AD Connect“ auf dem lokalen AD installiert und eingerichtet werden.

Bevor man damit beginnt, empfehle ich eine Gruppe namens „ADSyncOfficeUsers“ anzulegen und in diese Gruppe nur die User hinzuzufügen, welche mit Office 365 synchronisiert werden sollen.

Beim installieren von „AD Connect“ würde ich NIE die Express-Einstellungen verwenden! Wer das macht, synchronisiert seine ganze Lokale Domain mit allen Benutzern, Gruppen und Geräten nach Office 365 und das wäre mir zu viel.

Beim Einrichten muss man den Dialogen folgen und seine Domain (Verzeichnis) hinzufügen. Danach wählt man aus was synchronisiert werden soll, hier habe ich mich bewusst nur für „Users“ entschieden und im nächsten Schritt auch auf die oben angelegte neue Gruppe den Filter beschränkt. So werden nur die User mit Office 365 synchronisiert, welche auch in dieser Gruppe aufgeführt werden.

Beim Einstellen kann man festlegen wie sich Authentifiziert werden soll, hier habe ich nur die Kennworthash-Funktion aktiviert. Hierbei wird das Passwort des Users verschlüsselt an Office 365 übergeben. Meldet sich nun jemand an Office 365 an, dann wird nur der verschlüsselte Teil verglichen. Es erfolgt kein echtes Anmelden an die lokale Domain. Wer das möchte kann dies aber auch so einrichten, aber so muss ständig bei jeder Anmeldung die lokale Domain bzw. die Anmelde-Prozesse von extern erreichbar sein.

ACHTUNG:

Das Kennwort-/Gruppen-Rückschreiben funktioniert nur, wenn man die passende Azure P1 oder P2 Lizenz für jeden User wo das möglich sein soll hat.

Sobald das Setup erfolgreich zu Ende gebracht wurde, werden in Office 365 alle User aus der Gruppe „ADSyncOfficeUsers“ aufgelistet und haben das Kennwort aus der lokalen Domain. Man kann das Kennwort in Office 365 ändern, aber es wird immer wieder mit dem Kennwort aus der lokalen AD überschrieben.

Ordnet man lokale Gruppen zur neue Gruppe „ADSyncOfficeUsers“ hinzu, so werden auch diese Gruppen als „E-Mail aktivierte Sicherheitsgruppe“ in der Cloud angelegt. Die Gruppe kann aber nur über die lokale AD bearbeitet werden.

Nachdem die User in der Cloud angelegt wurden, weißt man diesen noch die passenden Lizenzen zu und der User kann mit Office 365 anfangen zu arbeiten.

Umfasst die zugewiesene Lizenz auch Exchange Online, so wird auch gleich ein E-Mail-Postfach eingerichtet.

Normalerweise soll man so erstellte Users in Office 365 nicht löschen können, aber irgendwie klappte das bei mir dennoch.

Richtig wäre wohl der Weg, den User aus der lokalen Gruppe „ADSyncOfficeUsers“ zu entfernen. Der User wird auf der Seite von Office 365 gelöscht und ist für 30 Tage dort noch zu finden. Den User kann man nun in Office 365 wiederherstellen und schon ist der User nur noch in der Cloud.

Verhalten

Synchronisiert man aus der lokalen AD die User zu Office 365, so werden bestimmte Merkmale dort übergeben und überschrieben. Werden diese Merkmale in Office 365 geändert, so können diese Merkmale beim nächsten Durchlauf durch die Einstellungen der lokalen AD überschreiben werden.

z.B. Ein User wird in der lokalen AD gesperrt -> in Office 365 wird dieser nun ebenso für den Login gesperrt. Ändert man dieses Einstellung in Office 365, so hält diese Einstellung nicht lange an und wird von der lokalen AD wieder als gesperrt Überschrieben.

Im Default wird der „userPrincipalName“ vom lokalen AD zur Cloud synchronisiert. Dieser Eintrag enthält in der Regel die E-Mail-Adresse zusammengesetzt aus dem User- und  lokalen Domainnamen. Dieser Name wird, wenn diese Domain in Office 365 bereits hinzugefügt wurde, als Loginname für die Cloud verwendet. Existiert diese Domain aber nicht, so wird nur der Benutzername + des Tenant-Domainnamen xxx.onmicrosoft.com verwendet.

Erweiterte Einrichtungen

Da User-Eigenschaften über AD Connect aus der lokalen Domain stammen, kann man bestimmte Eigenschaften zum User in der Cloud nicht ändern. Man muss diese Änderungen in der lokalen Domain umsetzen und diese werden dann zur Cloud synchronisiert.

Aliases Einrichten

In lokaler Domain in den User-Eigenschaften über Attribut-Editor das Attribut „proxyAdresses“ aufrufen und durch „smpt:[zusätzlicherAliases]@meineDomain.de“ erweitern.

Office 365 – Das Erstellen von Gruppen für Mitglieder einschränken

Das Erstellen von Gruppen für Mitglieder einschränken

Mitunter kann es sinnvoll sein, dass wirklich nur der Admin des Tenantes oder nur bestimmte Benutzer neue Gruppen wie für Teams, Planer oder SharePoint einrichten dürfen.

Hierfür erstellt man eine Gruppe „Groups Creators“ und über ein kleines PowerShell-Script wird allen normalen Mitgliedern nun das GroupCreators-Recht entzogen und nur für die neu erstellte Gruppe und Globalen-Admins erlaubt.

Wer das testen möchte, kann sich danach mit einem normalen Benutzer anmelden und wird unter „Planer“ diesen Hinweis sehen:

Quelle:

https://docs.microsoft.com/de-de/microsoft-365/solutions/manage-creation-of-groups?view=o365-worldwide

Office 365 – Einrichten – Teams

Leider können wir Sie nicht anmelden.

AADSTS7000112: Application ‚5e3ce6c0-xxxx-xxxx-8d4b-75ee78xxxx'(Microsoft Teams Web Client) is disabled.

Lösung:

Die Teams Web Client Anmeldung ist vermutlich deaktiviert.

Über das Microsoft 365 Admin Center navigiert man zu Azure Active Directory und dort zu Unternehmensanwendungen.

Nun Filtert man die Anwendungen nach „Microsoft-Anwendungen“ und dem Status „Deaktiviert“. In der Liste sollte nun „Microsoft Teams Web Client“ erscheinen. Darauf klicken und folgende Einstellungen vornehmen:

  • Unter Verwalten -> Eigenschaften -> „Aktiviert für die Benutzeranmeldung“ auf „JA“ stellen und das ganze Speichern.

Danach klappt auch die Anmeldung

 

Office 365 – Einrichten (nur für Admins)

Hier entsteht erstmal nur ein grober Leitfaden zur Einrichtung.

    • mit globalen Admin-Konto (*.onmicrosoft.com) anmelden
    • eine vorhandene Domain einrichten/ Hinzufügen, über dessen dann z.B. Mails versendet werden können. Theoretisch kann man aber auch die Domain-Adresse seines Tenants zum Mailen nutzen, aber wer auf Coperate Identity wert legt, nutzt seine eigene Domain.
    • Self-Service-Passwort-Reset einrichten und neue Benutzer auffordern sich dafür zu registrieren.
      Einrichtung erfolgt über „Azure Active Directory Admin Center“
      Die Code-Eingaben zur Verifizierung müssen recht schnell erfolgen, da sonst der Code abläuft und der Prozess wiederholt werden muss.
      In jedem Fall sollte dies für den Admin eingerichtet werden.
      Ich empfehle eine Sicherheitsgruppe „SSPR-Group“ anzulegen und alle die dann in dieser Gruppe sind, müssen sich für diesen Service Zwangs-registrieren, sobald Sie sich das erste mal anmelden wollen.
      SSPR macht nur Sinn, wenn man die Benutzerpflege direkt am Tenat durchführt. Nutzt man AD Connect zum synchronisieren seiner lokalen Domain-User und hat keinen passenden Azure AD Premium P1 oder P2 Plan, dann funktioniert das mit den SSPR nicht.
    • Zwei-Faktoren-Authentifizierung einrichten z.B. mit Handynummer oder Authenticator-App.
      Kann sein dass es erst später einzurichten geht, wenn Benutzer angelegt wurden.
      https://docs.microsoft.com/de-de/microsoft-365/admin/security-and-compliance/set-up-multi-factor-authentication?view=o365-worldwide
    • Unter „Office 365 Security & Compliance“ Sicherheits-, Aufbewahrungsregeln für das Mailing etc festlegen.
      „Bedrohungsmanagement“ -> DKIM,
    • Bei Bedarf Azur AD Sync einrichten. Hierbei werden die Benutzer und Passwörter aus einer vorhandenen lokalen Domain synchronisiert. Auf Server-Seite müssen entsprechende Ports und Programme installiert werden, damit die Kommunikation mit der Cloud funktionieren kann.
      Alternativ kann man auch eigene Benutzer getrennt von der Domain anlegen und Verwalten. Aber ein späterer Wechsel zu Azur AD Sync ist schwierig bis nicht möglich.
      Wichtig: Wenn Mailpostfächer aus alten Exchange-Servern migriert werden müssen, dürfen für die zu migrierenden Benutzer/ Postfächer noch keine Benutzerkonten angelegt sein!
    • Das Erstellen von Gruppen für alle Mitglieder einschränken
      https://docs.microsoft.com/de-de/microsoft-365/solutions/manage-creation-of-groups?view=o365-worldwide
    • Wenn alle Benutzer angelegt oder aus der lokalen AD synchronisiert worden sind, dann kann die Sprache und Zeitzone der User via PowerShell zentral eingerichtet werde. Macht man dies nicht und loggt sich der User nicht/ nie in OWA ein, so werden in Outlook die Ordner mit englischer Bezeichnung (Inbox, Trash etc.) angezeigt. Dies kann zu Problemen führen, wenn man aus alten Beständen Mails in Outlook importieren muss.
$cred = Get-Credential

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential

$cred -Authentication Basic -AllowRedirection Import-PSSession $session

Get-Mailbox -ResultSize unlimited | ? {$_.RecipientTypeDetails -eq "UserMailbox"} | Get-MailboxRegionalConfiguration

Get-Mailbox -ResultSize unlimited | ? {$_.RecipientTypeDetails -eq "UserMailbox"} | Set-MailboxRegionalConfiguration -Language "de-DE" -DateFormat "dd.MM.yyyy" -TimeFormat "HH:mm" -TimeZone "W. Europe Standard Time" -LocalizeDefaultFolderName
    • dfsadfsdaaf

 

BSI Informationspool – Sichere Konfiguration von Microsoft Office 2013/2016/2019/365

Vorwort

Hin und wieder erstellt die BSI sinn bringende Dokumentationen für ein sicheres Arbeiten mit den digitalen Medien.

Link -> https://www.allianz-fuer-cybersicherheit.de/ACS/DE/Informationspool/_function/Informationspool_Formular.html

In diesem Fall schlägt die BSI Konfigurationen für eine domainweite Anwendung von GPO und dem sicheren Arbeiten mit Microsoft Office vor.

Je nach Bedarf kann man diese Einstellungen so 1:1 übernehmen, sollte sich aber im klaren sein, dass unter Umständen bestimmte Funktionen nicht mehr wie erwartet funktionieren können. Unter den einzelnen Empfehlungen gebe ich hier meine Erfahrungen preis und sage warum ich einige Einstellungen so nicht übernehmen würde.

BSI-CS 135 -> Office allgemein

Computerrichtlinie\Sicherheitseinstellungen
Benutzerrichtlinien\Sicherheitseinstellungen
Punkt 7.+83.  VBA für Office-Anwendungen deaktivieren

Wer wirklich überhaupt nicht mit Makros arbeitet kann hier den Punkt aktivieren. Diese Einstellung greift dann auf alle Office-Anwendungen und man ist hier gegenüber bestimmter Attacken sicher.

Wer aber Makros benötigt, sollte diesen Punkt nicht konfigurieren und bei jeder Anwendung im Einzelnen die Option „VBA zulassen“ bewerten. Wer VBA benötigt, sollte sichere Arbeitsverzeichnisse festlegen aus denen das Ausführen von Makros erlaubt ist.

Diese Einstellungen findet man unter:

Benutzerrichtlinie\Sicherheitseinstellungen\Trust Center\Vertrauenswürdiger Speicherort #1 bis #20

Benutzerrichtlinie\Verschiedenes
Punkt 43. Anmeldungen bei Office blockieren

Wer mit Office 365 und Exchange Online arbeitet, der muss sich z.B. zum Abholen von Mails anmelden können. Somit ist das Einstellen auf „keine zulässig“ nicht richtig. Ich empfehle hier auf „nur Org-Id“ einzustellen. So kann man sich bei Office-Anwendungen nicht mit einem privaten Microsoft Account anmelden.

Ist diese Rule auf „keine zulässig“ oder nur eines der Beiden, dann bekommt der der nicht darf folgendes Fenster angezeigt, wo normalerweise das Anmeldeformular zu Microsoft zu sehen ist:

Der entsprechende Regkey ist hier zu finden:

Computer\HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\common\signinßsigninoptions
Computer\HKEY_CURRENT_USER\Software\Microsoft\office\16.0\common\signinßsigninoptions

signinoptions als REG_DWORD mit Werten 0-2 (0=beide, 1=nur Microsoft-Konto, 2=nur Org-Id)

Benutzerrichtlinie\Globale Optionen\Benutzerdefiniert
Punkt 45. Alle Benutzeranpassungen deaktivieren

Wer firmeneigene Menü-Icons in Office verwendet, der sollte hier die Regel für die entsprechende Anwendung nicht aktivieren, da sonst die eigenen Menü-Icons verschwinden. Zudem ist das eigene Einstellen der Schnellstartleiste und Menüleiste nicht mehr möglich. Wer aber ohnehin ohne Makros arbeitet, sollte hier der Empfehlung von BSI folgen, da man so auch nicht den vorher ausgeblendeten Menüpunkt „Entwicklermodus“ aktivieren kann.

Ich habe es trotz eigener Menü-Icons so eingerichtet, dass via GPO z.B. Excel nicht aktiviert wurde, habe aber beim Import benutzerdefinierter RegKeys  den Wert auf nicht erlauben gesetzt. So blieben mir die firmeneigenen Menü-Icons erhalten, konnte aber dennoch die Schnellstartleiste/ Menüleiste zur eigenen Editierung sperren.

[HKEY_CURRENT_USER\Software\Microsoft\office\16.0\common\toolbars\excel]
"nousercustomization"=dword:00000001

Benutzerrichtlinie\Datenschutz\Trust Center
Punkt 56. Die Verwendung verbundener Erfahrungen in Office zulassen

Auch hier ist das Deaktivieren problematisch, wenn man mit Office 365 arbeitet und z.B. OneNote Notizbücher mit der Cloud synchronisieren muss.

In den Anwendungen unter „Datei\Konto“ steht bei verbundenen Diensten „OFFLINE Office ist zurzeit offline“

In diesem Zustand kann sich z.B. kein OneNote Notizbuch mit der Cloud synchronisieren.

Daher setze ich diesen Schalter auf „aktiviert“. Der RegKey außerhalb der GPO ist dieser hier:

[HKEY_CURRENT_USER\Software\Microsoft\office\16.0\common\privacy]
"disconnectedstate"=dword:00000001

Benutzerrichtlinie\Sicherheitseinstellungen\Digitale Signaturen
Punkt 105. Zertifikatausstellerfilter angeben
Punkt 106. Namen des Zeitstempelserver angeben

Da ich diese Angaben nicht kenne, konnte ich diese Rule nicht wie von BSI empfohlen aktivieren und habe diese auf „nicht konfiguriert“ stehen lassen.

BSI-CS 138 -> Word
BSI-CS 136 -> Excel
BSI-CS  045 -> PowerPoint
BSI-CS 140 -> Access
BSI-CS 141 -> Visio
BSI-CS 139 -> Outlook

Downloads

Hier biete ich entsprechende RegKeys zum Download an, ich denke für den privaten Sektor eine guten Ausgangsposition um Office sicherer einzustellen. Diese sind nur Empfehlungen und stellen keinen 100%-Schutz dar!

Wer diese RegKeys nutzen will, sollte sich im Aufgabenplaner/ Taskmanager eine Batch-Datei anlegen und diese bei jeder Useranmeldung starten lassen. So wird sichergestellt, dass versehentliches Umstellen in den Office-Anwendungen wieder rückgängig gemacht werden. Dies betrift natürlich nur Einstellungen, welche durch diese RegKeys erfasst wurden.

Allerdings kann man auch manuell durch Doppelklick auf die RegKeys oder der Batch-Datei diese Einstellungen importieren.

Erstellt eine  Datei und bennent diese z.B. „Office-Secure.bat“. Achtet darauf, dass der Explorer (Optionen\Ansicht) unter dem Punkt „Erweiterungen bei bekannten Dateitypen ausblenden“ nicht aktiv ist.

In die Batch-Datei schreibt Ihr nun folgendes:

@echo off
echo Reg_Import Office-Security
reg import %Userprofile%\Downloads\regkeys\global_HKLM_2020_02_06.reg
reg import %Userprofile%\Downloads\regkeys\global_HKLU_2020_02_06.reg
if %ERRORLEVEL% NEQ 0 (
echo Fehler bei RegImport Office-Security
)

Speichert die RegKeys ins Downloadverzeichnis in einen noch anzulegenden Ordner namens „regkeys“.

RegKey Office 2013/2016/2019/365 allgemein