MIGRAZIONE · ADCS E NDES
Spegni l'ultimo server dei certificati.
ADCS sopravvive spesso per tre motivi: NDES per Intune, l'autoenrollment per i PC aggiunti al dominio e i certificati Kerberos dei domain controller. SCEPman copre tutti e tre dal tuo tenant Azure, così la CA, il web server CDP e il server NDES possono essere dismessi, un caso d'uso alla volta.
- Niente NDES
- Autoenrollment via Group Policy senza software client
- Certificati per i domain controller
- CA intermedia sotto la tua root esistente
CONFRONTO
Cosa serve per gestire ADCS, NDES e SCEPman
L'impegno richiesto da ciascuna opzione, come descritto nella nostra documentazione.
| Microsoft CA con connettore PKCS | NDES con SCEP | SCEPman | |
|---|---|---|---|
| Setup | 2 to 3 days and more: CRL distribution point, template, GPO, account di servizio, versioni del connettore | 2 more days and more: server NDES, uno per tipo di certificato, altri due template, difficile da diagnosticare | under 30 minutes per il servizio principale |
| Manutenzione | Monitoraggio CDP, monitoraggio del connettore, aggiornamenti del sistema operativo | Tutto quanto sopra, più il rinnovo manuale del certificato dell'enrollment agent | Health monitoring in Azure; l'App Service aggiorna la piattaforma |
| Revoca | Manuale; cercare nel database della CA è complesso | Manuale | Automatica da Entra ID, Intune e Jamf; manuale in Certificate Master |
| Disponibilità | Diversi punti di guasto: virtualizzazione, OS, web server CDP, connettore | Come sopra, più NDES | App Service, opzionalmente in due region dietro Traffic Manager |
| Scalabilità | Richiede un cluster CA, configurato manualmente | Server NDES duplicati | Autoscaling o pochi clic |
| Backup | Database CA, chiave CA e configurazione, con cadenza regolare | Come sopra | Il servizio principale è stateless; la chiave è nel Key Vault; backup dello storage opzionale |
| Superficie di attacco | Un server tier 0 comunica con internet attraverso il connettore | Accesso inbound a NDES, un asset tier 0 | Endpoint autenticati tramite Entra, Key Vault e Storage dietro private endpoint |
| MDM | Solo Intune | Diversi, ognuno con una propria istanza NDES | Intune, Jamf Pro e altri MDM |
ENTERPRISE EDITION · DAL 3.0
Certificati per Windows aggiunto al dominio senza ADCS
I client Windows nel tuo dominio sanno già come effettuare l'enrollment: la Group Policy li indirizza verso un servizio di enrollment, Kerberos ne verifica l'identità e l'autoenrollment fa il resto. L'endpoint Active Directory di SCEPman è esattamente quel servizio. Registri un service principal nel tuo AD, punti la Group Policy su SCEPman, e computer e utenti si iscrivono con gli strumenti già integrati in Windows. Niente da installare sui client.
- Template per user, computer, RDP server and domain controller, ognuno attivabile separatamente.
- I client rinnovano autonomamente quando rimane meno di 20% della validità.
- Limita l'enrollment ai membri dei gruppi AD che indichi.
- SCEPman aggiunge l'estensione SID, così i certificati soddisfano il strong mapping che i domain controller applicano dalla KB5014754.
KERBEROS
Certificati per i tuoi domain controller
I domain controller hanno bisogno di un certificato di autenticazione Kerberos affinché i dispositivi aggiunti a Entra ID e quelli in join ibrido possano accedere alle risorse on-premises; lo richiede anche Windows Hello for Business in modalità hybrid key trust. SCEPman lo emette tramite il template del domain controller dell'endpoint Active Directory, oppure tramite il suo endpoint DC dedicato. Il certificato include gli extended key usage Client Authentication, Server Authentication, Kerberos Authentication e Smart Card Logon.
COESISTENZA
Aggiungi SCEPman come CA intermedia sotto la tua root
Non devi sostituire la tua root dal primo giorno. In Enterprise Edition, SCEPman può operare come CA intermedia: la tua root esistente firma il certificato CA di SCEPman, che rimane nel tuo Key Vault. I dispositivi che si fidano della tua root si fidano subito dei certificati di SCEPman, e puoi spostare i casi d'uso uno alla volta mentre ADCS continua a emettere gli altri.
Un percorso di migrazione in cinque passi
Pianifica l'ordine con il tuo team di rete: i server RADIUS e i gateway VPN devono fidarsi della nuova root prima che il primo dispositivo presenti un certificato SCEPman.
- Scegli la rootScegli la rootUna nuova root SCEPman, distribuita tramite MDM e Group Policy, oppure SCEPman come CA intermedia sotto la tua root attuale.
- Aggiungi un profilo SCEPAggiungi un profilo SCEPCrea un nuovo profilo SCEP nel tuo MDM che punta a SCEPman, affiancato a quello esistente; rimuovi il profilo NDES una volta che i dispositivi hanno ricevuto i nuovi certificati.
- Sposta WindowsSposta WindowsAbilita l'endpoint Active Directory e punta la policy di autoenrollment su di esso, template per template.
- Sposta i serverSposta i serverI certificati server tramite Certificate Master, EST o l'API; i domain controller tramite il loro template.
- Dismetti ADCSDismetti ADCSRevoca ciò che rimane, pubblica un ultimo CRL e dismetti la CA, il CDP e NDES.
Domande sull'abbandono di ADCS
01SCEPman e ADCS possono coesistere?
Sì. Sono CA separate; i dispositivi possono avere certificati di entrambe durante la migrazione.
02È necessaria la Enterprise Edition?
Per l'endpoint Active Directory, i certificati dei domain controller, Certificate Master e la CA intermedia, sì.
03E i certificati per gli utenti che non usano mai il tuo MDM?
Gli utenti aggiunti al dominio li ottengono tramite l'endpoint Active Directory; tutti gli altri tramite Certificate Master o l'enrollment self-service.
04SCEPman deve trovarsi nella nostra rete?
No. I client lo raggiungono tramite HTTPS; l'endpoint Active Directory li autentica con Kerberos attraverso il service principal che registri.
Pianifica il passaggio da ADCS.
Inizia dal tuo MDM e da NDES, la parte più critica, e mantieni ADCS finché non è stato migrato l'ultimo template.