Office 365 SMIME

Zum Verschlüsseln und Signieren von Mails ist S/MIME die bevorzugte Variante neben PGP. Nahezu jeder moderne Mailclient kann auch S/MIME signierte Mails empfangen und prüfen und mit einem lokalen Zertifikat auch selbst signiert versenden. Die Verschlüsselung ist ebenfalls möglich. Mit dem Einsatz unter Office 365 sind aber ein paar Besonderheiten zu beachten, die auf die Trennung von Azure-AD und lokalem AD und Exchange in der Cloud zurück zu führen sind.

Lesen Sie dazu auch die Seite Benutzerzertifikate im AD 

Von der Firmen-PKI zum Client

Wer mit einer internen PKI arbeitet, um z.B., interne Mails zu sichern und mit Partnern zu kommunizieren, die der Firmen-PKI vertrauen, wird dafür sorgen dass:

  • Anwender nach Authentifizierung ein Zertifikat erhalten
    Denkbar ist hier ein Autoenrollment, damit alle eins bekommen.
  • Das Template z.B. nur die Nutzung für SMIME vorgibt
    Damit damit kein Code-Signing oder EFS genutzt wird. Auch die Gültigkeit sollte an die Firmenanforderungen angepasst sein. Zudem sollten Benutzer nur ein Zertifikat anfordern oder vor Ablauf verlängern können, nicht dass am Ende auf jedem PC ein eigener Private Key liegt.
  • Der Private Key gesichert wird
    Damit man im Recovery-Fall an den Schlüssel kommt um weiter auch alte Mails lesen zu können.
  • Certificate Roaming den private Key verteilt
    Damit der Anwender zumindest auf allen Windows Clients der Domäne auch seinen gleichen private Key mitnehmen kann, selbst wenn dieser normal nicht exportierbar ist
  • Der Public-Key im Active Directory (Feld "UserCertificate") publiziert wird.
    Hier kann Exchange die Daten dann in das OAB übernehmen und Outlook darauf zugreifen.
  • Mobile Clients
    Eine generelle Frage ist, wie man das Zertifikat samt private Key sicher auf Mobilgeräte bekommt. Bei größeren Stückzahlen ist hier ein MDM und angepasster Enrollment-Prozess einzuplanen.
  • Schreibweise der Felder
    Achten Sie besonders auf die Schreibweise der SMTP-Adresse. Es gibt Clients, bei denen die Signaturprüfung warnt, wenn die Mailadresse des Absender und die im Zertifikat sich bei Groß/Kleinschreibung unterscheiden. Tipp: Alle SMTP-Adressen im AD (Feld: "Mail" und "ProxyAddresses") klein schreiben lassen und das Zertifikat dann auch so ausstellen.

On-Prem funktioniert das auch sehr einfach aber mit Office 365 kommen ein paar Komponenten dazu.

  • Exchange Online liest nur das Azure AD
    Damit ist klar, dass die Zertifikate im lokalen Active Directory natürlich auch in das Azure AD übertragen werden müssen. Dabei hilft ADSync.
  • Exchange muss der PKI vertrauen
    Per Default vertraut natürlich Exchange dem Aussteller erst mal nicht. Sie müssen ihr eigenen Stammzertifikate daher für ihren Tenant erst mal "freischalten".
  • OWA
    Wie kann ein Anwender mit OWA verschlüsselt empfangene Mails lesen oder eigene Mails signieren? Anpassungen beim "Serverseitigen OWA" sind ja erst mal nicht möglich
  • Mobile Device Manager
    Wer Office 365 nutzt, wird sich auch mit InTune und Office 365 MDM zum Management beschäftigen.

Für den "Kreis" der Zertifikate mit Office 365 bedeutet dies:

  1. Root Cert in Ofice 365 bereit stellen
    Zuerst muss der Administrator die Stammzertifikate in der Cloud bereitstellen, damit die Benutzerzertifikate
  2. Ein Benutzer fordert ein Zertifikate bei der internen PKI an.
    Der Client rechnet dabei ein Schlüsselpaar (Privatekey/Publickey), speichert den privaten Schlüssel lokal und sendet den PublicKey mit weiteren Daten z.B.: per Autoenrollment an die PKI. Optional auch mit dem privaten Schlüssel.
  3. Die PKI speichert idealerweise den PrivateKey in einem sicheren Bereich, veröffentlicht das Zertifikat im On-Prem AD und gibt das Zertifikat an den Client zurück.
    Überlegen Sie , wie der private Key auf allen Geräten verfügbar machen, an denen der Anwender S/MIME benutzen wird, z.B. per "Certificate Roaming".
  4. ADSync repliziert das Zertifikat in das Azure AD
    Hier kann von einer Zeitverzögerung von bis zu drei Stunden ausgegangen werden, wenn Sie nicht manuell auf dem DirSync/ADSync manuell antriggern.
  5. Exchange Online erstellt ein OAB
    Bei Office 365 nutzt nur OWA direkt das Azure-AD. Ein Outlook hingegen nutzt primär das Offline Adressbuch, welches vom Exchange Server erst generiert werden muss. Das passiert laut "2427141 You can't find a User in the offline address book in Office 365" alle 24h.
  6. Outlook Client lädt das OAB herunter
    Auch der Client lässt sich manchmal etwas Zeit und lädt die OAB-Aktualisierung verzögert herunter. Auch das kann natürlich forciert werden. für Tests ist ein mobiler Client

Der ganze Ablauf sieht als Bild dann so aus:

Es kann also bis zu 48 Stunden dauern, bis ein neu erstelltes Zertifikate von einem anderen Anwender mit einen Outlook Client im Cached Mode zu Verschlüsseln genutzt werden kann. Etwas schneller geht es mit OWA oder mit mobilen Clients, die nicht auf das OAB zurückgreifen und direkt den Exchange Server und damit das Azure-AD befragen. In Outlook können Sie die zweite Wartezeit natürlich durch einen manuellen Download des Offline Adressbuch beschleunigen.

Wenn sie einen Prozess etabliert haben, der z.B. alle Stunde einen "Zeitstempel" an ein besonderes Benutzerobjekt schreibt, können Sie im Outlook Adressbuch einfach erkennen, wie alt das aktuell genutzte Adressbuch ist.

RootCA und Office 365

Damit Sie aber überhaupt in Office 365 mit Zertifikaten einer eigenen PKI arbeiten können, müssen Sie ihre Root-Zertifikate und eventuell vorhandenen Intermediate-Zertifikate erst in ihrem Office 365-Tenant importieren. Dazu exportieren Sie auf einem Client ihres Forest oder auf der Zertifizierungsstelle erst einmal die Stammzertifikate und Zwischenzertifikate in eine SST-Datei. Das geht über die MMC für Zertifikate per GUI. Sie wählen die entsprechenden Zertifikate aus:

Und dann exportieren Sie diese über den Wizard:

Diese SST-Datei müssen Sie dann in einer Exchange PowerShell in Exchange Online importieren. Sie verbinden sich also wieder per PowerShell mit der Cloud

# exchange PowerShell mit Office 365 verbinden
$cred = Get-Credential
$Session = New-PSSession `
   -ConfigurationName Microsoft.Exchange  `
   -ConnectionUri https://outlook.office365.com/PowerShell-liveid/  `
   -Credential $cred  `
   -Authentication Basic  `
   -AllowRedirection
Import-PSSession $Session

#SST Datei laden
$sst = Get-Content `
   -path "c:\firmenca.sst" `
   -Encoding Byte

# Inhalt in Office 365 hinterlegen
Set-SmimeConfig `
   -SMIMECertificateIssuingCA $sst

Ich habe es mir zur Angewohnheit gemacht, den Erfolg auch zu überprüfen. Das geht sehr schnell, wenn Sie noch die eben gestartete PowerShell geöffnet haben:

# SST wieder retour lesen (Exchange Online PowerShell)
[io.file]::WriteAllBytes("c:\cert.sst",(Get-SmimeConfig).SMIMECertificateIssuingCA)

Wenn Sie dann die SST-Datei starten, sollte eine MMC die Liste der Zertifikate anzeigen, die sie gerade importiert haben.

Schließen Sie die PowerShell noch nicht. Wir benötigen diese noch.

DirSync/ADSync und UserCertificate

Der Office 365 Tenant vertraut nun ihrer privaten PKI und die für Anwender ausgestellten Zertifikate sind im lokalen Active Directory veröffentlicht. Zur Sicherheit können Sie dies ja in der MMC für Active Benutzer und Computer nachprüfen.

Diese Information können Sie natürlich auch per PowerShell und LDAP abfragen:

get-adUser `
   -properties Usercertificate `
   -ldapfilter "(Usercertificate=*)" `
   | ft name,Usercertificate -autosize

Die Liste zeigt dann alle Benutzer mit den Zertifikaten. Damit ist die Vorarbeit geleistet.

Nun gilt es im Azure AD diese Daten zu prüfen, ob ihr DirSync/ADSync auch wirklich ganz arbeitet leistet. Allerdings brauchen Sie dazu nicht die Azure AD-PowerShell, sondern weiterhin die Exchange Remote PowerShell. Das Property "UserCertificate" wird mit einem Get-MSOLUser nicht geliefert. Es muss schon ein Get-Mailbox sein.

get-mailbox `
   | where { $_.Usercertificate -ne $null}`
   | ft name,Usercertificate,*smime*

Hier sollten aber alle Benutzer, die On-Prem ein Zertifikate haben und durch den DirSync eingeschlossen sind, auch aufgeführt werden. Dann ist alles soweit in Ordnung, dass die privaten Zertifikate auch im Azure-AD hinterlegt sind und die Chancen stehen gut, dass Exchange beim nächsten "OAB-Generation" diese Zertifikate auch in das Offline Adressbuch aufnimmt und die Outlook Clients beim nächsten Download diese Zertifikate auch zum verschlüsselten Senden an diese Empfänger nutzen können.

Zertifikate nicht in Exchange Online - woran liegt es ?

In der Regel geht alles glatt aber wenn die Zertifikate nicht in Exchange Online auftauchen, dann gibt es nach meiner Erfahrung ein paar häufige Fehler

  • Zertifikate im falschen LDAP-Feld
    Für Office 365 ist das LDAP-Feld "UserCertificate" interessant. Es gibt parallel auch noch das LDAP-Feld "UserSMIMECertificate". Dies ist aber nicht von belang, Ich habe aber schon gesehen, dass Firmen mit einer fremden PKI die Zertifikate per LDAP dort importiert haben. Das sollte ihnen aber schon weiter oben bei der Kontrolle aufgefallen sein.
  • Zu viele Zertifikate
    Das Feld "UserCertificate" ist ein MultiValue-Feld, aber darf dennoch nicht zu groß werden. Wenn Sie aber z.B. AutoEnrollment mit Einmalprofilen auf einem Terminal Server kombinieren und per Template nicht die Mehrfachausstellung unterbunden haben, dann bekommt der Benutzer jeden Tag ein neues Zertifikate. Das ist eine schwere Fehlkonfiguration und sollte umgehend geändert werden, das der Benutzer vermutlich nie mehr verschlüsselt empfangene Mails öffnen kann. Entfernen Sie möglichst schnell diesen Fehler, ziehen die Zertifikate zurück und löschen Sie die im AD publizierten Zertifikate, z.B. mit Remove-Usercert
  • User nicht im DirSync
    Viele Firmen filtern den DirSync, damit administrative Konten, Dienstkonten etc., die nicht in Office 365 relevant sind, auch gar nicht im Azure-AD auftauchen. Da eine Filterung per OU oft ungeeignet ist, wird gerne ein AD-Property verwendet. Wen dies nicht korrekt gesetzt ist, dann sollten Sie aber den Benutzer überhaupt nicht im Azure-AD als Identität mit Postfach sehen.
  • Postfach
    Der wichtigste Aspekt ist aber, dass der Benutzer On-Premises aussieht, als wenn er ein Postfach hat. Selbst wenn Sie gar kein Exchange On-Prem betreiben und nicht mal die Schemaerweiterungen installiert haben, repliziert ADSync nur dann das Feld "UserCertificate", wenn On-Prem auch das Feld "MailNickName" gefüllt ist. Zum Glück ist dieses Feld nicht Bestandteil der Exchange Schema Erweiterung aber ohne lokalen Exchange Server wird die Pflege gerne vergessen. Siehe dazu auch Office 365:DirSync mit Exchange

Wenn Sie weitere Fälle gefunden haben, die hier aufgeführt werden sollten, dann reicht eine kurze mal an Kontakt.

Outlook und UserSMIMECertificate

Neben dem Feld UserCertificate gibt es noch UserSMIMECertificate. Jeder Anwender kann in Outlook selbst seine Zertifikate "veröffentlichen". Outlook lädt diese dann aber nicht nach UserCertificate hoch sondern nach UserSMIMECertificate. Wenn Outlook dann verschlüsseln will, nutzt es zuerst UserSMIMECertificate. Das kann zu Unstimmigkeiten führen, wenn die Firma nur die Zertifikate in UserCertificate verwaltet.

Da hilft dann nur diese Funktion per Gruppenrichtlinie in Outlook abschalten, was aber nur mit Domainmitgliedern geht und nicht für all die Office 365 Outlook-Nutzer zuhause. Oder sie "putzen" immer mal wieder das Feld.

set-mailbox `
   -identity User1 `
   -UserCertificate $null `
   -UserSMimeCertificate $null

Dieser Befehlt funktioniert sogar bei einem per DirSync verbundenen Benutzer, bei dem die meisten anderen Properties "ReadOnly" sind. Siehe dazu auch Office 365:DirSync mit Exchange.

Userzertifikate in Office 365 detailliert einsehen

Natürlich können Sie mit Outlook versuchen eine Mail verschlüsselt zu senden und so indirekt die Erreichbarkeit des Zertifikats prüfen. Das ist aber keine 100%tige Option, denn Sie könnten das Zertifikat des Anwender schon in ihren Kontakten vorhalten. Zudem könnte ihr Outlook ein altes OAB nutzen und damit den Test wertlos machen. Sie könnten auch einen mobilen Client verwenden, so er denn auf die Zertifikate in Exchange Online zurückgreift.

Es gibt aktuell (Stand Juni 2015) keine GUI, um als Administrator in Exchange Online die Zertifikate bei einem Benutzer anzuzeigen. Aber es ist natürlich per PowerShell möglich. Wie schon weiter oben  beschrieben, benötigen wir eine Exchange Remote PowerShell. Die folgenden Zeilen erstellen einen Report aller Benutzer mit einem Zertifikat

$UserCredential = Get-Credential
$Session = New-PSSession `
   -ConfigurationName Microsoft.Exchange `
   -ConnectionUri https://outlook.office365.com/PowerShell-liveid/ `
   -Credential $UserCredential `
   -Authentication Basic -AllowRedirection
Import-PSSession $Session

get-mailbox | ?{$_.Usercertificate -ne $null}| ft name,Usercertificate

Name UserCertificate                        
----                                    --------------- User1                                   {48 130 8 0 48 130 5 232 160 3 2 1 2... User2                                   {48 130 6 159 48 130 5 135 160 3 2 1... User3                                   {48 130 7 253 48 130 5 229 160 3 2 1...

Wer möchte, kann aber nun auch noch die Zertifikate selbst wieder als CER-Datei extrahieren und so einer genaueren Analyse unterziehen. Beachten Sie, dass das Feld "UserCertificate" ein Array ist.

#UserZert in der Cloud auslesen
[io.file]::WriteAllBytes("c:\test4_pki.cer",(Get-Mailbox test4_pki).Usercertificate[0])

Noch eine Stufe weiter geht dann ein kompletter Export aller Zertifikate aller User in einzelne Dateien.

foreach ($mailbox in get-mailbox) {
   write-host ("processing " + $mailbox.alias+":") -nonewline 
   if ($malbox.Usercertificate -ne $null) {
      For($count=0;$count -le $malbox.Usercertificate.count;$count++){
         write-host "." -nonewline
         [string]$filename = "c:\temp\"+$mailbox.alias+"."+$count+".cer"
         [io.file]::WriteAllBytes($filename,$Mailbox.Usercertificate[$count])
      }
      write-host "User Done"
   }
   else {
      write-host "Skip User without certificate"
   }
}
write-host "All Done"

Dies ist aber kein "Backup". es handelt sich nur um die sowieso öffentlichen Schlüssel mit der Signatur eine PKI. Die privaten Schlüssel haben nur ihr Benutzer und eventuell die PKI, wenn Sie ein Key Recovery konfiguriert haben.

OWA und SMIME

Ich habe schon anfangs gesagt, das Anwender mittlerweile in Office 365 per Outlook Web App mit S/MIME arbeiten können. Das hört sich erst mal einfach an aber es müssen dennoch Voraussetzungen erfüllt sein. Die Verschlüsselung könnte noch der Exchange Server übernehmen aber zum Signieren ausgehender Mails wird der private Schlüssel benötigt. Den wollen Sie sicher nicht dem Server übereichen und das in der Regel auch technisch nicht möglich ist. Daher muss OWA-Client, d.h. ihr Browser, die Mails verschlüsseln und signieren.

Gleiches gilt für verschlüsselt angekommene Nachrichten. Auch hier muss ihr Browser mit dem erreichbaren privaten Schlüssel die Mails decodieren, die ja vom Absender mit dem öffentlichen Schlüssel des Empfängers verschlüsselt wurden.

Damit stellen sich zwei Fragen:

  1. Kann ihr Browser mit OWA das erforderliche Addin ausführen?
    Hier gibt es einmal das Betriebssystem (Windows, Linux, MacOS aber auch Android, IOS und Windows Phone). Aber auch die Wahl des Browsers (IE, Chrome, Firefox etc.) kann hier knifflig werden.
  2. Wo ist der "private Key"?
    Wer einen fest zugeordneten Client verwendet, wird bevorzugt Outlook oder den passenden ActiveSync-Client nutzen. OWA ist ja primär der "Überall-Zugang" zum Postfach. Aber wie nehmen Sie ihren privaten Schlüssel in dem Fall sicher mit und wie stellen Sie sicher, dass er auch sicher wieder entfernt wird. Klassisch kommt hier eine Smartcard zum Einsatz, was aber einen entsprechenden Leser erforderlich macht. Selbst eine Smartcard mit USB-Stick kann nicht an jedem Endgerät angeschlossen werden.

Diese Herausforderungen sind nicht immer lösbar. Anwender werden hier Einschränkungen akzeptieren müssen. Manchmal sollten "vertrauliche Mails" eben doch nicht auf "Any Device" gelesen und im schlimmsten Fall sogar unverschlüsselt weiter verwendet werden. Anstatt per S/MIME den Transport zu sichern, kann es durchaus sinnvoller sein die Information selbst per RMS zu schützen. Aber auch dieses Verfahren hat seine Schattenseiten.

Wichtig ist in dem Umfeld auch noch die Möglichkeit des Administrators pro Benutzer die Verwendung von S/MIME zu unterbinden. Innerhalb von Exchange können Administratoren so genannte OWAMailboxPolicies definieren. Eine solche Policy fasst verschiedene Einstellungen von OWA zusammen von denen eine sich auf S/MIME beziehen. Neben der Default Policy können weitere Richtlinien angelegt werden. Das wurde hier gemacht. Beim New-OwaMailboxPolicy können Sie noch keine Konfigurationsparameter einstellen. Das geht erst nach dem Anlegen der neuen Policy mit "Set-OwaMailboxPolicy".

PS C:\> New-OweMailboxPolicy test

PS C:\> Get-OwaMailboxPolicy | ft  name,smimeenabled -AutoSize

Name                     SMimeEnabled
----                     ------------
OwaMailboxPolicy-Default        False
test                            True

Kontrollieren Sie bitte die neu angelegte Policy auf ihre Default Werte. Sie entsprechen nicht automatisch den Einstellungen der "Default Policy", wie hier gut zu sehen ist.

SMIME ist in Office 365 (Stand Juni 2015) in der Default Policy zwar deaktiviert aber in jeder neu angelegten Policy ist es aktiv. Jeder Mailbox kann dann über "Set-CASMailbox" genau eine Richtlinie zugewiesen werden. So können Sie z.B. verhindern, dass Anwender mit OWA überhaupt S/MIME einsetzen. Das kann sinnvoll sein, um den Einsatz zum einen nur auf bestimmte Personen zu beschränken oder durch den Verzicht auf OWA das öffnen gesondert gesicherter Mails auf fremden Geräten zu verhindern.

Weitere Links