Category Archives: Azure Active Directory

Errore di Permessi di Azure AD Sync: codice errore 8344

Errore di Permessi di Azure AD Sync: codice errore 8344

Errore Azure AD Sync Export “Permissions-Issue”
Mettiamo il caso in cui stiamo lavorando sul troubleshooting dello strumento Azure AD Sync di uno dei nostri clienti poichè riscontra problemi con lo strumento.
Il client MIIS riportava errori di esportazione per tutti gli utenti dell’azienda e l’errore era il seguente: “Permissions-Issue”.

Errore Azure AD Sync Export
Ogni qualvolta AAD Sync effettua una sincronizzazione con Office 365, ci viene riportato il messaggio d’errore su “Export”.
Se guardiamo con attenzione al messaggio d’errore, questo dice “Permissions-issue” ma abbiamo già verificato che il nostro account on-premises e quello di Office 365 abbiano effettivamente tutti i permessi necessari per AAD Sync tool. Inizialmente potremmo pensare che si tratti di un falso errore ma così non è ed abbiamo la soluzione da fornirvi.
Qui sotto trovate lo screenshot del messaggio d’errore che ci si presenta.

Errore di Permessi di Azure AD Sync: codice errore 8344

Quando cliccate su permission-issue, vedrete comparire la seguente immagine che vi fornisce i dettagli del messaggio d’errore, assieme al codice errore.

Errore di Permessi di Azure AD Sync: codice errore 8344

Vediamo ora i singoli passaggi da eseguire per sistemare la problematica.

Resolve AAD Sync Export Error
Abbiamo visto che, cliccando su Permission-Issue per vederne i dettagli, l’errore della sorgente dati connessa è il nr 8344. Per risolvere l’errore, fate quanto segue.

1. Eseguite lo script Active Directory Inheritance per scaricare una lista di utenti su cui è stata bloccata l’ereditarietà. Una volta recuperata la lista, assicuratevi che per questi gruppi/utenti abbiate permesso l’ereditarietà.

Per permettere l’ereditarietà, assicuratevi che siano abilitate le funzionalità avanzate.
Recatevi in View -> user properties –> Security –> Advanced.
Da qui, selezionate la casella “to include inheritable permissions from this object’s parent”.

2. Assicuratevi di avere assegnato i permessi on-prem richiesti all’account di Azure AD Sync.

3. Una volta controllati i permessi richiesti e l’ereditarietà, assicuratevi che l’account sia parte del security group di AAD Sync in active directory. Il nome del gruppo di sicurezza è MSOL_AD_Sync_RichCoexistence. Dopo aver aggiunto l’account di servizio al gruppo, eseguite nuovamente la sincronizzazione completa e vedrete che tutti gli errori relativi ai permessi saranno scomparsi.

Piccolo dettaglio: nello scenario che abbiamo preso ad esempio, il cliente stava utilizzando l’AAD Sync assieme al password sync ed avevano configurato Exchange 2010 SP3 ibrido.

Rinominare gli utenti sincronizzati con Azure connect

In questo post, andremo ad analizzare uno scenario comune a molti clienti.
Mettiamoci nei panni di un’azienda che utilizza Office 365 e sincronizza i suoi utenti dall’AD locale ad Azure AD.

Quando aggiorniamo il nome dell’utente e l’UPN sul server AD in locale, però, non si sincronizza su Azure.
Eseguiamo allora il seguente comando:
Set-Msoldirsyncfeature -feature SynchronizeUPNformanagedusers -enabled $true -force

Sono passate 24 ore da quando abbiamo apportato i cambiamenti e nessuno degli username di azure è stato aggiornato.
L’indirizzo email primario non riflette i cambiamenti.
Ad esempio, john.Smith diventa John.Smith27 per l’indirizzo email principale. John.Smith diventa un alias automatico ma lo username dell’utente su Office365 ed Azure AD continua ad essere John.Smith.

La sincronizzazione con la directory di Google Cloud funziona correttamente. Sono soltanto Azure AD e Microsoft Azure Active Directory Sync Tool che non funzionano nella maniera appropriata.
Stiamo eseguendo l’ultima versione di Microsoft Azure Active Directory Connect sul server.

Abbiamo provato ad avviare/stoppare il Directory sync.

L’esecuzione del comando Powershell per assicurare la sincronizzazione dalla UPN locale, dovrebbe essere applicato allo username/UPN di Azure.

Possiamo utilizzare PowerShell per completare il task ma questo non sistemerebbe il problema sottostante dato dal fatto che gli username non si aggiornano via Microsoft tool come dovrebbe essere.

Come risolvere il problema?
Prima di tutto, eseguiamo il seguente comando:
Set-Msoldirsyncfeature -feature SynchronizeUPNformanagedusers -enabled $true -force

Successivamente, dovete rinominare tutti gli utenti di Azure AD ad una nuova UPN. In questo modo, si dovrebbero modificare tutte le UPN ad includere un Underscore.
$gn = Get-aduser -filter * -properties Emailaddress `

ForEach($g in $gn){
Get-aduser -identity $g.samaccountname | Set-aduser -UserprincipalName _+($u.samaccountname)}

Sul server in cui è in esecuzione Azure AD Connect, eseguite:
Start-AdsyncsyncCycle -policytype Delta # Or Intitial Delta works

Una volta che tutti gli username sono stati aggiornati e sincronizzati correttamente, potete tornare alla vostra UPN.
$gn = Get-aduser -filter * -properties Emailaddress `

ForEach($g in $gn){
Get-aduser -identity $g.samaccountname | Set-aduser -UserprincipalName $u.emailaddress}

Infine, eseguite un altro giro del seguente comando:
Start-AdsyncsyncCycle -policytype Delta # Or Intitial Delta works

Ora i nomi e login della UPN dovrebbero essere tutti aggiornati via Azure Connect.
Se, per qualsiasi motivo gli updtate Initial e Delta non sincronizzano i cambiamenti alla UPN, date priorità al seguente comando da impostare sul tenant di Azure:
Set-Msoldirsyncfeature -feature SynchronizeUPNformanagedusers -enabled $true -force

Utilizzare l’attributo mS-DS-ConsistencyGuid per risolvere i problemi di sincronizzazione ad Office 365/AAD

Avevamo affrontato l’argomento, anche nel seguente post di qualche anno fa:
Come mappare utenti OnPremise Active Directory a utenti Office365 esistenti.

Oggi parliamo di una modalità molto interessante per effettuare il troubleshoot delle problematiche di sincronizzazione ad Office 365 (Azure Active Directory). Il metodo consiste nell’utilizzare l’attributo “mS-DS-ConsistencyGuid”.

Come molti di voi sapranno, storicamente, AD Connect utilizzava “ObjectGUID” come attributo sourceAnchor per sincronizzare gli oggetti con il cloud.
A partire dalla versione 1.1.524.0, possiamo invece utilizzare mS-DS-ConsistencyGuid.

Quale è il bello di questo attributo? A differenza dell’ObjectGuid, quest’attributo è scrivibile.
Questo significa che possiamo manipolare gli oggetti sincronizzati in maniera più semplice. Recentemente, i clienti hanno iniziato a creare ticket relativamente a questa tematica. Siamo in grado di risolvere questo problema senza causare interruzioni di servizio agli utenti finali, gli scenari possono variare da:
Ho un ambiente multi-foresta sincronizzato e l’utente è stato migrato tra queste;
Un utente è stato eliminato dall’Active Directory per errore mentre AD Connect non lavorava e l’abbiamo re-installato;
Ho perso l’unico DC nella mia foresta, perciò ho dovuto ri-costruire completamente il mio AD foresta.

Vi consigliamo di creare SEMPRE due domain controller!!

Prerequisiti: dovrete avere accesso ad AAD Powershell connesso al vostro tenant (con i permessi di global admin), all’AD Connect Server e al Domain Controller..

Scenario 1
Un utente viene eliminato per errore dall’Active Directory mentre l’AD Connect non stava funzionando. Viene creato un nuovo account poiché non è possibile recuperare quello vecchio e, successivamente, viene re-installato l’AD Connect ma i cambiamento apportati sull’Active Directory non sono sincronizzati con l’account cloud.

NOTE: Ci sono poi molti altri scenari possibili, questo è quello che abbiamo portato come esempio.

Capire il problema
– Poiché AD Connect era giù, la rimozione dell’utente non è stata rilevata da AD Connect.
– Di conseguenza, questa eliminazione non è avvenuta in AAD. Questo significa che l’account è orfano in AAD.
– Il nuovo account ha un nuovo attributo ImmutableID (originato da ObjectGUID) on-prem. Quest’attributo non può essere modificato nel cloud per gli account sincronizzati.
Per riprodurre questo comportamento, abbiamo disinstallato AD Connect, eliminato l’account utente dall’Active Directory e re-installato l’AD Connect.

Per avere conferma del fatto che il problema sia con il differente ImmutableID, potete seguire i seguenti passaggi:
1. Recuperare l’attributo ImmutableID degli account nel cloud affetti dal problema.
Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==

2. Effettuare una ricerca metaverso per il nuovo utente creato in AD (o convertire l’ObjectGUID preso dall’AD in formato base64 con lo strumento GUID2ImmutableID) per confermare il nuovo ImmutableID.

Utilizzare l'attributo mS-DS-ConsistencyGuid per sistemare i problemi di sincronizzazione ad Office 365/AAD

3. Se avete la resilienza degli attributi, AD Connect non mostrerà alcun errore. Potete recarvi sul Portale o su PowerShell per identificare l’errore.

Utilizzare l'attributo mS-DS-ConsistencyGuid per sistemare i problemi di sincronizzazione ad Office 365/AAD

In sostanza, qualsiasi cambiamento apportiate su quest’oggetto on-premise, non si rifletterà nel cloud.

Passaggi da risolvere

1. Confermare che l’attributo utilizzato dall’AD Connect come “SourceAnchor” sia il “mS-DS-ConsistencyGuid”. Semplicemente, eseguite l’AD e scegliete la voce “View Current Configuration”.

Utilizzare l'attributo mS-DS-ConsistencyGuid per sistemare i problemi di sincronizzazione ad Office 365/AAD

2. Assicuratevi che gli attributi “UPN” e “ProxyAddresses” siano gli stessi su Office 365 e sugli account di AD: potete scaricare il report degli utenti nel Portale di Amministrazione o utilizzare PowerShell per estrarre queste informazioni. Questi attributi sono essenziali, se conoscete altri mancanti, aggiungetevi all’account nel vostro AD locale.

3. Prendete il valore ImmutableID dell’account cloud/originale.
Qui sotto il comando PowerShell:

Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==

4. Dobbiamo convertire il valore dell’“ImmutableID” in formato HEX per poterlo aggiungere all’account on-prem:

[system.convert]::FromBase64String(“kKfL2wwI+0W+rN0kfeaboA==”) | %{$a += [System.String]::Format(“{0:X}”, $_) + ” “};$result = $null;$result = $a.trimend();$result

L’output è:
90 A7 CB DB C 8 FB 45 BE AC DD 24 7D E6 9B A0

5. Ora torniamo al server AD Connect ed interrompiamo il task schedulato (è una buona tecnica poichè impedisce che la sincronizzazione dei task continui mentre stiamo effettuando il troubleshooting di:

Set-ADSyncScheduler -SyncCycleEnabled $false

6. Spostiamo l’account ad OU non sincronizzato ed eseguiamo un delta sync (richiesto per il match che accadrà in seguito).

Start-ADSyncSyncCycle -PolicyType Delta

7. Nell’account creato in ADDS, modificate il suo attributo.
Fatelo localizzando l’mS-DS-ConsistencyGuid e aggiungendo il valore HEX dallo steo 2 (se c’è un valore, l’AD Connect aggiunge l’attuale valore ObjectGUID come comportamento di default, procedete ad aggiungere quello nuovo):

Utilizzare l'attributo mS-DS-ConsistencyGuid per sistemare i problemi di sincronizzazione ad Office 365/AAD

8. Riportare l’account alla OU sincronizzato ed eseguite nuovamente un delta sync: se tutto funziona come desiderato, significa che la sincronizzazione è avvenuta in maniera corretta.

9. Aggiungete o modificate un attributo in AD per assicurarvi che la sincronizzazione funzioni come deve. Infine, controllate il portale e l’errore sarà sparito.

Utilizzare l'attributo mS-DS-ConsistencyGuid per sistemare i problemi di sincronizzazione ad Office 365/AAD

Conclusioni
Con questa nuova funzionalità, è possibile risolvere i problemi precedentemente molto complicati quando si utilizzava l’“ObjectGUID”.
Indipendentemente dallo scenario, dovremmo sempre utilizzare l’originale ImmutableID (già impostato sul cloud), convertirlo in valore HEX ed aggiungerlo all’ “mS-DS-ConsistencyGuid” per far sì che avvenga la corrispondenza.
Se state per migrare account tra diverse foreste, assicuratevi di popolare l’oggetto “mS-DS-ConsistencyGuid” della foresta desiderata con il valore dell’oggetto sorgente “ObjectGUID”.

Il supporto di Azure AD B2B Collaboration per la Google ID è in public preview

Se conosci un pochino Azure B2B Collaboration, saprai che rende incredibilmente più semplice e sicura la condivisione di applicazioni e la collaborazione al di fuori dei confini aziendali. Quello che probabilmente non sai è che è una delle funzionalità che sta crescendo più velocemente e che ogni mese più di 1 milione di nuovi utenti viene invitato a collaborare utilizzando Azure AD B2B.

Microsoft ha lavorato a lungo per rendere B2B Collaboration sempre più scorrevole ed inclusivo.
L’obiettivo è quello di permetterti di collaborare con le persone di qualsiasi azienda nel mondo, che abbiano o meno Azure AD o un dipartimento IT. Quello che Microsoft sta facendo è ridurre l’attrito durante l’invitation redemption e l’aumento delle credenziali, abilitando i tuoi partner ad utilizzare le identità esistenti per collaborare con te.

Oggi siamo felici di rivelarti il prossimo step: la preview pubblica del supporto per la Google ID.
Microsoft fino ad ora supportava l’accesso ad Azure AD per gli account Microsoft ma gli utenti richiedevano il supporto anche per provider non-Microsoft. Per questo, siamo felici di annunciare che Google è il primo provider di identità di terze parti supportato da Azure AD.

Il supporto di Azure AD B2B Collaboration per la Google ID è in public preview

Abilitare il provider Google rende l’esperienza di invito dei tuoi utenti Gmail molto più fluida. Una volta impostata la B2B Google federation per la tua azienda, gli utenti Gmail che hai invitato, potranno utilizzare la loro identità Google per registrarsi e collaborare. Non avranno più bisogno di creare un account Azure AD o Microsoft per accedere ad app e risorse che vuoi condividere con loro.

ATTENZIONE: al momento sono supportate solo le Identità Google con l’estensione
@gmail. com.
Puoi abilitare le identità Google attraverso l’Organizational relationships: una nuova esperienza di amministrazione che ti permette di gestire tutte le impostazioni relative alla collaborazione esterna.

Il supporto di Azure AD B2B Collaboration per la Google ID è in public preview

Sotto la voce Organizational relationships, puoi vedere una lista di utenti proveniente da altre aziende e creare dei “Terms of use” e “Access reviews” personalizzati per gli utenti guest.
Una volta abilitate ulteriori funzionalità, troverai altri metodi di autenticazione federata per gli utenti B2B assieme ad altre caratteristiche di collaborazione presenti alla voce Organizational relationships.

Il supporto di Azure AD B2B Collaboration per la Google ID è in public preview

Per saperne di più, visualizzate la documentazione ufficiale.
E, se ti va, rilascia il tuo feedback completando questo breve sondaggio.

AAD Connect will not start due to logon failure

In questo articolo, vi presentiamo una situazione che potrebbe capitarvi ed il comportamento che qualsiasi utente metterebbe in atto di conseguenza.
L’errore in questione, è un’ulteriore conferma del fatto che dovete sempre prestare attenzione a non installare AAD Connect su un domain controller.

La situazione che presentiamo si è creata perché l’utente amministratore doveva sincronizzare alcuni nuovi utenti ma, quando ha aperto AAD Connect, gli si è presentato il seguente messaggio:

AAD Connect will not start due to logon failure

Come si evince dal messaggio d’errore, il servizio associato “Microsoft Azure AD Sync” non sta funzionando.

AAD Connect will not start due to logon failure

Il servizio ha fallito l’esecuzione con il seguente errore: “Error 1069: The service did not start due to logon failure”.

AAD Connect will not start due to logon failure

I permessi associati dell’account “AAD_” erano confermati ed un tentativo di avviare il servizio ha fatto sì che si presentasse il medesimo errore.

Lo step successivo dell’utente, è stato quello di riavviare il server su cui AAD Connect era installato. Ma, nuovamente, AAD Connect ha restituito il medesimo errore ed il servizio non è partito.

Dopo aver rimosso e re-installato AAD Connect ed aver riavviato il server, si è presentato nuovamente il messaggio d’errore.

Successivamente, AAD Connect è stato rimosso manualmente e re-installato. Questa volta, dopo aver riavviato il server, AAD Connect funziona correttamente.

Ciò nonostante, dopo un po’ di tempo, si è ripresentato il medesimo messaggio.

A questo punto, l’utente decide di dare un’occhiata alle impostazioni di “Log on as a service” all’interno delle Local Security Policy ed assicurarsi che l’account “AAD_” (o qualsiasi gruppo di cui facesse parte) non fosse uno degli utenti assegnati.
In effetti l’impostazione “Log on as a service” era stata gestita dalle group policy ma nessuno degli account di default era assegnato (i.e. “NETWORK SERVICE” and “NT SERVICE\ALL SERVICES”).

Dopo aver ricevuto il permesso del cliente, l’impostazione “Log on as a service” all’interno delle “Default Domain Policy” era stato aggiornato per includere gli account corretti.

ATTENZIONE
L’impostazione di group policy “Log on as a service” si trova sotto le seguente voce:
Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

Una volta aggiornata la group policy, è stato eseguito il comando “gpupdate /force” dal Command Prompt per aggiungere i nuovi cambiamenti al server interessato.

A questo punto, il “Microsoft Azure AD Sync” si è avviato senza ulteriori problematiche e AAD Connect si è aperto correttamente.