Google Apps, AD e SSO

Siamo un piccolo negozio che esegue Google Apps (Enterprise) per le nostre esigenze di posta elettronica. Lo adoro. Internamente, stiamo usando Windows AD (2003). Nessuna lamentela neanche lì.

Vorrei che alcuni metodi di SSO andassero tra AD e Google Apps in modo tale che AD fosse l'unico posto in cui i miei amici dovevano gestire (e periodicamente CAMBIARE!) Le password.

Ho esaminato le "tfm" di google in passato, ma credo di non averlo capito. Qualcuno ha fatto questo? Se è così, saresti disposto a condividere come? Può essere fatto senza un'enorme quantità di complessità e spese?

Ci sono un paio di cose che puoi fare con Google Apps.

Puoi configurare un server SAML connesso alla tua rete AD e quindi impostare Google per l'autenticazione dell'accesso a Google Apps sul server SAML. Abbiamo usato un'applicazione php chiamata simpleSAMLphp perché abbiamo già i server configurati per eseguire PHP e abbiamo sviluppatori con competenze php. Lo svantaggio dell'utilizzo di una sola soluzione SAML è che puoi accedere solo agli account attraverso il web. Ciò significa che non puoi accedere alla tua casella di posta tramite imap / pop e non puoi accedere a Google Talk con qualsiasi vecchio client XMPP.

L'uso di SAML non crea automaticamente account nel dominio Google Apps. Probabilmente avrai anche bisogno di uno strumento che sincronizzi gli account per cui puoi utilizzare lo strumento di sincronizzazione della directory di Google Apps . Ciò ti consentirà di creare account, ma non sincronizzerà le password per impostazione predefinita perché gli hash delle password di Windows non sono reversibili e Google non può farci nulla.

È possibile utilizzare qualcosa come PasswdHk per intercettare le modifiche della password nel tuo annuncio e quindi archiviare la password in un formato (sha1 non salato) che l'utilità di sincronizzazione della directory di Google può utilizzare per impostare le password di Google Apps. Ma questo aggiunge un po 'di rischio per la sicurezza poiché Google accetterà solo hash di password md5 o sha1 non salati attraverso la sua API di provisioning e per sincronizzare con Google, in pratica è necessario archiviare questi hash. Se vuoi usarlo, è molto importante mantenere sicuri questi hash.

Hmmph. Mi hai entusiasmato tutti per SAML fino a quando non ho parlato di imap / pop. Ciò ucciderebbe tutte le persone che usano client Windows Mobile e Blackberry, no? Qualche alternativa intelligente lì?

Se si è disposti ad accettare il rischio di memorizzare gli hash delle password, è possibile combinare SSO e la sincronizzazione della directory per ottenere un sistema funzionante.

In alternativa, qualcuno potrebbe sviluppare un portale Intranet in cui gli utenti del tuo dominio dovrebbero andare per inizializzare il proprio account Google e impostare la password per l'account Google. Avevo preso in considerazione lo sviluppo di qualcosa del genere, ma non riuscivo a convincere i miei colleghi a concordare sul fatto che fosse la strada da percorrere.

L'idea di base è questa, costruisci una webapp che

• Vive sulla tua intranet e si autentica sulla tua directory attiva
• Dispone di una funzione che utilizzerà il nome utente e la password utilizzati dall'utente per accedere al sito Intranet e ottenere qualsiasi altra informazione necessaria dall'AD, quindi utilizzare l'API di provisioning di Google per aggiungere / aggiornare l'account degli utenti.

Costruire lo strumento in realtà non dovrebbe essere troppo difficile, avevo stimato di hackerare qualcosa di base che avrebbe richiesto solo 12-16 ore di tempo di sviluppo. Il vantaggio di questa soluzione è che ti offre la funzionalità Google Apps al 100%, il rovescio della medaglia è che in qualche modo disturba l'utente finale.

Anche a me piacerebbe vedere una risposta migliore a questa.

Ho giocato con Google Apps Directory Sync per sincronizzare gli utenti di Google dagli utenti di Active Directory. Sembrava bello, fino al punto in cui ho letto che l'implementazione LDAP di AD mantiene la password in un campo binario crittografato, a cui lo strumento di sincronizzazione di Google non può accedere.

L' altra soluzione SSO di Google sembra invertire la rotta, in modo che Google sia la fonte autorevole di credenziali. Non ci interessa; cosa accadrebbe sulla nostra LAN se il nostro accesso a Internet non fosse attivo?

Quindi in questo momento la mia migliore soluzione è un foglio di calcolo di Google Apps con nomi utente e password, che poi esportiamo in CSV e importiamo in blocco in Google Apps . Questo non gestisce le modifiche alla password. Finora il meglio che abbiamo è di educare i nostri utenti a cambiare sia la password di Google che quella di Windows con la stessa nuova password quando i criteri della password di Windows impongono un cambiamento.

Ecco un filtro password che memorizza l'hash nell'annuncio. http://code.google.com/p/sha1hexfltr/ Salva in modo sicuro gli hash nell'annuncio. Non è necessario SSO, non sono necessari nuovi server!

Hmm, nessuno fa la cosa SSO? Confesso di essere un po 'sorpreso!

Solo per far girare le cose: ho avuto PingConnect suggerito tramite altri canali. Qualcuno l'ha usato?

Puoi usare LemonLDAP :: NG per farlo. Vedi http://lemonldap-ng.org/documentation/latest/applications/googleapps

Alcuni prodotti come Oracle Internet Directory + Oracle SSO (e IBM TIM / TAM) consentono l'aggancio a sistemi di terze parti. Ciò significa che il prodotto è configurato per la sincronizzazione con Active Directory e memorizza le credenziali su ogni altro prodotto che si possa immaginare. Ottieni un nuovo link di accesso che semina le credenziali al sistema desiderato (in questo caso - Google Apps), e il gioco è fatto.

Tieni presente che è abbastanza complicato avviare una tale configurazione e potrebbe anche costarti un po 'di denaro, quindi non si adatta a tutte le organizzazioni.

Sembra che ci sia Google Apps Password Sync (GAPS) per la sincronizzazione delle password da utilizzare in combinazione con la sincronizzazione della directory attiva. Ma non l'ho ancora usato.