Requisiti di sviluppo di applicazioni Windows Vista per la compatibilità del controllo dell'account utente

 

Jennifer Allen

Aggiornamento giugno 2007

Riepilogo: Questo white paper è progettato per aiutare gli sviluppatori di applicazioni a progettare applicazioni con funzionalità di Windows Vista conformi a Controllo account utente. Sono inclusi i passaggi dettagliati relativi al processo di progettazione, insieme a esempi di codice, requisiti e procedure consigliate. Questo documento illustra anche gli aggiornamenti tecnici e le modifiche apportate all'esperienza utente in Windows Vista. (71 pagine stampate).

Contenuto

Perché il controllo dell'account utente?
Windows Vista Aggiornamenti
Nuove tecnologie per Windows Vista
Architettura di Controllo dell'account utente
Controllo dell'account utente influisce sull'applicazione?
Progettazione di applicazioni per Windows Vista
Distribuzione e applicazione di patch alle applicazioni per gli utenti standard
Risoluzione dei problemi comuni
Riferimenti

Perché il controllo dell'account utente?

Gli sviluppatori di applicazioni hanno creato in modo coerente applicazioni Windows che richiedono diritti utente eccessivi e privilegi di Windows, spesso richiedendo che l'utente in esecuzione sia un amministratore. Di conseguenza, pochi utenti di Windows vengono eseguiti con i diritti utente minimi e i privilegi di Windows necessari. Molte aziende, cercando di bilanciare la facilità di distribuzione e facilità d'uso con la sicurezza, hanno spesso fatto ricorso alla distribuzione dei propri desktop come amministratore a causa di problemi di compatibilità delle applicazioni utente standard.

L'elenco seguente illustra i motivi aggiuntivi per cui è difficile eseguire come utente standard nei computer pre-Microsoft Windows Vista:

1. Molte applicazioni Windows richiedono che l'utente connesso sia un amministratore, ma che non richieda effettivamente l'accesso a livello di amministratore. Queste applicazioni eseguono diversi controlli di accesso amministratore prima di poter essere eseguiti, tra cui:
   • Controllo del token di accesso dell'amministratore.
   • Richieste di accesso "Tutti gli accessi" nelle posizioni protette dal sistema.
   • Scrivere dati in percorsi protetti, ad esempio %ProgramFiles%, %WinDir%, e HKLM\Software.
2. Molte applicazioni Windows non sono progettate con il concetto di privilegi minimi e non separano la funzionalità utente e amministratore in due processi distinti.
3. Windows 2000 e Windows XP creano ogni nuovo account utente come amministratore per impostazione predefinita; pertanto, i componenti principali di Windows, ad esempio data e ora e i pannelli di controllo risparmio energia non funzionano bene per un utente standard
4. Gli amministratori di Windows 2000 e Windows XP devono creare due account utente separati, uno per le attività amministrative e un account utente standard per eseguire attività quotidiane. Pertanto, gli utenti devono disconnettersi dagli account utente standard e accedere di nuovo come amministratore o usare RunAs per eseguire qualsiasi attività amministrativa.

Con controllo dell'account utente Microsoft offre una tecnologia per semplificare la distribuzione di desktop utente standard, nell'azienda e a casa.

Basandosi sull'architettura di sicurezza di Windows come originariamente progettato nel sistema operativo Microsoft Windows NT 3.1, il team UAC ha cercato di implementare un modello utente standard che era sia flessibile che più sicuro. Nelle versioni precedenti di Windows viene creato un token di accesso per un amministratore durante il processo di accesso. Il token di accesso dell'amministratore include la maggior parte dei privilegi di Windows e la maggior parte degli identificatori di sicurezza amministrativi (SID). Questo token di accesso garantisce che un amministratore possa installare le applicazioni, configurare il sistema operativo e accedere a qualsiasi risorsa.

Il team UAC ha adottato un approccio drasticamente diverso al processo di creazione dei token di accesso in Windows Vista. Quando un utente amministratore accede a un computer Windows Vista, vengono creati due token di accesso: un token di accesso utente standard filtrato e un token di accesso amministratore completo. Anziché avviare il desktop (Explorer.exe) con il token di accesso dell'amministratore, viene usato il token di accesso utente standard. Tutti i processi figlio ereditano da questo avvio iniziale del desktop (processo di explorer.exe), che consente di limitare la superficie di attacco di Windows Vistas. Per impostazione predefinita, tutti gli utenti, inclusi gli amministratori, accedono a un computer Windows Vista come utenti standard.

Nota Esiste un'eccezione all'istruzione precedente: gli utenti guest accedono al computer con meno diritti utente e privilegi rispetto agli utenti standard.

Quando un amministratore tenta di eseguire un'attività amministrativa, ad esempio l'installazione di un'applicazione, controllo dell'account utente richiede all'utente di approvare l'azione. Quando l'utente approva l'azione, l'attività viene avviata con il token di accesso amministratore completo dell'amministratore. Si tratta del comportamento predefinito del prompt degli amministratori ed è configurabile nello snap-in Gestione criteri di sicurezza locale (secpol.msc) e con Criteri di gruppo (gpedit.msc).

Nota Un account amministratore in un computer Windows Vista con controllo dell'account utente abilitato è detto anche account amministratore in Amministrazione modalità approvazione. Amministrazione modalità approvazione identifica l'esperienza utente predefinita per gli amministratori.

Ogni elevazione amministrativa è anche un processo specifico, che impedisce ad altri processi di usare il token di accesso senza richiedere all'utente l'approvazione. Di conseguenza, gli utenti amministratori hanno un controllo più granulare sulle applicazioni installate, con un impatto significativo sul software dannoso che prevede che l'utente connesso sia in esecuzione con un token di accesso amministratore completo.

Gli utenti standard hanno anche la possibilità di elevare i privilegi nel flusso ed eseguire attività amministrative usando l'infrastruttura di Controllo dell'account utente. Quando un utente standard tenta di eseguire un'attività amministrativa, controllo dell'account utente richiede all'utente di immettere credenziali valide per un account amministratore. Si tratta del comportamento predefinito del prompt degli utenti standard ed è configurabile nello snap-in Gestione criteri di sicurezza locale (secpol.msc) e con Criteri di gruppo (gpedit.msc).

Windows Vista Aggiornamenti

Gli aggiornamenti seguenti riflettono le modifiche di base cumulative apportate alle funzionalità che si sono verificate in Windows Vista.

Controllo dell'account utente abilitato per impostazione predefinita

Di conseguenza, è possibile che si verifichino alcuni problemi di compatibilità con applicazioni diverse che non sono ancora state aggiornate per il componente UAC di Windows Vista. Se un'applicazione richiede un token di accesso amministratore (questo è indicativo di un errore di "accesso negato" restituito quando si tenta di eseguire l'applicazione), è possibile eseguire il programma come amministratore usando l'opzione Esegui come amministratore nel menu di scelta rapida (fare clic con il pulsante destro del mouse). Come eseguire questa operazione è descritta più avanti in questo documento nella sezione Running Programs as an Administrator .How to do this is document later in this document in this document in the Running Programs as an Administrator section.

Tutti gli account utente successivi vengono creati come utenti standard

Sia gli account utente standard che gli account utente amministratore possono sfruttare la sicurezza avanzata di Controllo dell'account utente. Nelle nuove installazioni, per impostazione predefinita, il primo account utente creato è un account amministratore locale in Amministrazione modalità approvazione (controllo dell'account utente abilitato). Tutti gli account successivi vengono quindi creati come utenti standard.

Le richieste di elevazione dei privilegi vengono visualizzate sul desktop protetto per impostazione predefinita

Le richieste di consenso e credenziali vengono visualizzate sul desktop protetto per impostazione predefinita in Windows Vista.

Le richieste di elevazione dei privilegi per le applicazioni in background vengono ridotte a icona sulla barra delle applicazioni

Le applicazioni in background richiederanno automaticamente all'utente l'elevazione dei privilegi sulla barra delle applicazioni, invece di passare automaticamente al desktop sicuro per l'elevazione dei privilegi. La richiesta di elevazione dei privilegi verrà visualizzata ridotta a icona sulla barra delle applicazioni e lampeggia per notificare all'utente che un'applicazione ha richiesto l'elevazione dei privilegi. Un esempio di elevazione in background si verifica quando un utente accede a un sito Web e inizia a scaricare un file di installazione. L'utente passa quindi a controllare la posta elettronica mentre l'installazione viene scaricata in background. Una volta completato il download in background e l'installazione inizia, l'elevazione viene rilevata come attività in background anziché come attività in primo piano. Questo rilevamento impedisce all'installazione di rubare bruscamente lo stato attivo dello schermo dell'utente mentre l'utente sta eseguendo un'altra attività, leggendo la posta elettronica. Questo comportamento crea un'esperienza utente migliore per la richiesta di elevazione dei privilegi. Informazioni sul modo in cui gli sviluppatori di applicazioni possono assicurarsi che le applicazioni non vengano ridotte a icona sulla barra delle applicazioni quando richiedono l'elevazione dei privilegi più avanti in questo documento.

Le elevazioni dei privilegi sono bloccate nel percorso di accesso dell'utente

Le applicazioni che iniziano quando l'utente accede e richiedono l'elevazione dei privilegi sono ora bloccate nel percorso di accesso. Senza impedire alle applicazioni di richiedere l'elevazione dei privilegi nel percorso di accesso dell'utente, sia gli utenti standard che gli amministratori devono rispondere a una finestra di dialogo Controllo account utente in ogni accesso. Windows Vista notifica all'utente se un'applicazione è stata bloccata posizionando un'icona nell'area di notifica. L'utente può quindi fare clic con il pulsante destro del mouse su questa icona per eseguire applicazioni che sono state bloccate per richiedere l'elevazione dei privilegi durante l'accesso dell'utente. L'utente può gestire le applicazioni di avvio disabilitate o rimosse da questo elenco facendo doppio clic sull'icona della barra.

L'account amministratore predefinito è disabilitato per impostazione predefinita nelle nuove installazioni

L'account amministratore predefinito è disabilitato per impostazione predefinita in Windows Vista. Se Windows Vista determina durante un aggiornamento da Windows XP che l'amministratore predefinito è l'unico account amministratore locale attivo, Windows Vista lascia l'account abilitato e inserisce l'account in Amministrazione modalità approvazione. L'account amministratore predefinito, per impostazione predefinita, non può accedere al computer in modalità provvisoria. Per altre informazioni, vedere le sezioni seguenti. L'account amministratore predefinito viene creato durante l'installazione con il nome utente Administrator.

Non aggiunto a un dominio

Quando è presente almeno un account amministratore locale abilitato, la modalità provvisoria non consente l'accesso con l'account amministratore predefinito disabilitato. È invece possibile usare qualsiasi account amministratore locale per accedere. Se l'ultimo account amministratore locale è inavvertitamente abbassato di livello, disabilitato o eliminato, la modalità provvisoria consentirà all'account amministratore predefinito disabilitato di accedere per il ripristino di emergenza.

Aggiunto a un dominio

L'account amministratore predefinito disabilitato in tutti i casi non può accedere in modalità provvisoria. Un account utente membro del gruppo Domain Admins può accedere al computer per creare un amministratore locale, se non esiste.

Nota Se l'account amministrativo del dominio non ha mai eseguito l'accesso in precedenza, il computer deve essere avviato in modalità provvisoria con rete perché le credenziali non saranno state memorizzate nella cache.

Nota Una volta che il computer è disgiunti, verrà ripristinato il comportamento non aggiunto a un dominio illustrato in precedenza.

Controllo dell'account utente e scenari remoti

Quando un amministratore accede a un computer Windows Vista in remoto, tramite Desktop remoto, ad esempio, l'utente viene connesso al computer come utente standard per impostazione predefinita. L'amministrazione remota è stata modificata per essere restrittiva in transito. Ciò consente di impedire a software dannoso di eseguire "loopback" dell'applicazione se un utente è in esecuzione con potenziale amministrativo.

account utenti locali

Quando un utente con un account amministratore nel database sam (SAM) locale di Un computer Windows Vista si connette in remoto a un computer Windows Vista, l'utente non ha alcun potenziale di elevazione nel computer remoto e non può eseguire attività amministrative. Se l'utente vuole amministrare la workstation con un account SAM, l'utente deve accedere in modo interattivo al computer da amministrare.

Account utente di dominio

Quando un utente con un account utente di dominio accede a un computer Windows Vista in remoto in cui l'utente è membro del gruppo Administrators, l'utente di dominio verrà eseguito con un token di accesso amministratore completo nel computer remoto e l'interfaccia utente non sarà effettiva.

Nuovo elenco di Controllo di accesso predefinito (ACL) Impostazioni

Gli elenchi di controllo di accesso in determinate directory di Windows sono stati modificati per abilitare la condivisione e la collaborazione dei dati nelle directory dei dati e all'esterno delle directory protette degli utenti. La directory protetta di un utente è il profilo utente (ad esempio C:\Users\Denise\Pictures\), mentre un esempio di una directory dati si trova all'esterno della partizione del sistema operativo in un'unità dati (ad esempio D:\Pictures\). Poiché la directory radice, C in questa istanza, è protetta da elenchi di controllo di accesso più restrittivi, gli utenti non erano in grado di usare le directory dei dati nelle prime versioni di Windows Vista.

Queste modifiche ACL garantiscono che gli utenti possano condividere e modificare i file senza dover fornire l'approvazione a una finestra di dialogo Controllo account utente. Inoltre, gli utenti possono ora rendere privata una cartella. Questa modifica garantisce che gli utenti possano comunque mantenere facilmente la riservatezza e l'integrità dei dati nelle unità dati. Queste cartelle private saranno comunque leggibili da altri amministratori se elevate e devono essere usate per mantenere i dati privati dagli utenti standard.

Di seguito sono riportate le impostazioni predefinite dell'elenco di controllo di accesso in %systemroot% e l'unità dati in Windows XP.

Impostazioni ACL %systemroot% e unità dati di Windows XP

Utente o gruppo	Controllo di accesso voce
BUILTIN\Administrators	Controllo completo
NT AUTHORITY\SYSTEM	Controllo completo
CREATOR OWNER	Controllo completo
BUILTIN\Users	Read Accesso speciale: FILE_APPEND_DATA Accesso speciale: FILE_WRITE_DATA
Tutti	Read

La tabella seguente illustra in dettaglio le nuove impostazioni dell'elenco di controllo di accesso all'unità dati di Windows Vista per le unità dati create con format.exe.

Impostazioni ACL dell'unità dati di Windows Vista

Utente o gruppo	Controllo di accesso voce
BUILTIN\Administrators	Controllo completo
NT AUTHORITY\SYSTEM	Controllo completo
NT AUTHORITY\Utenti autenticati	Modifica
BUILTIN\Users	Lettura ed esecuzione Lettura generica, esecuzione generica

La tabella seguente descrive in dettaglio le nuove impostazioni dell'elenco di controllo di accesso all'elenco di controllo di accesso al sistema operativo Windows Vista (%systemroot%).

Impostazioni ACL di Windows Vista %systemroot%

Utente o gruppo	Controllo di accesso voce
BUILTIN\Administrators	Controllo completo
NT AUTHORITY\SYSTEM	Controllo completo
BUILTIN\Users	Lettura ed esecuzione
NT AUTHORITY\Utenti autenticati	Modifica Accodare dati
Etichetta obbligatoria\Livello obbligatorio	Nessuna scrittura

Nuove impostazioni di sicurezza dell'interfaccia utente e modifiche al nome dell'impostazione di sicurezza

Le nuove impostazioni di sicurezza e gli aggiornamenti dei nomi delle impostazioni di sicurezza sono dettagliate nella sezione Riferimenti di questo documento.

Nuove tecnologie per Windows Vista

Le sezioni seguenti illustrano nuove tecnologie per Windows Vista, tra cui il rilevamento del programma di installazione, l'applicazione di patch utente standard con Windows Installer 4.0, l'isolamento dei privilegi dell'interfaccia utente e la virtualizzazione.

Servizio ActiveX Installer

Il servizio di installazione ActiveX consente alle aziende di delegare l'installazione del controllo ActiveX per gli utenti standard. Questo servizio garantisce che le attività aziendali di routine non siano impedite da installazioni e aggiornamenti del controllo ActiveX non riusciti. Windows Vista include anche le impostazioni Criteri di gruppo che consentono ai professionisti IT di definire GLI URL host da cui gli utenti standard possono installare controlli ActiveX. Il servizio ActiveX Installer è costituito da un servizio Windows, un modello amministrativo Criteri di gruppo e alcune modifiche in Internet Explorer ed è un componente facoltativo che verrà abilitato solo nei client in cui è installato.

Rilevamento del programma di installazione

I programmi di installazione sono applicazioni progettate per distribuire software e la maggior parte della scrittura nelle directory di sistema e nelle chiavi del Registro di sistema. Queste posizioni di sistema protette sono in genere scrivibili solo dagli utenti amministratore; ciò significa che gli utenti standard non hanno accesso sufficiente per installare i programmi. Windows Vista rileva in modo euristico i programmi di installazione e richiede le credenziali di amministratore o l'approvazione dell'utente amministratore per eseguire con privilegi di accesso. Windows Vista rileva anche gli aggiornamenti e i programmi di annullamento dell'installazione. Si noti che un obiettivo di progettazione dell'interfaccia utente consiste nel impedire l'esecuzione di installazioni senza la conoscenza e il consenso dell'utente perché scrivono in aree protette del file system e del Registro di sistema.

Importante Quando si sviluppano nuovi programmi di installazione, molto simile allo sviluppo di programmi per Windows Vista, assicurarsi di incorporare un manifesto dell'applicazione con un elemento requestedExecutionLevel appropriato (vedere passaggio sei: Creare e incorporare un manifesto dell'applicazione con l'applicazione). Quando il programma di installazione richiestoExecutionLevel è presente nel manifesto dell'applicazione incorporata, esegue l'override del rilevamento del programma di installazione.

Il rilevamento del programma di installazione si applica solo a:

• Eseguibili a 32 bit
• Applicazioni senza una richiestaExecutionLevel
• Processi interattivi in esecuzione come utente standard con LUA abilitato

Prima di creare un processo a 32 bit, gli attributi seguenti vengono controllati per determinare se è un programma di installazione:

• Il nome del file include parole chiave come "install", "setup", "update" e così via.
• Parole chiave nei campi Risorse di controllo delle versioni seguenti: Fornitore, Nome società, Nome prodotto, Descrizione file, Nome file originale, Nome interno e Nome esportazione.
• Parole chiave nel manifesto side-by-side incorporato nel file eseguibile.
• Parole chiave in voci di StringTable specifiche collegate nel file eseguibile.
• Attributi chiave nei dati RC collegati nel file eseguibile.
• Sequenze di destinazione di byte all'interno del file eseguibile.

Nota Le parole chiave e le sequenze di byte sono state derivate da caratteristiche comuni osservate da varie tecnologie di installazione.

Assicurarsi di esaminare attentamente l'intero documento, incluso il passaggio Sei: Creare e incorporare un manifesto applicazione con l'applicazione.

Nota Controllo account utente: rilevare le installazioni dell'applicazione e richiedere l'impostazione di elevazione deve essere abilitata per il rilevamento del programma di installazione per rilevare i programmi di installazione. Questa impostazione è abilitata per impostazione predefinita e può essere configurata con lo snap-in Di Security Policy Manager (secpol.msc) o con Criteri di gruppo (gpedit.msc).

Informazioni generali e una panoramica di Microsoft Windows Installer sono disponibili in MSDN Library.

Applicazione di patch in un ambiente UAC

Microsoft Windows Installer 4.0 è stato progettato con L'interfaccia utente in mente per semplificare le installazioni e l'applicazione. Con l'introduzione di Windows Installer 4.0, le patch possono essere applicate alle applicazioni senza reinstallare una versione più recente dell'applicazione. Questo metodo è ideale quando un'applicazione viene distribuita in un'installazione per computer e le patch devono essere distribuite da un utente senza richiedere un token di accesso amministrativo. Per informazioni su come creare e applicare patch alle applicazioni, vedere Patching Per-User Managed Applications.

Integrazione del Centro sicurezza

Quando l'interfaccia utente è disabilitata in un computer Windows Vista, il Centro sicurezza crea un avviso e chiede all'utente di riabilitare l'interfaccia utente. Il Centro sicurezza visualizza questo avviso dopo il riavvio del computer dopo la modifica dell'impostazione dell'interfaccia utente.

Isolamento dei privilegi dell'interfaccia utente

L'isolamento dei privilegi dell'interfaccia utente (UIPI) è uno dei meccanismi che consentono di isolare le applicazioni in esecuzione come amministratore completo dai processi in esecuzione come account inferiore a un amministratore nello stesso desktop interattivo. UIPI è specifico del sottosistema di finestra e grafica noto come USER che supporta i controlli windows e interfaccia utente. UIPI impedisce a un'applicazione con privilegi inferiori di usare i messaggi di Windows per inviare l'input da un processo a un processo con privilegi più elevati. L'invio di input da un processo a un altro consente a un processo di inserire l'input in un altro processo senza che l'utente fornisca azioni tramite tastiera o mouse.

Il concetto alla base di UIPI è semplice. Windows Vista definisce un set di livelli di privilegi dell'interfaccia utente in modo gerarchico. La natura dei livelli è tale che i livelli di privilegio più elevati possono inviare messaggi finestra alle applicazioni in esecuzione a livelli inferiori. Tuttavia, i livelli inferiori non possono inviare messaggi di finestra alle finestre dell'applicazione a livelli più elevati.

Il livello dei privilegi dell'interfaccia utente è a livello di processo. Quando un processo viene inizializzato, il sottosistema Utente chiama nel sottosistema di sicurezza per determinare il livello di integrità del desktop assegnato nel token di accesso di sicurezza del processo. Il livello di integrità del desktop viene impostato dal sottosistema di sicurezza quando il processo viene creato e non cambia. Di conseguenza, il livello di privilegi dell'interfaccia utente viene impostato anche dal sottosistema Utente quando il processo viene creato e non cambia.

Tutte le applicazioni eseguite da un utente standard hanno lo stesso livello di privilegi dell'interfaccia utente. Come utente standard, le applicazioni vengono eseguite a un singolo livello di privilegio. UIPI non interferisce o modifica il comportamento della messaggistica delle finestre tra le applicazioni allo stesso livello di privilegio. UIPI viene applicato per un utente membro del gruppo administrators e può eseguire applicazioni come utente standard (talvolta definito processo con un token di accesso filtrato) ed elabora anche l'esecuzione con un token di accesso amministratore completo sullo stesso desktop. UIPI impedisce ai processi con privilegi inferiori di accedere ai processi con privilegi più elevati bloccando il comportamento seguente.

Un processo con privilegi inferiori non può:

• Eseguire una convalida dell'handle della finestra con privilegi di processo più elevati.
• SendMessage o PostMessage a finestre dell'applicazione con privilegi più elevati. Queste API (Application Programming Interface) restituiscono esito positivo, ma eliminano automaticamente il messaggio della finestra.
• Usare gli hook di thread per connettersi a un processo con privilegi più elevati.
• Usare hook journal per monitorare un processo con privilegi più elevati.
• Eseguire l'inserimento di DLL (Dynamic Link Library) in un processo con privilegi più elevati.

Con UIPI abilitato, le risorse UTENTE condivise seguenti vengono comunque condivise tra processi a livelli di privilegio diversi:

• Finestra desktop, che possiede effettivamente la superficie dello schermo
• Memoria condivisa di sola lettura desktop
• Tabella Atom globale
• Appunti

Il disegno sullo schermo è un'altra azione non bloccata da UIPI. Il disegno sullo schermo fa riferimento al processo di utilizzo del metodo Paint per visualizzare il contenuto in un output esterno, ad esempio un monitor. Il modello USER/graphics device interface (GDI) non consente il controllo sulle superfici di disegno; pertanto, è possibile che un'applicazione con privilegi inferiori dipinga l'area di superficie di una finestra dell'applicazione con privilegi più elevati.

Nota Poiché La shell di Windows (Explorer) è in esecuzione come processo utente standard, qualsiasi altro processo in esecuzione come utente standard può comunque inviare le sequenze di tasti. Questo è il motivo principale per cui un account amministratore in Amministrazione modalità approvazione viene richiesto il consenso per l'elevazione dei privilegi quando avvia un'azione amministrativa, ad esempio facendo doppio clic su un Setup.exe o facendo clic su un'icona di protezione elevazione.

Virtualizzazione

Importante La virtualizzazione viene implementata per migliorare i problemi di compatibilità delle applicazioni per le applicazioni in esecuzione come utente standard in Windows Vista. Gli sviluppatori non devono basarsi sulla virtualizzazione presente nelle versioni successive di Windows.

Prima di Windows Vista, molte applicazioni venivano in genere eseguite dagli amministratori. Di conseguenza, le applicazioni possono leggere e scrivere liberamente file di sistema e chiavi del Registro di sistema. Se queste applicazioni fossero eseguite da un utente standard, l'utente non riuscirebbe a causa di un accesso insufficiente. Windows Vista migliora la compatibilità delle applicazioni per questi utenti reindirizzando le scritture (e le successive operazioni di file o registro) a un percorso per utente all'interno del profilo dell'utente. Ad esempio, se un'applicazione tenta di scrivere in C:\Program Files\Contoso\Settings.ini e l'utente non dispone delle autorizzazioni per scrivere in tale directory, la scrittura verrà reindirizzata a C:\Users\<nome> utente\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. Per il Registro di sistema, se un'applicazione tenta di scrivere in HKEY_LOCAL_MACHINE\Software\Contoso\ verrà automaticamente reindirizzata a HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso o HKEY_USERS\< SID >utente _Classes\VirtualStore\Machine\Software\Contoso.

La figura seguente illustra in dettaglio il processo di virtualizzazione in Windows Vista. In questo esempio Denise è un amministratore in Amministrazione modalità approvazione e Brian è un utente standard. La virtualizzazione è costituita da due componenti: virtualizzazione dei file e virtualizzazione del Registro di sistema.

Figura 1. Processo di virtualizzazione

Importante Durante lo sviluppo di programmi Windows Vista, per ridurre la complessità dei file virtualizzati e delle chiavi del Registro di sistema, assicurarsi di incorporare un manifesto dell'applicazione con una richiesta appropriataExecutionLevel per disattivare la virtualizzazione di file e registro.

La virtualizzazione è abilitata solo per:

• Processi interattivi a 32 bit
• File/cartella e chiavi del Registro di sistema scrivibili dall'amministratore

La virtualizzazione è disabilitata per:

• Processi a 64 bit
• Processi non interattivi
• Processi che rappresentano
• Chiamanti in modalità kernel
• Eseguibili con un oggetto requestedExecutionLevel

Virtualizzazione e roaming:

• I file/cartelle e le chiavi del Registro di sistema di virtualizzazione non vengono trasferiti (vedere profili mobili)
• Associato a oggetti globali che non eseguono il roaming

Virtualizzazione file

La virtualizzazione dei file risolve la situazione in cui un'applicazione si basa sulla possibilità di archiviare un file, ad esempio un file di configurazione, in un percorso di sistema in genere scrivibile solo dagli amministratori. L'esecuzione di programmi come utente standard in questa situazione potrebbe causare errori del programma a causa di livelli di accesso insufficienti.

Quando un'applicazione scrive in un percorso di sistema scrivibile solo dagli amministratori, Windows scrive tutte le operazioni di file successive in un percorso specifico dell'utente nella directory dell'archivio virtuale, che si trova in %LOCALAPPDATA%\VirtualStore. Successivamente, quando l'applicazione legge questo file, il sistema fornirà quello nell'archivio virtuale. Poiché l'infrastruttura di sicurezza di Windows elabora la virtualizzazione senza l'assistenza dell'applicazione, l'applicazione ritiene che sia stata in grado di leggere e scrivere direttamente in Programmi. La trasparenza della virtualizzazione dei file consente alle applicazioni la percezione che stanno scrivendo e leggendo dalla risorsa protetta, quando infatti accedono alla versione virtualizzata.

Nota Quando si enumera le risorse nelle cartelle e nel Registro di sistema, Windows Vista unisce le chiavi globali di file/cartelle e registro di sistema in un unico elenco. In questa visualizzazione unita, la risorsa globale (protetta) viene elencata insieme alla risorsa virtualizzata.

Importante La copia virtuale sarà sempre presente per prima all'applicazione. Ad esempio, config.ini è disponibile in \PF\App\config.ini e %LOCALAPPDATA%\VirtualStore\config.ini e il config.ini nell'archivio virtuale sarà sempre quello letto, anche se \PF\App\config.ini viene aggiornato.

La figura seguente illustra in che modo vengono visualizzate le visualizzazioni globali e unite per le risorse virtualizzate per utenti diversi.

Figura 2. Risorse e viste virtualizzate

Di seguito è riportato un esempio del processo di virtualizzazione dei file:

Syed Abbas, un rappresentante di vendita presso Woodgrove Bank, è in esecuzione con un account utente standard in un computer che condivide con altri rappresentanti di vendita. Syed usa spesso un'applicazione foglio di calcolo per aggiornare e salvare un file nella directory Programmi\SalesV1\: \Program Files\SalesV1\SalesData.txt. Anche se Programmi\SalesV1\ è protetto, il file verrà salvato correttamente dal punto di vista dell'applicazione foglio di calcolo a causa della virtualizzazione dei file di Windows Vista. A tale scopo, la scrittura del file viene reindirizzata a Users\username\appdata\Virtual Store\Program Files\SalesV1\SalesData.txt. Quando Syed apre Esplora risorse e passa alla directory Programmi, visualizzerà la visualizzazione globale del file SalesData.txt.

Nota Affinché Syed rilevi i file virtualizzati, deve passare all'archivio virtuale con il pulsante File di compatibilità sulla barra degli strumenti di Explorer.

Tuttavia, dopo Stuart Munson, un altro rappresentante vendite, accede alla workstation, non visualizzerà il file SalesData.txt nella directory Programmi\SalesV1\. Se un utente diverso usa il computer e scrive il file \Program files\SalesV1\SalesData.txt, tale scrittura verrà virtualizzato anche nell'archivio virtuale dell'utente. I file Syed aggiorna e salva rimangono indipendenti dagli altri file virtualizzati nel sistema.

Virtualizzazione del Registro di sistema

La virtualizzazione del Registro di sistema è simile alla virtualizzazione dei file, ma si applica alle chiavi del Registro di sistema in HKEY_LOCAL_MACHINE\SOFTWARE. Questa funzionalità consente alle applicazioni che si basano sulla possibilità di archiviare le informazioni di configurazione in HKEY_LOCAL_MACHINE\SOFTWARE continuare quando vengono eseguite con un account utente standard. Le chiavi e i dati vengono reindirizzati a HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE. Come nel caso di virtualizzazione dei file, ogni utente ha una copia virtualizzata di tutti i valori archiviati in HKLM.

Dettagli di virtualizzazione del Registro di sistema

• Può essere attivato/disattivato su singole chiavi nell'hive software
• Nuova opzione FLAGS in reg.exe per il controllo di virtualizzazione a livello di chiave: consente l'abilitazione/disabilitazione ricorsiva della virtualizzazione e il controllo dei "criteri di accesso aperto"
• ZwQueryKey: eseguire una query sui flag di virtualizzazione a livello di codice per una chiave.
• La virtualizzazione avviene sopra il reindirizzamento WoW64
• Abilitato sia nelle viste del Registro di sistema a 64 bit che a 32 bit: HKU\{SID}_Classes\VirtualStore\Machine\Software e HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264
• La maggior parte delle app legacy a 32 bit userà la visualizzazione a 32 bit

La virtualizzazione è progettata solo per facilitare la compatibilità delle applicazioni con i programmi esistenti. Le applicazioni progettate per Windows Vista non devono eseguire scritture in aree di sistema sensibili, né devono basarsi sulla virtualizzazione per fornire un rimedio per un comportamento errato dell'applicazione. Quando si aggiorna il codice esistente per l'esecuzione in Windows Vista, gli sviluppatori devono assicurarsi che, durante il runtime, le applicazioni archiviino solo i dati in percorsi per utente o in percorsi computer all'interno di %alluserprofile% (CSIDL_COMMON_APPDATA) con impostazioni di elenco di controllo di accesso (ACL) impostate correttamente.

Importante Microsoft intende rimuovere la virtualizzazione dalle versioni future del sistema operativo Windows perché viene eseguita la migrazione di più applicazioni a Windows Vista. Ad esempio, la virtualizzazione è disabilitata nelle applicazioni a 64 bit.

Raccomandazioni sulla virtualizzazione

La virtualizzazione è progettata solo per facilitare la compatibilità delle applicazioni con i programmi esistenti. Le applicazioni progettate per Windows Vista non devono eseguire scritture in aree di sistema sensibili, né devono basarsi sulla virtualizzazione per fornire un rimedio per un comportamento errato dell'applicazione. Quando si aggiorna il codice esistente per l'esecuzione in Windows Vista, gli sviluppatori devono assicurarsi che, durante il runtime, le applicazioni archiviino solo i dati in percorsi per utente o in percorsi computer all'interno di %alluserprofile% con impostazioni di elenco di controllo di accesso (ACL) impostate correttamente.

Importante Microsoft intende rimuovere la virtualizzazione dalle versioni future del sistema operativo Windows perché viene eseguita la migrazione di più applicazioni a Windows Vista. Ad esempio, la virtualizzazione è disabilitata nelle applicazioni a 64 bit.

• Aggiungere un manifesto dell'applicazione con un oggetto requestedExecutionLevel appropriato per le applicazioni interattive. In questo modo la virtualizzazione verrà disattivata per l'applicazione manifestata.
• Non usare il Registro di sistema come meccanismo di comunicazione tra processi. I servizi e le applicazioni utente avranno visualizzazioni diverse della chiave.
• Testare l'applicazione in Windows Vista: assicurarsi che i processi in esecuzione come utente standard non scrivono in spazi dei nomi globali come %systemroot%.
• Per sviluppatori di driver di filtro: controllare l'intervallo di altitudine. Vedere Filtri del file system. Devono essere superiori alla virtualizzazione FSFilter.
• Tenere presente che le risorse virtualizzate sono copie per utente delle risorse globali.

Modifiche ai token di accesso

Quando un utente accede a un computer Windows Vista, Windows esamina i privilegi amministrativi di Windows e gli ID relativi (ID relativi) che l'account utente possiede per determinare se l'utente deve ricevere due token di accesso (un token di accesso filtrato e un token di accesso completo). Windows creerà due token di accesso per l'utente se una delle condizioni seguenti è vera:

1. L'account dell'utente contiene uno dei RID seguenti.
   • DOMAIN_GROUP_RID_ADMINS
   • DOMAIN_GROUP_RID_CONTROLLERS
   • DOMAIN_GROUP_RID_CERT_ADMINS
   • DOMAIN_GROUP_RID_SCHEMA_ADMINS
   • DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
   • DOMAIN_GROUP_RID_POLICY_ADMINS
   • DOMAIN_ALIAS_RID_ADMINS
   • DOMAIN_ALIAS_RID_POWER_USERS
   • DOMAIN_ALIAS_RID_ACCOUNT_OPS
   • DOMAIN_ALIAS_RID_SYSTEM_OPS
   • DOMAIN_ALIAS_RID_PRINT_OPS
   • DOMAIN_ALIAS_RID_BACKUP_OPS
   • DOMAIN_ALIAS_RID_RAS_SERVERS
   • DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
   • DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
   • DOMAIN_ALIAS_RID_CRYPTO_OPERATORS
2. L'account dell'utente contiene tutti i privilegi diversi da quelli di un account utente standard. Un account utente standard contiene solo i privilegi seguenti.
   • SeChangeNotifyPrivilege
   • SeShutdownPrivilege
   • SeUndockPrivilege
   • SeIncreaseWorkingSetPrivilege
   • SeTimeZonePrivilege

Quali privilegi contengono il token filtrato sono basati sul fatto che il token originale contenga uno dei RIDS con restrizioni elencati in precedenza. Se uno dei RID con restrizioni si trova nel token, tutti i privilegi vengono rimossi tranne:

• SeChangeNotifyPrivilege
• SeShutdownPrivilege
• SeUndockPrivilege
• SeReserveProcessorPrivilege
• SeTimeZonePrivilege

Se nel token non sono presenti RID con restrizioni, vengono rimossi solo i privilegi seguenti:

• SeCreateTokenPrivilege
• SeTcbPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeDebugPrivilege
• SeImpersonatePrivilege
• SeRelabelPrivilege

Il primo token di accesso, denominato token di accesso filtrato, ha i RID precedenti (se presenti) contrassegnati come USE_FOR_DENY_ONLY nel token di accesso e i privilegi amministrativi di Windows, non elencati in precedenza, rimossi. Il token di accesso filtrato verrà usato per impostazione predefinita quando l'utente avvia le applicazioni. Il token di accesso completo non modificato, denominato token di accesso collegato, viene associato al token di accesso filtrato e viene usato quando vengono effettuate richieste per avviare le applicazioni con un token di accesso amministrativo completo.

Altre informazioni sui RID sono disponibili nell'articolo di MSDN Library Stringhe SID [Sicurezza].

Per altre informazioni sui privilegi di Windows, vedere l'articolo Msdn Library Authorization Constants [Security].

Architettura di Controllo dell'account utente

Il diagramma seguente rappresenta il flusso di processo per l'avvio eseguibile in Windows Vista.

Figura 3. Architettura di Controllo dell'account utente

Di seguito è riportata una descrizione del flusso di processo visualizzato nel diagramma dell'architettura di Controllo dell'account utente e la modalità di implementazione di Controllo dell'account utente quando un eseguibile tenta di avviare.

Percorso di avvio utente standard

Il percorso di avvio dell'utente standard di Windows Vista è simile al percorso di avvio di Windows XP, ma include alcune modifiche.

• ShellExecute() chiama CreateProcess().
• CreateProcess() chiama AppCompat, Fusion e Rilevamento del programma di installazione per valutare se l'applicazione richiede l'elevazione dei privilegi. L'eseguibile viene quindi esaminato per determinare il relativo oggetto requestedExecutionLevel, archiviato nel manifesto dell'applicazione dell'eseguibile. Il database AppCompat archivia le informazioni per le voci di correzione della compatibilità delle applicazioni di un'applicazione. Il rilevamento del programma di installazione rileva i file eseguibili di installazione.
• CreateProcess() restituisce un codice di errore Win32 che indica ERROR_ELEVATION_REQUIRED.
• ShellExecute() cerca in modo specifico questo nuovo errore e, dopo averlo ricevuto, chiama al servizio Application Information Service (AIS) per tentare l'avvio con privilegi elevati.

Percorso di avvio con privilegi elevati

Il percorso di avvio con privilegi elevati di Windows Vista è un nuovo percorso di avvio di Windows.

• AIS riceve la chiamata da ShellExecute() e valuta nuovamente il livello di esecuzione richiesto e Criteri di gruppo per determinare se l'elevazione dei privilegi è consentita e definire l'esperienza utente di elevazione dei privilegi.
• Se il livello di esecuzione richiesto richiede l'elevazione dei privilegi, il servizio avvia la richiesta di elevazione dei privilegi sul desktop interattivo del chiamante (basato su Criteri di gruppo), usando HWND passato da ShellExecute().
• Dopo che l'utente ha fornito il consenso o le credenziali valide, AIS recupererà il token di accesso corrispondente associato all'utente appropriato, se necessario. Ad esempio, un'applicazione che richiede un oggetto requestedExecutionLevel of highestAvailable recupererà token di accesso diversi per un utente che è solo un membro del gruppo Backup Operators rispetto a un membro del gruppo Administrators locale.
• AIS rimette una chiamata CreateProcessAsUser(), fornendo il token di accesso dell'amministratore e specificando il desktop interattivo del chiamante.

Controllo dell'account utente influisce sull'applicazione?

L'eventuale effetto dell'applicazione da parte dell'account utente dipende dallo stato corrente dell'applicazione. In diversi casi, non saranno necessarie modifiche per rispettare i requisiti di Microsoft Sicurezza di Windows. Tuttavia, alcune applicazioni, incluse le applicazioni line-of-business (LOB), potrebbero richiedere modifiche ai processi di installazione, funzione e aggiornamento per funzionare correttamente in un ambiente UAC di Windows Vista.

Nota Se un'applicazione funziona bene come utente standard in Windows XP, funzionerà bene come un utente standard in Windows Vista.

Perché è necessario rimuovere le dipendenze amministrative dell'applicazione?

Un passaggio fondamentale per aumentare la sicurezza dell'ambiente di elaborazione complessivo consiste nel consentire agli utenti di eseguire senza usare il token di accesso amministrativo. Se un'applicazione opera o installa solo quando l'utente è un amministratore, gli utenti vengono costretti a eseguire applicazioni con accesso con privilegi elevati non necessari. Il problema fondamentale è che quando gli utenti sono sempre costretti a eseguire applicazioni usando token di accesso elevati, codice ingannevole o dannoso può facilmente modificare il sistema operativo, o peggio, influire sugli altri utenti.

L'obiettivo di Microsoft è consentire ai clienti di comprendere che le applicazioni non devono essere eseguite inutilmente come amministratore e per porre domande in qualsiasi momento a cui viene chiesto di approvare la richiesta di esecuzione di un'applicazione come amministratore. Controllo dell'account utente è un componente fondamentale per aiutare a raggiungere questo obiettivo e andrà a lungo per ripristinare un ambiente di elaborazione più sicuro per tutti gli utenti.

Riduzione del costo totale di proprietà dell'applicazione

L'account utente standard è molto interessante per gli amministratori IT interessati ad aumentare la sicurezza e il controllo sui computer gestiti, riducendo al tempo stesso il costo totale di proprietà. Poiché un account utente standard non può apportare modifiche al sistema, esiste una relazione diretta con la riduzione di TCO e la migliore controllo dell'installazione dell'applicazione e modifiche a livello di sistema. L'account utente standard è anche attraente per gli utenti domestici in cui i genitori condividono un computer con bambini. Microsoft Windows Vista include controlli genitori integrati, che vengono implementati solo creando account utente figlio come utenti standard. Gli account utente standard non possono anche modificare o eliminare i file creati da altri utenti. Non possono leggere i file nei profili degli altri utenti, infettare i file di sistema o modificare i file eseguibili condivisi dal sistema, accidentalmente o intenzionalmente. Gli account utente standard comportano un miglioramento generale della sicurezza del computer e dei controlli genitori.

Proteggere per impostazione predefinita

In Microsoft, i tenet dell'iniziativa Di calcolo affidabile di Microsoft sono stati radicati nello sviluppo di software. Di conseguenza, la sicurezza migliorata è stata una parte integrante del processo di sviluppo di Windows Vista.

Il pilastro della sicurezza di Trustworthy Computing include tre concetti fondamentali: sicuri per progettazione, sicuri per impostazione predefinita e sicuri nella distribuzione. Come si sviluppano le applicazioni e altri ISV per contribuire alla sicurezza complessiva del sistema operativo sarà un fattore di successo fondamentale per ottenere un calcolo affidabile in Windows Vista.

L'obiettivo della parte restante di questa guida è aiutare gli sviluppatori a insegnare agli sviluppatori come:

• Scrivere applicazioni che non richiedono all'utente di essere un amministratore per eseguire attività di routine
• Creare pacchetti di installazione con le tecnologie di patch dell'interfaccia utente di Windows® Installer 4.0 che distribuiscono bene nel desktop utente standard nelle aziende e aggiornano correttamente nella casa.
• Identificare le funzionalità utente e amministrative standard e estrapolare le attività amministrative per la compatibilità dell'interfaccia utente
• Scrivere interfacce utente dell'applicazione che usano la funzionalità dell'interfaccia utente

È essenziale per il successo dell'interfaccia utente che gli sviluppatori di applicazioni abbracciano la filosofia dei privilegi minimi e progettano le proprie applicazioni per funzionare correttamente quando si esegue con un account utente standard.

Uno degli obiettivi della versione di Windows Vista è quello di evangelizzare e incoraggiare il principio di progettazione per gli utenti e gli amministratori standard in Amministrazione modalità approvazione a tutti gli sviluppatori. Il raggiungimento di questo obiettivo aiuterà la prevenzione di vari attacchi contro le singole applicazioni e ridurrà la possibilità che tali attacchi comprometteranno la sicurezza del sistema. Anche se questi obiettivi possono essere raggiunti in qualche grado oggi richiedendo agli amministratori di usare due account, tende a non riuscire per i motivi seguenti:

• È quasi impossibile controllare un utente con un token di accesso amministratore completo. Gli amministratori possono installare applicazioni ed eseguire qualsiasi applicazione o script desiderato. I responsabili IT cercano sempre modi per creare "desktop standard" in cui gli utenti accedono come utenti standard. I desktop standard riducono notevolmente i costi dell'help desk e riducono il sovraccarico IT.
• Si verifica un sovraccarico significativo quando si passano da un account all'altro ogni volta che l'utente vuole eseguire un'operazione amministrativa.
• Dopo aver eseguito un'operazione amministrativa, gli utenti possono dimenticare di tornare al proprio account utente standard o decidere che è troppo sforzo tornare indietro.

Di conseguenza, gli utenti possono decidere di accedere sempre ai propri account amministrativi, sconfiggendo così le misure di sicurezza. Per attenuare questo problema, l'interfaccia utente introduce il concetto di modalità di approvazione Amministrazione. Un account utente Amministrazione modalità approvazione è un account utente membro del gruppo amministratori locali in un sistema abilitato per l'interfaccia utente.

Nell'organizzazione, Amministrazione modalità approvazione verrà usata come tecnologia bridge per la migrazione a Windows Vista. Idealmente, le aziende eseguiranno tutti gli utenti come utenti standard e disabilitano la richiesta di elevazione per gli utenti standard. Questa configurazione consente un desktop standard gestito in cui le installazioni vengono distribuite con una tecnologia di distribuzione software, ad esempio Microsoft Systems Management Server (SMS).

Importante Microsoft consiglia comunque che i membri del gruppo Domain Admins continuino a mantenere due account utente separati in Windows Vista: un account utente standard e un account utente amministratore del dominio. È necessario eseguire tutte le operazioni di amministrazione del dominio con l'account amministratore del dominio. Per migliorare ulteriormente la sicurezza, valutare la possibilità di distribuire una soluzione smart card negli ambienti di dominio. Per altre informazioni, vedere la Guida alla pianificazione dell'accesso sicuro tramite smart card .

Di seguito sono riportati gli obiettivi di progettazione di Windows Vista per Amministrazione modalità approvazione:

• Eliminare la necessità di due account separati per gli utenti membri del gruppo di amministratori: questo obiettivo viene eseguito eseguendo programmi solo con un token di accesso utente standard, a meno che l'utente non fornisca l'approvazione per l'uso del token di accesso amministrativo completo.
• Proteggere i processi in esecuzione con un token di accesso amministrativo completo dall'accesso o modificato da tali processi in esecuzione come utente standard.
• Fornire una transizione facile tra le aree di lavoro amministratore e utente standard.

Attualmente, la maggior parte delle applicazioni Windows deve essere eseguita come amministratore, ma non eseguire effettivamente operazioni amministrative. Queste applicazioni sono un byproduct della filosofia dei sistemi operativi Microsoft Windows 9x: "tutti sono un amministratore".

Di seguito sono riportati esempi di applicazioni problematiche:

• Applicazioni che inutilmente scrivono in HKEY_LOCAL_MACHINE (HKLM) o nei file di sistema all'interno del file system.
• Installazione di ActiveX per facilitare un'applicazione line-of-business con un'interfaccia Web.
• Le applicazioni che richiedono inutilmente l'accesso alle risorse che richiedono un token di accesso amministrativo completo.

La sezione successiva presenta nuove tecnologie per Windows Vista che influisce sugli ISV.

Come si determina se l'applicazione ha dipendenze amministrative?

Per aiutare gli sviluppatori, gli ISV e le organizzazioni a valutare le applicazioni, Microsoft fornisce Microsoft Standard User Analyzer. L'analizzatore utente standard può essere usato per consentire l'identità del comportamento non conforme all'interfaccia utente di un'applicazione. Microsoft consiglia agli sviluppatori di eseguire questo strumento per identificare i problemi relativi all'esecuzione dell'applicazione in un account utente standard. Questi test devono essere eseguiti, anche se l'applicazione è già installata ed eseguita correttamente in un account utente standard in Windows XP. L'applicazione può eseguire operazioni, ad esempio il tentativo di scrivere nelle posizioni del Registro di sistema e prendere decisioni in base al comportamento del sistema, ad esempio cercando una risposta di errore. Windows Vista può comportarsi in modo diverso rispetto alle versioni precedenti del sistema operativo Windows a causa dell'aggiunta di un nuovo supporto per la compatibilità delle applicazioni. È pertanto consigliabile testare tutte le applicazioni con la nuova versione di Standard User Analyzer.

L'analizzatore utente standard registra tutte le operazioni amministrative rilevate da un'applicazione, tra cui l'accesso al Registro di sistema/file system e le chiamate API elevate. Questi dati vengono archiviati in un file di log e vengono visualizzati all'interno dello strumento. L'analizzatore utente standard identifica le dipendenze comuni seguenti, oltre a molte altre:

• Dipendenza da oggetti che limitano l'accesso richiesto solo agli utenti attendibili.

  Ad esempio, HKEY_LOCAL_MACHINE concede solo KEY_WRITE agli amministratori e a SYSTEM, un'applicazione che richiede KEY_WRITE a HKEY_LOCAL_MACHINE non funzionerà con l'interfaccia utente abilitata.

• Uso dei privilegi di Windows con ramificazioni di sicurezza, ad esempio SE_DEBUG_PRIVILEGE, che consente il debug dei processi degli altri utenti e viene concesso solo agli amministratori.

Quali sono i requisiti se si dispone di un'applicazione di amministratore legittimo?

Per le applicazioni che, per progettazione, eseguire operazioni amministrative legittime, Microsoft ha implementato un'estensione alla sezione trustInfo dello schema manifesto dell'applicazione Windows XP corrente. È possibile usare questi nuovi attributi per indicare al sistema che si dispone di un'applicazione amministrativa legittima; il sistema chiederà automaticamente l'approvazione dell'utente per avviare l'applicazione con un token di accesso amministrativo completo. Per informazioni su come estendere il manifesto dell'applicazione, vedere la sezione Creare e incorporare un manifesto dell'applicazione con l'applicazione all'interno di questo documento.

Progettazione di applicazioni per Windows Vista

L'elenco seguente rappresenta un flusso di lavoro per progettare l'applicazione per Windows Vista:

1. Testare l'applicazione per la compatibilità dell'applicazione Windows Vista
2. Classificare l'applicazione come utente, amministratore o applicazione utente mista standard
3. Riprogettazione della funzionalità dell'applicazione per la compatibilità dell'interfaccia utente
4. Riprogettazione dell'interfaccia utente dell'applicazione
5. Riprogettazione del programma di installazione dell'applicazione
6. Creare e incorporare un manifesto dell'applicazione con le applicazioni amministrative
7. Testare l'applicazione
8. Firmare l'applicazione
9. Determinare se perseguire il programma Logo di Windows Vista

1. Testare l'applicazione per la compatibilità dell'applicazione

I test per la compatibilità delle applicazioni con L'interfaccia utente possono essere facilmente eseguiti installando Standard User Analyzer.

Per utilizzare la visualizzazione grafica del log grafico di Standard User Analyzer, è necessario installare Microsoft Application Verifier. Application Verifier è un download gratuito nel sito Web Microsoft.

La procedura seguente illustra come identificare le applicazioni amministrative pre-Windows Vista che non vengono eseguite correttamente in Windows Vista usando Standard User Analyzer.

Esistono due approcci che è possibile adottare per usare Standard User Analyzer: avviare l'applicazione come utente standard o avviare l'applicazione con privilegi elevati come amministratore:

Avviare l'applicazione come utente standard.

In questa istanza, l'analizzatore utenti Standard è in esecuzione in modalità diagnosi. L'applicazione avrà esito negativo al primo errore rilevato e l'analizzatore utenti standard segnala il motivo per cui non è riuscito.

Avviare l'applicazione con privilegi elevati come amministratore.

In questa istanza, l'analizzatore utenti standard è in esecuzione in modalità di stima. L'applicazione sarà in grado di eseguire il suo corso e l'analizzatore utente standard prevede e fornisce una panoramica degli errori che l'applicazione potrebbe riscontrare se viene eseguita come utente standard.

Dopo aver risolto e risolto i bug, eseguire questa procedura ancora una volta come utente standard senza l'analizzatore utente standard per assicurarsi che l'applicazione funzioni come previsto in Windows Vista.

Per identificare i problemi di compatibilità delle applicazioni per le applicazioni pre-Windows Vista

1. Accedere a un computer Windows Vista come amministratore in Amministrazione modalità approvazione.
2. Fare clic su Start, fare clic su Tutti i programmi e quindi su Standard User Analyzer.
3. In Standard User Analyzer, per Applicazione di destinazione, specificare il percorso completo della directory per un'applicazione da testare o fare clic sul pulsante Sfoglia per individuare il file eseguibile dei programmi con Esplora risorse.
4. Fare clic su Avvia e quindi fare clic su Continua nella finestra di dialogo Controllo account utente.
5. Dopo l'avvio dell'applicazione di test, eseguire attività amministrative standard nell'applicazione e chiudere l'applicazione al termine.
6. In Standard User Analyzer esaminare l'output in ogni scheda. Usare questi dati per identificare i problemi di compatibilità che il programma potrebbe avere.

2. Classificare l'applicazione come utente standard, amministratore o applicazione utente mista

Le applicazioni amministrative in Windows Vista hanno spesso una combinazione di funzionalità utente amministrative e standard. Di conseguenza, una serie di opzioni deve essere considerata quando si decide come funzionerà l'applicazione in Windows Vista. La funzionalità amministrativa può essere rimossa completamente o separata dalla funzionalità dell'account utente standard richiedendo all'utente l'approvazione.

Domande per classificare l'applicazione

Rispondere alle domande seguenti per determinare se l'applicazione richiederà una riprogettazione per la compatibilità di Windows Vista:

• L'applicazione viene eseguita come utente standard?
• È possibile correggere la funzionalità amministrativa per non richiedere più un token di accesso amministratore?
• Le sezioni amministrative possono essere rimosse dalla funzionalità del programma?

L'applicazione viene eseguita come utente standard?

Per rispondere a questa domanda, assicurarsi che l'applicazione o la funzionalità siano completamente usate dagli utenti standard. Se una parte della funzionalità richiede che l'utente sia un amministratore, la risposta a questa domanda è "No".

Come verificare che l'applicazione o il pannello di controllo possano essere usati dagli utenti standard:

• Testare accuratamente l'applicazione o il pannello di controllo sia come utente standard che come amministratore. Verificare che le interazioni utente siano tutte identiche sia per gli utenti standard che per gli amministratori.
• Controllare dove vengono archiviate le impostazioni nel Registro di sistema. Se le impostazioni vengono archiviate in HKLM, l'applicazione o il pannello di controllo richiederanno probabilmente un token di accesso amministratore.
• Se una delle impostazioni è per computer, l'applicazione o il pannello di controllo richiederanno un token di accesso amministratore.
• Se una delle impostazioni esegue qualsiasi operazione nei profili di altri utenti, l'applicazione o il pannello di controllo richiederanno un token di accesso amministratore.

È possibile correggere le funzionalità amministrative per non richiedere più un token di accesso amministratore?

Se l'applicazione o il pannello di controllo dispone di impostazioni o interazioni che richiedono un token di accesso completo all'amministratore, può essere modificato in modo da funzionare correttamente come utente standard? In particolare, è possibile archiviare le informazioni in base alle impostazioni utente? Se non può, la risposta a questa domanda è "No".

Un buon esempio del tipo di funzionalità/impostazione che può essere risolto è Calc.exe (calcolatore di Windows). In Windows XP, l'impostazione di "Scientific" rispetto a "Standard" è un'impostazione per computer, che significa che è stato necessario un token di accesso amministrativo completo per modificare l'impostazione. In Windows Vista questa impostazione viene archiviata nel profilo dell'utente.

Come verificare che le sezioni amministrative possano essere rimosse dalla funzionalità del programma:

• Testare accuratamente l'applicazione o il pannello di controllo sia come utente standard che come amministratore. L'esperienza può essere la stessa per entrambi i tipi di utenti?

• È possibile ridurre gli elenchi di controllo di accesso (ACL) necessari per scrivere nella chiave HKLM?

  Nota Questo corso non dovrebbe essere preso leggero. Prestare attenzione a non compromettere la sicurezza complessiva del sistema riducendo il controllo offerto dall'ACL.

• È possibile modificare l'interfaccia utente per impostare lo stato per utente anziché lo stato globale (e non esporre la modifica dello stato globale tramite l'interfaccia utente)?

Le sezioni amministrative possono essere rimosse dalla funzionalità del programma?

La funzionalità deve assolutamente avere questa funzionalità? Se non è possibile tagliare le funzionalità/funzionalità amministrative, la risposta a questa domanda è "No".

Per determinare se le sezioni amministrative possono essere rimosse dalla funzionalità del programma, eseguire le operazioni seguenti:

• Testare il pannello di controllo come utente standard e un amministratore. Qual è lo scenario utente per conservare questa funzionalità?
• Questa impostazione o funzionalità è esposta altrove? Forse la funzionalità nel pannello di controllo è ridondante.

Analisi delle risposte per classificare l'applicazione

Se hai risposto "Sì" a una delle domande precedenti

Apportare le modifiche necessarie nell'applicazione o nel pannello di controllo (se presente) per eliminare tali elementi che richiedono all'utente di avere un token di accesso amministrativo completo.

L'elenco seguente illustra i vantaggi di avere un'applicazione utente standard vera:

• La funzionalità è altrettanto utilizzabile per tutti gli utenti. Questo è lo stato ideale perché la maggior parte delle funzionalità non deve richiedere un token di accesso amministratore completo.
• Gli utenti non visualizzeranno mai una richiesta di elevazione con le funzionalità.
• Le funzionalità sono molto più sicure non richiedendo mai il token di accesso dell'amministratore.

Se hai risposto "No" a tutte le domande precedenti

L'applicazione o il pannello di controllo devono essere modificati per rendere la funzionalità funzionante con l'interfaccia utente.

Verificare che l'applicazione o la Pannello di controllo funzioni con l'interfaccia utente:

Infine, testare l'applicazione o il pannello di controllo come utente standard e un amministratore. Assicurarsi che non sia possibile usare altre opzioni (le domande precedenti) per questo particolare pannello di controllo o applicazione.

3. Riprogettazione della funzionalità dell'applicazione per la compatibilità dell'interfaccia utente

Usare le informazioni in questa sezione dopo aver classificato l'applicazione e determinato se deve essere riprogettata per l'interfaccia utente.

Un grande componente della riprogettazione dell'applicazione per Windows Vista esaminerà il modello di accesso utente dell'applicazione nel suo core.

Requisiti per tutte le applicazioni Windows Vista

Specificare un oggetto RequestedExecutionLevel

Per il corretto funzionamento dell'interfaccia utente, il sistema operativo deve essere in grado di identificare il codice che richiede privilegi elevati e quale codice non esegue.

In Windows Vista queste modifiche richiedono che le applicazioni siano contrassegnate con informazioni che consentono al sistema operativo di determinare in quale contesto deve essere avviata l'applicazione. Ad esempio, le applicazioni utente standard devono essere contrassegnate per essere eseguite come richiamatore e le applicazioni abilitate per l'accessibilità devono essere identificate dal sistema.

Non registrare i componenti con Rundll32

Alcune applicazioni usano i file eseguibili di Windows Rundll32 per eseguire i componenti. Tuttavia, questo metodo non è conforme ai requisiti di sviluppo di Windows Vista. La chiamata direttamente in Rundll32 comporta problemi di compatibilità dell'interfaccia utente. Quando un'applicazione si basa sui file eseguibili Rundll32 per eseguire l'esecuzione, Rundll32 chiama Application Information Service (AIS) per conto dell'applicazione per avviare il prompt di elevazione dell'interfaccia utente. Di conseguenza, il prompt di elevazione dell'account utente non ha conoscenza dell'applicazione originale e visualizza l'elevazione dell'applicazione che richiede l'elevazione come "Processo host Windows(Rundll32)." Senza una descrizione e un'icona chiare per l'elevazione delle richieste dell'applicazione, gli utenti non hanno modo di identificare l'applicazione e determinare se è sicuro elevarlo.

Se l'applicazione chiama rundll32 per eseguire i componenti, usare il flusso di lavoro seguente per riprogettare la chiamata di esecuzione.

1. Creare un nuovo file eseguibile separato per l'applicazione.
2. Nel nuovo file eseguibile chiamare la funzione esportata nella DLL specificata con Rundll32. Potrebbe essere necessario CaricareLibrary la DLL se non dispone di un file lib.
3. In un file di risorse creare e aggiungere una nuova icona per il file eseguibile. Questa icona verrà visualizzata nella richiesta di elevazione dell'elevazione dell'account utente quando l'applicazione richiede l'elevazione delle richieste.
4. Specificare un nome breve e significativo per l'eseguibile. Questo nome verrà visualizzato nella richiesta di elevazione dell'elevazione dell'account utente quando l'applicazione richiede l'elevazione delle richieste.
5. Creare e incorporare un file manifesto dell'applicazione per l'eseguibile e contrassegnarlo con il livello di esecuzione richiesto di requireAdministrator. Questo processo è dettagliato nella sezione Crea e Incorpora un manifesto applicazione con l'applicazione.
6. Authenticode firmare il nuovo eseguibile. Questo processo è dettagliato nella sezione Authenticode Sign Your Application.

Dopo l'installazione di un'applicazione, l'utente deve essere in grado di reinstallarlo senza errori.

Requisiti per le applicazioni utente standard

Ecco un riepilogo delle cose da ricordare quando si progettano applicazioni che operano correttamente in un account utente standard. Gli sviluppatori devono tenere presente questi requisiti durante la fase di progettazione delle applicazioni.

Configurazione

• Non eseguire mai azioni amministrative (ad esempio il completamento del processo di installazione) per la prima esecuzione; deve essere eseguita come parte del processo di installazione iniziale.
• Non scrivere mai direttamente nella directory di Windows o nelle sottodirectory. Usare i metodi corretti per l'installazione di file come i tipi di carattere.
• Se è necessario aggiornare automaticamente l'applicazione, usare un meccanismo adatto per l'uso da parte degli utenti standard, ad esempio l'applicazione di patch di Controllo account utente di Windows Installer 4.0 per eseguire l'aggiornamento.

Salvataggio dello stato

• Non scrivere informazioni per utente o informazioni scrivibili dall'utente nelle directory programmi o programmi.
• Non usare percorsi hardcoded nel file system. Sfruttare l'API KnownFolders e ShGetFolder per trovare dove scrivere dati.

Eseguire e testare in un account utente standard

Se si scrive un'applicazione non amministrativa, ad esempio un'applicazione LOB o un'applicazione utente, ad esempio un gioco, è sempre necessario scrivere dati dell'applicazione in una posizione a cui l'utente standard può accedere. Di seguito sono riportati alcuni dei requisiti consigliati.

• Scrivere dati per utente nel profilo utente: CSIDL_APPDATA.
• Scrivere dati per computer in Utenti\Tutti gli utenti\Dati applicazione: CSIDL_COMMON_APPDATA.
• L'applicazione non può dipendere da alcuna API amministrativa. Ad esempio, un programma che prevede di chiamare correttamente la funzione Windows SetTokenInformation() avrà esito negativo in un account utente standard.

Essere veloci di passaggio utente (FUS)

Le applicazioni verranno installate più comunemente da un utente diverso dall'utente che eseguirà l'applicazione. Ad esempio, nella casa, questo significa che un padre installerà l'applicazione per il figlio. Nell'organizzazione, un sistema di distribuzione, ad esempio SMS o Criteri di gruppo annuncio, installerà l'applicazione usando un account amministratore.

Se le impostazioni per utente non esistono alla prima esecuzione, ricompilarle. Non presupporre che il processo di installazione si occupasse delle impostazioni.

Requisiti per le applicazioni di amministratore

Utilizzare la proprietà HWND per essere riconosciuta come applicazione in primo piano

Le applicazioni in background richiederanno automaticamente all'utente l'elevazione dei privilegi sulla barra delle applicazioni, invece di passare automaticamente al desktop sicuro per l'elevazione dei privilegi. La richiesta di elevazione dei privilegi verrà visualizzata ridotta a icona sulla barra delle applicazioni e lampeggia per notificare all'utente che un'applicazione ha richiesto l'elevazione dei privilegi. Un esempio di elevazione in background si verifica quando un utente accede a un sito Web e inizia a scaricare un file di installazione. L'utente passa quindi a controllare la posta elettronica mentre l'installazione viene scaricata in background. Una volta completato il download in background e l'installazione inizia, l'elevazione viene rilevata come attività in background anziché come attività in primo piano. Questo rilevamento impedisce all'installazione di rubare bruscamente lo stato attivo dello schermo dell'utente mentre l'utente esegue un'altra e-mail di lettura attività. Questo comportamento crea un'esperienza utente migliore per la richiesta di elevazione dei privilegi.

Tuttavia, alcune applicazioni in primo piano richiedono attualmente applicazioni in background in Windows Vista. Questo comportamento è il risultato di un HWND padre assente. Per garantire che Windows Vista riconosca l'applicazione come applicazione in primo piano, è necessario passare un HWND padre con shellExecute, CreateElevatedComObject (COM) o una chiamata al codice gestito.

Il meccanismo di elevazione dell'account utente usa HWND come parte di determinare se l'elevazione è uno sfondo o un'elevazione in primo piano. Se l'applicazione è determinata come applicazione in background, l'elevazione viene posizionata sulla barra delle applicazioni come pulsante lampeggiante. L'utente deve fare clic sul pulsante, come per qualsiasi applicazione che richiede l'accesso in primo piano, prima che l'elevazione continui. Se non si passa HWND, questa situazione si verifica anche se l'applicazione potrebbe effettivamente avere in primo piano.

L'esempio di codice seguente illustra come passare HWND con ShellExecute:

BOOL RunAsAdmin( HWND hWnd, LPTSTR lpFile, LPTSTR lpParameters )
{
    SHELLEXECUTEINFO   sei;
    ZeroMemory ( &sei, sizeof(sei) );

    sei.cbSize          = sizeof(SHELLEXECUTEINFOW);
    sei.hwnd            = hWnd;
    sei.fMask           = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
    sei.lpVerb          = _TEXT("runas");
    sei.lpFile          = lpFile;
    sei.lpParameters    = lpParameters;
    sei.nShow           = SW_SHOWNORMAL;

    if ( ! ShellExecuteEx ( &sei ) )
    {
        printf( "Error: ShellExecuteEx failed 0x%x\n", GetLastError() );
        return FALSE;
    }
    return TRUE;
}

L'esempio di codice seguente illustra come passare HWND con CreateElevatedComObject usando il moniker di elevazione. Presuppone che sia già stato inizializzato COM nel thread corrente. Altre informazioni sul moniker di elevazione sono disponibili nel passaggio 4 di questo documento.

HRESULT CreateElevatedComObject(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv)
{
    BIND_OPTS3 bo;
    WCHAR  wszCLSID[50];
    WCHAR  wszMonikerName[300];

    StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0])); 
    HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);
    if (FAILED(hr))
        return hr;
    memset(&bo, 0, sizeof(bo));
    bo.cbStruct = sizeof(bo);
    bo.hwnd = hwnd;
    bo.dwClassContext  = CLSCTX_LOCAL_SERVER;
    return CoGetObject(wszMonikerName, &bo, riid, ppv);

BIND_OPTS3 è una novità di Windows Vista. Deriva da BIND_OPTS2. Viene definita come segue:

typedef struct tagBIND_OPTS3 : tagBIND_OPTS2
{
    HWND hwnd;
} BIND_OPTS3, * LPBIND_OPTS3;

L'unica aggiunta è un campo HWND, hwnd. Questo handle rappresenta una finestra che diventa il proprietario dell'interfaccia utente di elevazione quando è abilitata la richiesta sicura del desktop.

L'esempio di codice seguente illustra come passare HWND nel codice gestito per garantire che i dialoghi padre siano a conoscenza di HWND e del relativo uso.

System.Diagnostics.Process newProcess = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("D:\SomeProgram.exe");
info.UseShellExecute = true;
info.ErrorDialog = true;
info.ErrorDialogParentHandle = this.Handle;
newProcess.StartInfo = info;
newProcess.Start();

Non richiedere l'elevazione nel percorso di accesso dell'utente

Le applicazioni che iniziano quando l'utente accede e richiedono l'elevazione dei privilegi sono ora bloccate nel percorso di accesso. Senza impedire alle applicazioni di richiedere l'elevazione dei privilegi nel percorso di accesso dell'utente, sia gli utenti standard che gli amministratori devono rispondere a una finestra di dialogo Controllo account utente in ogni accesso. Windows Vista notifica all'utente se un'applicazione è stata bloccata posizionando un'icona nell'area di notifica. L'utente può quindi fare clic con il pulsante destro del mouse su questa icona per eseguire applicazioni che sono state bloccate per richiedere l'elevazione dei privilegi durante l'accesso dell'utente. L'utente può gestire le applicazioni di avvio disabilitate o rimosse da questo elenco facendo doppio clic sull'icona della barra.

Un esempio di codice C++ che illustra come usare l'Utilità di pianificazione per eseguire l'elevazione dei privilegi per l'utente è disponibile nella sezione Riferimenti di questo documento.

Non usare Runas per avviare un processo con privilegi elevati

L'opzione Esegui come... da Windows XP e Windows Server 2003 è stata sostituita con Esegui come amministratore nel menu di scelta rapida (disponibile quando si fa clic con il pulsante destro del mouse su un eseguibile) in Windows Vista. Quando un utente standard seleziona l'opzione Esegui come amministratore , viene visualizzato un elenco di amministratori attivi nel computer locale. Vengono visualizzati anche gli utenti standard con privilegi più elevati, ad esempio i membri del gruppo Operatori di backup. Quando un amministratore seleziona l'opzione Esegui come amministratore , una finestra di dialogo Controllo account utente richiede immediatamente all'utente di continuare prima di eseguire l'applicazione.

Gli utenti devono usare il comando runas al prompt dei comandi per eseguire un'applicazione come un altro utente.

Importante Tenere presente che runas non offre la possibilità di avviare un'applicazione con un token di accesso con privilegi elevati, indipendentemente dal fatto che si tratti di un utente standard con privilegi come un operatore di backup o un amministratore. Il comando runas concede all'utente la possibilità di avviare un'applicazione con credenziali diverse. Il metodo migliore da usare per avviare un'applicazione con un account diverso consiste nell'eseguire l'azione a livello di codice usando un servizio e non basarsi sull'utente per eseguire il componente come utente diverso. Se il programma usa il comando runas a livello di codice, assicurarsi che non sia progettato per avviare un processo con privilegi elevati.

Se l'applicazione richiederà all'utente di eseguire parti dell'applicazione con un account utente diverso, assicurarsi che il comando runas con l'opzione del prompt dei comandi sia esposto. Nella tabella seguente vengono illustrati in dettaglio i parametri disponibili per il comando runas .

Parametri runas

Parametro	Descrizione
/noprofile	Specifica che il profilo dell'utente non deve essere caricato. Ciò consente all'applicazione di caricare più rapidamente, ma può causare malfunzionamenti di alcune applicazioni.
/Profilo	Specifica che il profilo dell'utente deve essere caricato. Si tratta dell'impostazione predefinita.
/Env	Usare l'ambiente corrente anziché l'utente.
/netonly	Usare questo parametro se le credenziali specificate sono solo per l'accesso remoto.
/savecred	Usare le credenziali salvate in precedenza dall'utente. Questa opzione non è disponibile in Windows XP, Home Edition e verrà ignorata.
/Smartcard	Usare questo parametro se le credenziali da fornire provengono da una smart card.
/User	Nome utente dell'utente. Il nome utente deve essere specificato sotto forma di USER\DOMAIN o USER@DOMAIN.
/showtrustlevels	Visualizza le valori trustlevels che possono essere usati come argomenti per il parametro /trustlevel.
/Trustlevel	Uno dei livelli enumerati in /showtrustlevels.
Programma	Riga di comando per un eseguibile.

Esempio:

runas /noprofile /user:mymachine\Denise cmd

Note:

• Immettere la password dell'utente solo quando richiesto.
• Il /profile parametro non è compatibile con il parametro /netonly.
• Il parametro /savecred non è compatibile con il parametro /smartcard.

Requisiti per le applicazioni console

Un'applicazione console presenta l'output nella finestra della console e non con un'interfaccia utente separata. Se per l'esecuzione di un'applicazione è necessario un token di accesso amministratore completo, tale applicazione deve essere avviata da una finestra della console con privilegi elevati.

Per le applicazioni console è necessario eseguire le operazioni seguenti:

Contrassegnare l'applicazione "asInvoker"

A tale scopo, è possibile creare il manifesto dell'applicazione in cui è stato impostato RequestedExecutionLevel == asInvoker. Questa configurazione consente ai chiamanti da contesti non elevati di creare il processo, che consente di procedere al passaggio 2.

Specificare un messaggio di errore se l'applicazione viene eseguita senza un token di accesso amministratore completo

Se l'applicazione viene avviata in una console non con privilegi elevati, l'applicazione deve fornire un breve messaggio e uscire. Il messaggio consigliato è:

"Accesso negato. Le autorizzazioni di amministratore sono necessarie per usare le opzioni selezionate. Usare un prompt dei comandi dell'amministratore per completare queste attività."

L'applicazione deve anche restituire il codice di errore ERROR_ELEVATION_REQUIRED in caso di errore di avvio per facilitare lo scripting.

Requisiti per gli script

Gli script possono essere considerati come un gruppo di applicazioni eseguiti in un ordine predefinito e i risultati di uno incanalato in un altro.

Per rendere conforme l'interfaccia utente degli script, esaminare la logica degli script e aggiungere "test" per assicurarsi che prima di eseguire un'azione nello script, l'utente (o la persona che esegue lo script) disponga di privilegi sufficienti per eseguire tale attività.

Requisiti per le operazioni bulk

Se un'attività eseguita dall'applicazione è costituita da azioni su più oggetti e alcuni di essi potrebbero richiedere il token di accesso amministrativo dell'utente, visualizzare la richiesta di elevazione dei privilegi la prima volta che è necessaria. Se l'utente approva l'elevazione, eseguire le altre attività. In caso contrario, terminare l'operazione batch. Questo comportamento sarà coerente con l'operazione di selezione multipla/copia/eliminazione corrente.

API che consentono di identificare un amministratore

• IsUserAnAdmin()
• GetTokenInformation()

Autorizzazioni di accesso del Registro di sistema/Handle intrinsecamente diverse tra amministratori e utenti standard

• MAXIMUM_ALLOWED
• KEY_WRITE
• DELETE (se applicato alle chiavi del Registro di sistema)
• Altre parole chiave simili a HKLM (aperte con MAXIMUM_ALLOWED in XP):
• SHELLKEY_HKLM_EXPLORER
• SHELLKEY_HKLM_SHELL

Verranno applicate altre API che vengono riindirizzato ai valori del Registro di sistema HKLM e alla virtualizzazione

• WritePrivateProfileString(,,,"system.ini");
• CheckSectionAccess("system.ini",...);

4. Riprogettare l'interfaccia utente dell'applicazione per la compatibilità con controllo dell'account utente

Usare le linee guida in questa sezione per sviluppare l'interfaccia utente dell'applicazione per la compatibilità con controllo dell'account utente. Rispettando attentamente queste linee guida nello sviluppo dell'applicazione, l'applicazione avrà un'esperienza utente coerente e prevedibile in Windows Vista.

• Impatto di Controllo dell'account utente nell'esperienza utente di Windows
• Obiettivi dell'esperienza utente di Controllo dell'account utente
• Richiesta di elevazione dei privilegi
• Flusso del processo dell'esperienza utente
• Punti di ingresso di elevazione
• Implementazione dell'interfaccia utente
• Quando aggiungere un'icona di scudo all'interfaccia utente dell'applicazione
• Decisioni chiave per le applicazioni solo amministratore

Importante La rielaborazione dell'interfaccia utente dell'applicazione non soddisfa i requisiti per la compatibilità con controllo dell'account utente. Le funzionalità di base dell'applicazione devono essere conformi ai requisiti del modello utente standard di Windows Vista. Questi requisiti sono stati descritti in dettaglio nel passaggio precedente, passaggio tre: riprogettare la funzionalità dell'applicazione per la compatibilità con controllo dell'account utente.

Impatto di Controllo dell'account utente nell'esperienza utente di Windows

L'impatto più grande e immediato sull'esperienza utente sarà sentito dagli amministratori. Gli utenti amministratori dovranno ora fornire l'autorizzazione per eseguire attività amministrative. In combinazione con questo, gli utenti standard avranno ora la possibilità di chiedere agli amministratori di concedere l'autorizzazione per determinate attività amministrative all'interno della sessione attualmente registrata.

Obiettivi dell'esperienza utente di Controllo dell'account utente

L'obiettivo complessivo per l'esperienza utente di Controllo dell'account utente consiste nel fornire una prevedibilità nell'esperienza utente:

• Per un amministratore, ciò significa che l'utente sa sempre quando dovrà concedere l'autorizzazione per eseguire un'attività con privilegi elevati.

Questo è l'atto di richiedere il token di accesso amministratore dell'utente in modo che possa apportare modifiche necessarie per l'amministratore.

• Per gli utenti standard, ciò significa che sapranno quando:
  • Sarà necessario fornire l'approvazione dell'amministratore (ambienti home e non gestiti) per le attività amministrative
  • OPPURE Quando non è possibile completare un'attività (ambienti gestiti in cui l'elevazione è esplicitamente non consentita) e deve contattare l'help desk

Obiettivi di progettazione

L'elenco seguente include gli obiettivi di progettazione di Controllo dell'account utente.

Eliminare l'elevazione non necessaria

Gli utenti devono eseguire privilegi elevati solo per eseguire attività che richiedono un token di accesso amministratore. Tutte le altre attività devono essere progettate per eliminare la necessità di elevazione. Il software pre-Windows Vista richiede spesso un token di accesso amministratore inutilmente scrivendo nelle sezioni del Registro di sistema HKLM o HKCR o nelle cartelle di sistema di Programmi o Windows.

Essere prevedibili

Gli amministratori devono sapere quali attività richiedono l'elevazione dei privilegi. Se non riescono a prevedere in modo accurato la necessità di elevazione, è più probabile fornire il consenso per le attività amministrative quando non dovrebbero. Gli utenti standard devono sapere quali attività richiedono a un amministratore di eseguire o non possono essere eseguite in tutti gli ambienti gestiti.

Richiedere uno sforzo minimo

Le attività che richiedono un token di accesso con privilegi più elevati devono essere progettate per richiedere una singola elevazione. Le attività che richiedono più elevazioni diventano rapidamente noiose.

Ripristinare l'utente standard

Al termine di un'attività che richiede un livello superiore di token di accesso, il programma deve ripristinare lo stato utente standard.

Richiesta di elevazione dei privilegi

La richiesta di elevazione dei privilegi è basata su un'interfaccia utente di Windows esistente. La richiesta di elevazione dei privilegi visualizza informazioni contestuali sul file eseguibile che richiede l'elevazione dei privilegi e il contesto è diverso a seconda che l'applicazione sia firmata o meno da Authenticode. La richiesta di elevazione dei privilegi viene visualizzata in due varianti: la richiesta di consenso e la richiesta di credenziali.

Richiesta di consenso

La richiesta di consenso viene visualizzata agli amministratori in Amministrazione modalità approvazione quando tentano di eseguire un'attività amministrativa. Si tratta dell'esperienza utente predefinita per gli amministratori in Amministrazione modalità approvazione e può essere configurata nello snap-in Gestione criteri di sicurezza locale (secpol.msc) e con Criteri di gruppo.

La figura seguente è un esempio di richiesta di consenso per il controllo dell'account utente.

Figura 4. Richiesta di consenso di Controllo dell'account utente

Richiesta credenziali

La richiesta di credenziali viene visualizzata agli utenti standard quando tentano di eseguire un'attività amministrativa. Si tratta dell'esperienza utente predefinita per gli utenti standard e può essere configurata nello snap-in Gestione criteri di sicurezza locale (secpol.msc) e con Criteri di gruppo.

La figura seguente è un esempio di prompt delle credenziali del controllo dell'account utente.

Figura 5. Richiesta di credenziali di Controllo dell'account utente

Criterio di consenso predefinito della richiesta di elevazione dei privilegi per Windows Vista

Nella tabella seguente viene descritto lo stile di richiesta predefinito per ogni tipo di account utente in Windows Vista.

Comportamento predefinito della richiesta di elevazione dei privilegi

Tipo di account utente	Impostazione richiesta di elevazione dei privilegi
Utente standard	Richiesta di credenziali
Account amministratore in modalità approvazione Amministrazione	Richiedi consenso

Flusso del processo dell'esperienza utente

Il flusso del processo dell'esperienza utente dell'interfaccia utente è costituito da tre componenti distinti:

1. Punto di ingresso di elevazione (ad esempio, un controllo o un collegamento che visualizza l'icona dello scudo UAC).
2. Richiesta di elevazione dei privilegi (richiesta di consenso o credenziali di amministratore).
3. Processo con privilegi elevati.

Il flusso di lavoro di esempio seguente riepiloga il modo in cui i componenti precedenti sono correlati:

1. Un amministratore in Amministrazione modalità approvazione accede a un computer Windows Vista.
2. L'utente decide quindi di aggiungere un altro utente amministratore per il computer.
3. L'utente fa clic su Start, fa clic su Pannello di controllo e quindi fa clic sul collegamento nella sezione Sicurezza intitolata Consenti un programma tramite Windows Firewall, visualizzato inline con un'icona di scudo.
4. Viene visualizzata una richiesta di consenso che richiede all'utente l'approvazione.
5. L'utente fa clic su Continua e viene creato il processo con privilegi elevati.
6. In Impostazioni di Windows Firewall l'utente modifica le impostazioni di Windows Firewall e quindi fa clic su OK, che termina il processo con privilegi elevati.
7. L'utente continua a lavorare sul computer come utente standard.

Nota I punti di ingresso di elevazione non ricordano lo stato (ad esempio, quando si torna da una posizione o un'attività schermata), nonché il punto di ingresso non ricorderà che si è verificata l'elevazione. Di conseguenza, l'utente dovrà ripetere l'elevazione per immettere nuovamente l'attività,il collegamento o il pulsante.

Punti di ingresso elevazione

Per i punti di ingresso, l'icona dello scudo verrà collegata a determinati controlli (ad esempio pulsanti, collegamenti di comando, collegamenti ipertestuali) per indicare che il passaggio immediato successivo richiede l'elevazione.

Icona schermata

L'icona dello scudo è la decorazione principale dell'interfaccia utente per un punto di elevazione controllo dell'account utente. Questa icona indica le attività correlate alla sicurezza in Windows Vista e nelle versioni precedenti di Windows e questa relazione è continuata in Windows Vista.

La figura seguente è un esempio dell'icona dello scudo.

Figura 6. Icona Scudo di sicurezza

L'icona dello scudo avrà un ruolo fondamentale in tutti e tre i componenti dell'esperienza utente di Controllo dell'account utente.

Quando si visualizza il sistema con Esplora risorse, tutte le applicazioni contrassegnate per richiedere un token di accesso amministratore all'avvio verranno decorate automaticamente con un glifo dello scudo sopra la relativa icona. Ciò consente agli utenti di sapere quali applicazioni, al momento dell'avvio, richiederanno l'elevazione dei privilegi.

Proprietà dell'icona dello scudo:

• Aspetto coerente nell'intera esperienza utente di Controllo dell'account utente.
• Non riflette alcuno stato di visualizzazione ,ad esempio attivo, al passaggio del mouse, disabilitato e così via.
• Non ricorda lo stato.

Esistono tre stili di controllo coerenti che un punto di ingresso contrassegnato con un'icona di scudo può assumere all'interno dell'esperienza utente:

• Pulsante Controllo dell'account utente
• Collegamento ipertestuale di Controllo dell'account utente
• Collegamento al comando di Controllo dell'account utente

Questi stili si applicano a tutti gli scenari in cui possono essere visualizzati questi elementi dell'interfaccia utente, ad esempio Procedure guidate, Pagine delle proprietà, Pannello di controllo Framework, Esplora risorse e così via. Ognuno degli stili implica che una richiesta di elevazione dei privilegi verrà visualizzata immediatamente dopo che l'utente fa clic su un controllo dell'interfaccia utente di Controllo dell'account utente.

In questa sezione viene illustrato anche un quarto punto di ingresso dell'interfaccia utente dell'interfaccia utente, la sovrimpressione dell'icona di Controllo dell'account utente. Indipendentemente dal fatto che un eseguibile riceva o meno una sovrapposizione di icone non sia controllato dallo sviluppatore dell'applicazione. Windows Vista sovrappone un'icona di schermata sulle icone delle applicazioni per i file eseguibili che hanno richiestoExecutionLevel impostato su requireAdministrator.

Pulsante Di schermata UAC

Il pulsante di schermatura UAC deve essere usato in qualsiasi pulsante dell'interfaccia utente che, quando premuto, richiederà la richiesta di elevazione dei privilegi per richiedere all'utente l'approvazione o le credenziali.

I pulsanti di schermata UAC possono essere usati come pulsanti di commit (ad esempio , Avanti in una procedura guidata) o come pulsante per visualizzare un'interfaccia utente di impostazioni aggiuntiva ,ad esempio Modifica impostazioni in una finestra di dialogo delle proprietà.

Il pulsante UAC shield è costituito da due componenti dell'interfaccia utente:

• Icona Scudo di sicurezza
• Etichetta testo

Il pulsante di schermatura UAC viene inserito in un pacchetto in modo che gli sviluppatori possano usarlo al posto di un pulsante normale. Il pulsante Controllo dell'account utente supporta anche il rendering dell'icona dello scudo sul lato sinistro o destro dell'etichetta di testo. Inoltre, gli sviluppatori avranno la possibilità di nascondere/mostrare l'icona dello scudo mentre viene visualizzato il pulsante Controllo dell'account utente.

Lo screenshot seguente è un esempio di pulsante di schermata UAC.

Figura 7. Pulsante di schermata UAC

Collegamento ipertestuale di Controllo dell'account utente

Il collegamento ipertestuale controllo dell'account utente deve essere usato in qualsiasi collegamento ipertestuale dell'interfaccia utente che, quando si fa clic, richiederà la richiesta di elevazione dei privilegi per richiedere l'approvazione o le credenziali all'utente.

Un collegamento ipertestuale di Controllo dell'account utente è costituito dai componenti seguenti:

• Icona Scudo di sicurezza
• Controllo Collegamento ipertestuale

Il collegamento ipertestuale di Controllo dell'account utente non è incluso nell'icona dello scudo da usare per uno sviluppatore. Gli sviluppatori dovranno ottenere la risorsa icona dello scudo ed eseguirne il rendering accanto al collegamento ipertestuale.

Lo screenshot seguente è un esempio di collegamento ipertestuale di Controllo dell'account utente.

Figura 8. Collegamento ipertestuale di Controllo dell'account utente

Collegamento al comando UAC

Il collegamento al comando controllo dell'account utente deve essere usato in qualsiasi pulsante dell'interfaccia utente su cui, quando si fa clic, richiederà la richiesta di elevazione dei privilegi per richiedere l'approvazione o le credenziali all'utente.

I collegamenti ai comandi di Controllo dell'account utente devono essere usati solo come pulsanti di commit , ad esempio "Esegui questa opzione" in una finestra di dialogo.

Il collegamento al comando UAC è costituito dai componenti seguenti:

• Icona Scudo di sicurezza
• Componenti di collegamento ai comandi standard
• Testo del collegamento
• Testo della nota

Il collegamento al comando di Controllo dell'account utente viene inserito in un pacchetto in un modo in cui uno sviluppatore può usare un collegamento di comando di Controllo dell'account utente al posto di un collegamento di comando normale. Il collegamento al comando controllo dell'account utente supporta il rendering dell'icona dello scudo sul lato sinistro o destro del collegamento di comando.

Di seguito è riportato un esempio di collegamento a un comando di Controllo dell'account utente.

Figura 9. Collegamento al comando di Controllo dell'account utente

Sovrapposizioni di icone

In Windows Vista, se un file eseguibile richiede l'elevazione dell'elevazione per l'avvio, l'icona dell'eseguibile deve essere "stampata" con un'icona di scudo per indicare questo fatto. Il manifesto dell'applicazione dell'eseguibile deve contrassegnare "requireAdministrator" per designare l'eseguibile come richiesta di un token di accesso amministrativo completo. La sovrimpressione dell'icona dello scudo verrà inserita automaticamente anche nei file eseguibili ritenuti di elevazione in base all'euristica del rilevamento del programma di installazione. Ad esempio, un file denominato setup.exe riceverà automaticamente una sovrapposizione di icone schermate anche se l'eseguibile non ha un manifesto dell'applicazione incorporato.

La figura seguente è un esempio di sovrapposizione dell'icona di Controllo dell'account utente.

Figura 10. Sovrimpressione icona controllo dell'account utente

Nota Le indicazioni su come creare e incorporare un manifesto dell'applicazione con un eseguibile sono disponibili nella sezione Creare e incorporare un manifesto dell'applicazione con l'applicazione di questo documento.

Implementazione dell'interfaccia utente

Implementazione e API dell'icona schermata

Questa sezione fornisce informazioni preliminari sulle icone e sulle API disponibili per gli sviluppatori durante la migrazione o l'implementazione di nuove funzionalità dell'applicazione amministrativa.

Implementazione e API dell'icona schermata

Icone	API
Shield	Risorsa utente: IDI_SHIELD
Pulsante	Button_SetElevationRequired(hwndButton)
Syslink/Hyperlink	Layout IDI_SHIELD accanto a syslink
Collegamento ai comandi	Caricare IDI_SHIELD e impostare come icona di collegamento al comando
Menu di scelta rapida	Supporto delle icone in DefCM per i comandi statici

Aggiungere un'icona schermata all'interfaccia utente

Aggiungere un'icona piccola:

#include <shellapi.h>
SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_SMALLICON, &sii);
hiconShield  = sii.hIcon;

Aggiungere un'icona grande:

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_LARGEICON, &sii);
hiconShield  = sii.hIcon;

Aggiungere un'icona di dimensioni personalizzate:

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICONLOCATION, &sii);
hiconShield  = ExtractIconEx(sii. ...);

Nota In genere, non è consigliabile aggiungere l'icona dello scudo direttamente all'interfaccia utente. È consigliabile usare uno dei metodi di elaborazione dell'icona dello scudo in un controllo . Inoltre, l'aggiunta di un'icona schermata nell'interfaccia utente non garantisce la compatibilità di Controllo dell'account utente. È anche necessario riformulare l'intera esperienza utente dell'applicazione (aggiungere un oggetto requestedExecutionLevel, correggere eventuali bug utente standard e assicurarsi che l'interfaccia utente sia intuitiva e compatibile con controllo dell'account utente).

Aggiungere un'icona di scudo a un pulsante

Il controllo pulsante standard (PUSHBUTTON, DEFPUSHBUTTON) è stato migliorato per consentire di aggiungere un'icona insieme al testo visualizzato, senza richiedere l'impostazione degli stili BS_ICON o BS_BITMAP.

Per visualizzare l'icona dello scudo, chiamare la macro seguente (definita in commctrl.h):

Button_SetElevationRequiredState(hwndButton, fRequired);

Nota hwndButton è il HWND del pulsante; fRequired determina se visualizzare (TRUE) o nascondere (FALSE) l'icona dello scudo UAC.

Aggiungere un'icona di schermata a un pulsante di Windows Installer

Le finestre di dialogo di Windows Installer create usando il supporto della tabella interna possono aggiungere uno scudo all'ultimo pulsante della sequenza di dialogo dell'interfaccia utente impostando l'attributo ElevationShield sul controllo.

Aggiungere un'icona schermata a un pulsante "Avanti" in una procedura guidata

Importante La visualizzazione dell'icona dello scudo UAC è supportata solo in AeroWizards (PSH_AEROWIZARD).

Per visualizzare l'icona dello schermo sul pulsante "Avanti" per una pagina specifica in un aeroWizard, usare il codice seguente:

case WM_NOTIFY:
    if (reinterpret_cast<NMHDR*>(lParam)->code == PSN_SETACTIVE)
    {
        // Show next button
        //
        // Note new wParam flag -- when PSWIZBF_ELEVATIONREQUIRED flag
        // is specified, it indicates that the next page will require
        // elevation, so if the next button is being shown, show it as
        // a shield button.

        SendMessage(GetParent(hwndDlg), 
                    PSM_SETWIZBUTTONS, 
                    PSWIZBF_ELEVATIONREQUIRED, 
                    PSWIZBF_NEXT);

        // return 0 to accept the activation
        SetWindowLong(hwndDlg, DWLP_MSGRESULT, 0); 
    }
    break;

Aggiungere un'icona di schermata a un pulsante finestra di dialogo attività

Attenzione Un pulsante della finestra di dialogo attività non deve mai richiedere un'icona di schermata UAC. L'azione "premere" su un pulsante della finestra di dialogo attività è prevista per eseguire il commit/annullare e ignorare la finestra di dialogo dell'attività. Sarebbe strano che un pulsante di questo tipo visualizzi la richiesta di elevazione all'utente.

Elevare una finestra di dialogo modale

Usare il moniker di elevazione per elevare l'oggetto COM che rappresenta la finestra di dialogo modale.

Attività:

• Spostare la finestra di dialogo in un oggetto COM.
• Esporre un metodo ShowDialog().
• Usare l'API CreateElevatedComObject() per creare l'oggetto COM e chiamare ShowDialog().

Questa API eseguirà un'istanza dell'oggetto COM come amministratore dopo aver eseguito il processo di elevazione.

Nota È disponibile una versione di questa API più complessa da chiamare. Una versione semplificata sarà disponibile in una versione successiva di Windows Vista.

Linee guida per l'istruzione e l'assistenza per gli utenti

Quando un'interfaccia utente è stata rivalutata e inserita dietro un pulsante, gli ISV devono valutare se viene garantita una modifica al nome del pulsante. Microsoft consiglia vivamente di usare Advanced come etichetta pulsante per le attività di elevazione. Usare invece etichette più descrittive e comprensibili, ad esempio Cambia impostazioni o un termine che suggerisce cosa è dietro il pulsante.

Linee guida per l'interfaccia utente solo amministratore

Se un'applicazione verrà sempre avviata da un amministratore, non è necessario aggiungere schermate aggiuntive all'interno dell'interfaccia utente dell'applicazione. Questo perché l'applicazione verrà elevata e tutto ciò che fa sarà elevato e quindi non richiede un'ulteriore elevazione.

Nota Se sono presenti collegamenti ad altre interfacce utente di amministratore nell'esperienza utente di sola amministratore, l'interfaccia utente avvierà la destinazione con privilegi elevati. Pertanto, non è necessario inserire gli schermi in un'applicazione che è esclusivamente amministrativa.

Quando aggiungere l'icona schermata all'interfaccia utente dell'applicazione

Un'applicazione scelta amministrativa

Un processo o un oggetto COM con privilegi elevati

L'applicazione iniziale viene avviata senza richiedere l'elevazione. Tali elementi nell'interfaccia utente che richiedono un token di accesso amministrativo vengono decorati con un'icona di schermata come identificazione. Questa decorazione indica all'utente che usando tale funzionalità richiederà l'approvazione dell'amministratore. Quando l'applicazione rileva che uno di questi pulsanti è stato selezionato, ha le due opzioni seguenti.

• L'applicazione avvia un secondo programma usando ShellExeucute() per eseguire l'attività amministrativa. Questo secondo programma verrà contrassegnato con una richiestaExecutionLevel di requireAdministrator, causando così che l'utente venga richiesto di approvare. Questo secondo programma verrà eseguito con un token di accesso amministrativo completo e sarebbe in grado di eseguire l'attività desiderata.
• L'applicazione avvia un oggetto COM usando CreateElevatedComObject(). Questa API avvia l'oggetto COM con un token di accesso amministrativo completo dopo l'approvazione e questo oggetto COM può eseguire l'attività desiderata.

Questo metodo offre l'esperienza utente più ricca ed è il metodo preferito per gestire le funzionalità amministrative.

I requisiti dell'elenco seguenti per un processo o un oggetto COM con privilegi elevati:

• Il pannello di controllo deve implementare la decorazione dello scudo e la relativa architettura necessaria.
• Lo sviluppatore deve determinare dove deve andare lo schermo sull'interfaccia utente.
• Lo sviluppatore deve eseguire il lavoro dell'architettura per separare la logica di business in un oggetto COM dall'oggetto interfaccia utente.
• Lo sviluppatore deve chiamare il processo di elevazione dell'interfaccia utente quando viene rilevato l'evento OnClick per l'icona dello schermo.

L'elenco seguente illustra i vantaggi della progettazione corretta di un processo o di un oggetto COM con privilegi elevati:

• Questa è la migliore esperienza utente generale per entrambi i tipi di utente. L'interfaccia utente verrà avviata, visualizzabile a tutti e tutte le funzionalità dell'interfaccia utente in tale interfaccia utente saranno accessibili a tutti. Solo quando è necessaria un'attività di amministratore, l'utente tenta di completare l'attività.
• Questa operazione consente ora di rendere completamente conforme all'interfaccia utente il passaggio in avanti.
• La separazione dell'interfaccia utente/COM è una procedura consigliata per l'architettura.

Facendo clic su un'icona schermata, l'applicazione avvia un programma con privilegi elevati o un oggetto COM con privilegi elevati per eseguire l'attività.

Applicazione solo amministratore

In questa istanza, l'avvio iniziale dell'applicazione richiede l'approvazione dell'amministratore. Questo metodo viene chiamato "prompt prima dell'avvio". Dopo l'avvio, l'applicazione viene eseguita con un token di accesso amministrativo completo e può quindi eseguire le attività amministrative desiderate. Questo metodo è il minimo lavoro per lo sviluppatore. Il manifesto dell'applicazione è contrassegnato con una richiestaExecutionLevel di requireAdministrator.

Importante Anche se ciò richiede la quantità minima di lavoro per lo sviluppatore, si noti che, proprio come altre applicazioni amministrative in Windows Vista, gli amministratori dovranno elevare per usare questa applicazione e che gli utenti standard non potranno usare l'applicazione.

L'elenco seguente dettagli i requisiti per le applicazioni solo amministratore:

• Il manifesto dell'applicazione deve contenere un set di contrassegnoExecutionLevel richiesto per richiedereAdministrator.
• L'utente viene richiesto di approvare l'amministratore prima dell'avvio dell'applicazione con un token di accesso amministrativo completo.

L'elenco seguente illustra i vantaggi della progettazione corretta di un'applicazione solo amministratore:

• Il sistema operativo non deve "indovinare" se l'applicazione di installazione è un'applicazione amministrativa.
• Gli utenti standard riceveranno automaticamente un suggerimento che l'operazione è un'operazione amministrativa. Ad esempio, quando viene visualizzata l'icona per un'applicazione contrassegnata richiedeAdministrator, l'icona ha uno scudo incorporato nell'icona.
• In Windows Vista, se si contrassegna l'applicazione come richiestoAdministrator si sa che, dopo l'avvio, verrà eseguito con un token di accesso amministratore completo. Gli utenti devono eseguire l'applicazione (come amministratore in modalità approvazione Amministrazione o tramite Esegui come amministratore).

Nota Contrassegnare un'applicazione richiedeAdministrator non eleva in modo automatico l'applicazione. L'utente dovrà comunque concedere il consenso di elevazione per avviare l'applicazione. Non è possibile contrassegnare un'applicazione in Windows Vista per elevare in modo invisibile all'utente.

Nell'elenco seguente vengono illustrati i punti di considerazione per la progettazione di un'applicazione solo amministratore:

• Questa esperienza utente significa che tutti gli utenti visualizzeranno un prompt di elevazione (il prompt delle credenziali o il prompt dei consenso) prima dell'interfaccia utente anche visibile. Ciò significa anche che nessuno è in grado di visualizzare semplicemente le impostazioni correnti fino a quando non viene autenticata con le credenziali di amministratore
• Se si contrassegna richiedeAdministrator in un'applicazione di installazione, è necessario tenere presente che l'utente che esegue la configurazione è diverso dall'utente che può usare l'applicazione. Pertanto, non è necessario modificare HKEY_CURRENT_USER (HKCU) e altre impostazioni per utente, ad esempio la scrittura nel profilo utente, durante la configurazione amministrativa.

Importante È necessario presupporre che l'utente che esegue l'applicazione amministrativa sia diversa dall'utente normale nel computer.

I file eseguibili che richiedono un token di accesso amministratore sono contrassegnati con una sovrapposizione dell'icona di schermata.

Applicazione mista

Un'applicazione mista è una che può essere eseguita dagli utenti, tutti gli utenti del sistema (utenti standard, amministratori in Amministrazione modalità approvazione e quelli inclusi tra operatori di backup). Si tratta anche di un'applicazione "prompt prima dell'avvio". L'applicazione verrà eseguita con il token di accesso del chiamante e verrà avviata normalmente per gli utenti standard (nessun prompt di elevazione). Il programma deve quindi modificare il comportamento in fase di esecuzione per disabilitare tali funzionalità che non sarebbero disponibili per l'utente in base al token di accesso amministrativo ottenuto.

Un'applicazione mista non ha la possibilità di ottenere privilegi amministrativi aggiuntivi dopo l'avvio; pertanto, non offre la flessibilità del processo con privilegi elevati o del metodo dell'oggetto COM descritto in precedenza. Ciò è più utile per le applicazioni che richiedono un token di accesso superiore a quello di un utente standard, ma minore di un amministratore completo.

Ad esempio, Microsoft Management Console (MMC) è contrassegnato come massimoDisponibile. Se un utente standard true esegue MMC, MMC verrà avviato come applicazione utente standard senza alcun tentativo di elevazione o richiesta. Se l'utente è un utente "token diviso", ad esempio un amministratore in Amministrazione modalità approvazione o un operatore di backup, il sistema operativo chiederà all'utente di ottenere il consenso per avviare MMC con il privilegio "più alto" disponibile dell'utente. Nel caso di un utente standard con privilegi di operatore di backup, dopo l'elevazione, MMC verrà avviato con l'utente standard + Operatore di backup, ma niente di più. Se un amministratore avvia MMC, dopo l'elevazione, MMC verrà eseguito come applicazione di amministratore completa.

Il vantaggio di progettare correttamente un'applicazione mista è che l'applicazione è disponibile per tutti gli utenti del sistema, anche se alcune funzionalità potrebbero essere disabilitate.

L'elenco seguente illustra i punti di considerazione per la progettazione di applicazioni miste:

• Lo sviluppatore deve modificare dinamicamente il comportamento dell'applicazione in base ai privilegi amministrativi di Windows e ai diritti utente disponibili dall'utente.
• L'utente standard non è in grado di agire sulle funzioni a livello amministrativo sull'interfaccia utente. Non esiste alcun potenziale di elevazione della richiesta dopo l'esecuzione del programma (gli amministratori devono elevare prima di aprire l'interfaccia utente).

Nota Esiste una soluzione alternativa per il punto puntato precedente. Un amministratore può avviare un prompt dei comandi con privilegi elevati nel computer dell'utente standard ed eseguire l'applicazione dal prompt dei comandi. Ad esempio, fare clic con il pulsante destro del mouse sul prompt dei comandi, selezionare Esegui come amministratore e quindi digitare "applicationname.exe" nel prompt dei comandi.

L'esperienza utente viene ramiata tra l'utente standard e l'amministratore in Amministrazione modalità approvazione.

Esempio di applicazione mista: applicazione di backup

L'applicazione può essere avviata da un membro del gruppo Operatori di backup. Il programma verifica quindi che il livello massimo di privilegi amministrativi e diritti utente disponibili dall'utente sia sufficiente per l'operazione del programma. Per altre informazioni sul comportamento di avvio del programma, vedere la sezione Contrassegno manifesto applicazione e comportamento di avvio dell'applicazione di questo documento.

Decisioni chiave per la progettazione di applicazioni Administrator-Only

Oggetti business back-end

Questa sezione offre una panoramica dei tre modelli che uno sviluppatore può scegliere quando si sviluppa un'applicazione amministrativa che offre la migliore esperienza utente.

• Modello Amministrazione Broker
• Modello di servizio Back-End
• Modello a oggetti COM Amministrazione

modello Amministrazione Broker

Nel modello Amministrazione Broker l'applicazione viene suddivisa in due eseguibili indipendenti, ovvero un eseguibile utente standard e un eseguibile amministrativo. Lo sviluppatore, usando un manifesto dell'applicazione, contrassegna il programma utente standard con una richiestaExecutionLevel di asInvoker e contrassegna il programma amministrativo con una richiestaExecutionLevel di requireAdministrator. Un utente avvierà prima il programma utente standard. Quando l'utente tenta di eseguire un'operazione che il programma utente standard conosce richiede un token di accesso amministratore completo, esegue un shellExecute() e avvia il programma amministrativo. L'API Windows ShellExecute() esamina il manifesto e richiede l'approvazione dell'utente prima di eseguire l'applicazione con il token di accesso amministrativo completo dell'utente. Il programma amministrativo può quindi eseguire le attività amministrative.

Nota Il programma eseguibile amministrativo può abilitare la comunicazione tra processi con un eseguibile utente standard usando memoria condivisa, RPC locale o pipe denominate. Se il programma amministrativo abilita la comunicazione con l'eseguibile utente standard, lo sviluppatore deve usare una buona procedura di sicurezza per convalidare tutti gli input dal programma con privilegi inferiori.

Nota Non esiste alcun canale di comunicazione tra i due programmi una volta avviato il secondo programma

I dettagli dell'elenco seguente usano per il modello di broker di amministrazione:

• Procedure guidate: quando l'hardware guidato si rende conto che il driver richiesto non è installato nel computer o si trova nel percorso approvato dell'organizzazione, ha bisogno di un'applicazione con privilegi elevati con la possibilità di spostare un driver nell'archivio computer.
• Autorun.exe chiamata Setup.exe: la prima volta che si inserisce un CD di gioco, l'operazione necessaria da autorun.exe consiste nel configurare l'applicazione. La seconda volta che si inserisce il CD, l'operazione predefinita consiste nel riprodurre il gioco.

Un vantaggio per l'uso del modello di broker di amministrazione è che probabilmente è il meccanismo più semplice da implementare per lo sviluppatore.

L'elenco seguente illustra alcuni svantaggi per l'uso del modello di broker Amministrazione:

• Le transizioni dall'applicazione all'applicazione possono essere confuse all'utente. Può essere difficile mantenere l'apprised dell'utente per il motivo per cui una nuova applicazione è "comparsa" nel monitoraggio.
• Inoltre, lo stato è più difficile da passare tra queste due applicazioni. Ad esempio, non si userebbe questo metodo per passare lo stato tra un pannello di controllo utente standard (CPL) e la controparte amministratore semplicemente per consentire alla stessa CPL di avere funzionalità amministrative e non amministrative. L'utente standard CPL deve archiviarne lo stato da qualche parte.
• Spesso, è presente un sacco di codice replicato durante la suddivisione della funzionalità tra due programmi.

Per implementare il modello di broker amministratore, creare due programmi (un utente standard e un amministratore), contrassegnarli con il manifesto appropriato richiestoExecutionLevel e avviare il programma amministrativo dal programma utente standard usando ShellExecute().

Modello di servizio Back-End

Nel modello di servizio back-end l'applicazione viene nuovamente suddivisa in due eseguibili indipendenti, ovvero un eseguibile utente standard che fornisce l'interfaccia utente all'utente e un servizio back-end in esecuzione nel sistema. Microsoft Remote Procedure Call (RPC) viene usato per comunicare tra i due. L'applicazione front-end è contrassegnata con una richiestaExecutionLevel di asInvoker e il servizio back-end è in esecuzione come SYSTEM. La comunicazione tra l'applicazione e il servizio back-end viene eseguita con RPC.

Un uso per il modello di servizio back-end consiste nel controllare i programmi che potrebbero influire sul sistema, ad esempio programmi antivirus o anti-spyware. L'applicazione front-end fornisce i mezzi in base ai quali l'utente connesso e gli aspetti di controllo del servizio.

Un vantaggio principale dell'uso del modello di servizio back-end è che non è necessaria alcuna richiesta di elevazione.

L'elenco seguente illustra alcuni svantaggi per l'uso del modello di servizio back-end:

• Il servizio deve limitare i tipi di attività che l'applicazione front-end può indicare a tale scopo. Ad esempio, un servizio antivirus può consentire a un utente standard di avviare un'analisi del sistema, ma non di disabilitare il controllo dei virus in tempo reale.
• L'aggiunta di un servizio non necessario al sistema può influire sull'intero sistema. Assicurarsi che il servizio sia veramente necessario per l'implementazione di Windows Vista e che il servizio sia progettato correttamente.

Per implementare il modello di servizio back-end, creare un'applicazione front-end utente standard e un servizio back-end. Installare il servizio nel sistema durante l'installazione del prodotto.

Modello a oggetti COM Amministrazione

Questo modello è incluso qui, ma è stato descritto in dettaglio in precedenza in questo documento. Il modello a oggetti COM amministratore consente l'elevazione amministrativa dinamica per eseguire operazioni specifiche dall'interno di un'applicazione o di un pannello di controllo.

Un vantaggio principale per l'uso del modello a oggetti COM amministratore è che presenta l'esperienza utente migliore per l'utente.

L'elenco seguente illustra alcuni svantaggi per l'uso del modello a oggetti COM amministratore:

• Richiede la maggior parte del lavoro per lo sviluppatore perché ogni funzionalità dell'applicazione deve essere valutata e testata per le funzionalità di amministratore e tale funzione deve essere fornita da un oggetto COM back-end.
• L'utente deve fornire l'approvazione dell'elevazione.
• L'"unità" risultante dell'applicazione utente standard e Amministrazione oggetto COM back-end è ora "drivable" e non è protetto da UIPI e altri meccanismi di isolamento.

Per implementare il modello a oggetti COM amministratore, creare un'applicazione front-end utente standard e avviare oggetti COM back-end elevati per eseguire attività amministrative.

5. Riprogettazione del programma di installazione dell'applicazione

Le procedure consigliate seguenti sono per installazioni di applicazioni ben comportate in un ambiente Windows Vista o UAC. Non si tratta tuttavia di un elenco completo. Per una spiegazione più dettagliata dei requisiti di logo per Windows Vista, inclusi i requisiti dell'interfaccia utente, vedere la documentazione del logo di Windows Vista e la versione approfondita della bozza più recente del documento linee guida del logo di Windows Vista.

Usare questi requisiti durante la riprogettazione dell'applicazione.

Usare Windows Installer 4.0 per il pacchetto di installazione.

Molti dei requisiti seguenti sono già integrati nel motore di Windows Installer. L'uso di Windows Installer per il pacchetto di installazione ti aiuterà a seguire i requisiti di installazione di Windows Vista.

Usare i file con versione e non eseguire il downgrade dei file durante l'installazione.

Il controllo delle versioni dei file garantisce che lo stato di installazione finale sia corretto al termine dell'installazione. Senza versioni di file, alcune speciali mani saranno necessarie per garantire che l'installazione funzioni correttamente per molti scenari di installazione diversi. Inoltre, quando si installano file con versione, non eseguire il downgrade delle versioni, in particolare i file condivisi. Il downgrade delle versioni può essere utile per l'applicazione, ma spesso causa problemi con altre applicazioni. Dichiarando le versioni corrette dei file nel pacchetto di Windows Installer, Windows Installer supporta in modo nativo questa funzionalità.

Installare applicazioni e archiviare i dati per utente in posizioni diverse.

Le applicazioni devono essere installate in una cartella nella directory Programmi. Per configurare questa operazione, è possibile usare la proprietà ProgramFilesFolder nella tabella Direcotry del pacchetto Windows Installer, i dati di configurazione per utente devono essere archiviati nei file nella directory \Users\username\AppData o nelle chiavi del Registro di sistema nella radice HKCU. I dati utente, i modelli e i file creati dall'applicazione dispongono di percorsi appropriati nella sottodirectory \Users\username. Anche se questa operazione non è stata applicata in passato, poiché molti utenti eseguivano programmi con un token di accesso amministratore completo, le applicazioni che non inseriscono le informazioni nella posizione corretta potrebbero non riuscire. Questo è particolarmente vero quando la virtualizzazione è disattivata.

Usare un percorso di cartella coerente durante l'installazione di componenti condivisi.

I componenti condivisi devono essere installati nella directory Common Files usando la proprietà CommonFilesFolder nella tabella Directory del pacchetto di Windows Installer. La gestione dei componenti condivisi può essere problematica e deve essere evitata, se possibile. Uno sviluppatore che non installa componenti condivisi in modo coerente può terminare con le informazioni di registrazione com (Component Object Model) che puntano ai componenti meno recenti. I moduli di merge di Windows Installer (MSM) sono progettati in modo specifico per abilitare l'installazione coerente dei componenti condivisi nel contesto di tutti i pacchetti che installano il componente condiviso. Altri problemi si verificano quando le modifiche dei componenti condivisi causano un errore delle applicazioni esistenti. Un modo per risolvere questo problema è che le applicazioni vengano compilate usando gli assembly con versione Microsoft .NET o Win32.

Eseguire il rollback dell'installazione se un'installazione ha esito negativo.

Il software parzialmente installato può non riuscire in modi strani e imprevisti che forniscono un'esperienza utente scarsa. Windows Installer supporta questa funzionalità di rollback.

Non installare i collegamenti dell'applicazione in tutto il profilo dell'utente.

Anche se potrebbe essere tentato di aggiungere l'icona dell'applicazione a ogni punto di esposizione noto in Windows, spesso gli utenti sentono che hanno perso il controllo del proprio computer. Gli utenti vengono quindi costretti a rimuovere manualmente questi collegamenti per restituire il computer a un aspetto desiderato e sentire. Se lo sviluppatore vuole aggiungere icone al desktop, chiedere all'utente l'autorizzazione durante l'installazione. Windows Vista indirizza l'individuazione delle applicazioni dopo l'installazione e l'elenco delle applicazioni usate più di recente per evitare l'attraversamento di menu Start di grandi dimensioni.

Evitare l'avvio automatico delle applicazioni in background all'accesso utente.

Anche se è possibile aggiungere programmi al gruppo di avvio o Esegui chiave durante l'installazione, aggiunge sovraccarico al sistema. Nel tempo, le prestazioni del sistema dell'utente possono ridurre significativamente. Se l'applicazione può trarre vantaggio da un'attività in background, consentire la configurazione dell'utente. Inoltre, l'aggiunta di un'attività di avvio tramite la chiave di esecuzione HLKM potrebbe impedire a un account utente standard di modificare il comportamento in futuro. Se l'utente vuole avviare un'applicazione in fase di accesso, archiviare le informazioni nella chiave di esecuzione di HKCU.

Seguire la logica di rimozione pulita.

Un utente potrebbe rimuovere un'applicazione non solo per liberare spazio su disco, ma anche per restituire il computer allo stato precedente all'installazione dell'applicazione. Il processo di disinstallazione dell'applicazione deve essere rimosso correttamente e completamente rimosso dall'applicazione. Windows Installer è predefinito per le regole seguenti:

• Tutti i file e le cartelle dell'applicazione non condivisi.
• File di applicazione condivisi il cui numero di riferimenti (refcount) raggiunge zero.
• Voci del Registro di sistema, ad eccezione delle chiavi che potrebbero essere condivise da altri programmi.
• Tutti i collegamenti dal menu Start creato dall'applicazione al momento dell'installazione.
• Le preferenze utente possono essere considerate dati utente e lasciate indietro, ma è consigliabile includere un'opzione per eseguire una rimozione completamente pulita.
• Disinstallatore stesso (se non si usa Windows Installer).

6. Creare e incorporare un manifesto dell'applicazione con l'applicazione

In Windows Vista, il modo corretto per contrassegnare le applicazioni consiste nell'incorporare un manifesto dell'applicazione all'interno del programma che indica al sistema operativo le esigenze dell'applicazione. Nella versione di Windows Vista sono disponibili disposizioni per consentire l'esecuzione di codice non manifesto o non firmato con un token di accesso amministrativo completo.

Nota Nelle versioni future, l'unico modo per eseguire un'applicazione con privilegi elevati sarà avere un manifesto firmato che identifica il livello di privilegio necessario per l'applicazione.

Schema del manifesto dell'applicazione

I manifesti dell'applicazione non sono nuovi della versione di Windows Vista. I manifesti sono stati usati in Windows XP per aiutare gli sviluppatori di applicazioni a identificare quali versioni delle DLL con cui è stata testata l'applicazione. Fornire il livello di esecuzione è un'estensione per lo schema del manifesto esistente.

Il manifesto dell'applicazione Windows Vista è stato migliorato con attributi che consentono agli sviluppatori di contrassegnare le applicazioni con un livello di esecuzione richiesto. Di seguito è riportato il formato.

<requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>

Valori possibili del livello di esecuzione richiesto

Valori	Descrizione	Comment
asInvoker	L'applicazione viene eseguita con lo stesso token di accesso del processo padre.	Consigliato per le applicazioni utente standard. Rifratto con punti di elevazione interni in base alle indicazioni fornite in questo documento.
highestAvailable	L'applicazione viene eseguita con i privilegi più elevati che l'utente corrente può ottenere.	Consigliato per le applicazioni in modalità mista. Pianificare di rifrazionare l'applicazione in una versione futura.
Requireadministrator	L'applicazione viene eseguita solo per gli amministratori e richiede che l'applicazione venga avviata con il token di accesso completo di un amministratore.	Consigliato solo per le applicazioni di amministratore. I punti di elevazione interni non sono necessari. L'applicazione è già in esecuzione con privilegi elevati.

Nota Le applicazioni di hosting possono diventare applicazioni standard solo per utenti o amministratori solo se supportano tale tipo di applicazione ospitata. Ad esempio, MMC.exe ora ospita solo snap-in amministrativi e Explorer.exe ospita solo il codice utente standard.

Comportamento del sistema

Markin dell'applicazione	Virtualizzare?
Contrassegno	Sì
asInvoker	No
Requireadministrator	No
highestAvailable	No

Contrassegno del manifesto dell'applicazione e comportamento di avvio dell'applicazione

In questa sezione viene illustrato in dettaglio il comportamento della richiesta di elevazione dei privilegi a seconda del token di accesso al processo padre, l'impostazione del controllo dell'account utente: comportamento della richiesta di elevazione dei privilegi per gli amministratori in Amministrazione modalità approvazione e controllo dell'account utente: comportamento della richiesta di elevazione dei privilegi per i criteri degli utenti standard e del contrassegno del livello di esecuzione richiesto per l'applicazione.

Se un'applicazione può essere eseguita e quali diritti utente e privilegi amministrativi di Windows può ottenere dipendono dalla combinazione del livello di esecuzione richiesto dell'applicazione nel database di compatibilità dell'applicazione e dai privilegi amministrativi disponibili per l'account utente che ha avviato l'applicazione. Le tabelle seguenti identificano il possibile comportamento di runtime in base a tali combinazioni possibili.

Comportamento di avvio dell'applicazione per un membro del gruppo Administrators locale

Token di accesso processo padre	Criteri di consenso per i membri del gruppo Administrators locale	Nessuno o asInvoker	highestAvailable	Requireadministrator
Utente standard	Nessuna richiesta	L'applicazione viene avviata come utente standard	L'applicazione viene avviata con un token di accesso amministrativo completo; nessun prompt	L'applicazione viene avviata con un token di accesso amministrativo completo; nessun prompt
Utente standard	Richiedi consenso	L'applicazione viene avviata come utente standard	L'applicazione viene avviata con un token di accesso amministrativo completo; richiedere il consenso	L'applicazione viene avviata con un token di accesso amministrativo completo; richiedere il consenso
Utente standard	Richiesta di credenziali	L'applicazione viene avviata come utente standard	L'applicazione viene avviata con un token di accesso amministrativo completo; richiedere le credenziali	L'applicazione viene avviata con un token di accesso amministrativo completo; richiedere le credenziali
Amministratore (Controllo dell'account utente disabilitato)	N/D	L'applicazione viene avviata con un token di accesso amministrativo completo; nessun prompt	L'applicazione viene avviata con un token di accesso amministrativo completo; nessun prompt	L'applicazione viene avviata con un token di accesso amministrativo completo; nessun prompt

Comportamento di avvio dell'applicazione per un account utente standard

Token di accesso processo padre	Criteri di consenso per utenti standard	asInvoker	highestAvailable	Requireadministrator
Utente standard	Nessuna richiesta	L'applicazione viene avviata come utente standard	L'applicazione viene avviata come utente standard	L'avvio dell'applicazione non riesce
Utente standard	Richiesta di credenziali	L'applicazione viene avviata come utente standard	L'applicazione viene avviata come utente standard	Richiedere le credenziali di amministratore prima di eseguire l'applicazione
Utente standard (Controllo dell'account utente disabilitato)	N/D	L'applicazione viene avviata come utente standard	L'applicazione viene avviata come utente standard	L'applicazione potrebbe essere avviata ma avrà esito negativo in un secondo momento

Comportamento di avvio dell'applicazione per un utente standard con privilegi aggiuntivi (ad esempio, operatore di backup)

Token di accesso processo padre	Criteri di consenso per utenti standard	asInvoker	highestAvailable	Requireadministrator
Utente standard	Nessun prompt	L'applicazione viene avviata come utente standard	L'applicazione viene avviata come utente standard con privilegi aggiuntivi	L'applicazione non riesce a avviare
Utente standard	Richiesta di credenziali	L'applicazione viene avviata come utente standard	Richiedere le credenziali prima di eseguire l'applicazione	Richiedere le credenziali di amministratore prima di eseguire l'applicazione
Utente standard (Controllo dell'account utente disabilitato)	N/D	L'applicazione viene avviata come utente standard	L'applicazione viene avviata come utente standard con privilegi aggiuntivi	L'applicazione potrebbe essere avviata ma avrà esito negativo in un secondo momento

Valori uiAccess

Possibili valori uiAccess

Valore	Descrizione
Falso	L'applicazione non deve eseguire l'input all'interfaccia utente di un'altra finestra sul desktop. Le applicazioni che non forniscono l'accessibilità devono impostare questo flag su false. Le applicazioni necessarie per eseguire l'input ad altre finestre sul desktop (tastiera sullo schermo, ad esempio) devono impostare questo valore su true.
Vero	L'applicazione può ignorare i livelli di controllo dell'interfaccia utente per guidare l'input a finestre con privilegi superiori sul desktop. Questa impostazione deve essere usata solo per le applicazioni assistive Technology dell'interfaccia utente.

Importante Le applicazioni con il flag uiAccess impostato su true devono essere autenticate per iniziare correttamente. Inoltre, l'applicazione deve risiedere in un percorso protetto nel file system. \Programmi\ e \windows\system32\ sono attualmente i due percorsi protetti consentiti.

Come creare un manifesto incorporato con Microsoft Visual Studio

Visual Studio offre la possibilità di incorporare automaticamente un file manifesto XML all'interno della sezione della risorsa dell'immagine PE (Portable Eseguibile). In questa sezione viene illustrato come usare Visual Studio per creare un'immagine PE firmata contenente un manifesto. Questo manifesto può quindi includere gli attributi necessariExecutionLevel che consentono all'applicazione di eseguire con il livello di privilegi desiderato in Windows Vista. Al momento dell'avvio del programma, le informazioni sul manifesto verranno estratte dalla sezione della risorsa dell'PE e usate dal sistema operativo. Non è necessario usare l'interfaccia utente grafica di Visual Studio per includere un manifesto. Una volta apportate le modifiche necessarie nel codice sorgente, la compilazione e il collegamento tramite gli strumenti della riga di comando includeranno anche il manifesto nell'immagine PE risultante.

File manifesto

Per contrassegnare l'applicazione, creare prima un file manifesto da usare con l'applicazione di destinazione. Questa operazione può essere eseguita usando qualsiasi editor di testo. Il file manifesto deve avere lo stesso nome del target.exe con estensione manifesto , come illustrato nell'esempio seguente.

Executable: IsUserAdmin.exe 
Manifest:IsUserAdmin.exe.manifest
Sample application manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="IsUserAdmin"
     type="win32"/> 
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Le parti del manifesto che devono essere modificate per l'applicazione sono contrassegnate in grassetto. Essi includono quanto segue:

• Identità dell'assembly
• Nome
• Tipo
• Descrizione
• Attributi nella richiestaExecutionLevel

Compilazione di manifesti dell'applicazione all'interno di codice C/C++ con Visual Studio 2005 per applicazioni solo Windows Vista

Importante Se l'applicazione è destinata all'esecuzione in Windows Vista e Windows XP, è necessario seguire le procedure descritte nella sezione successiva: Compilazione e incorporamento di un manifesto con Microsoft Visual Studio 2005 per Le applicazioni Windows XP e Windows Vista.

Successivamente, è necessario collegare il manifesto al file eseguibile aggiungendo una riga nel file di risorse dell'applicazione (il file rc) per incorporare il manifesto in Microsoft Visual Studio all'interno della sezione della risorsa del file PE. A tale scopo, inserire il manifesto nella stessa directory del codice sorgente per il progetto che si sta creando e modificare il file rc in modo da includere le righe seguenti.

#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST "IsUserAdmin.exe.manifest"

Dopo aver ricompilato l'applicazione, il manifesto deve essere incorporato nella sezione della risorsa del file eseguibile.

Compilazione e incorporamento di un manifesto con Microsoft Visual Studio 2005 per le applicazioni Windows XP e Windows Vista

In Visual Studio 2005 l'interfaccia IDE (Integrated Development Environment) C/C++ che consente l'inclusione di file manifesto aggiuntivi in un file eseguibile di destinazione esegue alcune operazioni di elaborazione nel codice XML, che inserisce un tag xmlns duplicato. A causa di questo, il metodo documentato in precedenza su come includere un manifesto in un progetto C++ di Visual Studio 2005 non può essere usato se l'applicazione deve essere eseguita in Windows Vista e Windows XP. Le procedure seguenti vengono modificate per includere tag di versione espliciti nella sezione trustInfo.

Una correzione è pianificata per lo strumento mt.exe per risolvere il problema in cui genera la dichiarazione dello spazio dei nomi duplicato nel codice XML. Fino a quando non è disponibile una nuova versione di mt.exe, è possibile evitare il problema dell'unione dei manifesti aggiungendo in modo esplicito i tag di versione alla sezione trustinfo del manifesto. Di seguito è riportato un manifesto di esempio:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
      <ms_asmv2:security>
         <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
      </ms_asmv2:security>
   </ms_asmv2:trustInfo>
</assembly>

Progetto C o C++

Nella procedura seguente viene descritto come creare un manifesto per un tipo di progetto C o C++ in Visual Studio 2005.

Per creare un manifesto per un progetto C o C++ in Microsoft Visual Studio 2005

1. Aprire il progetto in Microsoft Visual Studio 2005
2. In Progetto selezionare Proprietà.
3. In Proprietà selezionare Strumento manifesto e quindi input e output.
4. Aggiungere il nome del file manifesto dell'applicazione in File manifesto aggiuntivi.
5. Ricompilare l'applicazione

Nota I manifesti aggiornati che includono tag di versione espliciti consentono all'applicazione di eseguire correttamente sia in Windows Vista che in Windows XP.

Codice gestito (C#, J# e Visual Basic)

Visual Studio non incorpora attualmente un manifesto predefinito nel codice gestito. Per il codice gestito, lo sviluppatore inserisce semplicemente un manifesto predefinito nel file eseguibile di destinazione usando mt.exe. I passaggi saranno i seguenti:

Per inserire un file manifesto predefinito nel file eseguibile di destinazione con mt.exe

1. Usare un editor di testo, ad esempio Blocco note di Windows, per creare un file manifesto predefinito, temp.manifest.
2. Usare mt.exe per inserire il manifesto. Il comando sarà: mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

Aggiunta del manifesto dell'applicazione come passaggio in Visual Studio Post-Build

L'aggiunta del manifesto dell'applicazione può essere automatizzata anche come passaggio post-compilazione. Questa opzione è disponibile per C/C++ e per i due linguaggi di codice gestito di C# e J#.

Nota L'IDE non include attualmente un'opzione di post-compilazione per un'applicazione Visual Basic.

Inserire la riga seguente come attività post build in Proprietà progetto:

mt.exe -manifest "$(ProjectDir)$(TargetName).exe.manifest" 
-updateresource:"$(TargetDir)$(TargetName).exe;#1"

7. Testare l'applicazione

Testare l'applicazione riprogettata o nuova per la compatibilità dell'applicazione con Standard User Analyzer. Una procedura che descrive in dettaglio questo processo è stata descritta in precedenza in questo documento nella sezione Test dell'applicazione per la compatibilità dell'interfaccia utente.

Usare il flusso di lavoro seguente per testare l'applicazione.

Per testare l'applicazione per la compatibilità finale dell'interfaccia utente

1. Testare l'applicazione con lo strumento Standard User Analyzer.
2. Accedere a un computer Windows Vista come amministratore in Amministrazione modalità approvazione ed eseguire il programma. Assicurarsi di testare tutte le funzionalità e notare l'esperienza utente. File qualsiasi elevazione o bug dell'interfaccia utente di conseguenza.
3. Accedere a un computer Windows Vista come utente standard ed eseguire il programma. Assicurarsi di testare tutte le funzionalità e notare eventuali differenze o errori nell'esperienza utente standard rispetto all'amministratore in Amministrazione esperienza utente in modalità approvazione. File qualsiasi elevazione e bug dell'esperienza utente di conseguenza.

8. Autenticaode firmare l'applicazione

L'applicazione contiene ora un manifesto, che verrà rilevato e le informazioni analizzate sull'avvio dell'applicazione. L'eseguibile può tuttavia essere manomesso. Per evitare questo problema, è necessario firmare l'applicazione con una firma Authenticode. Si noti che Windows Vista avrà la possibilità di impedire l'avvio di un'applicazione senza segno con un token di accesso amministratore completo. Se si vuole che l'applicazione funzioni correttamente negli ambienti bloccati, durante la visualizzazione di un'interfaccia utente più descrittiva, deve essere firmata con una firma Authenticode.

Per firmare l'applicazione, è possibile generare un certificato da makecert.exe o ottenere una chiave di firma del codice da una delle autorità di certificazione commerciale (CA), ad esempio VeriSign, Thawte o una CA Microsoft.

Nota È necessario un certificato commerciale se l'applicazione deve essere attendibile nel computer di destinazione di un cliente che installa l'applicazione.

Se si usa il file makecert.exe per generare la coppia di chiavi di firma, tenere presente che genera solo una chiave a 1024 bit. Le firme Authenticode devono essere almeno una chiave a 2048 bit. Il file makecert.exe deve essere usato solo a scopo di test.

La procedura seguente illustra in dettaglio i requisiti elevati per l'uso di makecert.exe per generare la coppia di chiavi di firma. Un esempio e makecert.exe parametri seguono questa procedura.

Per usare makecert.exe per generare la coppia di chiavi di firma

1. Generare il certificato.
2. Firmare il codice.
3. Installare il certificato di test.

Procedura di firma di esempio

Le procedure seguenti vengono fornite come esempi e non devono essere rigorosamente seguite. Ad esempio, sostituire il nome del certificato di test con il nome del certificato e assicurarsi di personalizzare le procedure mappate all'ambiente di certificazione e sviluppo specifico.

Passaggio 1: Generare il certificato

makecert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" 
ContosoTest.cer

parametrimakecert.exe

Parametro	Descrizione
/r	Consente di creare il certificato autofirmato
/Pe	Rende la chiave privata del certificato esportabile nel computer di firma.
/ss StoreName	Nome dell'archivio certificati che archivierà il certificato di test. Esempio: PrivateCertStore
/n X500Name	Nome X500 dell'oggetto del certificato. Esempio: Contoso.com(test)
CertificateName.cer	Nome certificato. Esempio: ContosoTest.cer

Passaggio 2: Firmare il codice

Signtool sign /v /s PrivateCertStore /n Contoso.com(Test) /t 
http://timestamp.verisign.com/scripts/timestamp.dll file.exe

Passaggio 3: Installare il certificato di test

Per installare il certificato di test

1. Avviare una finestra dei comandi con privilegi elevati facendo clic con il pulsante destro del mouse sul prompt dei comandi e selezionando Esegui come amministratore.
2. Nel prompt dei comandi digitare mmc.exe e premere INVIO.
3. Nel mmc selezionare File e quindi aggiungi/Rimuovi snap-in...
4. In Aggiungi o Rimuovi snap-in selezionare Certificati, fare clic su Aggiungi e quindi fare clic su OK.
5. Nella finestra di dialogo Certificati snap-in selezionare Account computer e fare clic su Avanti.
6. In Seleziona computer selezionare Computer locale e quindi fare clic su OK.
7. In Aggiungi o Rimuovi snap-in fare clic su OK.
8. Nello snap-in Certificati e passare a Autorità di certificazione radice attendibili, fare clic con il pulsante destro del mouse su Certificati, selezionare Tutte le attività e quindi selezionare Importa...
9. Nella Procedura guidata Importazione certificati importare il certificato di test ContosoTest.cer.

9. Partecipare al programma logo di Windows Vista

Microsoft offre il programma Logo di Windows Vista per aiutare i clienti a identificare i sistemi e le periferiche che soddisfano una definizione completa delle funzionalità della piattaforma e degli obiettivi qualitativi per garantire un'esperienza di calcolo ottimale per gli utenti finali.

Distribuzione e applicazione di patch per gli utenti standard

In genere, le aziende dovranno considerare come installeranno applicazioni nelle workstation degli utenti in modo automatizzato, riducendo così i costi amministrativi. Ci sono fondamentalmente due parti di questo problema, prima di tutto come queste applicazioni devono essere in pacchetto per la distribuzione e secondo, quale tecnologia deve essere usata per distribuirle. Nel caso di ambienti aziendali più piccoli, un meccanismo di distribuzione affidabile e automatizzato potrebbe non essere necessario.

Supponendo che l'organizzazione abbia già preso un inventario del software eseguito nel suo ambiente, il passaggio successivo consiste nel ripacchetto di queste applicazioni per la distribuzione. Microsoft consiglia il formato di Windows Installer perché ha la possibilità di separare la gestione delle impostazioni per utente da impostazioni per computer. Questo tipo di gestione in genere non è possibile con altri formati di creazione pacchetti, in particolare i file eseguibili di distribuzione semplicemente eseguiti da un account con più privilegi, ad esempio SYSTEM. La libreria MSDN contiene molti articoli in Windows Installer; un suggerimento è la roadmap per la documentazione di Windows Installer.

Il formato di Windows Installer include la possibilità di controllare l'installazione di queste applicazioni tramite Criteri di gruppo (Microsoft IntelliMirror) e anche tramite SMS. Per abilitare Install on Demand con estensione file o collegamenti, le tabelle seguenti nel pacchetto basato su Windows Installer devono essere popolate con dati pubblicitari: collegamento, estensione, icona e verbo. È consigliabile popolare anche la classe, MIME, ProgID e TypeLib. Per altre informazioni su IntelliMirror e Installa su richiesta, vedere Patching Per-User Managed Applications .

Esistono altre tecnologie del programma di installazione che consentono alle applicazioni di installare per utente e supportare l'aggiornamento automatico, ad esempio ClickOnce. Ciò significa che il programma di installazione non richiederà privilegi di amministratore o superiore per installare e che l'utente eseguirà sempre la versione più recente purché il computer sia connesso alla rete. Pone anche alcuni limiti alla capacità di un professionista IT di controllare l'installazione di queste applicazioni.

La distribuzione clickOnce è una tecnologia di installazione di Microsoft .NET che installa e configura automaticamente un'applicazione lato client quando un utente fa clic su un collegamento manifesto, ad esempio un manifesto in un sito Web, in un CD o in un percorso UNC (Universal naming Convention). Per impostazione predefinita, l'applicazione verrà copiata nella cartella File Internet temporanei ed eseguita all'interno di un ambiente con restrizioni.

Nota Anche se l'applicazione è stata firmata con il nome sicuro IT che lo fornisce Full Trust, non è comunque possibile eseguire alcuna operazione che richiede autorizzazioni di amministratore, ad esempio l'accesso a determinate parti del file system e del Registro di sistema. Le applicazioni ClickOnce, tuttavia, sono destinate alle applicazioni per utente, pertanto non dovrebbe essere un problema.

Importante ClickOnce non deve essere usato per la distribuzione di applicazioni che eseguono operazioni amministrative.

Distribuzione in un singolo computer

Per distribuire un'applicazione per un singolo computer, l'amministratore deve "pubblicare" l'applicazione nel computer.

Distribuzione in tutti gli utenti in un dominio

Per annunciare tutti gli utenti in un dominio, l'amministratore deve "pubblicare" l'applicazione tramite Criteri di gruppo distribuzione. Attualmente, solo il componente di distribuzione software basato su Criteri di gruppo dei sistemi operativi Windows Server 2003 e windows 2000 Server® sfrutta questa funzionalità.

Applicazione di patch come utente standard con Windows Installer 4.0

L'applicazione di patch dell'account utente standard consente agli autori di pacchetti di Windows Installer di identificare le patch firmate che possono essere applicate da un utente standard futuro. Le condizioni seguenti devono essere soddisfatte per abilitare l'applicazione di patch utente standard con Windows Installer 4.0:

• L'applicazione è stata installata con Windows Installer 4.0.
• L'applicazione è stata originariamente installata per ogni computer.
• La tabella MsiPatchCertificate è presente e popolata nel pacchetto del programma di installazione finestra originale (.msi file).
• Le patch vengono firmate digitalmente da un certificato elencato nella tabella MsiPatchCertificate.
• Le patch possono essere convalidate con la firma digitale.
• L'applicazione di patch dell'account utente standard non è stata disabilitata impostando la proprietà MSIDISABLELUAPATCHING o il criterio DisableLUAPatching.

Comportamento di disinstallazione utente standard di Windows Installer 4.0

Il comportamento previsto per una patch di Windows Installer 4.0 applicata da un utente standard è che può essere rimosso anche dall'utente standard.

Risoluzione dei problemi comuni

Le sezioni seguenti illustrano i problemi comuni riscontrati con le applicazioni in Windows Vista.

I problemi comuni includono:

• Problemi di installazione di ActiveX
• I documenti ActiveX non vengono installati
• Applicazione, framework o componente aggiuntivo obbligatorio
• L'autorizzazione amministrativa è necessaria per l'installazione/l'applicazione di patch
• Percorsi delle impostazioni dell'applicazione per utente
• Impostazione predefinita dell'applicazione per il salvataggio in una directory protetta

Problemi di installazione di ActiveX

I controlli ActiveX devono essere installati da un amministratore. I controlli ActiveX vengono in genere usati in applicazioni line-of-business per estendere le funzionalità del Web browser per creare interfacce utente più flessibili o per elevare l'accesso alle risorse computer normalmente negate alle applicazioni in esecuzione all'interno del Web browser. I controlli ActiveX vengono in genere installati incorporando un riferimento al controllo ActiveX in una pagina Web. In questo modo Microsoft Internet Explorer scarica e installa il controllo se non esiste nel computer locale. In genere, i controlli ActiveX scaricati in questo modo si trovano nella directory %HOMEPATH%\Impostazioni locali\File Internet temporanei, che è scrivibile dagli utenti standard. Tuttavia, per funzionare all'interno di Internet Explorer, i controlli devono avere voci del Registro di sistema multiple, che non sono possibili per gli amministratori non.

Soluzione

La rimozione del controllo ActiveX dall'applicazione comporta quasi sempre una perdita di funzionalità. Pertanto, questo non è consigliato per la correzione a meno che il controllo ActiveX non fornisca un miglioramento visivo o funzionale che non fa parte della funzionalità principale del sito. Ad esempio, un ticker azionario in un portale non correlato alle scorte.

Nella maggior parte dei casi, creare il pacchetto del controllo ActiveX per l'installazione tramite SMS o Criteri di gruppo è la soluzione corretta. Tuttavia, la maggior parte dei controlli non verrà inclusa nell'immagine di base, pertanto i siti Web devono modificare le pagine in modo da non riuscire correttamente. Ciò deve includere il rilevamento del controllo ActiveX mancante e il reindirizzamento alla pagina richiesta software Desktop gestito.

Documenti ActiveX non installati

I documenti ActiveX sono una tecnologia deprecata da Microsoft Visual Basic 4 e Microsoft Visual Basic 5. Possono essere scaricati in modo simile ai controlli ActiveX.

Soluzione

Poiché Visual Basic 4 e Visual Basic 5 sono deprecati, Microsoft consiglia di sostituire l'applicazione. È possibile installare il documento ActiveX come parte di un'installazione client; tuttavia, gli aggiornamenti al documento saranno limitati senza ridistribuire tramite SMS o Criteri di gruppo.

Applicazione, Framework o Componente aggiuntivo obbligatorio

Molte applicazioni hanno dipendenze da altri software, che potrebbero non essere installati per impostazione predefinita, perché sono già disponibili nel computer o perché l'altra applicazione non fornisce file binari distribuibili per l'uso da parte di terze parti. In circostanze normali, l'utente verrà indirizzato all'acquisizione e all'installazione del software aggiuntivo. In un desktop gestito l'installazione non è possibile. Gli esempi includono Adobe Acrobat, Microsoft Office, componenti Web di Office, WinZip e i criteri di sicurezza IT Microsoft .NET.

Soluzione

Dopo aver identificato le dipendenze, possono essere in pacchetto con l'immagine di base o rese disponibili tramite l'installazione SMS su richiesta. L'applicazione potrebbe dover modificare il modo in cui notifica all'utente finale del software mancante, indirizzando l'utente al sito di installazione SMS anziché al produttore.

L'autorizzazione amministrativa è necessaria per l'installazione/l'applicazione di patch

Poiché l'installazione di un programma richiede l'aggiunta di file ai file di programma, richiederà sempre autorizzazioni amministrative e, pertanto, deve essere eseguita come utente con autorizzazioni elevate.

Nota È anche possibile "eseguire il push" della patch con SMS o Criteri di gruppo in combinazione con il pannello di controllo Aggiungi o Rimuovi programmi (ARP). l'utente seleziona il software da installare e il programma di installazione del sistema esegue il resto: l'utente non deve essere un amministratore. Per le installazioni iniziali, è possibile gestire il pacchetto del software per un agente di installazione per eseguire il push. Tuttavia, alcune applicazioni si basano su aggiornamenti automatici frequenti che potrebbero non allinearsi correttamente a un modello di applicazione gestito centralmente.

Le applicazioni che rilevano gli aggiornamenti e tentano di applicare patch a se stessi non potranno farlo perché non avranno l'autorizzazione per modificare i file nelle directory di sistema.

Soluzione

• Creare un pacchetto dell'applicazione/patch per la distribuzione tramite SMS. Le applicazioni possono comunque rilevare che un aggiornamento è disponibile (purché lo facciano senza richiedere autorizzazioni amministrative) e possa reindirizzare al sito di provisioning.
• Domanda se l'applicazione richiede autorizzazioni computer elevate, ad esempio file system, accesso al Registro di sistema o interoperabilità COM. In caso contrario, potrebbe essere possibile riscrivere l'applicazione come pacchetto di distribuzione ClickOnce, che verrà eseguito nella sandbox Microsoft .NET.
• Convertire in un'applicazione Web senza dipendenze sul lato client.

percorsi delle impostazioni dell'applicazione Per-User

Per Windows Vista, le impostazioni dell'applicazione che devono essere modificate in fase di esecuzione devono essere archiviate in una delle posizioni seguenti:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

I documenti salvati dall'utente devono essere archiviati in CSIDL_MYDOCUMENTS.

Nota La cartella Documenti di un utente non è più archiviata in Documenti e impostazioni. In Windows Vista una nuova directory radice nel file system denominato Users contiene ora i profili per gli utenti del computer.

Poiché queste directory sono state modificate, gli sviluppatori sono invitati a usare gli ELENCHI CSID per individuare il percorso di directory note specifiche in modo indipendente dal sistema. Per altre informazioni, vedere CSIDLs.

Un'applicazione richiede l'accesso in scrittura al file system. Quando viene eseguito in un desktop gestito, un'applicazione dispone solo dell'autorizzazione di scrittura per le cartelle seguenti e i relativi figli.

• CSIDL_PROFILE
• CSIDL_COMMON_APPDATA

Nota Gli utenti standard non possono scrivere in Users\Common.

• C:\Users\Common>cd "Application Data"
  • C:\Users\Common\Application Data>echo File > File.txt
  • C:\Users\Common\Application Data>

Le applicazioni non devono tentare di scrivere in altre posizioni, ad esempio quanto segue:

• C:\windows.
• C:\Windows\System32.
• Programmi\{applicazione}.
• C:\{application}.

Nota Ciò funzionerà se l'utente ha creato la cartella, che i membri del gruppo Utenti possono eseguire per impostazione predefinita.

Un'applicazione sta tentando di creare in modo specifico C:\Users\Profiles\{user} non è consentita poiché l'utente può creare solo cartelle in C:\Users\{user}. La posizione scelta sembra confusa in base alla posizione in cui Microsoft ha archiviato la cartella Documents nelle versioni precedenti del sistema operativo.

Le impostazioni dell'applicazione che devono essere modificate in fase di esecuzione devono essere archiviate in una delle posizioni seguenti:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

I documenti salvati dall'utente devono essere archiviati nella cartella CSIDL_MYDOCUMENTS.

Tutti i percorsi non devono essere hardcoded, ma devono usare la funzione Environment.GetFolderPath().

Impostazioni predefinite dell'applicazione per il salvataggio in una directory protetta

Alcune applicazioni consentono agli utenti di salvare o esportare i dati nel computer locale. Spesso, la finestra di dialogo viene predefinita in posizioni come C:\, a cui gli utenti standard non dispongono delle autorizzazioni di scrittura. Inoltre, alcune applicazioni non rispondono correttamente quando il codice per scrivere il file ha esito negativo perché a causa di un accesso negato dal sistema operativo.

Soluzione

Si supponga che gli utenti possano scrivere solo nei propri profili. Per i documenti salvati intenzionalmente dagli utenti, inizializzare le finestre di dialogo da avviare in Documenti (Environment.GetFolderPath(Environment.SpecialFolder.Personal). Tenere presente che la finestra di dialogo Salva consentirà a un utente di passare ad altre posizioni rispetto al profilo dell'utente, pertanto l'applicazione deve includere la logica per assicurarsi che non venga eseguita correttamente se un utente sceglie una directory diversa rispetto a quelle presenti nel proprio profilo.

Riferimenti

Questa sezione include un riferimento alla virtualizzazione e un riferimento alle impostazioni di sicurezza.

Informazioni di riferimento sulla virtualizzazione

Virtualizzazione file

• Virtualizzare (%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(Sottodirectory)
• Reindirizzamento a: %LOCALAPPDATA%\VirtualStore
• Eseguibili binari esclusi: .exe, .dll, .sys

Virtualizzazione del Registro di sistema:

• Virtualize (HKLM\SOFTWARE)
• Reindirizzamento a: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys>
• Chiavi escluse dalla virtualizzazione
• HKLM\Software\Classi
• HKLM\Software\Microsoft\Windows
• HKLM\Software\Microsoft\Windows NT

Applicabilità

• Gli archivi virtuali non si spostano
• Gli oggetti globali corrispondenti non si spostano
• Abilitato solo per gli utenti standard interattivi
• Disabilitato per i processi non interattivi
• Disabilitato per i file eseguibili a 64 bit
• Disabilitato per i file eseguibili che richiedono un livello di esecuzione (richiestoExecutionLevel) nel manifesto dell'applicazione, il modello per la separazione
• Disabilitato per la modalità kernel e i chiamanti rappresentati
• Vengono virtualizzate solo le chiavi e i file del Registro di sistema scrivibili solo dall'amministratore

Informazioni di riferimento sulle impostazioni di sicurezza dell'interfaccia utente

Questo riferimento illustra in dettaglio le impostazioni di sicurezza disponibili per amministrare l'interfaccia utente con Criteri di gruppo o i criteri di sicurezza locali del computer.

Nota Le procedure presentate in questa sezione sono destinate all'amministrazione di computer non gestiti. Per usare Criteri di gruppo per amministrare le impostazioni centralmente in un ambiente gestito, usare utenti e computer di Active Directory (dsa.msc) anziché lo snap-in gestione criteri di sicurezza locale (secpol.msc).

Configurazione delle impostazioni di sicurezza dell'interfaccia utente

La procedura seguente illustra in dettaglio come configurare le impostazioni di sicurezza dell'interfaccia utente con Gestione criteri di sicurezza. La procedura descrive in dettaglio l'esperienza utente predefinita per un amministratore in Amministrazione modalità approvazione.

Per visualizzare/impostare le impostazioni di sicurezza dell'interfaccia utente con Security Policy Manager

1. Fare clic sul pulsante Start , digitare secpol.msc nella casella di ricerca e quindi premere INVIO.
2. Al prompt del consenso del controllo account utente fare clic su Continua.
3. In Impostazioni di sicurezza locali espandere Criteri locali e quindi fare clic su Opzioni di sicurezza.
4. Fare clic con il pulsante destro del mouse sull'impostazione di sicurezza che si desidera modificare e selezionare Proprietà.

La procedura seguente illustra in dettaglio come configurare le impostazioni di sicurezza dell'interfaccia utente con la Criteri di gruppo. La procedura descrive in dettaglio l'esperienza utente predefinita per un amministratore in Amministrazione modalità approvazione.

Per visualizzare/impostare le impostazioni di sicurezza dell'interfaccia utente con l'editor di oggetti Criteri di gruppo

1. Fare clic sul pulsante Start , digitare gpedit.msc nella casella di ricerca e quindi premere INVIO.
2. Al prompt del consenso del controllo account utente fare clic su Continua.
3. In Criteri di gruppo espandere Configurazione utente e quindi opzioni di sicurezza.
4. Fare clic con il pulsante destro del mouse sull'impostazione di sicurezza che si desidera modificare e selezionare Proprietà.

Impostazioni di sicurezza dell'interfaccia utente

Nella tabella seguente sono elencate le impostazioni di sicurezza dell'interfaccia utente configurabili. Queste impostazioni possono essere configurate con Security Policy Manager (secpol.msc) o gestite centralmente con Criteri di gruppo (gpedit.msc).

Impostazioni di sicurezza dell'interfaccia utente

Impostazione	Descrizione	Valore predefinito
Controllo account utente: Amministrazione modalità approvazione per l'account amministratore predefinito.	Esistono due possibili impostazioni: Abilitato: l'amministratore predefinito verrà eseguito come amministratore in Amministrazione modalità approvazione. Disabilitato: l'amministratore viene eseguito con un token di accesso amministratore completo.	Disabilitato per le nuove installazioni e per gli aggiornamenti in cui l'amministratore predefinito non è l'unico amministratore attivo locale nel computer. L'account amministratore predefinito è disabilitato per impostazione predefinita per le installazioni e gli aggiornamenti nei computer aggiunti al dominio. Abilitato per gli aggiornamenti quando Windows Vista determina che l'account amministratore predefinito è l'unico amministratore locale attivo nel computer. Se Windows Vista determina questa operazione, l'account amministratore predefinito viene mantenuto abilitato anche dopo l'aggiornamento. L'account amministratore predefinito è disabilitato per impostazione predefinita per le installazioni e gli aggiornamenti nei computer aggiunti al dominio.
Controllo account utente: comportamento della richiesta di elevazione dei privilegi per gli amministratori in modalità Approvazione amministratore	Per questa impostazione sono disponibili tre valori possibili: Eleva senza richiedere: elevare in modo invisibile all'utente. Richiesta di credenziali: richiedere agli utenti di immettere la password di accesso prima di continuare. Richiedere il consenso: chiedere all'utente l'approvazione prima di elevare. Si tratta dell'impostazione predefinita.  Questa impostazione determina il modo in cui l'utente viene richiesto prima di eseguire un programma con autorizzazioni più elevate. Questo criterio è effettivo solo quando l'interfaccia utente è abilitata.	Richiedi consenso
Controllo account utente: comportamento della richiesta di elevazione dei privilegi per gli utenti standard	Determina la modalità di richiesta dell'utente prima di eseguire un programma con autorizzazioni più elevate. Questo criterio è effettivo solo quando l'interfaccia utente è abilitata. Di seguito sono riportate le opzioni di configurazione disponibili per questa impostazione: Nega automaticamente le richieste di elevazione: gli utenti non verranno richiesti quando un'applicazione vuole eseguire un'attività amministrativa. L'applicazione non verrà avviata e presenterà un errore di accesso negato o equivalente all'utente. Richiesta di credenziali: richiedere agli utenti di immettere la password di accesso prima di continuare.	Richiesta di credenziali
Controllo account utente: rileva installazione applicazioni e richiedi elevazione	Esistono due valori possibili: Abilitato: l'utente viene richiesto il consenso o le credenziali quando Windows Vista rileva un programma di installazione. Disabilitato: le installazioni dell'applicazione avranno esito negativo o avranno esito negativo in modo non deterministico.	Attivato
Controllo account utente: eleva solo file eseguibili firmati e convalidati	Esistono due valori possibili: Abilitato: verranno eseguiti solo i file eseguibili firmati. Questa impostazione blocca l'esecuzione delle applicazioni non firmate. Disabilitato: verrà eseguito sia il codice firmato che non firmato.	Disabled
Controllo account utente: solo applicazioni con accesso all'interfaccia utente e con privilegi elevati installate in percorsi sicuri	Esistono due valori possibili: Abilitato: il sistema concederà solo privilegi UIAccess e diritti utente ai file eseguibili avviati da in %ProgramFiles% o %windir%. Gli elenchi di controllo di accesso in queste directory garantiscono che l'eseguibile non sia modificabile dall'utente (che in caso contrario consente l'elevazione dei privilegi). I file eseguibili UIAccess avviati da altre posizioni verranno avviati senza privilegi aggiuntivi, ad esempio eseguiranno "asInvoker". Disabilitato: i controlli della posizione non vengono eseguiti, quindi tutte le applicazioni UIAccess verranno avviate con il token di accesso completo dell'utente dopo l'approvazione dell'utente.	Attivato
Controllo account utente: esegui tutti gli amministratori in modalità Approvazione amministratore	Esistono due valori possibili: Abilitato: gli amministratori e gli utenti standard verranno richiesti quando si tenta di eseguire operazioni amministrative. Lo stile del prompt dipende dai criteri. Disabilitato: l'interfaccia utente è essenzialmente "disattivata" e il servizio AIS viene disabilitato automaticamente dall'avvio automatico.	Attivato
Controllo account utente: alla richiesta di elevazione passa al desktop sicuro	Esistono due valori possibili: Abilitato: visualizza il prompt di elevazione dell'account utente sul desktop sicuro. Il desktop sicuro può ricevere solo messaggi dai processi di Windows, che elimina i messaggi dal software dannoso. Di conseguenza, le richieste di consenso e credenziali non possono essere spoofate sul desktop sicuro. Disabilitato: il prompt di elevazione dell'account utente viene visualizzato sul desktop dell'utente.	Attivato
Controllo account utente: virtualizza errori di scrittura su file e nel Registro di sistema in percorsi distinti per ogni utente	Esistono due valori possibili: Abilitato: le applicazioni che non contengono una voce del database di compatibilità dell'applicazione o un contrassegno a livello di esecuzione richiesto nel manifesto dell'applicazione non sono conformi all'interfaccia utente. Gli ambienti che usano software non conformi devono mantenere abilitata questa impostazione. Disabilitato: le applicazioni conformi all'interfaccia utente non devono scrivere in aree protette e causare errori di scrittura. Di conseguenza, gli ambienti che usano solo applicazioni conformi all'interfaccia utente devono disabilitare questa impostazione. Le applicazioni non conformi che tentano di scrivere in Programmi e %systemroot% avranno esito negativo se questa impostazione è disabilitata.	Attivato

Nota Per la maggior parte delle situazioni, l'opzione Elevate senza richiesta non è consigliata. L'elevazione senza richiesta consente alle applicazioni in esecuzione come utente standard di avviare applicazioni amministrative senza consenso dell'utente e ignorare in modo efficace l'interfaccia utente.

Esempio di codice dell'utilità di pianificazione

L'esempio di codice C++ seguente illustra come usare Utilità di pianificazione per eseguire l'elevazione per l'utente. Di conseguenza, l'applicazione può elevare automaticamente durante l'accesso usando le credenziali di un amministratore e Windows Vista non blocca l'applicazione. È necessario creare un utente amministratore per l'applicazione durante l'installazione in modo che questa soluzione funzioni correttamente.

//---------------------------------------------------------------------
//  This file is part of the Microsoft .NET Framework SDK Code Samples.
// 
//  Copyright (C) Microsoft Corporation.  All rights reserved.
// 
//This source code is intended only as a supplement to Microsoft
//Development Tools and/or on-line documentation.  See these other
//materials for detailed information regarding Microsoft code samples.
// 
//THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY
//KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
//IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
//PARTICULAR PURPOSE.
//---------------------------------------------------------------------

/****************************************************************************
* Main.cpp - Sample application for Task Scheduler V2 COMAPI                * Component: Task Scheduler                          
* Copyright (c) 2002 - 2003, Microsoft Corporation 
* This sample creates a task to at the time registered to start the desired task.                                                             *
****************************************************************************/
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <comdef.h>
#include <comutil.h>
//Include Task header files - Included in Windows Vista Beta-2 SDK from MSDN
#include <taskschd.h>
#include <conio.h>
#include <iostream>
#include <time.h>

using namespace std;

#define CLEANUP \
pRootFolder->Release();\
        pTask->Release();\
        CoUninitialize();

HRESULT CreateMyTask(LPCWSTR, wstring);

void __cdecl wmain(int argc, wchar_t** argv)
{
wstring wstrExecutablePath;
WCHAR taskName[20];
HRESULT result;

if( argc < 2 )
{
printf("\nUsage: LaunchApp yourapp.exe" );
return;
}

// Pick random number for task name
srand((unsigned int) time(NULL));
wsprintf((LPWSTR)taskName, L"Launch %d", rand());

wstrExecutablePath = argv[1];

result = CreateMyTask(taskName, wstrExecutablePath);
printf("\nReturn status:%d\n", result);

}
HRESULT CreateMyTask(LPCWSTR wszTaskName, wstring wstrExecutablePath)
{
    //  ------------------------------------------------------
    //  Initialize COM.
TASK_STATE taskState;
int i;
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if( FAILED(hr) )
    {
        printf("\nCoInitializeEx failed: %x", hr );
        return 1;
    }

    //  Set general COM security levels.
    hr = CoInitializeSecurity(
        NULL,
        -1,
        NULL,
        NULL,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
        RPC_C_IMP_LEVEL_IMPERSONATE,
        NULL,
        0,
        NULL);

    if( FAILED(hr) )
    {
        printf("\nCoInitializeSecurity failed: %x", hr );
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Create an instance of the Task Service. 
    ITaskService *pService = NULL;
    hr = CreateElevatedComObject( CLSID_TaskScheduler,
                           NULL,
                           CLSCTX_INPROC_SERVER,
                           IID_ITaskService,
                           (void**)&pService );  
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        CoUninitialize();
        return 1;
    }
        
    //  Connect to the task service.
    hr = pService->Connect(_variant_t(), _variant_t(), _variant_t(), _variant_t());
    if( FAILED(hr) )
    {
        printf("ITaskService::Connect failed: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Get the pointer to the root task folder.  This folder will hold the
    //  new task that is registered.
    ITaskFolder *pRootFolder = NULL;
    hr = pService->GetFolder( _bstr_t( L"\\") , &pRootFolder );
    if( FAILED(hr) )
    {
        printf("Cannot get Root Folder pointer: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }
    
    //  Check if the same task already exists. If the same task exists, remove it.
    hr = pRootFolder->DeleteTask( _bstr_t( wszTaskName), 0  );
    
    //  Create the task builder object to create the task.
    ITaskDefinition *pTask = NULL;
    hr = pService->NewTask( 0, &pTask );

    pService->Release();  // COM clean up.  Pointer is no longer used.
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        pRootFolder->Release();
        CoUninitialize();
        return 1;
    }
        

    //  ------------------------------------------------------
    //  Get the trigger collection to insert the registration trigger.
    ITriggerCollection *pTriggerCollection = NULL;
    hr = pTask->get_Triggers( &pTriggerCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get trigger collection: %x", hr );
CLEANUP
        return 1;
    }
  
    //  Add the registration trigger to the task.
    ITrigger *pTrigger = NULL;
    
    hr = pTriggerCollection->Create( TASK_TRIGGER_REGISTRATION, &pTrigger );     
    pTriggerCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\nCannot add registration trigger to the Task %x", hr );
        CLEANUP
        return 1;
    }
    pTrigger->Release();

    //  ------------------------------------------------------
    //  Add an Action to the task.     
    IExecAction *pExecAction = NULL;
    IActionCollection *pActionCollection = NULL;

    //  Get the task action collection pointer.
    hr = pTask->get_Actions( &pActionCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get Task collection pointer: %x", hr );
        CLEANUP
        return 1;
    }
    
    //  Create the action, specifying that it is an executable action.
    IAction *pAction = NULL;
    hr = pActionCollection->Create( TASK_ACTION_EXEC, &pAction );
    pActionCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\npActionCollection->Create failed: %x", hr );
        CLEANUP
        return 1;
    }

    hr = pAction->QueryInterface( IID_IExecAction, (void**) &pExecAction );
    pAction->Release();
    if( FAILED(hr) )
    {
        printf("\npAction->QueryInterface failed: %x", hr );
        CLEANUP
        return 1;
    }

    //  Set the path of the executable to the user supplied executable.
hr = pExecAction->put_Path( _bstr_t( wstrExecutablePath.c_str() ) );  

//hr = pExecAction->put_Path( (BSTR)wstrExecutablePath );  
    if( FAILED(hr) )
    {
        printf("\nCannot set path of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    hr = pExecAction->put_Arguments( _bstr_t( L"" ) );  
//    hr = pExecAction->put_Arguments( _bstr_t( L"ArgumentsToYourExecutable--HelpFileToOpen" ) );  
   if( FAILED(hr) )
    {
        printf("\nCannot set arguments of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    
    //  ------------------------------------------------------
    //  Save the task in the root folder.
    IRegisteredTask *pRegisteredTask = NULL;
    hr = pRootFolder->RegisterTaskDefinition(
            _bstr_t( wszTaskName ),
            pTask,
        TASK_CREATE, 
_variant_t(_bstr_t( L"S-1-5-32-545")),//Well Known SID for \\Builtin\Users group
_variant_t(), 
TASK_LOGON_GROUP,
            _variant_t(L""),
            &pRegisteredTask);
    if( FAILED(hr) )
    {
        printf("\nError saving the Task : %x", hr );
        CLEANUP
        return 1;
    }
    printf("\n Success! Task successfully registered. " );
for (i=0; i<100; i++)//give 10 seconds for the task to start
{
pRegisteredTask->get_State(&taskState);
if (taskState == TASK_STATE_RUNNING)
{
printf("\nTask is running\n");
break;
}
Sleep(100);
}
if (i>= 100) printf("Task didn't start\n");

//Delete the task when done
    hr = pRootFolder->DeleteTask(
            _bstr_t( wszTaskName ),
            NULL);
    if( FAILED(hr) )
    {
        printf("\nError deleting the Task : %x", hr );
        CLEANUP
        return 1;
    }

    printf("\n Success! Task successfully deleted. " );

//  Clean up.
    CLEANUP
    CoUninitialize();
    return 0;
}