Zum Hauptinhalt springen
Deutsch
|
English

SMTPAUTHCLIENTID - Detailbeschreibung

Administration

IC12568
Administration

Überblick

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

Was macht dieser Parameter?

Der Parameter legt die Azure Client ID (Anwendungs-ID) fest, die speziell für die OAuth-Authentifizierung beim E-Mail-Versand über SMTP verwendet wird. Diese ID identifiziert die registrierte Anwendung in Azure Active Directory, über die der E-Mail-Versand authentifiziert werden soll.

Wofür wird dieser Parameter verwendet?

  • Authentifizierung beim E-Mail-Versand über Microsoft 365 / Azure AD

  • Trennung der SMTP-Authentifizierung von der Login-Authentifizierung

  • Verwendung unterschiedlicher Azure-Anwendungen für Login und E-Mail-Versand

  • Dedizierte Service-Identität für den E-Mail-Versand mit spezifischen Berechtigungen

Technische Details (für Administratoren)

Format: GUID (Globally Unique Identifier)
Standardwert: string.Empty (leer)

Gültige Werte:

  • GUID = Eine spezifische Azure Client ID für SMTP (Format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

Wichtige Hinweise:

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

  • Die Client ID findest du in Microsoft Azure in der App-Registrierung unter Übersicht als "Anwendungs-ID (Client)"

  • Bei leerem Wert wird auf den Wert von AZURECLIENTID zurückgegriffen

  • Die zugehörige Anwendung muss in Azure AD mit den Berechtigungen "Mail.Send" registriert sein

Zusammenspiel mit anderen Parametern:

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

  • SMTPAUTHTENANTID: Definiert die zugehörige Tenant ID für die SMTP-Authentifizierung

  • AZURETENANTID: Fallback für die Tenant ID

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

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

Wann sollten Sie diesen Wert ändern?

Wert auf eine spezifische GUID setzen, wenn:

  • Eine dedizierte Azure-Anwendung nur für E-Mail-Versand verwendet werden soll

  • Der E-Mail-Versand mit anderen API-Berechtigungen laufen soll als der Portal-Login

  • Mehrere Azure-Anwendungen mit unterschiedlichen Berechtigungen im Einsatz sind

  • Compliance-Anforderungen eine strikte Trennung der Identitäten vorschreiben

  • Audit-Trails für E-Mail-Versand und Login getrennt geführt werden sollen

Wichtige Hinweise

  1. Azure AD App-Registrierung erforderlich
    Die Client ID muss zu einer in Azure AD registrierten Anwendung gehören. Diese Anwendung benötigt die API-Berechtigung "Microsoft Graph: Mail.Send" (Application Permission oder Delegated Permission).

  2. Zusammenspiel mit Tenant ID
    Die Client ID muss zur gleichen Tenant ID gehören, die in SMTPAUTHTENANTID (oder AZURETENANTID als Fallback) konfiguriert ist. Eine falsche Kombination führt zu Authentifizierungsfehlern.

  3. Modern Authentication erforderlich
    Der Parameter funktioniert nur, wenn SMTPUSEOAUTH auf 1 gesetzt ist. Andernfalls wird die klassische Passwort-basierte Authentifizierung verwendet.

  4. Berechtigungstypen in Azure AD
    Für automatisierten E-Mail-Versand (ohne Benutzerkontext) sollte "Application Permission" verwendet werden. Für Benutzer-bezogenen Versand reicht "Delegated Permission".

  5. Problembehandlung
    Bei Fehlermeldungen wie "AZURECLIENTID oder AZURETENANTID nicht konfiguriert" prüfe, ob bei leerem SMTPAUTHCLIENTID ein gültiger Wert in AZURECLIENTID vorhanden ist.

  6. Sicherheit der Client ID
    Die Client ID ist öffentlich und nicht geheim. Das zugehörige Client Secret (falls verwendet) muss jedoch vertraulich behandelt werden.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter hat erhebliche Sicherheitsauswirkungen.

Positive Aspekte:

  • Ermöglicht Prinzip der minimalen Rechte durch dedizierte Service-Identität

  • Trennung von Login- und E-Mail-Berechtigungen erhöht die Sicherheit

  • OAuth-basierte Authentifizierung ist sicherer als Passwort-basierte Methoden

  • Bessere Nachvollziehbarkeit durch getrennte Audit-Logs in Azure AD

  • Bei Kompromittierung nur E-Mail-Versand betroffen, nicht der gesamte Login

Zu beachten:

  • Die Client ID muss korrekt konfiguriert sein, sonst schlägt der E-Mail-Versand fehl

  • Die zugehörige App-Registrierung muss mit korrekten Berechtigungen konfiguriert sein

  • Bei Änderungen kann der E-Mail-Versand unterbrochen werden

  • Die Kombination aus Client ID und Tenant ID muss in Azure AD existieren

Datenschutzrechtliche Bewertung:

  • Client ID selbst enthält keine personenbezogenen Daten

  • Zugehörige Logs in Azure AD können jedoch Absender- und Empfängerinformationen enthalten

  • Separate Service-Identität kann DSGVO-Compliance erleichtern (Zweckbindung)

Empfehlung: Verwende eine dedizierte Client ID für SMTP, wenn du unterschiedliche Berechtigungsstufen für Login und E-Mail-Versand benötigst. Dies folgt dem Prinzip der minimalen Rechte und erhöht die Gesamtsicherheit des Systems.

Praktisches Beispiel

Ausgangssituation:

Ein Unternehmen möchte den E-Mail-Versand über eine dedizierte Azure-Anwendung mit eingeschränkten Berechtigungen durchführen. Die Login-Anwendung hat erweiterte Berechtigungen wie Calendar.ReadWrite, während die E-Mail-Anwendung nur Mail.Send benötigt.

Konfiguration:

  1. Zwei App-Registrierungen in Azure AD erstellt:

    • Login-App: Client ID a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6 (mit Calendar.ReadWrite, Mail.Send, User.Read)

    • SMTP-App: Client ID x9y8z7w6-v5u4-t3s2-r1q0-p9o8n7m6l5k4 (nur mit Mail.Send)

  2. SMTPUSEOAUTH auf 1 gesetzt

  3. SMTPAUTHCLIENTID gesetzt auf: x9y8z7w6-v5u4-t3s2-r1q0-p9o8n7m6l5k4

  4. SMTPAUTHTENANTID gesetzt auf: z9y8x7w6-v5u4-t3s2-r1q0-p9o8n7m6l5k4

  5. AZURECLIENTID bleibt auf: a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6 (für Login)

Nach der Änderung:

  • Login verwendet weiterhin die ursprüngliche App mit allen Berechtigungen

  • E-Mail-Versand verwendet die neue App mit nur Mail.Send-Berechtigung

  • Geringeres Risiko bei Kompromittierung der E-Mail-Credentials

  • Klarere Trennung der Funktionen in Azure AD Audit-Logs

Ergebnis:

Höhere Sicherheit durch Prinzip der minimalen Rechte. Bei einem hypothetischen Sicherheitsvorfall mit der SMTP-Identität sind nur E-Mail-Funktionen betroffen, nicht Kalender- oder Benutzerverwaltungsfunktionen.

Alternative Szenarien:

Szenario A - Multi-Tenant-Umgebung:

  • Hauptmandant mit Tenant ID abc... und Client ID 123...

  • E-Mail wird über separaten Service-Tenant gesendet mit eigener Client ID

  • SMTPAUTHCLIENTID und SMTPAUTHTENANTID verweisen auf Service-Tenant

Szenario B - Staging- und Produktionsumgebung:

  • Produktions-App-Registrierung mit Client ID prod-guid...

  • Test-App-Registrierung mit Client ID test-guid...

  • Parameter ermöglicht einfaches Umschalten zwischen Umgebungen

Empfohlene Einstellung

Für Standard-Installationen: leer (Fallback auf AZURECLIENTID verwenden)

Begründung:

  • Vereinfacht die Konfiguration bei nur einer Azure-Anwendung

  • Reduziert Verwaltungsaufwand (nur eine App-Registrierung pflegen)

  • Ausreichend für die meisten Anwendungsfälle

  • Schnellere Einrichtung und weniger Fehlerquellen

Ausnahmen (Separate Client ID für SMTP konfigurieren):

  • Sicherheitsrichtlinien verlangen Prinzip der minimalen Rechte

  • E-Mail-Versand über separaten Service-Tenant

  • Unterschiedliche Berechtigungsstufen für Login und E-Mail erforderlich

  • Getrennte Audit-Trails für Compliance-Anforderungen nötig

Tipp: Wenn du separate Client IDs verwendest, dokumentiere beide App-Registrierungen mit ihren jeweiligen Berechtigungen in deinem Systemhandbuch. Stelle sicher, dass bei App-Updates oder Zertifikatserneuerungen beide Anwendungen aktualisiert werden.

War dieser Artikel hilfreich?