Spcnet.it

2026-05-24 18:16:49

Fine dell’autenticazione CBA diretta per Exchange ActiveSync: guida alla migrazione verso Microsoft Entra ID

L’8 maggio 2026, il team di Exchange Online di Microsoft ha annunciato la deprecazione dell’autenticazione basata su certificati (CBA) diretta per Exchange ActiveSync (EAS). Entro la fine del 2026, qualsiasi client EAS che utilizza certificati per autenticarsi direttamente contro Exchange Online dovrà migrare al nuovo metodo basato su Microsoft Entra ID, pena l’interruzione del servizio email mobile.

Se la tua organizzazione ha configurato l’accesso alle email mobili tramite certificati client, questo articolo ti guida attraverso tutto ciò che devi sapere: perché Microsoft sta effettuando questo cambiamento, chi è interessato e — soprattutto — come completare la migrazione prima della scadenza.

Cos’è l’autenticazione CBA diretta per Exchange ActiveSync?

Exchange ActiveSync (EAS) è il protocollo che permette ai dispositivi mobili (smartphone, tablet) di sincronizzare email, calendari e contatti con Exchange Online. L’autenticazione basata su certificati (Certificate-Based Authentication, CBA) rappresenta un approccio passwordless: invece di inserire credenziali, il dispositivo presenta un certificato X.509 per autenticarsi.

Nel flusso legacy attuale, il funzionamento è il seguente:

1. I certificati client vengono distribuiti ai dispositivi mobili durante la configurazione MDM
2. Quando l’app email si connette, invia il certificato direttamente a Exchange Online
3. Exchange Online riceve il certificato e ne gestisce internamente la validazione
4. L’accesso viene concesso senza che il client ottenga mai un token OAuth standard

Questo approccio, sebbene sicuro a livello crittografico, è classificato da Azure AD come autenticazione legacy: il client non ottiene mai un token OAuth moderno, ma si affida a un meccanismo interno ad alta privilegio all’interno di Exchange Online.

Perché Microsoft sta eliminando questo metodo?

Il problema centrale è che la CBA diretta verso Exchange bypassa il moderno ecosistema di autenticazione di Microsoft Entra ID. Le conseguenze pratiche per gli amministratori sono significative:

• Incompatibilità con le Conditional Access Policy: le policy che bloccano l’autenticazione legacy in Azure AD bloccano anche la CBA diretta su EAS, creando un dilemma “tutto o niente” per chi vuole applicare controlli di sicurezza moderni senza interrompere l’accesso email mobile
• Mancanza di token OAuth: senza un token OAuth standard, non è possibile applicare controlli granulari come la durata della sessione, la revoca in tempo reale o l’integrazione con Identity Protection
• Superficie di attacco interna: Exchange Online si affida a un meccanismo interno ad alta privilegio per validare i certificati, introducendo una complessità architetturale non necessaria

Il nuovo flusso con Entra ID risolve tutti questi problemi:

1. Il client invia il certificato a Microsoft Entra ID per la validazione
2. Entra ID valida il certificato e restituisce un token OAuth al client
3. Il client presenta il token OAuth a Exchange Online per l’autenticazione

In questo modo, la CBA diventa un metodo di autenticazione moderno a tutti gli effetti, integrato nel flusso OAuth standard e soggetto a tutte le Conditional Access Policy configurate nel tenant.

Chi è interessato da questa modifica?

È importante chiarire cosa non è interessato da questa deprecazione:

• Outlook Mobile (usa già Modern Authentication)
• Exchange Server on-premises
• Altri client Exchange Online che non usano EAS con CBA
• Organizzazioni che non hanno mai configurato EAS CBA

La modifica riguarda esclusivamente i client Exchange ActiveSync (tipicamente le app email native di iOS e Android) configurati per usare certificati client come metodo di autenticazione verso Exchange Online.

Come verificare se la tua organizzazione è interessata:

1. Controlla la configurazione MDM: se il tipo di autenticazione nei profili email è impostato su “Certificate” anziché “OAuth”, probabilmente stai usando la CBA legacy
2. Verifica i log di sign-in di Entra ID: accedi all’Azure Portal → Microsoft Entra ID → Sign-in logs → filtra per “Client App: Exchange ActiveSync”. Se in “Authentication Details” vedi “Certificate” come metodo di autenticazione, sei impattato

Guida alla migrazione verso Entra-Based CBA

La buona notizia è che l’infrastruttura PKI e le CA (Certificate Authority) utilizzate per EAS CBA sono fondamentalmente le stesse richieste per Entra CBA. Questo semplifica notevolmente la transizione.

Step 1: Abilitare Microsoft Entra CBA nel tenant

Accedi al portale Azure e naviga in Microsoft Entra ID → Protection → Authentication methods → Certificate-based authentication. Configura le tue Certificate Authority:

• Almeno una CA root deve essere configurata in Entra ID, insieme a tutte le CA intermedie
• Ogni CA deve avere una Certificate Revocation List (CRL) accessibile da un URL pubblico su Internet
• Gli utenti devono avere accesso a un certificato emesso da una PKI attendibile

Per verificare la configurazione via PowerShell (Microsoft Graph PowerShell):

# Recupera le CA di autenticazione configurate nel directory
Get-MgOrganizationCertificateBasedAuthConfiguration -OrganizationId (Get-MgOrganization).Id

# Oppure con il modulo AzureAD (legacy)
Get-AzureADTrustedCertificateAuthority

Step 2: Verificare i certificati utente

Per Exchange ActiveSync, i certificati client devono contenere l’indirizzo email routable dell’utente nel campo Subject Alternative Name (SAN), in uno dei seguenti formati:

• Principal Name: user@domain.com
• RFC822 Name: user@domain.com (Entra ID lo mappa all’attributo Proxy Address)

I certificati già usati per la CBA diretta su EAS soddisfano quasi certamente questo requisito. Verifica semplicemente la presenza dell’email aziendale nel campo SAN del certificato.

Step 3: Aggiornare la configurazione dei dispositivi

Questa è la parte più operativa della migrazione. I profili email sui dispositivi mobili devono essere aggiornati per eseguire l’autenticazione certificato contro Entra ID invece che direttamente verso Exchange. In pratica:

• Se usi Microsoft Intune: aggiorna i profili di configurazione email per usare OAuth + certificati come metodo di autenticazione. Consulta la documentazione Intune per le specifiche della configurazione per iOS e Android
• Se usi soluzioni MDM di terze parti (VMware Workspace ONE, JAMF, MobileIron, ecc.): consulta il vendor per le istruzioni specifiche sull’abilitazione dell’autenticazione Entra con certificati

I nuovi endpoint dedicati per la CBA su EAS sono:

• Multi-tenant worldwide: outlook-cba.office365.com
• GCC-High: outlook-cba.office365.us
• DoD: outlook-dod-cba.office365.us

Step 4: Test e monitoraggio

Prima del rollout globale, testa il nuovo flusso Entra CBA con un gruppo pilota di dispositivi e utenti. Monitora i log di sign-in di Entra ID e i report sui dispositivi Exchange ActiveSync per identificare eventuali dispositivi che ancora usano il metodo legacy.

Timeline e pianificazione

I punti chiave da tenere a mente:

• Immediato: blocco per i nuovi tenant — non possono più configurare la CBA legacy
• Prossime settimane: Microsoft invierà comunicazioni Message Center ai tenant impattati
• Fine 2026: la CBA diretta verso Exchange Online verrà disabilitata per tutti i tenant esistenti

Microsoft raccomanda di completare la migrazione ben prima della scadenza di fine 2026 per evitare interruzioni del servizio. Considerando i tempi tipici di test, approvazione e deployment nei dispositivi mobili aziendali, è consigliabile iniziare la pianificazione adesso.

Conclusione

La deprecazione della CBA diretta per Exchange ActiveSync è parte del percorso di Microsoft verso la modernizzazione completa dell’autenticazione su Exchange Online, sulla scia dell’eliminazione di Basic Auth avvenuta negli anni scorsi. Il nuovo flusso basato su Entra ID offre sicurezza equivalente — passwordless, resistente al phishing, basato su certificati — con una ben migliore integrazione nell’ecosistema moderno di autenticazione e la piena compatibilità con le Conditional Access Policy.

Se la tua organizzazione usa EAS con CBA, il momento di iniziare la pianificazione della migrazione è adesso: la runway fino a fine 2026 è sufficiente per una transizione ordinata, ma non illimitata.

---

Fonte: Microsoft Tech Community — Exchange Team Blog (8 maggio 2026) | 4sysops.com

Retirement of Direct Exchange ActiveSync Certificate-Based Authentication by End of 2026 | Microsoft Community Hub

We are announcing the deprecation of Exchange ActiveSync (EAS) certificate-based authentication (CBA) directly to Exchange Online.  

^{The_Exchange_Team (TECHCOMMUNITY.MICROSOFT.COM)}

Spcnet.it

2026-05-24 18:17:13

Liquibase: gestione delle modifiche al database e automazione CI/CD

La gestione delle modifiche allo schema di un database è uno degli aspetti più delicati e sottovalutati nei progetti software moderni. Script SQL sparsi, modifiche manuali non documentate, disallineamenti tra ambienti di sviluppo, staging e produzione: questi problemi sono comuni in quasi ogni team di sviluppo. Liquibase risolve questi problemi portando il controllo di versione al database, proprio come Git fa con il codice sorgente.

Cos’è Liquibase e perché usarlo

Liquibase è uno strumento non open source rilasciato con licenza FSL con disponibilità del codice sorgente, per il database schema change management. Permette di definire, versionare e distribuire le modifiche allo schema del database tramite file di configurazione (chiamati changelog), supportando oltre 30 database diversi: Oracle, MySQL, PostgreSQL, SQL Server, DB2 e molti altri.

Il problema che Liquibase risolve è semplice ma critico: applicare modifiche al database con script SQL tradizionali è un processo manuale, error-prone e difficile da tracciare. Questi script spesso mancano di versioning, rendendo quasi impossibile sapere quale versione dello schema è in produzione rispetto allo sviluppo. Liquibase standardizza questo processo tramite file di configurazione versionati, tracciamento automatico via checksum MD5 e supporto nativo al rollback.

Concetti fondamentali

Prima di entrare nell’implementazione, è essenziale comprendere i quattro pilastri architetturali di Liquibase:

Changelog: è il file principale che contiene tutte le modifiche al database, organizzate in sequenza. Può essere in formato XML, YAML, JSON o SQL puro. Tipicamente si usa un file master che include sotto-changelog organizzati per release o sprint.

ChangeSet: è l’unità atomica di modifica, identificata univocamente da una coppia id + author. Ogni changeset viene eseguito una sola volta e tracciato nella tabella DATABASECHANGELOG. Una regola fondamentale: non modificare mai un changeset già eseguito; crea sempre un nuovo changeset per le correzioni.

Preconditions: verifiche condizionali che devono passare prima dell’esecuzione di un changeset. Permettono di rendere sicure le migrazioni anche in scenari complessi (es. verificare che una colonna non esista già prima di aggiungerla).

Contexts e Labels: meccanismi di filtraggio per controllare quali changeset vengono eseguiti in quale ambiente (dev, staging, prod). Indispensabili per gestire dati di test o configurazioni ambiente-specifiche.

Struttura base di un changelog YAML

Ecco un esempio pratico di changelog in formato YAML per la creazione di una tabella transazioni con supporto al rollback:

databaseChangeLog:
  - changeSet:
      id: create-payment-table
      author: devops.team
      changes:
        - createTable:
            tableName: payment_transaction
            columns:
              - column:
                  name: id
                  type: varchar(50)
                  constraints:
                    primaryKey: true
                    nullable: false
              - column:
                  name: amount
                  type: decimal(15,2)
                  constraints:
                    nullable: false
              - column:
                  name: currency_code
                  type: char(3)
                  constraints:
                    nullable: false
              - column:
                  name: transaction_date
                  type: timestamp
                  defaultValueComputed: CURRENT_TIMESTAMP
              - column:
                  name: status
                  type: varchar(20)
                  constraints:
                    nullable: false
      rollback:
        - dropTable:
            tableName: payment_transaction

Il blocco rollback è fondamentale: definisce esplicitamente come annullare la modifica, rendendo ogni deployment reversibile in modo prevedibile.

Configurazione per ambienti multipli

Un file liquibase.properties separato per ogni ambiente permette di gestire connessioni e contesti in modo sicuro:

# liquibase-dev.properties
changeLogFile=db/changelog.yaml
url=jdbc:postgresql://localhost:5432/devdb
username=dev_user
password=${DB_PASSWORD}
contexts=dev,test
defaultSchemaName=DEV_SCHEMA
logLevel=DEBUG

Nota importante: le credenziali non devono mai essere committate nel repository. Usa variabili d’ambiente, HashiCorp Vault, AWS Secrets Manager o Kubernetes Secrets per la gestione dei segreti.

Precondizioni per deployment sicuri

Le precondizioni rendono Liquibase robusto in ambienti dove lo schema potrebbe trovarsi in stati intermedi. Questo esempio in SQL nativo verifica che una colonna non esista prima di aggiungerla:

--liquibase formatted sql

--changeset devops.team:add-merchant-id
--preconditions onFail:MARK_RAN onError:HALT
--precondition-sql-check expectedResult:0 SELECT COUNT(*) FROM information_schema.columns WHERE table_name = 'payment_transaction' AND column_name = 'merchant_id'

ALTER TABLE payment_transaction 
ADD COLUMN merchant_id VARCHAR(50);

--rollback ALTER TABLE payment_transaction DROP COLUMN merchant_id;

Il comportamento onFail:MARK_RAN istruisce Liquibase a segnare il changeset come già eseguito (senza eseguirlo) se la precondizione fallisce — comportamento ideale quando la colonna esiste già per altri motivi.

Integrazione in pipeline CI/CD

La vera potenza di Liquibase emerge quando viene integrato in una pipeline di deployment automatizzato. Ecco un esempio completo con Jenkins:

pipeline {
    agent any
    
    stages {
        stage('Validate') {
            steps {
                sh 'liquibase validate'
            }
        }
        
        stage('Deploy Staging') {
            steps {
                sh 'liquibase --contexts=staging update'
            }
        }
        
        stage('Deploy Production') {
            when { 
                branch 'main' 
            }
            steps {
                input 'Deploy to Production?'
                sh 'liquibase --contexts=prod update'
            }
        }
    }
    
    post {
        failure {
            sh 'liquibase rollbackCount 1'
        }
    }
}

Il blocco post { failure } garantisce il rollback automatico dell’ultimo changeset in caso di errore — un salvagente fondamentale in produzione.

Pattern Kubernetes: Init Container

Per architetture cloud-native, il pattern degli init container è ideale: Liquibase viene eseguito come container di inizializzazione prima dell’avvio dell’applicazione, garantendo che lo schema sia sempre aggiornato prima che il servizio inizi a ricevere traffico:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    spec:
      initContainers:
      - name: liquibase-migration
        image: liquibase/liquibase:4.25.0
        command:
        - liquibase
        - --url=jdbc:postgresql://$(DB_HOST):5432/$(DB_NAME)
        - --username=$(DB_USER)
        - --password=$(DB_PASSWORD)
        - update
        env:
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: host
      containers:
      - name: payment-service
        image: payment-service:latest
        ports:
        - containerPort: 8080

Best practice per ambienti enterprise

Alcune regole fondamentali per adottare Liquibase in contesti di produzione:

• Principio del minimo privilegio: l’utente Liquibase deve avere solo i permessi DDL necessari, mai privilegi DBA completi.
• Revisione obbligatoria: ogni modifica al changelog deve passare per una Pull Request con review da un secondo sviluppatore prima del merge.
• Test su dati realistici: prima del deployment in produzione, eseguire le migrazioni in un ambiente staging con volumi di dati simili a quelli di produzione per individuare problemi di performance.
• Mai modificare changeset già eseguiti: il checksum MD5 rileverei la modifica e bloccherebbe il deployment. Crea sempre un nuovo changeset per le correzioni.
• Crea indici dopo i bulk insert: creare indici prima di caricare grandi quantità di dati aumenta enormemente il tempo di migrazione senza benefici pratici.

Monitoraggio con Prometheus e Grafana

Per ambienti enterprise, integrare le metriche Liquibase in un sistema di osservabilità permette di rilevare problemi prima che impattino la produzione. Le metriche chiave da tracciare includono:

• Durata per changeset: identifica migrazioni lente che potrebbero causare downtime
• Lock contention: conflitti sulla tabella DATABASECHANGELOGLOCK in ambienti multi-istanza
• Checksum failures: modifica non autorizzata a changeset già eseguiti
• Rollback rate: indicatore di qualità del processo di testing prima del deployment

# Esempio metriche Prometheus esportate da Liquibase
liquibase_deployment_success_total{environment="prod"} 145
liquibase_changeset_duration_seconds_bucket{id="1",database="prod",le="0.5"} 120
liquibase_rollback_total{environment="prod"} 3
liquibase_deployment_failure_total{environment="prod",reason="validation_error"} 2

Conclusione

Liquibase trasforma la gestione del database da processo manuale e rischioso a pratica ingegneristica controllata e auditabile. L’integrazione con i sistemi CI/CD permette di applicare agli schemi database gli stessi standard di qualità già applicati al codice applicativo: versionamento, review, test automatizzati e rollback prevedibile.

Per team che adottano DevOps o pratiche di continuous delivery, Liquibase non è un’opzione ma una necessità: è il tassello mancante tra il deployment del codice e quello del database.

Fonte: Liquibase: Database Change Management and Automated Deployments — DZone

Liquibase: Database Change Management + Automated Deployment

Liquibase automates schema versioning and deployment via changelogs, enabling version-controlled, rollback-ready migrations with tracking for DevOps pipelines.

^{Suman Basak (dzone.com)}