Dieser Artikel wurde automatisch übersetzt. Die Übersetzung kann Ungenauigkeiten enthalten.
Zur englischen Originalversion wechseln.
Ctrlk
linkedinx-twitter
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Windows

Stellen Sie Zertifikate über SCEP in Intune mithilfe von SCEPman auf Windows-Geräten bereit.

Der folgende Artikel beschreibt die Bereitstellung von Geräte- oder/und Benutzerzertifikaten für Windows-Geräte. Die Bereitstellung des SCEPman-Root-Zertifikats ist obligatorisch. Danach können Sie wählen, ob Sie nur Geräte-, nur Benutzer- oder sogar beide Zertifikatstypen bereitstellen möchten.

Root-Zertifikat

Die Grundlage für die Bereitstellung von SCEP-Zertifikaten ist, dem Root-Zertifikat von SCEPman zu vertrauen. Daher müssen Sie das CA-Root-Zertifikat herunterladen und es als Vertrauenswürdiges Zertifikat Profil über Microsoft Intune:

Beachten Sie, dass Sie für die Zuweisung des vertrauenswürdigen Zertifikats und des SCEP-Profils dieselbe Gruppe verwenden müssen. Andernfalls kann die Intune-Bereitstellung fehlschlagen.

Gerätezertifikate

Zertifikatstyp: Gerät

In diesem Fall richten wir ein Gerätezertifikat ein

Format des Subject-Namens: CN={{DeviceName}} oder CN={{DeviceId}} oder CN={{AAD_Device_ID}}

Empfohlen: Verwenden Sie {{DeviceName}}für das CN-RDN, damit das Zertifikat auf dem Gerät oder bei der Zertifikatsuche einen aussagekräftigen Namen hat.

Optional: Falls konfiguriert auf CN={{DeviceId}} oder CN={{AAD_Device_ID}}verwendet SCEPman das CN-Feld des Subject-Namens zur Identifizierung des Geräts und als Ausgangswert für die Generierung der Zertifikatsseriennummer. Microsoft Entra ID (Azure AD) und Intune bieten zwei verschiedene IDs an:

  • {{DeviceId}}: Diese ID wird von Intune generiert und verwendet. (erfordert AppConfig:IntuneValidation:DeviceDirectory auf Intune oder AADAndIntune)

  • {{AAD_Device_ID}}: Diese ID wird von Microsoft Entra ID (Azure AD) generiert und verwendet.

Falls weder CN={{DeviceId}} noch CN={{AAD_Device_ID}} für das CN-Feld verwendet wird (z. B. CN={{DeviceName}}), identifiziert SCEPman das Gerät anhand der Intune-Geräte-ID ((URI)-Wert: IntuneDeviceId://{{DeviceId}}) bereitgestellt im Subject Alternative Name (SAN).

Sie können diese Variablen und statischen Text im Textfeld angeben. Der Common Name für ein Gerät mit dem Namen Device1 kann hinzugefügt werden als CN={{DeviceName}}YourDomain.com

Wichtig: Die Wahl des CN-Feldes beeinflusst das automatische Widerrufsverhalten von Zertifikaten, die für Ihre von Intune verwalteten Geräte ausgestellt wurden.

Sie können bei Bedarf weitere RDNs hinzufügen (z. B.: CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}). Unterstützte Variablen sind in den Microsoft-Dokumentation.

Alternativer Betreffname: (URI)Wert: IntuneDeviceId://{{DeviceId}}

Das URI-Feld wird von Microsoft empfohlen um NAC-Lösungen zu ermöglichen, die Geräte anhand ihrer Intune Device ID zu identifizieren. Der Wert sollte sein:

Das URI-Feld ist obligatorisch falls weder CN={{DeviceId}} noch CN={{AAD_Device_ID}} im Format des Subject-Namens verwendet wird.

Andere SAN-Werte wie DNS können bei Bedarf hinzugefügt werden.

Gültigkeitsdauer des Zertifikats: 1 Jahr

Die verbleibende Zeit, bevor das Zertifikat abläuft. Standardmäßig auf ein Jahr festgelegt.

SCEPman begrenzt die Gültigkeit des Zertifikats auf das konfigurierte Maximum in der Einstellung AppConfig:ValidityPeriodDays, verwendet ansonsten aber die im Antrag konfigurierte Gültigkeit.

Anbieter für den Schlüsselspeicher (KSP): Im Trusted Platform Module (TPM) KSP registrieren, andernfalls fehlschlagen

Diese Einstellung bestimmt den Speicherort des privaten Schlüssels für die Zertifikate der Endbenutzer. Die Speicherung im TPM ist sicherer als die softwarebasierte Speicherung, da das TPM eine zusätzliche Sicherheitsebene bietet, um den Diebstahl von Schlüsseln zu verhindern.

Hinweis: Es gibt einen Fehler in einigen älteren TPM-Firmwareversionen der einige mit einem TPM-gestützten privaten Schlüssel erstellte Signaturen ungültig macht. In solchen Fällen kann das Zertifikat nicht für die EAP-Authentifizierung verwendet werden, wie sie für WLAN- und VPN-Verbindungen üblich ist. Außerdem kann dies Ihren Autopilot-Onboarding-Prozess beeinträchtigen.

Betroffene TPM-Firmwareversionen sind unter anderem:

  • STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100, 73.20.17568.6684

  • Intel: 11.8.50.3399, 2.0.0.2060

  • Infineon: 7.63.3353.0

  • IFX: Version 3.19 / Spezifikation 1.2

  • IFX-Version 7.63.3353.0 Spezifikation 2.0

Wenn Sie TPM mit dieser Firmware verwenden, aktualisieren Sie entweder Ihre Firmware auf eine neuere Version oder wählen Sie "Software KSP" als Anbieter für den Schlüsselspeicher aus.

Aktualisierung: Sie können den TPM-Fehler umgehen, indem Sie die RSA-PSS-Signaturalgorithmen, die das Problem verursachen, aus der Registrierung entfernen. Weitere Informationen finden Sie in Richard Hicks' Artikel und Microsoft Q&A

Schlüsselverwendung: Digitale Signatur und Schlüsselverschlüsselung

Bitte aktivieren Sie beide kryptografischen Aktionen.

SCEPman setzt die Schlüsselverwendung automatisch auf Digitale Signatur und Schlüsselverschlüsselung und überschreibt die Einstellung hier, sofern die Einstellung AppConfig:UseRequestedKeyUsages auf true.

Schlüsselgröße (Bits): 2048

SCEPman unterstützt 2048 Bit.

Hash-Algorithmus: SHA-2

SCEPman unterstützt den SHA-2-Algorithmus.

Root-Zertifikat: Profil aus dem vorherigen Schritt (Root-Zertifikat-Profil)

Bitte wählen Sie das Intune-Profil aus #Root-Zertifikat. Wenn Sie eine Zwischenzertifizierungsstelleverwenden, müssen Sie das Profil für das vertrauenswürdige Zertifikat für die Zwischenzertifizierungsstelle auswählen, nicht das Root-CA-Profil!

Erweiterte Schlüsselverwendung: Client Authentication, 1.3.6.1.5.5.7.3.2

Bitte wählen Sie Client Authentication (1.3.6.1.5.5.7.3.2) unter Vordefinierte Werte. Die anderen Felder werden automatisch ausgefüllt.

Erneuerungsschwelle (%): 20

Dieser Wert definiert, wann das Gerät sein Zertifikat erneuern darf (basierend auf der verbleibenden Laufzeit eines vorhandenen Zertifikats). Bitte lesen Sie den Hinweis unter Gültigkeitsdauer des Zertifikats und wählen Sie einen geeigneten Wert aus, der dem Gerät erlaubt, das Zertifikat über einen langen Zeitraum zu erneuern. Ein Wert von 20 % würde es einem Gerät mit einem 1 Jahr gültigen Zertifikat ermöglichen, 73 Tage vor Ablauf mit der Erneuerung zu beginnen.

SCEP-Server-URLs: Öffnen Sie das SCEPman-Portal und kopieren Sie die URL von Intune MDM

Beispiel

Beispiel

Benutzerzertifikate

Bitte folgen Sie den Anweisungen unter #Gerätezertifikate und beachten Sie die folgenden Unterschiede:

Zertifikatstyp: Benutzer

In diesem Abschnitt richten wir ein Benutzerzertifikat ein.

Format des Subject-Namens: CN={{UserName}},E={{EmailAddress}}

Sie können RDNs nach Bedarf definieren. Unterstützte Variablen sind in der Microsoft-Dokumentation. Wir empfehlen, den Benutzernamen (z. B.: janedoe) und die E-Mail-Adresse (z. B.: janedoe@contoso.com) als Grundeinstellung einzubeziehen.

Alternativer Betreffname: (UPN)Wert: {{UserPrincipalName}}

Sie müssen den Benutzerprinzipalnamen als alternativen Betreffnamen hinzufügen. Fügen Sie '{{UserPrincipalName}}' als alternativen Betreffnamen vom Typ Benutzerprinzipalname (UPN) hinzu. Dadurch kann SCEPman Zertifikate mit Benutzerobjekten in AAD verknüpfen. Die Einstellung für 'Format des Subject-Namens' ist frei wählbar.

Andere SAN-Werte wie eine E-Mail-Adresse können bei Bedarf hinzugefügt werden.

Basierend auf Kundenfeedback scheint es, dass einige VPN-Clients (z. B. Azure VPN Client für Virtual WAN) das Benutzerzertifikat nicht finden können, wenn es im TPM gespeichert ist. Versuchen Sie stattdessen, es im Software-KSP zu registrieren.

Beispiel

Benutzerzertifikat für digitale Signaturen

Sie können SCEPman für transnationale digitale Signaturen verwenden, d. h. für S/MIME-Signaturen in Microsoft Outlook. Wenn Sie die Zertifikate für das Signieren von Nachrichten verwenden möchten, müssen Sie die entsprechenden erweiterten Schlüsselverwendungen in der Intune-Profilkonfiguration hinzufügen.

Verwenden Sie SCEPman nicht für E-Mail-Verschlüsselung d. h. für S/MIME-E-Mail-Verschlüsselung in Microsoft Outlook (ohne separate Technologie für die Schlüsselverwaltung). Die Natur von des SCEP-Protokolls umfasst keinen Mechanismus zum Sichern oder Archivieren privater Schlüsselmaterialien. Wenn Sie SCEP für E-Mail-Verschlüsselung verwenden würden, könnten Sie die Schlüssel zum späteren Entschlüsseln der Nachrichten verlieren.

Um Benutzerzertifikate für digitale Signaturen bereitzustellen, folgen Sie bitte den Anweisungen unter #Benutzerzertifikate und beachten Sie die folgenden Unterschiede und Hinweise:

Alternativer Betreffname

  • (erforderlich) Benutzerprinzipalname (UPN): {{UserPrincipalName}}

  • (erforderlich) E-Mail-Adresse: {{EmailAddress}}

Bei der Bereitstellung eines Zertifikats für digitale Signaturen müssen Sie den UPN und die E-Mail-Adresse hinzufügen.

Schlüsselverwendung: nur Digitale Signatur

Erweiterte Schlüsselverwendung: Sichere E-Mail (1.3.6.1.5.5.7.3.4)

Bitte wählen Sie Sichere E-Mail (1.3.6.1.5.5.7.3.4) unter Vordefinierte Werte. Die anderen Felder werden automatisch ausgefüllt.

Erneuerungsschwelle (%): 50

Wir empfehlen, die Erneuerungsschwelle (%) so festzulegen, dass Zertifikate bei der Ausstellung von S/MIME-Signaturzertifikaten mindestens 6 Monate vor Ablauf erneuert werden. Dies liegt daran, dass in Outlook E-Mails mit abgelaufenen Zertifikaten als ungültig signiert angezeigt werden, was Benutzer verwirrt. Wenn lange vor Ablauf des alten Zertifikats ein neues Zertifikat vorhanden ist, betrifft dieses Verhalten nur ältere E-Mails, die Benutzer eher nicht mehr ansehen. Wenn Ihre Signaturzertifikate zum Beispiel ein Jahr gültig sind, sollten Sie die Erneuerungsschwelle auf mindestens 50 % setzen.

Beispiel

Nach einer erfolgreichen Profilsynchronisierung sollten Sie das Benutzerzertifikat unter Verwendungszwecke Sichere E-Mail

Das Zertifikat steht z. B. in Outlook für die Verwendung als digitale Signatur zur Verfügung. Unten sehen Sie ein Beispiel für die Verwendung

S/MIME-Signaturen in Outlook aktivieren

Nachdem Sie S/MIME-Signaturzertifikate auf Ihren Clientmaschinen bereitgestellt haben, müssen Sie Outlook so konfigurieren, dass diese Zertifikate vor dem Senden signierter E-Mails verwendet werden.

Neues Outlook

S/MIME für das neue Outlook kann manuell.

Klassisches Outlook

S/MIME für das klassische Outlook kann manuell oder schnell mit unserem PowerShell-Skript.

Outlook im Web

S/MIME für Outlook im Web kann manuell oder mit PowerShell über den folgenden Befehl aktiviert werden:

Weitere PowerShell-Befehle finden Sie hier.

Zuletzt aktualisiert

War das hilfreich?