Nicht verwalteter Linux-Client

circle-info

Gilt für SCEPman Version 2.9 und höher

circle-exclamation

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

2. App Service-Einstellungen

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:

New-SCEPmanCertificate -Url 'scepman.contoso.com' -SubjectFromUserContext -SaveToFolder '~/certs/'

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.sharrow-up-right 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

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

circle-exclamation

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?