Gestion des journaux

Activer la journalisation vers Azure Monitor

Depuis la version 3.0, SCEPman, ainsi que le Certificate Master, utiliseront l’API d’ingestion de journaux de Microsoft pour écrire des journaux dans Azure Monitor. Cela utilise le concept d’un espace de travail Log Analytics pour contenir les données et permettre leur analyse ainsi qu’une règle de collecte de données qui fait l’interface entre le service d’application et le stockage des journaux. Cela permet une approche plus moderne incluant des autorisations basées sur RBAC pour que SCEPman accède au LAW.

La création de l’espace de travail Log Analytics ainsi que la configuration de la règle de collecte de données sont effectuées automatiquement en exécutant Complete-SCEPmanInstallation du module PowerShell SCEPman.

Le la durée de rétention par défaut pour les données stockées dans une table Log Analytics est de afin que nous puissions vous fournir un devis ou un lien de commande qui permette les paiements sur facture. Le délai de paiement est de. Si une période de rétention différente est requise, ajustez la configuration de la table "SCEPman_CL" en conséquence.

Réactivation de l’API Data Collector

Si, pour une raison quelconque, vous souhaitez rétablir l’API précédente à utiliser, vous pouvez le faire en supprimant les variables du service d’application liées à l’ingestion de journaux et en ajoutant à nouveau celles à utiliser par l’API Data Collector.

Variables à supprimer:

• AppConfig:LoggingConfig:DataCollectionEndpointUri

• AppConfig:LoggingConfig:RuleId

Variables à ajouter :

• AppConfig:LoggingConfig:WorkspaceId

• AppConfig:LoggingConfig:SharedKey

SCEPman prendra automatiquement en compte les paramètres après un redémarrage et utilisera de nouveau l’API Data Collector.

Exemples de requêtes KQL

Voir les problèmes avec votre instance SCEPman

SCEPman_CL
| where Level == "Warn" or Level == "Error" or Level == "Fatal"

Nombre de certificats émis par point de terminaison dans la période sélectionnée

Cette requête est garantie de fonctionner avec SCEPman 3.0 et versions ultérieures lorsqu’on utilise l’API d’ingestion de journaux pour la journalisation. Les modifications apportées à SCEPman rendant cette requête inutilisable seront considérées comme des changements incompatibles (Breaking Changes).

SCEPman_CL
| where Level == "Info" and Message startswith_cs "Issued a certificate with serial number"
| project Message, RequestBase = trim_end('/', replace_string(replace_string(replace_regex(RequestUrl_s, "(/pkiclient\\.exe)?(\\?operation=PKIOperation(&message=.+)?)?", ""),"certsrv/mscep/mscep.dll","intune"),"step/enrollment","activedirectory"))
| summarize IssuanceCount = count() by Endpoint = extract("/([a-zA-Z]+)$", 1, RequestBase)

Si vous utilisez l’ancienne API d’ingestion de journaux, utilisez cette requête légèrement adaptée :

SCEPman_CL
| where Level == "Info" and Message startswith_cs "Issued a certificate with serial number"
| project Message, RequestBase = trim_end('/', replace_string(replace_string(replace_regex(RequestUrl, "(/pkiclient\\.exe)?(\\?operation=PKIOperation(&message=.+)?)?", ""),"certsrv/mscep/mscep.dll","intune"),"step/enrollment","activedirectory"))
| summarize IssuanceCount = count() by Endpoint = extract("/([a-zA-Z]+)$", 1, RequestBase)

À partir de SCEPman 2.8, il existe toujours exactement une entrée de journal de niveau Info dont le message commence par "Issued a certificate with serial number " par certificat émis, suivie de son numéro de série. Toutefois, en raison du problème des deux armées, il peut arriver que le certificat créé n’atteigne jamais le demandeur ou qu’un autre type d’erreur empêche l’enrôlement effectif. De même, en cas d’erreurs graves, il peut arriver qu’une entrée de journal existe sans entrée correspondante dans la base de données ou vice versa.

Certificats distincts avec vérification OCSP

let map_certtype = datatable(serial_start:string, readable:string)
[
  "40", "Appareil Intune",
  "41", "Appareil Intune",
  "42", "Appareil Intune non conforme",
  "50", "Statique",
  "51", "Statique",
  "60", "Utilisateur Intune",
  "61", "Utilisateur Intune",
  "64", "Utilisateur Jamf",
  "65", "Utilisateur Jamf",
  "6C", "Utilisateur Jamf sur appareil",
  "6D", "Utilisateur Jamf sur appareil",
  "70", "Contrôleur de domaine",
  "7C", "Utilisateur Jamf sur ordinateur",
  "7D", "Utilisateur Jamf sur ordinateur",
  "54", "Ordinateur Jamf",
  "55", "Ordinateur Jamf",
  "44", "Appareil Jamf",
  "45", "Appareil Jamf"
];
SCEPman_CL
| where LogCategory == "Scepman.Server.Controllers.OcspController" and Level == "Info"
| where Message startswith_cs "OCSP Response"
| project serial = extract("Serial Number ([A-F0-9]+)", 1, Message)
| distinct serial
| extend serial_start = substring(serial,0,2)
| join kind=leftouter map_certtype on serial_start
| summarize count() by (readable)

Si vous utilisez encore l’API Data Collector, utilisez plutôt cette requête :

let map_certtype = datatable(serial_start:string, readable:string)
[
  "40", "Appareil Intune",
  "41", "Appareil Intune",
  "42", "Appareil Intune non conforme",
  "50", "Statique",
  "51", "Statique",
  "60", "Utilisateur Intune",
  "61", "Utilisateur Intune",
  "64", "Utilisateur Jamf",
  "65", "Utilisateur Jamf",
  "6C", "Utilisateur Jamf sur appareil",
  "6D", "Utilisateur Jamf sur appareil",
  "70", "Contrôleur de domaine",
  "7C", "Utilisateur Jamf sur ordinateur",
  "7D", "Utilisateur Jamf sur ordinateur",
  "54", "Ordinateur Jamf",
  "55", "Ordinateur Jamf",
  "44", "Appareil Jamf",
  "45", "Appareil Jamf"
];
SCEPman_CL
| where LogCategory_s == "Scepman.Server.Controllers.OcspController" and Level == "Info"
| where Message startswith_cs "OCSP Response"
| project serial = extract("Serial Number ([A-F0-9]+)", 1, Message)
| distinct serial
| extend serial_start = substring(serial,0,2)
| join kind=leftouter map_certtype on serial_start
| summarize count() by (readable)