FileVault 2 Problemi di accesso su rete OpenLDAP con account amministratore, gestito, mobile su Lion 10.7.4

Naviga le tue risposte
4

Questo problema si verifica su qualsiasi macchina con Lion nel mio ambiente. Installa Lion e mi connetto a OpenLDAP per l'autenticazione. Abilito FileVault.

Alcuni utenti segnalavano che quando avrebbero riattivato il computer dalla modalità di sospensione o riavvio, l'unico account disponibile per sbloccare FileVault era Amministratore (non più l'account OpenLDAP locale memorizzato nella cache).

Nel tentativo di riprodurre questo problema, ho spento tutte le interfacce di rete sul mio MacBook Pro di prova e riavviato - FileVault abbastanza sicuro mi consentirà solo di sbloccare il mio disco rigido utilizzando la password dell'amministratore, proprio come è successo per il mio utenti.

Inoltre, quando ho provato a verificare se il mio account utente era ancora abilitato in FileVault (accedendo a Preferenze di sistema - > Sicurezza e privacy ), Sistema Preferenze arresti anomali .

Ho trovato una soluzione alternativa che a volte funziona: apri qualsiasi altro pannello Preferenze di sistema (ad esempio, Utenti e gruppi) e autenticati facendo clic sull'icona del lucchetto. Quindi fai clic su Mostra tutto per tornare all'interfaccia utente delle Preferenze di sistema e accedi a Sicurezza e amp; Privacy di nuovo. Funzionerà. Nella scheda FileVault, viene visualizzato il messaggio "Alcuni utenti non sono in grado di sbloccare questo disco" (presumibilmente il mio account Admin, gestito, mobile). Clicco sul pulsante "Abilita utenti" e viene visualizzata una finestra di dialogo, ma in questa finestra di dialogo il mio account utente è l'unico elencato e ha un segno di spunta verde, come se fosse impostato correttamente (anche quando non è ). Se faccio clic sul pulsante "Fine" qui, sembra che elabori qualcosa per un momento. Se riavvio dopo averlo fatto, funziona, e sono in grado di autenticarmi come me stesso.

Penso che quello che sta succedendo qui sia che la rete si sta spegnendo sui MacBook che sono in modalità di sospensione o spenti, e FileVault rimuove quindi tutti gli account che si autenticano con LDAP dagli utenti abilitati. Presumo che anche qui qualcosa sia rotto, a causa dello schianto che si verifica quando si cerca di indagare sulla configurazione di FileVault.

Procedura per la riproduzione

  1. Installa Lion.
  2. Connetti al mio server OpenLDAP.
  3. Abilita FileVault 2, abilita l'utente autenticato da LDAP per sbloccare FileVault.
  4. Reboot.
  5. Funziona!
  6. Accedi e disabilita le interfacce di rete, con l'obiettivo di obbligare Lion a utilizzare le credenziali LDAP memorizzate nella cache per l'autenticazione dell'utente in FileVault.
  7. Reboot.
  8. L'unico utente disponibile per l'autenticazione è Administrator.
  9. Dopo aver effettuato l'accesso come amministratore, quindi disconnettendosi e ricollegandosi come utente dell'autore LDAP, provo ad accedere a Preferenze di sistema - > Sicurezza e amp; Privacy. Ciò causa l'arresto anomalo delle Preferenze di sistema con il dump di arresto anomalo incollato di seguito. L'unico modo per prevenire questo arresto anomalo è quello di autenticarsi facendo clic sull'icona del lucchetto in qualsiasi altro pannello Preferenze di sistema (ad esempio Utenti e gruppi), quindi fare clic su "Mostra tutto", quindi fare nuovamente clic su "Sicurezza e privacy". Questa volta funzionerà. I dettagli sono riportati nella sezione Riepilogo di questo rapporto sui bug.

Risultati previsti

Mi aspetto che l'autenticazione di FileVault 2 funzioni per l'utente originariamente impostato in.

Risultati effettivi

Questo non sta succedendo e gli utenti finiscono per non essere in grado di sbloccare la loro macchina (e quindi, non possono lavorare senza di me (il sysadmin) in arrivo e sbloccare la loro macchina come Amministratore, quindi disconnettersi e lasciarli accedere in OS X sotto il loro account). Ho presentato una segnalazione di bug con Apple, ma non ho sentito nulla da loro. Ho intenzione di entrare in contatto con il supporto telefonico per vedere se è di qualche utilità, ma sono curioso di sapere se qualcuno qui ha incontrato e in qualche modo superare questi problemi.

Note

Questo è il registro di crash generato quando si tenta di accedere a Security & Privacy dopo che si è verificato il problema:

link

    
posta 05.06.2012 - 16:27
fonte

2 risposte

5

FileVault 2 utilizza l'attributo utente GeneratedUID per salvare chi è autorizzato a sbloccare un volume crittografato. Se GeneratedUID di un utente è diverso da quanto generato (o estratto da LDAP) quando FileVault 2 è stato abilitato, all'utente non sarà permesso di sbloccare la macchina, in quanto il suo account apparirà non disponibile a il menu EFI. Inoltre, questo causa l'arresto anomalo delle Preferenze di Sistema sul proprio Mac ogni volta che provano ad accedere a Sicurezza & Privacy prefpane.

Questo problema si verifica quando /usr/bin/mcxrefresh viene eseguito e ottiene un valore null o un valore diverso da quello memorizzato localmente da LDAP (se l'attributo non è definito per l'utente in questione o è definito in modo errato, rispettivamente), sovrascrivere GeneratedUID memorizzato localmente (che viene generato e memorizzato solo localmente quando FileVault 2 è abilitato senza un attributo LDAP corrispondente).

In altre parole, se un valore apple-generateduid esiste in LDAP per un utente e viene mappato correttamente sul Mac dell'utente con l'attributo GeneratedUID , FileVault 2 non genera un nuovo valore, ma utilizzerà il valore memorizzato in LDAP.

Sono riuscito a risolvere questo problema aggiungendo un attributo chiamato apple-generateduid alla voce LDAP di qualsiasi utente che ha riscontrato questo problema. Potrei generare un valore casuale per questo attributo in Python eseguendo il seguente one-liner dal mio terminale:

python -c 'import uuid; print str(uuid.uuid4()).upper();'

Questo non è l'unico passo, comunque. È inoltre necessario aggiungere una mappatura per questo attributo sul lato client. Questo è fatto facilmente usando i seguenti passi:

  1. Apri Preferenze di sistema .
  2. Fai clic su Utenti e amp; Gruppi .
  3. Fai clic su Opzioni di accesso .
  4. Fai clic sull'icona Unlock .
  5. In Server account di rete , fai clic su Modifica .
  6. Fai clic per evidenziare il tuo server di directory.
  7. Sotto Servizi , fai doppio clic sul tuo servizio di directory (nel mio caso, era LDAPv3)
  8. Nella finestra che si apre, evidenzia il nome della configurazione, quindi fai clic sul pulsante Modifica ... .
  9. Sotto Cerca e amp; Mapping scorri verso il basso e fai clic su Utenti per evidenziarlo.
  10. Fai clic sul pulsante Aggiungi (quello a sinistra).
  11. Scegli GeneratedUID dall'elenco dei tipi di attributi disponibili.
  12. Nella colonna di destra, fai clic sul pulsante Aggiungi e digita apple-generateduid . Fai clic su OK per salvare le modifiche finché non tornerai alla finestra di dialogo Preferenze di sistema principale.
  13. A questo punto è stata creata una mappatura da GeneratedUID a apple-generateduid . Ora, quando OS X cerca il valore GeneratedUID, otterrà il valore di apple-generateduid dall'utente nelle domande LDAP.

Infine, è importante che il valore memorizzato localmente di GeneratedUID e il valore memorizzato su LDAP corrispondano. Esegui il seguente comando e assicurati che i due valori GeneratedUID corrispondano:

dscl /Search search /Users GeneratedUID $(dscl . read /Users/$(echo $USER) GeneratedUID | cut -d " " -f2)

    
risposta data 18.06.2012 - 15:58
fonte
0

Supponendo che siano account mobili (che dovrebbero memorizzare nella cache le informazioni utente richieste localmente al momento dell'accesso) e che la connettività di rete al server LDAP non sia immediatamente disponibile / disponibile, sono molto sospettoso di questa linea di log:

2 libcsfde.dylib 0x00007fff8565af1f CSFDEGetUserEntryForUUID + 134

Questo è il thread che si blocca nel tuo log e subito prima che si blocchi, sta tentando di ottenere la lunghezza di una stringa restituita come risultato di quella particolare chiamata di libreria (privata).

Il nome della chiamata sembra implicare: CoreServices Full Data / Disk Encryption (aka FileVault2) "GetUserEntryForUUID" - nota: questa è una funzione che richiede FileVault per le informazioni dell'utente basate su un UUID, non il framework Collaboration, i servizi di identità, DirectoryServices / OpenDirectory, ecc.

Questo bit di codice chiede a FileVault di fornire dettagli su un utente con solo informazioni UUID, il che sembra che FV stia tracciando le informazioni dell'utente separatamente (eventualmente) dal resto di OS X. Questo è accurato , poiché la procedura FileVault2, come parte della marcatura degli utenti disponibili per sbloccare la partizione del sistema operativo di avvio, scrive alcune informazioni sulla partizione di ripristino.

Tuttavia, sembra che ci sia una rottura da qualche parte con i meccanismi di autenticazione degli account di directory OpenLDAP / mobile / "alternativo" e le informazioni necessarie non sono state scritte per poterlo sbloccare senza l'accesso alla rete al server OpenLDAP.

Questo è solo uno sparo al buio - ma forse un rappresentante della Apple sarebbe in grado di aiutare di più con questo. Mi sembra un vero bug vero per me.

    
risposta data 08.06.2012 - 20:30
fonte

Leggi altre domande sui tag

Le icone sul desktop possono rallentare Mac? aggiornamento iphone - è stato eseguito il backup?