Kategorie: Office

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

 

Sichere E-Mail-Kommunikation mit S/MIME-Zertifikaten

Kostenlose Zertifikate

Nachdem mein Zertifikat bei Comodo nicht mehr neu beantragt werden kann, habe ich mir neue Anbieter kostenloser Zertifikate gesucht.

Hierbei bin ich zum einen auf Volksverschlüsselung gestoßen und eben auf Actalis. Bei Volksverschlüsselung hat man das Problem, dass die auszustellende CA nicht jedem bekannt ist und so die Mail-Zertifikate als ungültig bzw. nicht vertrauenswürdig angezeigt wird. Dieses Problem sollte man mit Actalis nicht haben. Jedoch glaube ich, dass man mit Volksverschlüsselung länger am Markt rechnen kann. Andere Anbieter werden oft aufgekauft oder bieten plötzlich keine kostenlosen Zertifikate an. Die Authentifizierung bei Volksverschlüsselung ist recht mühsam, wenn man seinen Perso nicht mit der Online-Funktion ausgestattet hat und kein passenden Reader bereit steht.

Bei Actalis bekommt man Stand Feb. 2020 ein kostenloses Zertifikat. Aber auch nach einem knappen Jahr später bietet Actalis kostenlose E-Mail-Zertifikate an und mann kann recht bequem das vorhandene Zertifikat verlängern.

Einfach Zertifikat anfordern, Bestätigungscode (welcher per Mail versendet wird) eingeben und Passwort für das Zertifikat ausdrucken! Das Zertifikat bekommt Ihr im Anschluss per Mail als *pfx zugesandt.

Am sinnvollsten ist es aber vor der Verwendung des Zertifikats die Stammdaten in diesem zu aktualisieren. Dies macht Ihr über das Portal von Actalis.

Nun muss das Zertifikat nur in den Zertifikatsmanager importiert werden und die meisten Mail-Clients erkennen dann das Mail-Zertifikat.

Das Zertifikat wird von der Sub-CA “Actalis Client Authentication CA G1” ausgestellt, diese CA wurde wiederum von der Actalis Authentication Root CA” signiert, welche sich im Speicher für vertrauenswürdige Stammzertifizierungsstellen von Windows befinden sollte.

Aber nun der Reihe nach …

Zertifikat erstellen

  1. https://extrassl.actalis.it/portal/uapub/freemail?lang=en

  2. Verifikation-Code von erhaltener Mail kopieren, in das Formular eintragen, Captcha-Code bestätigen und AGB’s und Werbezwecke akzeptieren bzw. deaktivieren

  3. Password was im Browser angezeigt wird unbedingt sicher abspeichern, Notieren oder ausdrucken

  4. per E-Mail erhaltenes Zertifikat (zip-Archiv) herunterladen und sicher abspeichern
    In der Mail sind auch die Zugangsdaten zum Portal mit angegeben. Über das Portal kann man das Zertifikat nochmal herunterladen oder auch Pausieren lassen oder eben auch löschen.
    https://extrassl.actalis.it/portal/

Zertifikat verlängern

ca. 30 Tage vor Ablauf der Zertifikatsgültigkeit habe ich eine E-Mail von „sslwebserver@actalis.it“ bekommen und wurde über das Auslaufen informiert. In der E-Mail war ein Link enthalten, der mich zur Webseite zum Verlängern meines Zertifikates führte.

https://extrassl.actalis.it/portal/uapub/freemail?lang=en

    1. Link besuchen und E-Mail-Adresse des Zertifikats eintragen und „SEND VERIFICATION EMAIL“-Button anklicken
    2. Den Verifizierungscode aus der danach erhaltenen E-Mail in das Formular eintragen, den Roboter bestätigen und die Punkte unter Step 2 entsprechend ausfüllen. Die letzten zwei Optionen habe ich auf „I do not consent“ gestellt, damit ich keine Werbung bekomme.
    3. Im Browser wird, wenn alles erfolgreich verlaufen ist, das Zertifikatspasswort angezeigt. Dies muss sicher notiert oder ausgedruckt werden. Nachträglich kommt man nicht mehr an das Passwort heran!

    4. Daraufhin kommt eine letzte Mail mit dem neuen Zertifikat. Dies muss nun heruntergeladen und sicher abgespeichert werden.
      In der Mail ist auch ein Link zum Portal von Actalis enthalten. Die Zugangsdaten hierfür wurden bei erstmaliger Erstellung/ Registrierung des Zertifikats übersendet und wird bei einer Verlängerung nicht noch einmal angegeben. Über das Portal kann man das Zertifikat nochmal herunterladen oder Pausieren lassen oder eben auch löschen.

Sollte beim Schritt 3 das Passwort nicht angezeigt werden, weil plötzlich der „Ich bin kein Roboter“ muniert wird obwohl dieser richtig war, dann kann es daran liegen, dass man sich zwischen den einzelnen Schritten zu viel Zeit gelassen hat. In meinem Fall wurde ein Zertifikat ausgestellt, aber keine Mail mit diesem Zugesandt und ich bekam im Browser auch das Passwort für das Zertifikat nicht zusehen.

Über das Portal-Login kann man zuviel erstellte Zertifikate löschen lassen und sich ein neues (nach dieser Anleitung) erstellen.

Zertifikat unter Windows installieren

Wenn Ihr bereits vorhergehende Zertifikate besessen habt, so solltet Ihr diese Zertifikate im Gerätespeicher behalten. Denn nur mit dem alten Zertifikat können alte damit verschlüsselte Mails gelesen werden.

Habt Ihr ein neues Zertifikat auch bei Verlängerung, so kann man mit dem neuen Zertifikat nicht die alten Mails lesen. Das neue Zertifikat gilt nur für die Mails die mit diesem Zertifikat verschlüsselt werden.

Nun müsst Ihr das Zip-Archiv entpacken und *.pfx-Datei per Doppelklick und Passworteingabe (aus Schritt 3 – Zertifikat erstellen) öffnen bzw. Importieren.

Beim Importieren würde ich persönlich darauf verzichten, dass man die „Hohe Sicherheit …“ aktiviert. Diese Einstellung ist beim Arbeiten ehr hinderlich, auch wenn es sicherer wäre.

Aber dafür würde ich den Punkt „Schlüssel als exportierbar …“ deaktiviert lassen. So ist kein anderer in der Lage sich das Zertifikat ungefragt mit eigenem Passwort abzuspeichern.

Mittels dem Befehl „certmgr.msc“ kann man auch schauen ob das Zertifikat nun da ist.

 

Mail-Konto unter Outlook 2016/2016/365 einrichten

Voraussetzung hierfür ist natürlich ein eingerichtet E-Mail-Postfach des Users der nun über ein Zertifikat verfügt.

Da ich gerne selber bestimmen möchte wo Outlook die Postfach-Datei ablegt, gehe ich den Einrichtungsschritt immer über „Systemsteuerung\Benutzerkonten\Mail“. Hier hat man unter „weitere Einstellungen“ noch ein paar Einstellmöglichkeiten die beim direkten öffnen eines frischen Outlooks nicht änderbar sind.

Einfach ein neues Profil anlegen und darin dann das neue Mailkonto. Mit etwas Glück findet Outlook alle Einstellungen zum Provider wie pop3-Server etc. alleine. Andernfalls muss man die in Erfahrung bringen und entsprechend eintragen. Diese Einstellungen sind von Provider zu Provider unterschiedlich.

Erste Testnachricht an Dritten ist angekommen. Natürlich noch ohne Signatur und nicht verschlüsselt.

Zertifikat unter Microsoft Outlook 2016/2019/365 einrichten

Unter Datei\Optionen öffnet sich Fenster wo man diverse Einstellungen vornehmen kann. Dort unter „Tust Center\Einstellungen für das Trust Center ..“ im darauf folgenden Fenster unter E-Mail-Sicherheit das importierte Zertifikat auswählen.

Wer nun ständig signierte Mails versenden möchte aktiviert das Kontrollkästchen „Ausgehende Nachrichten digitale Signatur hinzufügen“.

Wer auch „Inhalt und Anlagen für ausgehende Nachrichten verschlüsseln“ aktiviert, da versendet wenn möglich nun seine Mails immer verschlüsselt. Kann aber die Mail wegen fehlenden öffentlichen Schlüssel des Empfängers nicht verschlüsselt werden, dann erscheint bei jedem Versenden eine Message-Box. Das ist eventuell störend, so dass man hier darauf verzichtet. In diesem Fall muss man die Verschlüsselung vor dem Versand einzeln aktivieren.

Erste Testmail mit enthaltener Signatur. Die Signatur bestätigt die Echtheit meiner Mail bzw. meiner Person. Keine andere Person kann mit dieser Signatur Mails versenden. Es sei denn, man lässt sich sein privates Zertifikat und den Privaten Schlüssel klauen!

Zertifikat auf Apple iPhone/ Apple iPad installieren und einrichten

Theoretisch kann man sich selbst eine Mail mit seinem Zertifikat senden und das Zertifikat dann so auf dem iPhone/ iPad öffnen bzw. installieren. Aber …

In diesem Fall sendet man eine unverschlüsselte Mail die wiederum abgriffen werden kann. Wer nun noch an das Zertifikatspasswort kommt, kann Mails mit diesem Zertifikat versenden, lesen und manipulieren.

Aus diesem Grund gehe ich einen anderen Weg und benutze hierzu meine eigene Cloud die auf einem meiner Server läuft. Da man jetzt ein solches Zertifikat nicht aus jeder Cloud heraus öffnen kann, gehe ich den Umweg über eine mobileconfig-Datei die speziell für Apple-Geräte gedacht ist.

Wer iCloud nutzt kann gerne auch sein Zertifikat dort hochladen und dann mit Safari vom iPhone/ iPad öffnen und installieren. Bitte vergesst nicht das spätere Löschen der Dateien/ Zertifikate aus der Cloud!!

Ladet Euch die Vorlage herunter öffnet diese mit einem Editor. Da man den Editor Notepad++ später noch brauch empfehle ich dieses herunterzuladen und zu installieren.

Editiert die *.mobileconfig und ändert folgende Strings:

[Name] = Euer Name
[E-Mail-Adresse] = Eure Adresse
[PrivateKey] = langer generierter String

Speichert diese Änderung und ladet Euch die Datei in Eure Cloud/ Webserver und öffnet dann diese Datei mit Safari auf dem iPad/ iPhone.

Je nach iOS Version könnt Ihr gleich das Profil installieren oder bekommt einen Hinweis, dass ein Profil geladen wurde und über „Einstellungen“ installiert werden kann.

vorlage_actalis

String generieren

mit Notepad++ generieren

Öffnet Euer Zertifikat (*.pfx) mit Notepad++ und markiert mit STRG+A den gesamten Text. Danach geht Ihr im Menü auf „Erweiterungen -> MIME Tools -> Base64 Encode“ und kopiert Euch den nun angezeigten langen String (STRG+C). Diesen String setzt Ihr in die Vorlage anstelle [PrivateKey].

Mit PowerShell generieren

certutil -encode Mein-Zertifikat.pfx neueZertDatei.enc
$content = gc neueZertDatei.enc
$newcontent=$content[(1..($content.length – 2))] add-content key.mobileconfig -value $newcontent -encoding UTF8

Im ersten Schritt werden Daten aus dem Zertifikat in eine neue Datei (neueZertDatei.enc) geschrieben. Im zweiten weist man den Inhalt aus der Datei einer Variable zu und filtert im dritten Schritt noch mal den Inhalt und gibt dieses Wert einer weiteren neuen Variable. Im letzten Schritt wird der Inhalt der letzten Variable in eine neue Datei namens „key.mobileconfig“ gespeichert.

Diesen String setzt man dann in die Vorlage anstelle [PrivateKey].

Zu finden sind die neuen Dateien alle unter „C:\User\[Benutzername]“.

Wichtig: Zum erneuten durchführen der PowerShell-Befehle oben, müssen vorhandene Dateien unter „C:\User\[Benutzername]“ vorher gelöscht werden. Die Befehle überschreiben keine vorhandenen Dateien!

E-Mail-App von Apple einrichten

Einstellungen -> Passwörter & Accounts -> Euer Mail-Account -> Account -> Erweitert -> Signieren -> neues Zertifikat von Actalis auswählen

Über „Erweitert“ zurück gehen und „Standardmäßig verschlüsseln“ auswählen und auch hier das neue Zertifikat auswählen.

Über „<“ und „< Account“ sowie „Fertig“ alles speichern.

Ab jetzt werden die Mails auch von den mobilen Apple Geräten verschlüsselt versendet, sofern man ein öffentliches Zertifikat des Empfängers besitzt.

Aber man kann nun auch an sich gerichtete verschlüsselte Nachrichten auf den mobilen Geräten lesen.

Anmerkung

Wichtig zu Wissen ist folgendes:

Nutzt Ihr Apple und sendet  Mails aus anderen Apps wie „Foto-App“, dann werden diese Mails NICHT verschlüsselt oder signiert. Nur Mails die direkt durch manuelles Öffnen der „Mail-App“ versendet werden, werden signiert und bei Bedarf verschlüsselt.