Disattivare l'autenticazione Microsoft Entra in SCCM

Quando togliere Microsoft Entra da SCCM è una scelta di architettura, non un click

In SCCM, disattivare l’autenticazione Microsoft Entra non significa solo cambiare il metodo di login. Vuol dire ridefinire come gli amministratori accedono alla console, come vengono gestiti i ruoli, quali endpoint restano esposti e quale identità diventa la base operativa del sistema. Se il tenant Entra è stato usato per SSO, MFA o assegnazione dei permessi, la rimozione va trattata come un change controllato, non come una semplificazione “temporanea”.

La domanda giusta non è “si può spegnere?”, ma “quale stato voglio ottenere dopo il cambio?”. In pratica: accesso solo con account locali o AD on-prem, niente dipendenza dal tenant, nessun impatto su automazioni, e possibilità di tornare indietro senza rifare la configurazione da zero. Se questo obiettivo non è chiaro, il rischio è tagliare il ramo su cui sta seduto l’accesso amministrativo.

Prima di toccare SCCM: cosa verificare davvero

Il punto critico è capire dove Entra entra in gioco. In molte installazioni il tenant non è usato solo per la console, ma anche per applicazioni collegate, account di servizio, enrollment, Conditional Access o integrazioni con ruoli amministrativi. Se rimuovi l’autenticazione senza mappare questi legami, puoi trovarti con utenti esclusi dalla console o con un accesso parziale che sembra funzionare finché non serve un’operazione critica.

Controlla almeno questi elementi: quali account aprono la console, quali gruppi hanno privilegi amministrativi, se l’accesso passa da browser o da credenziali memorizzate, e se esistono policy che richiedono MFA o device compliant. In parallelo, identifica il piano di rollback: esporta o annota la configurazione attuale, conserva le credenziali alternative già testate e verifica che almeno un admin possa autenticarsi senza dipendere da Entra.

Se hai un dubbio su quale componente stia davvero usando Entra, chiudilo prima del cambio con una verifica operativa: apri la console SCCM con un account alternativo, controlla l’evento di autenticazione lato Windows e osserva eventuali redirect verso la pagina di login Microsoft. Se il comportamento cambia in base al contesto utente, non stai gestendo un semplice toggle ma una dipendenza di identity più ampia.

Impatto tecnico: cosa si rompe di solito

Il primo impatto è sugli accessi. Se la console o i portali amministrativi sono stati configurati per usare Entra come provider principale, la disattivazione può lasciare gli operatori senza una via di ingresso valida. Il secondo impatto riguarda i ruoli: in alcune configurazioni i gruppi Entra sono stati mappati direttamente ai permessi SCCM, quindi togliere l’integrazione richiede una riconciliazione con gruppi locali o AD on-prem.

Il terzo impatto è più subdolo: gli ambienti di gestione spesso hanno procedure documentate “funzionanti solo perché qualcuno ha già fatto login una volta”. Dopo la disattivazione, il problema emerge quando si chiude la sessione, si rinnova il token o si prova da una postazione diversa. Per questo la verifica deve includere un test da sessione pulita, non solo un refresh della pagina già aperta.

Se il tuo obiettivo è ridurre la dipendenza dal cloud identity, il beneficio reale non è solo tecnico ma operativo: meno punti di fallimento esterni, meno vincoli di policy centralizzate, e un percorso di accesso più prevedibile in caso di outage del tenant. Il prezzo da pagare è la perdita di alcune protezioni native, soprattutto MFA e Conditional Access, che andranno replicate o compensate in altro modo.

Sequenza consigliata: disattivazione senza tagliarsi fuori

La regola è semplice: prima aggiungi un percorso alternativo, poi spegni Entra. Non fare il contrario. Se il sistema supporta più metodi di autenticazione, porta in esercizio quello alternativo su un numero ristretto di account admin, verifica il login end-to-end, e solo dopo rimuovi il provider Entra dalla configurazione attiva.

In termini pratici, la procedura deve essere reversibile. Salva lo stato corrente della configurazione, annota dove è definita l’autenticazione, e verifica quali servizi o componenti dipendono da quel metodo. Se lavori da interfaccia, usa il percorso del pannello per evitare errori di sintassi; se lavori da CLI o PowerShell, conserva il comando esatto eseguito e l’output prima e dopo il cambio.

Un approccio prudente è questo: prima abiliti e testi un account locale o AD on-prem con privilegi equivalenti, poi cambi la policy di accesso per escludere Entra, infine verifichi che la console, i portali e le funzioni amministrative restino raggiungibili. Se una di queste tre fasi fallisce, non proseguire: il costo di un rollback immediato è sempre inferiore a quello di un accesso amministrativo perso.

Verifiche operative dopo il cambio

Dopo la disattivazione, il test minimo non è “la pagina si apre”, ma “posso autenticarmi da una sessione nuova con il profilo previsto e completare un’azione amministrativa reale”. La prova più utile è aprire la console da una macchina non usata prima, autenticarsi con l’account di fallback e verificare almeno una funzione sensibile: visualizzazione dei ruoli, accesso ai device, apertura delle collection o modifica di una policy non critica.

Osserva anche i log di sistema e dell’applicazione. Se compare un errore di token, un redirect verso Microsoft o un messaggio di autorizzazione negata, il problema è ancora nell’identity flow e non nella console in sé. Se invece l’accesso riesce ma alcune funzioni risultano vuote o non editabili, il problema è probabilmente nei ruoli o nei gruppi assegnati.

Una verifica utile è controllare che il comportamento sia coerente tra utenti diversi con lo stesso ruolo. Se un admin entra e un altro no, il problema non è la disattivazione in sé ma la differenza tra le assegnazioni precedenti. In quel caso, la mappatura dei privilegi va ricostruita prima di considerare chiuso il change.

Rollback: come tornare indietro senza improvvisare

Il rollback deve essere preparato prima del cambio e non dopo il primo errore. Conserva la configurazione precedente, i riferimenti ai metodi di autenticazione attivi e un account di emergenza testato. Se la disattivazione è stata fatta da pannello, il rollback deve passare dallo stesso percorso; se è stata fatta da script o PowerShell, conserva lo snippet esatto usato per il ripristino.

Il criterio di rollback è netto: se un amministratore non riesce a entrare con il metodo alternativo, oppure se la console mostra errori di autenticazione ripetibili, riattiva il provider precedente e ripeti il test in ambiente controllato. Non aspettare che la finestra di manutenzione scada: quando l’accesso amministrativo è in dubbio, il rollback è la scelta corretta.

Se hai bisogno di documentare il ripristino, registra tre cose: quale opzione hai rimesso attiva, quale account ha validato il ritorno all’operatività, e quale log o schermata ha confermato il successo. Questo evita la solita situazione in cui “funziona di nuovo” ma nessuno sa esattamente quale pezzo sia stato ripristinato.

Errore comune: confondere autenticazione con autorizzazione

Molti problemi nascono perché si pensa che togliere Entra significhi solo cambiare il login. In realtà stai separando autenticazione e autorizzazione, e SCCM può dipendere da entrambe. Un utente può autenticarsi correttamente ma non avere più i ruoli necessari, oppure può avere i ruoli ma non il canale di accesso valido. Sono due piani diversi e vanno verificati separatamente.

Per questo è utile ragionare per strati: identità, sessione, ruolo, funzione. Se il login funziona ma il ruolo non si applica, il problema è nel mapping dei gruppi. Se il ruolo c’è ma la console non completa l’accesso, il problema è nel provider o nella sessione. Se tutto sembra corretto ma una singola funzione non risponde, allora il guasto è più probabilmente applicativo o di permessi granulari.

Quando ha senso disattivarlo davvero

Ha senso farlo quando vuoi ridurre la dipendenza da un tenant esterno, quando il modello operativo richiede accesso locale o on-prem, oppure quando stai semplificando un ambiente che non deve più usare Entra per policy aziendale. Ha meno senso farlo solo perché “si preferisce il vecchio metodo”: in quel caso rischi di perdere MFA, tracciabilità e centralizzazione senza un beneficio reale.

In ambienti misti, una strategia più pulita è mantenere Entra per gli utenti che ne hanno davvero bisogno e usare un percorso alternativo solo per gli amministratori di piattaforma. Se questo non è possibile, la disattivazione totale va accompagnata da un controllo più rigoroso sugli account privilegiati, sui log di accesso e sulle procedure di emergenza.

La regola finale è la stessa di qualsiasi change su identity: non fare affidamento sulla memoria. Prima del cambio, verifica il punto esatto in cui Entra entra nel flusso; dopo il cambio, dimostra che l’accesso alternativo funziona da zero; se qualcosa non torna, riattiva il provider precedente e correggi la mappatura con calma. È il modo più rapido per evitare di trasformare un cambio di autenticazione in un incidente di accesso amministrativo.