Category Archives: Azure Active Directory

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.

Il supporto di Azure AD Conditional Access per il blocco delle autenticazioni legacy è in Public Preview

Oggi siamo felici di annunciarvi la Public Preview del supporto di Azure AD Conditional Access per il blocco delle autenticazioni legacy.
In passato dovevate ricorrere all’ADFS per compiere quest’operazione ma, utilizzando il conditional access, è tutto più semplice e gestibile.
Ora potete gestire il blocco dell’autenticazione legacy in quanto parte dell’intera strategia di conditional access, tutto dalla console di amministrazione di Azure AD.
Molti di voi, inoltre, avranno la possibilità di spostarsi dall’ADFS ad un modello di autenticazione basato sul cloud ed abilitato da un’autenticazione pass-through.

Prima di tutto, definiamo la legacy authentication.
Si tratta di un termine che si riferisce ai protocolli di autenticazione utilizzati dalle app, quali:
– Client Office datati che non utilizzano la modern authentication (ad esempio client Office 2010);
– Client che utilizzano protocolli mail quali IMAP/SMTP/POP.

Hackers e malintenzionati preferiscono di gran lunga questi protocolli – quasi il 100% degli attacchi alle password utilizzano protocolli di legacy authentication.
Questo perchè questo tipo di protocolli non supportano l’autenticazione interattiva, che è invece richiesta per livelli di sicurezza aggiuntivi quali la multi-factor authentication e la device authentication.

Prima di addentrarci in dettagli, vogliamo essere chiari: raccomandiamo di bloccare l’utilizzo dei protocolli di legacy authentication nel vostro tenant. É un’attività semplice e veloce ma
migliorerà di gran lunga la vostra sicurezza.

Iniziamo
Per iniziare, trovate la nuova feature sotto la condizione “Client apps” all’interno di Azure AD Conditional access.

Qui sotto i passaggi per creare una test policy:

1. Nel portale Azure AD, andate su “Conditional access” e create una nuova policy;
2. Selezionate gli utenti per il vostro gruppo pilota. Come per le policy di conditional access, vi raccomandiamo di cominciare con un ridotto numero di utenti per essere sicuri di verificare l’impatto sulla user experience;
3. Selezionate “All cloud apps”;
4. Sotto la condizione “Client apps” dovreste ora vedere la casella “Other clients”. Quest’ultima include i client Office più datati che non supportano la modern authentication così come i client che utilizzano protocolli mail quali POP, IMAP, SMTP, ecc;

Supporto di Azure AD Conditional Access per il blocco delle autenticazioni legacy è in Public Preview

5. Selezionate il comando “Block access”;
6. Salvate la policy.

Per testarla, vi raccomandiamo di installare una versione precedente del client Office (ad esempio Office 2010) e loggarvi con un utente dal gruppo pilota.

Se volete effettuare dei test con i client di basic authentication che utilizzano SMTP, POP, IMAP, ecc, prima di tutto eseguite questo comando PowerShell per il test user e, dopo un’ora, loggatevi. Il comando assicura che la policy entri in vigore entro un’ora dalla sua esecuzione. Tipicamente, ci vogliono 24 ore perchè entri in vigore con i client di autenticazione base.

A questo link trovate le FAQ per saperne di più su questa nuova funzionalità.
Se invece non avete ancora confidenza con il conditional access, trovate maggiori informazioni alla documentazione ufficiale per Azure AD conditional access.