SMTPAUTHCLIENTSECRET - Detailbeschreibung

Überblick

Parameter: SMTPAUTHCLIENTSECRET
Kategorie: Smtp
Standardwert: string.Empty
Produkt: eTASK.Sonstige (Smtp)

Was macht dieser Parameter?

Der Parameter speichert das Client Secret (Geheimnis) für die OAuth-Authentifizierung beim E-Mail-Versand über SMTP. Dieses Secret dient als Passwort für die in SMTPAUTHCLIENTID (oder AZURECLIENTID) registrierte Azure-Anwendung und ermöglicht die sichere Authentifizierung beim Microsoft Graph API für den E-Mail-Versand.

Wofür wird dieser Parameter verwendet?

• Sichere Authentifizierung der Azure-Anwendung beim E-Mail-Versand

• Abruf von OAuth-Access-Tokens für Microsoft Graph Mail.Send API

• Ersatz für Benutzername/Passwort-basierte SMTP-Authentifizierung

• Ermöglicht automatisierten E-Mail-Versand ohne Benutzerkontext

• Unterstützt moderne Authentifizierungsstandards gemäß Microsoft-Vorgaben

Technische Details (für Administratoren)

Format: Verschlüsselter String (Client Secret / Application Password)
Standardwert: string.Empty (leer)

Wichtige Hinweise:

• Das Client Secret wird verschlüsselt in der Datenbank gespeichert

• Der Parameter muss als "Kennwort" markiert sein (UpdateDatabase = true) für verschlüsselte Speicherung

• Das Secret findest du in Microsoft Azure unter App-Registrierungen → Zertifikate & Geheimnisse → Neues Clientgeheimnis

• Client Secrets haben ein Ablaufdatum (max. 24 Monate) und müssen regelmäßig erneuert werden

• Der Parameter wird nur verwendet, wenn SMTPUSEOAUTH auf 1 gesetzt ist

Gültige Werte:

• Leer = Keine OAuth-Authentifizierung möglich, Fallback auf Passwort-basierte Authentifizierung

• Client Secret = Von Azure AD generierter Wert (z.B. "abc123~XYZ..." - ca. 40 Zeichen)

Zusammenspiel mit anderen Parametern:

• SMTPUSEOAUTH: Muss auf 1 gesetzt sein, damit OAuth-Authentifizierung aktiviert wird

• SMTPAUTHCLIENTID: Die Client ID, zu der dieses Secret gehört (Fallback: AZURECLIENTID)

• SMTPAUTHTENANTID: Die Tenant ID für die Authentifizierung (Fallback: AZURETENANTID)

• SMTPSERVER: Der SMTP-Server-Endpunkt (z.B. smtp.office365.com)

• SMTPPORT: Der Port für die SMTP-Verbindung (typischerweise 587 für OAuth)

• SMTPUSER: Wird bei OAuth-Authentifizierung nicht mehr benötigt

• SMTPPASSWORD: Wird bei OAuth-Authentifizierung nicht mehr benötigt

Wann sollten Sie diesen Wert ändern?

Wert setzen oder aktualisieren, wenn:

• OAuth-Authentifizierung für SMTP erstmalig eingerichtet wird

• Das Client Secret in Azure AD abgelaufen ist (spätestens nach 24 Monaten)

• Ein neues Client Secret generiert wurde (z.B. nach Sicherheitsvorfall)

• Die zugehörige Azure-Anwendung gewechselt wurde

• Microsoft-Sicherheitswarnungen auf kompromittiertes Secret hinweisen

• Beim Wechsel von Passwort-basierter zu OAuth-basierter Authentifizierung

Wert leer lassen, wenn:

• SMTPUSEOAUTH auf 0 steht und klassische Authentifizierung genutzt wird. Diese wird allerdings ab 2027 nicht mehr unterstützt

Wichtige Hinweise

1. Höchste Vertraulichkeitsstufe
   Das Client Secret ist ein hochsensibles Geheimnis. Behandle es wie ein Passwort und teile es niemals über unsichere Kanäle (E-Mail, Chat, etc.).

2. Verschlüsselte Speicherung erforderlich
   Stelle sicher, dass der Parameter in der Systemsteuerung mit aktiviertem "Kennwort"-Häkchen gespeichert wird. Nur so erfolgt die verschlüsselte Ablage in der Datenbank.

3. Ablaufdatum beachten
   Azure AD Client Secrets haben ein maximales Ablaufdatum von 24 Monaten. Plane die Erneuerung rechtzeitig ein und dokumentiere das Ablaufdatum in deinem Wartungsplan.

4. Nur Secret-Wert, nicht Secret-ID
   In Azure AD werden beim Erstellen eines Secrets zwei Werte angezeigt: Secret-ID und Secret-Wert. Verwende nur den Secret-Wert für diesen Parameter.

5. Einmalige Anzeige in Azure
   Azure AD zeigt den Secret-Wert nur einmal direkt nach der Erstellung an. Speichere ihn sofort sicher ab, z.B. in einem Passworttresor. Nach Verlassen der Seite kann der Wert nicht mehr eingesehen werden.

6. Rotation und mehrere Secrets
   Azure AD erlaubt mehrere aktive Secrets gleichzeitig. Bei Rotation kannst du ein neues Secret erstellen, in eTASK konfigurieren und testen, bevor du das alte Secret in Azure löschst.

7. Problembehandlung
   Bei Fehlermeldungen wie "MS Graph API Zugriffstoken konnte nicht abgerufen werden" prüfe:

   • Ist das Secret korrekt kopiert worden (ohne Leerzeichen am Anfang/Ende)?

   • Ist das Secret in Azure noch gültig (nicht abgelaufen)?

   • Stimmen Client ID und Tenant ID überein?

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter ist hochkritisch für die Sicherheit des Systems.

Positive Aspekte:

• Ersetzt Speicherung von Benutzer-Passwörtern durch App-Passwort

• Trennung von Benutzer-Identitäten und Service-Identitäten

• Regelmäßige Rotation möglich und empfohlen

• Zentrale Verwaltung in Azure AD mit Audit-Logs

• Bei Kompromittierung nur E-Mail-Versand betroffen, nicht Benutzerkonten

Zu beachten:

• Kritisches Geheimnis: Bei Kompromittierung kann Angreifer E-Mails im Namen der Organisation versenden

• Secret muss verschlüsselt gespeichert werden (Kennwort-Flag in Konfiguration)

• Zugriff auf die Datenbank-Backup-Dateien muss eingeschränkt werden

• Bei Sicherheitsvorfall muss Secret in Azure sofort widerrufen werden

• Regelmäßige Rotation (mindestens alle 12 Monate) erhöht Sicherheit

Compliance-Anforderungen:

• DSGVO: Secret-Handling muss in Verarbeitungsverzeichnis dokumentiert werden

• ISO 27001: Regelmäßige Rotation und sichere Speicherung erforderlich

• Audit-Anforderungen: Änderungen am Secret müssen protokolliert werden

Best Practices:

• Verwende ein dediziertes Secret nur für SMTP, nicht für andere Dienste

• Dokumentiere das Ablaufdatum in einem Wartungskalender

• Richte Azure AD-Alerts ein für ablaufende Secrets

• Teste neues Secret in Testumgebung vor Produktiveinsatz

• Speichere Backup-Secret in Passworttresor (offline, verschlüsselt)

Empfehlung: Implementiere einen 6-monatigen Rotationszyklus für Client Secrets. Bei kritischen Systemen erwäge den Einsatz von zertifikatbasierter Authentifizierung anstelle von Secrets (höhere Sicherheit, aber komplexere Verwaltung).

Praktisches Beispiel

Ausgangssituation:

Ein Unternehmen möchte die SMTP-Authentifizierung von Benutzername/Passwort auf moderne OAuth-Authentifizierung umstellen, um den Microsoft-Sicherheitsanforderungen zu entsprechen und Basic Authentication zu deaktivieren.

Konfiguration:

Schritt 1: Azure AD vorbereiten

1. In Azure AD unter App-Registrierungen → Zertifikate & Geheimnisse aufrufen

2. "Neues Clientgeheimnis" erstellen

3. Beschreibung eingeben: "eTASK SMTP OAuth"

4. Ablaufdatum wählen: 24 Monate

5. Secret-Wert sofort kopieren (wird nur einmal angezeigt!)

Schritt 2: eTASK konfigurieren

1. SMTPUSEOAUTH auf 1 setzen

2. SMTPAUTHCLIENTID auf Azure Client ID setzen

3. SMTPAUTHTENANTID auf Azure Tenant ID setzen

4. SMTPAUTHCLIENTSECRET auf Secret-Wert setzen (mit Kennwort-Flag!)

5. Ablaufdatum notieren: z.B. "03.04.2028"

Schritt 3: Testen

1. Test-E-Mail über Portal versenden

2. Applikationsprotokoll prüfen auf "MS Graph API Zugriffstoken" Meldungen

3. Bei Erfolg: Alte SMTPUSER/SMTPPASSWORD-Parameter leeren

Nach der Änderung:

• E-Mail-Versand läuft über OAuth ohne Benutzer-Passwörter

• Höhere Sicherheit durch App-basierte Authentifizierung

• Kompatibilität mit Microsoft-Sicherheitsrichtlinien (Basic Auth Deprecation)

• Audit-Trail in Azure AD für alle E-Mail-Versand-Aktivitäten

Ergebnis:

Moderne, sichere E-Mail-Authentifizierung gemäß Microsoft-Standards. Das System ist vorbereitet für die Deaktivierung von Basic Authentication in Microsoft 365.

Wartungsplan:

• Heute (03.04.2026): Secret erstellt und konfiguriert

• Oktober 2027 (18 Monate): Reminder für Secret-Rotation setzen

• Januar 2028 (22 Monate): Neues Secret erstellen und parallel aktivieren

• Februar 2028 (23 Monate): Altes Secret in Azure löschen

• März 2028 (24 Monate): Ablaufdatum des ursprünglichen Secrets

Empfohlene Einstellung

Für Standard-Installationen: Secret-Wert aus Azure AD (bei OAuth-Nutzung)

Begründung:

• Erforderlich für OAuth-basierte SMTP-Authentifizierung

• Microsoft empfiehlt OAuth statt Basic Authentication

• Höhere Sicherheit durch Token-basierte Authentifizierung

• Vorbereitung auf Deaktivierung von Basic Auth in Microsoft 365

Ausnahmen (Wert leer lassen):

• Zertifikat-basierte Authentifizierung wird verwendet (fortgeschritten)

• Klassische SMTP-Authentifizierung mit SMTPUSER/SMTPPASSWORD (veraltet)

• On-Premises Exchange Server ohne OAuth-Unterstützung

Rotation-Empfehlung:

• Standard-Umgebungen: Alle 12 Monate

• Hochsicherheits-Umgebungen: Alle 6 Monate

• Compliance-pflichtige Systeme: Gemäß Vorgaben (oft 3-6 Monate)

Tipp: Erstelle beim Einrichten gleich einen Kalendereintrag für die Secret-Rotation 2 Monate vor Ablauf. Verwende Azure AD-Alerts, um automatisch über bald ablaufende Secrets informiert zu werden. Dokumentiere das aktuelle Secret-Ablaufdatum im Systemhandbuch.