ugg.li Schnelle Hilfe für schnelle Admins

Ein DKIM-Schlüssel, der sich nie ändert, wird mit der Zeit zum Sicherheitsrisiko. Wie jedes kryptografische Geheimnis sollte auch ein privater DKIM-Schlüssel regelmäßig erneuert werden – obwohl kein technisches Ablaufdatum festgelegt werden kann.

Trotzdem hat die Rotation einen kleinen Haken: Wird sie falsch umgesetzt, sind plötzlich keine gültigen Signaturen mehr da – und legitime E-Mails sind plötzlich nicht mehr valide. Es kommt auf die richtige Vorgehensweise an. Bewährt hat sich eine Rotation mit zwei Selektoren, die auch Microsoft in Exchange Online einsetzt.

Warum DKIM-Schlüssel rotieren?

Risiken begrenzen: Wird ein privater Schlüssel gestohlen, kann damit im Namen der Domain signiert werden – und zwar so lange, wie der Schlüssel gültig ist. Eine regelmäßige Rotation verkürzt dieses Zeitfenster.

Kryptografie aktuell halten: 1024-Bit-Schlüssel sind heute nicht mehr zeitgemäß. Bei der Rotation empfielt sich der Wechsel auf einen Schlüssel mit 2048 Bit Länge an.

Security-Hygiene: Regelmäßiges Erneuern von Geheimnissen gehört in den meisten Sicherheitsstandards dazu.

Das Risiko entsteht nicht nur durch einen gestohlenen Schlüssel; auch bereits abgefangene, gültig signierte Nachricht können für DKIM-Replay-Angriffe missbraucht werden (solange der dazugehörige öffentliche Schlüssel noch im DNS veröffentlicht ist).

Wie oft sollte man rotieren?

Eine feste oder technische Vorgabe gibt es nicht. Für die meisten Unternehmungen ist die Rotation alle zwölf Monate ein brauchbarer Richtwert.

In sensiblen Umgebungen (Medizintechnik, Anwälte, Flugdienstzulieferer …) sollte das auch häufiger der Fall sein. Entscheidend ist weniger das Intervall, als mehr die Regelmäßigkeit. Die Rotation sollte im Idealfall geplant und automatisiert ablaufen.

DKIM Schlüssel Rotation in Microsoft 365 Exchange Online

Die Rotation an sich (inklusive umstellung auf 2048bit) ist schnell gestartet:

Connect-ExchangeOnline
Rotate-DkimSigningConfig -Identity <DOMAIN> -KeySize 2048

Den Erfolg der Maßnahme zeigt Get-DkimSigningConfig übersichtlich an:

Get-DkimSigningConfig -Identity <DOMAIN> | fl Domain, KeyCreationTime, RotateOnDate, SelectorBeforeRotateOnDate, SelectorAfterRotateOnDate,Selector1KeySize,Selector2KeySize

Domain                     : <DOMAIN>
KeyCreationTime            : 01.01.2001 08:41:42
RotateOnDate               : 01.02.2001 08:41:42
SelectorBeforeRotateOnDate : selector1
SelectorAfterRotateOnDate  : selector2
Selector1KeySize           : 1024
Selector2KeySize           : 2048

Warum gibt es hier (manchmal) Schlüssel in verschiedenen längen?

Microsoft verwendet zwei DKIM-Selektoren, selector1 und selector2. Diese werden nicht gleichzeitig rotiert. Stattdessen wird nur einer der beiden Selektoren erneuert, während der andere unverändert weiterverwendet wird.

Das hat einen ungewohnt pragmatischen Grund: So kann der aktive Schlüssel gewechselt werden, ohne dass die bestehenden DKIM-Signaturen ungültig werden. Der neue Schlüssel wird im DNS veröffentlicht und Exchange wird damit „neue“ Mails signieren. Der bisherige Schlüssel bleibt für „alte“ Mails unverändert verfügbar.

Wurde eine Domain „damals“(tm) mit 1024bit Schlüsseln eingerichtet und man rotiert nun, wird zunächst selector1 (before … after) auf 2048bit geändert. Bei der nächsten Rotation ist dann selector2 an der Reihe und wird ebenfalls auf 2048bit geändert.

Also keine Hektik, bald(tm) hat man lange Schlüssel.

Für die Vergabe von Lizenzen in Microsoft 365 ist die Pflege des Feldes „UsageLocation“ in EntraID bei jedem Benutzer verpflichtend.

Außerdem wird diese Information mittlerweile auch beim Teams „Dialplan“ verwendet. Man muss hier immer das Land eintragen, in dem der Anwender arbeitet.

Dazu gibt es mehrere Möglichkeiten:

• Manuelle Pflege: Man setzt das Feld direkt im Admin-Center bei der Lizenzzuweisung für jedes Microsoft 365 Objekt einzeln
• Tenant Default: Neue Nutzer übernehmen die im Tenant als Default hinterlegte Eigenschaft. Änderungen sind pro Benutzer weiter möglich
• EntraID Connect (ehemals AdSync) + AD Feld „msExchUsageLocation“: Das Feld msExchUsageLocation wird On-Premises bislang zwar nicht genutzt (oder automatisch gepflegt). Wenn man das tut, wird es von EntraIDConnect automatisch synchronisiert.
  Get-AdUser -identity "EXAMPLEDUDE" | Set-AdUser -replace @{msExchUsageLocation="DE"}
• Eine EntraID Sync-Regel erstellen, die einen festen Wert in das AzureAD schreibt oder ein anderes Feld (z.B. „c“ [Country]) dazu verwendet

Lösung

In den vermutlich meisten Fällen reicht es, das Attribut als Standard vorzugeben und die Ausnahmen zu pflegen. Bei deutschen Organisationen ~500 Nutzende war das bisher die pragmatischste und effizienteste Lösung.

Das geht recht schnell an der PowerShell, wenn man verstanden hat wie Microsoft’s Vibecoder arbeiten.

Hier ein Beispiel für die PowerShell7 (pwsh) mit dem aktuellen Graph-Modul:

Install-Module Microsoft.Graph -AllowClobber
Install-Module Microsoft.Graph.Authentication
Install-Module Microsoft.Graph.Identity.DirectoryManagement
Connect-MgGraph -Scopes Organization.ReadWrite.All

Update-MgOrganization -OrganizationId (Get-MgOrganization).Id -DefaultUsageLocation "DE"

Zur (Erfolgs-)Kontrolle des Attributes:

Get-MgOrganization | fl DefaultUsageLocation

Wenn man noch einen älteren Client mit der PowerShell 5 und den („deprecated“) MSOnline-Modulen hat, ist das hier das equivalent:

Install-Module MSOnline
Import-Module MSOnline -UseWindowsPowerShell 
Connect-MSOnlineService
Set-MsolCompanySettings -DefaultUsageLocation "DE"