Gli utenti hanno incontrato difficoltà durante il tentativo di effettuare il provisioning di utenti e gruppi da due origini di identità con lo stesso nome di dominio in Cisco Secure Access. Lo scenario specifico prevedeva la sincronizzazione delle identità da Active Directory locale e Microsoft EntraID (in precedenza Azure AD) in cui entrambe le origini utilizzavano lo stesso nome di dominio (ad esempio, domain.com).
Le principali preoccupazioni erano:
Informazioni sul comportamento del mapping di appartenenza a gruppi e proprietà di identità quando gli stessi utenti e gruppi esistono in entrambe le origini di identità
Garantire l'applicazione coerente e sicura dei criteri di accesso per gli utenti ibridi che accedono sia alle risorse locali che a quelle cloud
Mantenimento della visibilità IP interna per gli utenti in questa configurazione di identità ibrida
Determinare se la sincronizzazione simultanea da entrambe le origini potrebbe causare problemi in un ambiente di produzione
Nella documentazione è indicato che "la sincronizzazione simultanea degli stessi utenti e gruppi da Cisco AD Connector e dall'app Cisco User Management for Secure Access non è supportata e determina l'applicazione incoerente delle regole di accesso".
Cisco Secure Access con integrazione AD Connector ed EntraID
Active Directory locale con nome di dominio corrispondente al dominio EntraID
Microsoft EntraID (Azure AD) con lo stesso nome di dominio di Active Directory locale
Configurazione SSO SAML per la federazione delle identità
Modulo Secure Web Gateway (SWG) per l'applicazione delle policy
Ambiente ibrido che richiede l'accesso alle risorse locali e cloud
Il seguente comportamento è stato confermato per la sincronizzazione simultanea da entrambe le origini Active Directory e EntraID:
Quando si sincronizzano gruppi con lo stesso nome da entrambe le origini:
In Cisco Secure Access vengono creati due oggetti gruppo distinti, uno per ogni origine
I gruppi possono essere distinti in base al prefisso di origine nei criteri di accesso
I gruppi AD locali vengono visualizzati come: AD-Dominio/NomeGruppo
I gruppi EntraID vengono visualizzati come: NomeGruppo
La verifica del laboratorio ha dimostrato che la sincronizzazione è riuscita con il messaggio "Operazione riuscita. <<<< Sincronizzato" per gruppi da più domini EntraID.
Quando si sincronizzano utenti con lo stesso ID utente da entrambe le origini:
L'identità utente viene sovrascritta durante la sincronizzazione
In Secure Access rimane visibile un solo ID utente univoco
L'origine finale della sincronizzazione determina gli attributi dell'utente e le appartenenze ai gruppi
La sincronizzazione EntraID in genere ha la precedenza su Active Directory locale quando entrambi sono configurati
Entrambi i tipi di gruppo possono essere utilizzati nei criteri di accesso:
Fare riferimento a gruppi AD locali utilizzando il percorso completo: AD-Dominio/NomeGruppo
Fare riferimento ai gruppi EntraID utilizzando il nome semplice: NomeGruppo
I criteri possono differenziare gli utenti in base all'origine dell'appartenenza al gruppo
La procedura di configurazione è indicata per molti clienti.
1 Only provision identities from on-prem AD - for VA DNS protection 2 Use Azure entra for SSO/user authentication (no identities to be provisioned from Azure) - for SWG SAML
Durante il test, abbiamo confermato che ogni volta che un utente viene sincronizzato dal connettore AD locale, "dichiara" effettivamente tale identità nel dashboard Umbrella. Se lo stesso utente esiste già tramite la sincronizzazione di Azure AD, la sincronizzazione locale sovrascriverà i dati utente EntraID esistenti.
Questo comportamento è una limitazione documentata. Secondo la documentazione tecnica ufficiale di Cisco: https://securitydocs.cisco.com/docs/csa/china/olh/129444.dita
"La sincronizzazione simultanea delle stesse identità di utenti e gruppi da Umbrella AD Connector e dall'app Cisco Umbrella Azure AD non è supportata e determina un'applicazione dei criteri incoerente."
Conclusione: L'installazione desiderata (visibilità VA per gli utenti esistenti sia in Azure che in locale) è stata confermata come una configurazione non supportata. Il percorso successivo richiede l'utilizzo di client mobili per garantire l'imposizione coerente delle identità.
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
14-May-2026
|
Versione iniziale |