Nicht verwalteter Linux-Client
Gilt für SCEPman Version 2.9 und höher
nur SCEPman Enterprise Edition
Diese Methode kann verwendet werden, um Zertifikate für Benutzer und Geräte auszustellen, die nicht verwaltet werden oder von einem anderen MDM als Intune verwaltet werden.
Voraussetzungen
1. Self-Service-Enrollment
Um Zertifikate zu registrieren, müssen Benutzer authentifiziert sein, um ihre Berechtigung zu überprüfen. Folgen Sie dieser Anleitung für eine schrittweise Anleitung, wie Sie dies einrichten
2. App Service-Einstellungen
Konfiguration
Erforderlich für die Zertifikatserneuerung
Konfigurieren Sie Ihren SCEPman App Service so, dass mTLS-Clientzertifikate akzeptiert werden. Überprüfen Sie in der Konfigurationsseite des Abschnitts Einstellungen, ob der Clientzertifikatmodus unter Eingehende Clientzertifikate auf Optionaler interaktiver Benutzer.
Setzen Sie den Clientzertifikatmodus nicht auf Erfordern oder Zulassen, da dies den normalen Betrieb von SCEPman an den SCEP-Endpunkten unterbrechen würde!
Environment Variables
Um dieses Szenario nutzen zu können, müssen Sie die folgenden Umgebungsvariablen für den SCEPman App Service festlegen.
Erforderlich für die Zertifikatsregistrierung und -erneuerung
Setzen Sie diese Variable auf true um die Validierung von Zertifikatsignierungsanforderungen (CSRs) zu aktivieren.
Erforderlich für die Zertifikatserneuerung
Setzen Sie diese Variable auf true um Zertifikatserneuerungen zu aktivieren.
Erforderlich für die Zertifikatserneuerung
Setzen Sie diese Variable auf eine durch Kommas getrennte Liste von Zertifikatstypen, für die Sie die Erneuerung zulassen möchten. Eine Liste der möglichen Zertifikatstypen finden Sie in der verlinkten Variablendokumentation.
Beispiel: Static,IntuneUser,IntuneDevice
Dieses Szenario stellt Zertifikate des Typs aus IntuneUser.
PowerShell-Modul SCEPmanClient
Erstanforderungen
Sie können das PowerShell-Modul SCEPmanClient verwenden, um Zertifikate auf Ihrem Linux-Gerät anzufordern:
Der Benutzer muss sich dann in einer Browser-Sitzung interaktiv anmelden, und es wird ein Zertifikat für sein angemeldetes Konto erstellt.
Zertifikatserneuerung
Sie können das PowerShell-Modul auch verwenden, um bereits vorhandene Zertifikate zu erneuern. Dadurch entfällt auch die Notwendigkeit, für die Authentifizierung einen Service Principal zu verwenden:
Skript für Enrollment und Erneuerung
Wenn das PowerShell-Modul für Sie keine Option ist, kann das enrollrenewcertificate.sh Skript verwendet werden, um zunächst ein Zertifikat zu erhalten sowie es zu überprüfen und bei bevorstehendem Ablauf eine Erneuerung zu versuchen.
Client-Voraussetzungen
Die folgenden Voraussetzungen müssen auf dem ausführenden Client/Host vorhanden sein, um die Enrollment REST API nutzen zu können.
Azure CLI (Version 2.61 und höher)
Die Azure CLI wird verwendet, um den sich anmeldenden Benutzer zu authentifizieren, seine Berechtigung zu prüfen und das Zugriffstoken abzurufen.
cURL
Wird verwendet, um das erstellte CSR an den SCEPman Enrollment API-Endpunkt zu senden und das Zertifikat zu empfangen.
OpenSSL
OpenSSL wird verwendet, um einen privaten Schlüssel zu generieren und ein CSR für die Anmeldung oder Erneuerung eines Zertifikats zu erstellen.
Beispiel:
1. Befehl
Definiert das Verhalten des Skripts
Kann einer der folgenden Werte sein:
-u für Benutzerzertifikat mit automatischer Erkennung, ob es sich um ein erstmaliges Enrollment oder eine Erneuerung handelt
-d für Gerätezertifikat mit automatischer Erkennung, ob es sich um ein erstmaliges Enrollment oder eine Erneuerung handelt
-r für Erneuerung
-w für erstmaliges Enrollment eines Benutzers
-x für erstmaliges Enrollment eines Geräts
Wenn Sie ein Gerätezertifikat enrollen oder erneuern, wird standardmäßig versucht, die DeviceId aus ~/.config/intune/registration.toml zu lesen, und der authentifizierte Benutzer muss mit dem Besitzer des Objekts im konfigurierten DeviceDirectory
2. App-Service-URL
Die URL des SCEPman-App-Services.
Beispiel: "https://scepman.contoso.net/"
3. API_SCOPE
Dies ist der API-Bereich, den Sie in der SCEPman-api App-Registrierung in Ihrer Umgebung erstellen können.
Dem Benutzer wird Ihr gewünschter Zustimmungsdialog angezeigt, und er kann danach die Self-Service-Funktionalität verwenden.
Beispiel: "api://b7d17d51-8b6d-45eb-b42b-3dae638cd5bc/Cert.Enroll"
4. Zertifikatsverzeichnis
Das Verzeichnis, in dem das Zertifikat erstellt oder die Erneuerung versucht wird.
Beispiel: ~/certs/
5. Zertifikatsdateiname
Der Dateiname (ohne Erweiterung) des Zertifikats, das erstellt oder zur Erneuerung gelesen wird.
Beispiel: "myCertificate"
6. Dateiname des privaten Schlüssels
Der Dateiname des privaten Schlüssels, der erstellt oder zur Erneuerung gelesen wird.
Beispiel: "myKey"
7. Erneuerungsschwelle
Die Anzahl der Tage, die das Zertifikat noch gültig sein muss, damit das Skript den Erneuerungsprozess startet.
Beispiel: 30
Hinweise
Dieses Skript verschlüsselt die erzeugten Schlüssel nicht (dafür ist eine Passphrase-Eingabe erforderlich, daher wurde auf die Verschlüsselung verzichtet, um eine automatische Erneuerung zu ermöglichen.)
Wenn Sie mit einer Passphrase geschützte Zertifikate von Certificate Master erneuern, müssen Sie diese Passphrase eingeben, um sie zu erneuern.
Automatische Erneuerung einrichten
Wenn das obige Bash-Skript ausgeführt wird und erkennt, dass bereits ein Zertifikat enrollt wurde, erneuert es das Zertifikat (wenn es kurz vor dem Ablauf steht) mithilfe von mTLS. Wenn das Skript regelmäßig ausgeführt wird, wird sichergestellt, dass das Zertifikat erneuert wird, wenn es kurz vor dem Ablauf steht. Sie können dazu einen Cronjob einrichten. Der folgende Befehl ist ein Beispiel dafür, wie dies erfolgen könnte. Er richtet einen Cronjob ein, der den Befehl täglich ausführt (wenn das System eingeschaltet ist) sowie einen Cronjob, der den Befehl beim Neustart ausführt.
Da von Cron ausgeführte Befehle nicht unbedingt aus dem Verzeichnis ausgeführt werden, in dem sich das Skript/die Zertifikate befinden, ist es wichtig, die absoluten Pfade zu dem Skript/den Zertifikaten anzugeben.
Zuletzt aktualisiert
War das hilfreich?