Essere determinati e fare il sistemista, a volte, è un pregio; altre volte significa andare a letto pensando a un problema, svegliarsi nel cuore della notte con una possibile spiegazione, resistere alla tentazione di riaprire il Mac alle tre del mattino e, il giorno dopo, ricominciare da dove si era lasciato. Questo caso appartiene decisamente alla seconda categoria: per diversi giorni un account Microsoft 365 aziendale si rifiutava ostinatamente di funzionare correttamente negli Internet Account di macOS, nonostante password, MFA, browser, rete e praticamente tutto ciò che normalmente si controlla in queste situazioni sembrassero perfettamente a posto. La cosa che mi ha irritato di più, e naturalmente mi ha fatto insistere ancora di più, era che nelle ricerche che avevo fatto in quei giorni non trovavo nulla che conducesse realmente alla causa del problema; tante segnalazioni simili, molte procedure generiche, parecchi “rimuovi e aggiungi nuovamente l’account”, ma niente che spiegasse quello che stava succedendo nel mio caso.
Prima di entrare nella parte tecnica devo però essere molto chiaro: questa non è una procedura destinata all’utente finale e non è una modifica da provare “per vedere se funziona”. La soluzione descritta interviene sulla configurazione di Exchange Online a livello di tenant e richiede privilegi amministrativi adeguati, conoscenza di Exchange Online PowerShell e soprattutto la capacità di comprendere lo stato attuale dell’ambiente prima di modificarlo. Un comando eseguito senza sapere esattamente cosa sta facendo può bloccare l’accesso EWS ad altre applicazioni dell’organizzazione; se non siete amministratori del tenant o non avete familiarità con questi meccanismi, fermatevi alla diagnosi e passate le informazioni al vostro reparto IT. In questo caso sapere dove si mettono le mani non è una raccomandazione di rito, è parte integrante della soluzione.
Il problema: autenticazione corretta, ma macOS continuava a rifiutare l’account
Il comportamento era particolarmente ingannevole perché il login Microsoft funzionava. Inserivo l’account aziendale in macOS, venivo correttamente portato sul flusso di autenticazione Microsoft, completavo l’MFA tramite Authenticator e arrivavo apparentemente alla fine della procedura senza errori significativi; poco dopo, però, Calendario tornava a chiedere le credenziali e macOS mostrava il famigerato errore com.apple.accounts, accompagnato in alcune schermate dal riferimento account3.
La prima reazione, inevitabile, è pensare a qualcosa sul Mac. Cache delle credenziali, browser predefinito, componenti di sicurezza, Keychain, vecchi token, rete, profilo utente; del resto quando un problema compare soltanto su un determinato sistema operativo è naturale guardare inizialmente in quella direzione. Nel mio caso, però, più eliminavo variabili e meno la spiegazione “è il Mac” reggeva.
Outlook sul Web funzionava regolarmente, così come l’autenticazione Microsoft da browser; anche su iPhone le richieste MFA arrivavano senza problemi. Ho provato browser diversi, compresa una sessione anonima, un profilo del browser nuovo, una connessione Internet differente, ho eliminato e ricreato l’account, ho verificato il software di sicurezza installato e sono arrivato persino a rimuovere temporaneamente componenti che avrebbero potuto interferire con il traffico. Il risultato rimaneva sostanzialmente lo stesso.
Apple conferma che Mail e Calendario su macOS supportano Exchange Online e che gli account Microsoft cloud utilizzano l’autenticazione moderna OAuth; quindi il semplice fatto che l’MFA andasse a buon fine non significava, come ho scoperto a mie spese, che tutta la catena necessaria alla sincronizzazione della mailbox fosse realmente funzionante. (Support Apple)
Il test che ha cambiato completamente la diagnosi: OAuth funzionava, EWS no
Il punto di svolta è arrivato eseguendo una diagnostica più approfondita attraverso gli strumenti Microsoft. Autodiscover rispondeva correttamente, il processo OAuth non evidenziava problemi significativi, ma quando il test arrivava alla connessione alla mailbox attraverso Exchange Web Services la risposta diventava inequivocabile: HTTP 403 Forbidden.
Ed è stato proprio quel 403 a spostare definitivamente la ricerca dal Mac al tenant Microsoft 365.
Un errore 403 non dice “non riesco a trovare il server” e neppure “le credenziali sono sbagliate”; significa che il servizio è stato raggiunto, la richiesta è arrivata, ma qualcosa nella configurazione sta negando l’accesso. A quel punto la domanda non era più “perché macOS non riesce ad autenticarsi?”, ma “quale applicazione sta effettuando la richiesta EWS e perché Exchange Online non la autorizza?”.
La documentazione Microsoft conferma che l’accesso a EWS può essere governato sia a livello di organizzazione sia di singola mailbox attraverso Get-OrganizationConfig, Set-OrganizationConfig, Get-CASMailbox e relativi parametri di controllo; in particolare, quando EwsEnabled è impostato a $true e viene utilizzato EwsAllowedAppIDs, soltanto gli Application ID presenti in quella lista possono effettuare connessioni EWS dirette. (Microsoft Learn)
EwsEnabled era attivo. Il problema era altrove
A quel punto mi sono collegato a Exchange Online PowerShell e ho controllato la configurazione EWS dell’organizzazione:
Connect-ExchangeOnline
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsEnabled,EwsAllowedAppIDs,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockListNel mio caso EwsEnabled risultava correttamente impostato a True, quindi EWS non era stato semplicemente disabilitato. Era però valorizzato anche EwsAllowedAppIDs.
Questa è la parte che, almeno nel mio caso, nascondeva la trappola.
Microsoft documenta infatti EwsAllowedAppIDs come la lista degli Application ID Entra autorizzati a connettersi direttamente a EWS quando EwsEnabled è $true; un’applicazione che non compare nella lista viene bloccata. (Microsoft Learn)
E quindi ho iniziato a guardare non più soltanto “se EWS fosse attivo”, ma chi fosse autorizzato a usarlo.
Apple Internet Accounts e quell’Application ID che mancava
L’applicazione utilizzata dagli Internet Account Apple per l’integrazione con i servizi Microsoft è identificata dall’Application ID:
f8d98a96-0999-43f5-8af3-69971c7bb423Microsoft identifica questo GUID come quello utilizzato da Apple Internet Accounts e lo riporta anche nella propria documentazione e nei propri contenuti tecnici relativi all’integrazione con i client Apple. (Microsoft Learn)
Nel mio tenant erano già presenti altri Application ID autorizzati, ma quello di Apple non c’era.
A quel punto tutti i pezzi hanno iniziato finalmente a combaciare: login Microsoft riuscito, MFA riuscita, Autodiscover corretto, ma richiesta EWS proveniente da Apple Internet Accounts rifiutata perché l’Application ID non faceva parte della lista consentita. Il 403 Forbidden, improvvisamente, aveva perfettamente senso.
La parte delicata: aggiungere l’ID Apple senza cancellare quelli già presenti
Qui bisogna prestare particolare attenzione. EwsAllowedAppIDs non funziona come una proprietà alla quale si possa aggiungere distrattamente un valore presumendo che Exchange mantenga automaticamente tutto il resto; Microsoft specifica che il parametro riceve l’elenco completo degli ID e la stessa Microsoft, in un recente approfondimento tecnico, raccomanda di acquisire prima i valori già presenti e quindi riscrivere la lista completa aggiungendo il nuovo elemento. (Microsoft Learn)
In altre parole, non utilizzerei mai un comando che imposti direttamente soltanto l’ID Apple, perché si rischierebbe di sostituire la lista esistente e togliere involontariamente l’autorizzazione ad altre applicazioni.
Ho quindi utilizzato una procedura che legge prima la configurazione corrente, aggiunge esclusivamente l’Application ID di Apple, elimina eventuali duplicati e infine riscrive la lista completa:
$config = Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy
$currentAppIDs = @(
($config.EwsAllowedAppIDs -split ",") |
ForEach-Object { $_.Trim() } |
Where-Object { $_ }
)
$appleAppID = "f8d98a96-0999-43f5-8af3-69971c7bb423"
$updatedAppIDs = @($currentAppIDs + $appleAppID) | Select-Object -Unique
Set-OrganizationConfig -EwsAllowedAppIDs ($updatedAppIDs -join ",")Il principio del comando è semplice, anche se l’effetto sul tenant merita tutta l’attenzione del caso: leggiamo ciò che esiste già, aggiungiamo Apple Internet Accounts e rimettiamo tutto al proprio posto. Gli Application ID precedentemente configurati non vengono rimossi né sostituiti.
Subito dopo ho verificato il risultato:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsEnabled,EwsAllowedAppIDsA questo punto l’Application ID Apple risultava presente insieme agli altri.
Ho aggiunto l’ID, riprovato… e non funzionava ancora
Ed ecco il momento nel quale il sistemista insonne rischia seriamente di ricominciare da capo. Dopo aver effettuato la modifica, ho aggiunto nuovamente l’account sul Mac e inizialmente sembrava andare tutto bene; aprendo Calendario, però, la richiesta di password è ricomparsa e con lei ancora account3.
A quel punto la tentazione era pensare che anche questa strada fosse sbagliata. In realtà c’era un’altra variabile molto meno affascinante ma estremamente comune nei servizi cloud: la propagazione.
Exchange Online utilizza sistemi di caching per questo tipo di configurazione e Microsoft stessa indica che le modifiche a EwsAllowedAppIDs possono richiedere fino a 24 ore per propagarsi completamente. (TECHCOMMUNITY.MICROSOFT.COM)
Ho quindi fatto una cosa che, per uno che aveva ormai passato giorni dietro al problema, probabilmente è stata la più difficile dell’intera procedura: ho smesso di toccare tutto.
Ho rimosso nuovamente l’account e ho aspettato.
Il giorno successivo ho ripetuto la configurazione sugli stessi sistemi sui quali avevo effettuato tutti i test e questa volta è andata a buon fine. Account aggiunto, Mail funzionante, Calendario sincronizzato, nessuna nuova richiesta continua di password e nessun account3.
Dopo giorni di tentativi, la soluzione era finalmente lì.
Perché tutte le altre prove non potevano risolvere il problema
Col senno di poi è molto più facile ricostruire la logica. Cambiare browser non poteva cambiare una policy EWS a livello tenant; eliminare la cache locale non poteva autorizzare un Application ID assente da una allowlist; cambiare rete non poteva trasformare una risposta 403 Forbidden in un accesso consentito; disinstallare un antivirus poteva essere un test sensato per escludere interferenze, ma non avrebbe mai modificato le autorizzazioni applicative di Exchange Online.
Ed è proprio questo uno degli aspetti che mi ha spinto a scrivere l’articolo. Molti problemi informatici finiscono per assomigliarsi nell’interfaccia che vediamo: una finestra che torna a chiedere la password, un generico messaggio di errore, un account che sembra non autenticarsi. Ma sotto quella stessa schermata possono esserci problemi completamente differenti e, quando si resta bloccati troppo a lungo sulle prime ipotesi, si rischia di continuare a curare il sintomo invece di capire cosa stia realmente succedendo.
Nel mio caso il dettaglio decisivo non era il messaggio mostrato da macOS, ma quello che accadeva qualche livello più sotto: OAuth riuscito, EWS raggiunto, accesso negato.
Quando questa soluzione ha senso e quando invece no
Vorrei insistere su questo punto perché non voglio che l’articolo diventi una di quelle guide in cui si copia un comando PowerShell trovato su Google e si spera che faccia miracoli.
Questa soluzione ha avuto senso nel mio caso perché erano presenti contemporaneamente condizioni molto precise: l’account Microsoft 365 autenticava correttamente, Exchange Online ed EWS erano disponibili, il test diagnostico restituiva un 403 sulla chiamata EWS, EwsEnabled risultava attivo e il tenant utilizzava EwsAllowedAppIDs, all’interno del quale mancava l’Application ID di Apple Internet Accounts.
Se una di queste condizioni cambia, la causa potrebbe essere completamente diversa: Conditional Access, autorizzazioni dell’applicazione, configurazione a livello mailbox, token OAuth, MDM, Autodiscover, problemi di rete o altre policy del tenant.
La documentazione Microsoft distingue inoltre EwsAllowedAppIDs, che controlla le applicazioni attraverso l’Application ID, da EwsAllowList ed EwsBlockList, che lavorano invece sui client attraverso lo user agent e l’EwsApplicationAccessPolicy; confondere questi meccanismi significa rischiare di intervenire sulla configurazione sbagliata. (Microsoft Learn)
Un’ultima nota importante: EWS sta arrivando alla fine
C’è infine un dettaglio temporale che oggi, settembre 2026, non può essere ignorato. Microsoft ha già annunciato la dismissione di Exchange Web Services in Exchange Online: la disabilitazione inizierà globalmente nell’ottobre 2026 e il completamento è previsto per aprile 2027. Microsoft sta spingendo applicazioni proprie e di terze parti verso Microsoft Graph e raccomanda agli amministratori di analizzare fin da ora le proprie dipendenze da EWS. (Microsoft Learn)
Questo significa che quanto descritto qui fotografa un problema reale e una soluzione valida nel contesto attuale, ma non va interpretato come una configurazione destinata a vivere per sempre. Anzi, paradossalmente rende il caso ancora più interessante: siamo probabilmente in una fase di transizione nella quale vecchie e nuove modalità di accesso convivono, ed è proprio in queste fasi che emergono più facilmente problemi difficili da ricondurre a una causa evidente.
Alla fine era “solo” un GUID
Dopo giorni di test, account rimossi e ricreati, browser, reti, software di sicurezza, autenticazioni ripetute e qualche ora di sonno sacrificata, la soluzione si è ridotta all’aggiunta di un Application ID a una lista di Exchange Online: f8d98a96-0999-43f5-8af3-69971c7bb423
Una stringa abbastanza poco romantica per aver occupato così tante ore dei miei pensieri.
Ma è anche per situazioni come questa che continuo ad apprezzare il lavoro da sistemista: quando tutto ciò che sembra logico è già stato provato, resta quel momento in cui bisogna smettere di guardare l’errore dalla superficie e iniziare a seguire ciò che accade realmente dietro le quinte. A volte la soluzione arriva subito, altre volte ti tortura per giorni e ti segue anche a letto; però, quando finalmente trovi il punto esatto in cui qualcosa si interrompe e riesci a spiegare perché, quella piccola soddisfazione ripaga almeno una parte delle ore passate a pensarci.
E soprattutto, se questo articolo farà risparmiare a qualcun altro anche soltanto una delle notti che ho perso io, direi che ne sarà valsa la pena.
