Requisitos de desenvolvimento de aplicativos do Windows Vista para compatibilidade de controle de conta de usuário

 

Jennifer Allen

Atualizado em junho de 2007

Resumo: Este white paper destina-se a ajudar os desenvolvedores de aplicativos a criar aplicativos compatíveis com o Windows Vista compatíveis com o Controle de Conta de Usuário. Etapas detalhadas sobre o processo de design estão incluídas, juntamente com exemplos de código, requisitos e práticas recomendadas. Este artigo também detalha as atualizações técnicas e as alterações na experiência do usuário no Windows Vista. (71 páginas impressas.)

Sumário

Por que o controle de conta de usuário?
Atualizações do Windows Vista
Novas tecnologias para Windows Vista
Arquitetura do UAC
O UAC afetará seu aplicativo?
Criando aplicativos para o Windows Vista
Implantação e aplicação de patch de aplicativos para usuários padrão
Solução de problemas comuns
Referências

Por que o controle de conta de usuário?

Os desenvolvedores de aplicativos criaram aplicativos do Windows consistentemente que exigem direitos excessivos de usuário e privilégios do Windows, muitas vezes exigindo que o usuário em execução seja um administrador. Como resultado, poucos usuários do Windows são executados com os direitos de usuário mínimos e os privilégios do Windows necessários. Muitas empresas, buscando equilibrar a facilidade de implantação e a facilidade de uso com a segurança, muitas vezes recorreram à implantação de suas áreas de trabalho como administrador devido a problemas de compatibilidade de aplicativos de usuário padrão.

A lista a seguir detalha os motivos adicionais pelos quais é difícil executar como um usuário padrão em computadores pré-Microsoft Windows Vista:

1. Muitos aplicativos do Windows exigem que o usuário conectado seja um administrador, mas não exigem acesso no nível do administrador. Esses aplicativos executam uma variedade de verificações de acesso de administrador antes de terem permissão para execução, incluindo:
   • Marcar de token de acesso do administrador.
   • Solicitações de acesso "Todos os acessos" em locais protegidos pelo sistema.
   • Grave dados em locais protegidos, como %ProgramFiles%, %WinDir% e HKLM\Software.
2. Muitos aplicativos do Windows não são projetados com o conceito de privilégio mínimo e não separam a funcionalidade de usuário e administrador em dois processos separados.
3. O Windows 2000 e o Windows XP criam cada nova conta de usuário como administrador por padrão; portanto, os principais componentes do Windows, como a Data e a Hora e os painéis de controle do Power Management, não funcionam bem para um usuário padrão
4. Os administradores do Windows 2000 e do Windows XP devem criar duas contas de usuário separadas: uma para tarefas administrativas e uma conta de usuário padrão para executar tarefas diárias. Portanto, os usuários devem fazer logoff de suas contas de usuário padrão e fazer logon como administrador ou usar Executar como para executar qualquer tarefa administrativa.

Com o UAC (Controle de Conta de Usuário), a Microsoft está fornecendo uma tecnologia para simplificar a implantação de áreas de trabalho de usuário padrão, na empresa e em casa.

Com base na arquitetura de segurança do Windows, conforme originalmente projetado no sistema operacional Microsoft Windows NT 3.1, a equipe do UAC procurou implementar um modelo de usuário padrão que fosse flexível e mais seguro. Em versões anteriores do Windows, um token de acesso é criado para um administrador durante o processo de logon. O token de acesso do administrador inclui a maioria dos privilégios do Windows e a maioria dos SIDs (identificadores de segurança administrativos). Esse token de acesso garante que um administrador possa instalar aplicativos, configurar o sistema operacional e acessar qualquer recurso.

A equipe do UAC adotou uma abordagem drasticamente diferente para o processo de criação de token de acesso no Windows Vista. Quando um usuário administrador faz logon em um computador Windows Vista, dois tokens de acesso são criados: um token de acesso de usuário padrão filtrado e um token de acesso de administrador completo. Em vez de iniciar a área de trabalho (Explorer.exe) com o token de acesso do administrador, o token de acesso de usuário padrão é usado. Todos os processos filho herdam dessa inicialização inicial da área de trabalho (o processo de explorer.exe), que ajuda a limitar a superfície de ataque do Windows Vistas. Por padrão, todos os usuários, incluindo administradores, fazem logon em um computador Windows Vista como usuários padrão.

Nota Há uma exceção à instrução anterior: os convidados fazem logon no computador com menos direitos e privilégios de usuário do que os usuários padrão.

Quando um administrador tenta executar uma tarefa administrativa, como instalar um aplicativo, o UAC solicita que o usuário aprove a ação. Quando o usuário aprova a ação, a tarefa é iniciada com o token de acesso completo do administrador. Esse é o comportamento de prompt de administrador padrão e é configurável no snap-in local do Gerenciador de Políticas de Segurança (secpol.msc) e com Política de Grupo (gpedit.msc).

Nota Uma conta de administrador em um computador Windows Vista com UAC habilitado também é chamada de conta de administrador no modo de aprovação Administração. Administração Modo de Aprovação identifica a experiência do usuário padrão para administradores.

Cada elevação administrativa também é específica do processo, o que impede que outros processos usem o token de acesso sem solicitar aprovação ao usuário. Como resultado, os usuários administradores têm um controle mais granular sobre quais aplicativos são instalados, afetando muito o software mal-intencionado que espera que o usuário conectado esteja em execução com um token de acesso de administrador completo.

Os usuários padrão também têm a oportunidade de elevar o fluxo e executar tarefas administrativas usando a infraestrutura UAC. Quando um usuário padrão tenta executar uma tarefa administrativa, o UAC solicita que o usuário insira credenciais válidas para uma conta de administrador. Esse é o comportamento padrão do prompt de usuário padrão e é configurável no snap-in local do Gerenciador de Políticas de Segurança (secpol.msc) e com Política de Grupo (gpedit.msc).

Atualizações do Windows Vista

As atualizações a seguir refletem as alterações de núcleo cumulativas na funcionalidade que ocorreram no Windows Vista.

O UAC está habilitado por padrão

Como resultado, você pode encontrar alguns problemas de compatibilidade com aplicativos diferentes que ainda não foram atualizados para o componente UAC do Windows Vista. Se um aplicativo exigir um token de acesso de administrador (isso é indicativo de um erro de "acesso negado" que está sendo retornado quando você tenta executar o aplicativo), você pode executar o programa como administrador usando a opção Executar como administrador no menu de contexto (clique com o botão direito do mouse). Como fazer isso é documentado posteriormente neste documento na seção Executando programas como administrador.

Todas as contas de usuário subsequentes são criadas como usuários padrão

As contas de usuário padrão e as contas de usuário de administrador podem aproveitar a segurança aprimorada do UAC. Em novas instalações, por padrão, a primeira conta de usuário criada é uma conta de administrador local no modo de aprovação Administração (UAC habilitado). Todas as contas subsequentes são criadas como usuários padrão.

Os prompts de elevação são exibidos na Área de Trabalho Segura por Padrão

Os prompts de consentimento e credencial são exibidos na área de trabalho segura por padrão no Windows Vista.

Os prompts de elevação para aplicativos em segundo plano são minimizados para a barra de tarefas

Os aplicativos em segundo plano solicitarão automaticamente ao usuário elevação na barra de tarefas, em vez de ir automaticamente para a área de trabalho segura para elevação. O prompt de elevação aparecerá minimizado na barra de tarefas e piscará para notificar o usuário de que um aplicativo solicitou elevação. Um exemplo de elevação em segundo plano ocorre quando um usuário navega até um site da Web e começa a baixar um arquivo de instalação. Em seguida, o usuário vai para marcar email enquanto a instalação é baixada em segundo plano. Depois que o download for concluído em segundo plano e a instalação começar, a elevação será detectada como uma tarefa em segundo plano, em vez de uma tarefa em primeiro plano. Essa detecção impede que a instalação roube abruptamente o foco da tela do usuário enquanto o usuário está executando outra tarefa: ler email. Esse comportamento cria uma melhor experiência do usuário para o prompt de elevação. Informações sobre como os desenvolvedores de aplicativos podem garantir que seus aplicativos não sejam minimizados na barra de tarefas quando solicitarem elevação estiverem disponíveis posteriormente neste documento.

As elevações são bloqueadas no caminho de logon do usuário

Os aplicativos que começam quando o usuário faz logon e exigem elevação agora são bloqueados no caminho do logon. Sem impedir que os aplicativos solicitem elevação no caminho de logon do usuário, os usuários padrão e os administradores teriam que responder a uma caixa de diálogo Controle de Conta de Usuário em cada logon. O Windows Vista notifica o usuário se um aplicativo foi bloqueado colocando um ícone na bandeja do sistema. Em seguida, o usuário pode clicar com o botão direito do mouse neste ícone para executar aplicativos que foram impedidos de solicitar elevação conforme o usuário fez logon. O usuário pode gerenciar quais aplicativos de inicialização estão desabilitados ou removidos dessa lista clicando duas vezes no ícone da bandeja.

A conta de administrador interna está desabilitada por padrão em novas instalações

A conta de Administrador interna é desabilitada por padrão no Windows Vista. Se o Windows Vista determinar durante uma atualização do Windows XP que o administrador interno é a única conta de administrador local ativa, o Windows Vista deixará a conta habilitada e colocará a conta no modo de aprovação Administração. A conta de administrador interna, por padrão, não pode fazer logon no computador no modo de segurança. Consulte as seções a seguir para obter mais informações. A conta de administrador interna é criada durante a instalação com o nome de usuário Administrador.

Não ingressado no domínio

Quando houver pelo menos uma conta de administrador local habilitada, o modo de segurança não permitirá o logon com a conta de administrador interna desabilitada. Em vez disso, qualquer conta de administrador local pode ser usada para fazer logon. Se a última conta de administrador local for inadvertidamente rebaixada, desabilitada ou excluída, o modo de segurança permitirá que a conta de administrador interna desabilitada faça logon para recuperação de desastre.

Ingressado no domínio

A conta de administrador interna desabilitada em todos os casos não pode fazer logon no modo de segurança. Uma conta de usuário que é membro do grupo Administradores de Domínio pode fazer logon no computador para criar um administrador local se não existir nenhum.

Nota Se a conta administrativa de domínio nunca tivesse feito logon antes, o computador deverá ser iniciado no Modo de Segurança com Rede, pois as credenciais não terão sido armazenadas em cache.

Nota Depois que o computador for desarticulado, ele reverter de volta ao comportamento não associado ao domínio descrito anteriormente.

Controle de conta de usuário e cenários remotos

Quando um administrador faz logon em um computador do Windows Vista remotamente, por meio da Área de Trabalho Remota, por exemplo, o usuário é conectado ao computador como um usuário padrão por padrão. A administração remota foi modificada para ser restritiva na transmissão. Isso ajuda a impedir que software mal-intencionado execute "loopbacks" do aplicativo se um usuário estiver executando com potencial administrativo.

contas de usuário locais

Quando um usuário com uma conta de administrador em um banco de dados SAM (Gerenciador de Contas de Segurança) local do computador Windows Vista se conecta remotamente a um computador Windows Vista, o usuário não tem nenhum potencial de elevação no computador remoto e não pode executar tarefas administrativas. Se o usuário quiser administrar a estação de trabalho com uma conta SAM, o usuário deverá fazer logon interativamente no computador a ser administrado.

Contas de Usuário de Domínio

Quando um usuário com uma conta de usuário de domínio faz logon em um computador Windows Vista remotamente, onde o usuário é membro do grupo Administradores, o usuário do domínio será executado com um token de acesso de administrador completo no computador remoto e o UAC não estará em vigor.

Novas configurações de ACL (lista de Controle de Acesso padrão)

As ACLs em determinados diretórios do Windows foram alteradas para habilitar o compartilhamento de dados e a colaboração em diretórios de dados e fora dos diretórios protegidos dos usuários. O diretório protegido de um usuário é seu perfil de usuário (por exemplo, C:\Users\Denise\Pictures\), enquanto um exemplo de um diretório de dados é o local fora da partição do sistema operacional em uma unidade de dados (por exemplo, D:\Imagens\). Como o diretório raiz, C nesta instância, é protegido por ACLs mais restritivas, os usuários não puderam usar diretórios de dados em versões iniciais do Windows Vista.

Essas alterações de ACL garantem que os usuários possam compartilhar e editar arquivos sem precisar fornecer aprovação a uma caixa de diálogo Controle de Conta de Usuário. Além disso, os usuários agora podem tornar uma pasta privada. Essa alteração garante que os usuários ainda possam manter facilmente a confidencialidade e a integridade dos dados em unidades de dados. Essas pastas privadas ainda poderão ser lidas por outros administradores se forem elevadas e devem ser usadas para manter os dados privados dos usuários padrão.

Veja a seguir as configurações de ACL padrão em %systemroot% e a unidade de dados no Windows XP.

Configurações de ACL do Windows XP %systemroot% e da unidade de dados

Usuário ou Grupo	Entrada Controle de Acesso
BUILTIN\Administradores	Controle total
NT AUTHORITY\SYSTEM	Controle total
CREATOR OWNER	Controle total
BUILTIN\Users	Ler Acesso especial: FILE_APPEND_DATA Acesso especial: FILE_WRITE_DATA
Todos	Ler

A tabela a seguir detalha as novas configurações de ACL da unidade de dados do Windows Vista para unidades de dados criadas com format.exe.

Configurações de ACL da unidade de dados do Windows Vista

Usuário ou Grupo	Entrada Controle de Acesso
BUILTIN\Administradores	Controle total
NT AUTHORITY\SYSTEM	Controle total
NT AUTHORITY\Authenticated Users	Modificar
BUILTIN\Users	Leitura e execução Leitura genérica, execução genérica

A tabela a seguir detalha as novas configurações de ACL raiz do sistema operacional Windows Vista (%systemroot%).

Configurações de ACL %systemroot% do Windows Vista

Usuário ou Grupo	Entrada Controle de Acesso
BUILTIN\Administradores	Controle total
NT AUTHORITY\SYSTEM	Controle total
BUILTIN\Users	Leitura e execução
NT AUTHORITY\Authenticated Users	Modificar Acrescentar dados
Rótulo obrigatório\Alto nível obrigatório	Sem gravação

Novas configurações de segurança do UAC e alterações de nome da configuração de segurança

As novas configurações de segurança e as atualizações de nome da configuração de segurança são detalhadas na seção Referências deste documento.

Novas tecnologias para Windows Vista

As seções a seguir detalham novas tecnologias para o Windows Vista, incluindo detecção de instalador, aplicação de patch de usuário padrão com o Windows Installer 4.0, isolamento de privilégio de interface do usuário e virtualização.

Serviço Instalador do ActiveX

O ActiveX Installer Service permite que as empresas deleguem a instalação do controle ActiveX para usuários padrão. Esse serviço garante que as tarefas comerciais rotineiras não sejam impedidas por instalações e atualizações de controle ActiveX com falha. O Windows Vista também inclui Política de Grupo configurações que permitem que os profissionais de TI definam URLs de Host das quais os usuários padrão podem instalar controles ActiveX. O ActiveX Installer Service consiste em um serviço Windows, um modelo administrativo Política de Grupo e algumas alterações na Internet Explorer e é um componente opcional que só será habilitado em clientes em que ele está instalado.

Detecção do instalador

Os programas de instalação são aplicativos projetados para implantar software e a maioria grava em diretórios do sistema e chaves do Registro. Esses locais do sistema protegidos normalmente são graváveis somente por usuários administradores; isso significa que os usuários padrão não têm acesso suficiente para instalar programas. O Windows Vista detecta heuristicamente programas de instalação e solicita credenciais de administrador ou aprovação do usuário administrador para executar com privilégios de acesso. O Windows Vista também detecta heuristicamente programas de atualização e desinstalação. Observe que uma meta de design do UAC é impedir que as instalações sejam executadas sem o conhecimento e o consentimento do usuário, pois eles gravam em áreas protegidas do sistema de arquivos e do registro.

Importante Ao desenvolver novos programas de instalação, assim como o desenvolvimento de programas para Windows Vista, certifique-se de inserir um manifesto do aplicativo com um elemento requestedExecutionLevel apropriado (consulte a seção Etapa Seis: Criar e Inserir um Manifesto do Aplicativo com seu aplicativo). Quando requestedExecutionLevel está presente no manifesto do aplicativo inserido, ele substitui a Detecção do Instalador.

A detecção do instalador só se aplica a:

• Executáveis de 32 bits
• Aplicativos sem um requestedExecutionLevel
• Processos interativos em execução como um usuário padrão com LUA habilitado

Antes de um processo de 32 bits ser criado, os seguintes atributos são verificados para determinar se ele é um instalador:

• O nome do arquivo inclui palavras-chave como "instalar", "configurar", "atualizar" etc.
• Palavras-chave nos seguintes campos Recursos de Controle de Versão: Fornecedor, Nome da Empresa, Nome do Produto, Descrição do Arquivo, Nome de Arquivo Original, Nome Interno e Nome de Exportação.
• Palavras-chave no manifesto lado a lado inserido no executável.
• Palavras-chave em entradas stringTable específicas vinculadas no executável.
• Atributos de chave nos dados RC vinculados no executável.
• Sequências direcionadas de bytes dentro do executável.

Nota As palavras-chave e as sequências de bytes foram derivadas de características comuns observadas de várias tecnologias de instalador.

Verifique se você revisou completamente a totalidade deste documento, incluindo a seção Etapa Seis: Criar e inserir um manifesto do aplicativo com seu aplicativo.

Nota O Controle de Conta de Usuário: detectar instalações de aplicativos e solicitar a configuração de elevação deve ser habilitado para detecção de instalador para detectar programas de instalação. Essa configuração é habilitada por padrão e pode ser configurada com o snap-in do Gerenciador de Políticas de Segurança (secpol.msc) ou com Política de Grupo (gpedit.msc).

Informações gerais e uma visão geral do Microsoft Windows Installer podem ser encontradas no Biblioteca MSDN.

Aplicações de aplicação de patch em um ambiente UAC

O Microsoft Windows Installer 4.0 foi projetado com o UAC em mente para facilitar as instalações de aplicativos e a aplicação de patch. Com a introdução do Windows Installer 4.0, os patches podem ser aplicados a aplicativos sem reinstalar uma versão mais recente do aplicativo. Esse método é ideal quando um aplicativo é implantado em uma instalação por computador e os patches precisam ser implantados por um usuário sem a necessidade de um token de acesso administrativo. Para obter informações sobre como criar e aplicar patches a aplicativos, consulte Patching Per-User Managed Applications.

Integração da Central de Segurança

Quando o UAC está desabilitado em um computador Windows Vista, a Central de Segurança cria um alerta e solicita que o usuário habilite novamente o UAC. A Central de Segurança exibe esse alerta depois que o computador é reiniciado após a alteração da configuração do UAC.

Isolamento de privilégios da interface do usuário

O UIPI (Isolamento de Privilégios de Interface do Usuário) é um dos mecanismos que ajudam a isolar aplicativos em execução como um administrador completo de processos em execução como uma conta inferior a um administrador na mesma área de trabalho interativa. A UIPI é específica para o subsistema de janelas e gráficos conhecido como USER que dá suporte a controles de interface do usuário e janelas. A UIPI impede que um aplicativo com privilégios inferiores use mensagens do Windows para enviar entradas de um processo para um processo de privilégios mais altos. O envio de entrada de um processo para outro permite que um processo injete entrada em outro processo sem que o usuário forneça ações de teclado ou mouse.

O conceito por trás da UIPI é simples. O Windows Vista define um conjunto de níveis de privilégio de interface do usuário de maneira hierárquica. A natureza dos níveis é tal que níveis de privilégio mais altos podem enviar mensagens de janela para aplicativos em execução em níveis mais baixos. No entanto, níveis mais baixos não podem enviar mensagens de janela para janelas de aplicativos em níveis mais altos.

O nível de privilégio da interface do usuário está no nível do processo. Quando um processo é inicializado, o subsistema Usuário chama o subsistema de segurança para determinar o nível de integridade da área de trabalho atribuído no token de acesso de segurança do processo. O nível de integridade da área de trabalho é definido pelo subsistema de segurança quando o processo é criado e não é alterado. Portanto, o nível de privilégio da interface do usuário também é definido pelo subsistema Usuário quando o processo é criado e não é alterado.

Todos os aplicativos executados por um usuário padrão têm o mesmo nível de privilégio de interface do usuário. Como um usuário padrão, os aplicativos são executados em um único nível de privilégio. A UIPI não interfere nem altera o comportamento do sistema de mensagens de janela entre aplicativos no mesmo nível de privilégio. A UIPI entra em vigor para um usuário que é membro do grupo de administradores e pode estar executando aplicativos como um usuário padrão (às vezes chamado de processo com um token de acesso filtrado) e também processa a execução com um token de acesso de administrador completo na mesma área de trabalho. A UIPI impede que processos de privilégios inferiores acessem processos de privilégios mais altos bloqueando o comportamento a seguir.

Um processo de privilégios inferiores não pode:

• Executar uma validação de identificador de janela de privilégio de processo mais alto.
• SendMessage ou PostMessage para janelas de aplicativos com privilégios mais altos. Essas APIs (interfaces de programação de aplicativo) retornam êxito, mas removem silenciosamente a mensagem da janela.
• Use ganchos de thread para anexar a um processo de privilégio mais alto.
• Use ganchos de diário para monitorar um processo de privilégios mais altos.
• Execute a injeção de DLL (biblioteca de vínculo dinâmico) em um processo de privilégio mais alto.

Com a UIPI habilitada, os seguintes recursos de USUÁRIO compartilhados ainda são compartilhados entre processos em diferentes níveis de privilégio:

• Janela da área de trabalho, que na verdade possui a superfície da tela
• Memória compartilhada somente leitura do heap da área de trabalho
• Tabela atom global
• Área de Transferência

Pintar na tela é outra ação que não está bloqueada pela UIPI. Pintar na tela refere-se ao processo de usar o método Paint para exibir conteúdo em uma saída externa— um monitor, por exemplo. O modelo de GDI (interface do dispositivo user/graphics) não permite o controle sobre superfícies de pintura; portanto, é possível que um aplicativo com privilégios inferiores pinte sobre a região da superfície de uma janela de aplicativo com privilégios mais altos.

Nota Como o Shell do Windows (Explorer) está em execução como um processo de usuário padrão, qualquer outro processo em execução como usuário padrão ainda pode enviar pressionamentos de tecla. Esse é o principal motivo pelo qual uma conta de administrador no modo de aprovação do Administração é solicitada para consentimento de elevação quando inicia uma ação administrativa, como clicar duas vezes em uma Setup.exe ou clicar em um ícone de escudo de elevação.

Virtualização

Importante A virtualização é implementada para melhorar os problemas de compatibilidade de aplicativos para aplicativos em execução como um usuário padrão no Windows Vista. Os desenvolvedores não devem confiar na presença da virtualização em versões subsequentes do Windows.

Antes do Windows Vista, muitos aplicativos eram normalmente executados por administradores. Como resultado, os aplicativos podem ler e gravar livremente arquivos do sistema e chaves do Registro. Se esses aplicativos fossem executados por um usuário padrão, eles falhariam devido ao acesso insuficiente. O Windows Vista melhora a compatibilidade do aplicativo para esses usuários redirecionando gravações (e operações subsequentes de arquivo ou registro) para um local por usuário dentro do perfil do usuário. Por exemplo, se um aplicativo tentar gravar em C:\Program Files\Contoso\Settings.ini e o usuário não tiver permissões para gravar nesse diretório, a gravação será redirecionada para C:\Users\<user name>\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. Para o registro, se um aplicativo tentar gravar no HKEY_LOCAL_MACHINE\Software\Contoso\ ele será redirecionado automaticamente para HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso ou HKEY_USERS\< SID >do usuário _Classes\VirtualStore\Machine\Software\Contoso.

A figura a seguir detalha o processo de virtualização no Windows Vista. Neste exemplo, Denise é administradora no modo de aprovação Administração e Brian é um usuário padrão. A virtualização é composta por dois componentes: virtualização de arquivo e virtualização de registro.

Figura 1. Processo de virtualização

Importante Ao desenvolver programas do Windows Vista, para reduzir a complexidade de arquivos virtualizados e chaves do Registro, insira um manifesto do aplicativo com um requestedExecutionLevel apropriado para desativar a virtualização de arquivo e registro.

A virtualização só está habilitada para:

• Processos interativos de 32 bits
• Arquivo/pasta gravável do administrador e chaves do Registro

A virtualização está desabilitada para:

• Processos de 64 bits
• Processos não interativos
• Processos que representam
• Chamadores do modo kernel
• Executáveis que têm um requestedExecutionLevel

Virtualização e roaming:

• Arquivos/pastas de virtualização e chaves do Registro não usam roaming (consulte perfis móveis)
• Associado a objetos globais que não usam roaming

Virtualização de Arquivo

A virtualização de arquivos aborda a situação em que um aplicativo depende da capacidade de armazenar um arquivo, como um arquivo de configuração, em um local do sistema normalmente gravável somente por administradores. A execução de programas como um usuário padrão nessa situação pode resultar em falhas de programa devido a níveis insuficientes de acesso.

Quando um aplicativo grava em um local do sistema somente gravável pelos administradores, o Windows grava todas as operações de arquivo subsequentes em um caminho específico do usuário no diretório da Loja Virtual, que está localizado em %LOCALAPPDATA%\VirtualStore. Posteriormente, quando o aplicativo ler esse arquivo de volta, o sistema fornecerá aquele na Loja Virtual. Como a infraestrutura de segurança do Windows processa a virtualização sem a assistência do aplicativo, o aplicativo acredita que foi capaz de ler e gravar diretamente nos Arquivos de Programas com êxito. A transparência da virtualização de arquivos permite aos aplicativos a percepção de que eles estão escrevendo e lendo do recurso protegido, quando, na verdade, eles estão acessando a versão virtualizada.

Nota Quando você enumera recursos em pastas e no Registro, o Windows Vista mesclará chaves globais de arquivo/pasta e registro em uma única lista. Nessa exibição mesclada, o recurso global (protegido) é listado junto com o recurso virtualizado.

Importante A cópia virtual sempre estará presente no aplicativo primeiro. Por exemplo, config.ini está disponível em \PF\App\config.ini e %LOCALAPPDATA%\VirtualStore\config.ini, e a config.ini no repositório virtual sempre será a leitura, mesmo que \PF\App\config.ini seja atualizada.

A figura a seguir detalha como as exibições globais e mescladas para recursos virtualizados são exibidas para usuários diferentes.

Figura 2. Recursos e exibições virtualizados

Veja a seguir um exemplo do processo de virtualização de arquivo:

Syed Abbas, representante de vendas do Woodgrove Bank, está executando sob uma conta de usuário padrão em um computador que compartilha com outros representantes de vendas. Syed geralmente usa um aplicativo de planilha para atualizar e salvar um arquivo no diretório Arquivos de Programas\SalesV1\: \Program Files\SalesV1\SalesData.txt. Embora Arquivos de Programas\SalesV1\ esteja protegido, o arquivo será salvo com êxito do ponto de exibição do aplicativo de planilha devido à virtualização de arquivos do Windows Vista. Para fazer isso, a gravação do arquivo é redirecionada para Users\username\appdata\Virtual Store\Program Files\SalesV1\SalesData.txt. Quando Syed abrir o Windows Explorer e navegar até o diretório Arquivos de Programas, ele verá a exibição global do arquivo SalesData.txt.

Nota Para syed descobrir seus arquivos virtualizados, ele deve navegar até a loja virtual com o botão Arquivos de compatibilidade na barra de ferramentas Explorer.

No entanto, depois que Stuart Munson, outro representante de vendas, fizer logon na estação de trabalho, ele NÃO verá o arquivo SalesData.txt no diretório Program Files\SalesV1\. Se um usuário diferente usar o computador e gravar o arquivo \Program files\SalesV1\SalesData.txt, essa gravação também será virtualizada no repositório virtual desse usuário. Os arquivos que Syed atualiza e salva permanecerão independentes dos outros arquivos virtualizados no sistema.

Virtualização do Registro

A virtualização do Registro é semelhante à virtualização de arquivo, mas se aplica a chaves do Registro em HKEY_LOCAL_MACHINE\SOFTWARE. Esse recurso permite que aplicativos que dependem da capacidade de armazenar informações de configuração em HKEY_LOCAL_MACHINE\SOFTWARE continuem quando forem executados em uma conta de usuário padrão. As chaves e os dados são redirecionados para HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE. Como no caso de virtualização de arquivo, cada usuário tem uma cópia virtualizada de todos os valores armazenados em um aplicativo no HKLM.

Detalhes da Virtualização do Registro

• Pode ser ativado/desativado em chaves individuais no hive de software
• Nova opção FLAGS no reg.exe para controle de virtualização de nível de chave: permite habilitação/desabilitação recursiva da virtualização e controle da "política de acesso aberto à direita"
• ZwQueryKey: consultar programaticamente os sinalizadores de virtualização para obter uma chave.
• A virtualização ocorre sobre o redirecionamento wow64
• Habilitado nas exibições do Registro de 64 bits e 32 bits: HKU\{SID}_Classes\VirtualStore\Machine\Software e HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264
• A maioria dos aplicativos herdados de 32 bits usará a exibição de 32 bits

A virtualização destina-se apenas a ajudar na compatibilidade do aplicativo com programas existentes. Os aplicativos projetados para o Windows Vista NÃO devem executar gravações em áreas confidenciais do sistema, nem devem depender da virtualização para fornecer reparação para o comportamento incorreto do aplicativo. Ao atualizar o código existente para execução no Windows Vista, os desenvolvedores devem garantir que, durante o tempo de execução, os aplicativos armazenem dados apenas em locais por usuário ou em locais de computador em %alluserprofile% (CSIDL_COMMON_APPDATA) que tenham configurações de ACL (lista de controle de acesso) definidas corretamente.

Importante A Microsoft pretende remover a virtualização de versões futuras do sistema operacional Windows à medida que mais aplicativos são migrados para o Windows Vista. Por exemplo, a virtualização está desabilitada em aplicativos de 64 bits.

Recomendações de virtualização

A virtualização destina-se apenas a ajudar na compatibilidade do aplicativo com os programas existentes. Os aplicativos projetados para o Windows Vista NÃO devem executar gravações em áreas confidenciais do sistema, nem devem depender da virtualização para fornecer reparação para o comportamento incorreto do aplicativo. Ao atualizar o código existente para execução no Windows Vista, os desenvolvedores devem garantir que, durante o tempo de execução, os aplicativos armazenem apenas dados em locais por usuário ou em locais do computador dentro de %alluserprofile% que tenham configurações de ACL (lista de controle de acesso) definidas corretamente.

Importante A Microsoft pretende remover a virtualização de versões futuras do sistema operacional Windows à medida que mais aplicativos são migrados para o Windows Vista. Por exemplo, a virtualização está desabilitada em aplicativos de 64 bits.

• Adicione um manifesto do aplicativo com um RequestedExecutionLevel apropriado para seus aplicativos interativos. Isso desativará a virtualização do aplicativo manifesto.
• Não use o Registro como um mecanismo de comunicação entre processos. Os serviços e os aplicativos de usuário terão exibições diferentes da chave.
• Testar seu aplicativo no Windows Vista: verifique se os processos em execução como usuário padrão não gravam em namespaces globais, como %systemroot%.
• Para desenvolvedores de driver de filtro: verifique o intervalo de altitude. Consulte Filtros do Sistema de Arquivos. Eles devem ser maiores do que a virtualização FSFilter.
• Lembre-se de que os recursos virtualizados são cópias por usuário de recursos globais.

Alterações de token de acesso

Quando um usuário faz logon em um computador Windows Vista, o Windows examina os privilégios administrativos do Windows e as RIDs (IDs relativas) que a conta de usuário possui para determinar se o usuário deve receber dois tokens de acesso (um token de acesso filtrado e um token de acesso completo). O Windows criará dois tokens de acesso para o usuário se um dos seguintes itens for verdadeiro:

1. A conta do usuário contém qualquer um dos RIDs a seguir.
   • 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. A conta do usuário contém privilégios diferentes dos de uma conta de usuário padrão. Uma conta de usuário padrão contém apenas os privilégios a seguir.
   • SeChangeNotifyPrivilege
   • SeShutdownPrivilege
   • SeUndockPrivilege
   • SeIncreaseWorkingSetPrivilege
   • SeTimeZonePrivilege

Quais privilégios o token filtrado contém se o token original continha qualquer um dos RIDS restritos listados acima. Se qualquer um dos RIDs restritos estiver no token, todos os privilégios serão removidos, exceto:

• SeChangeNotifyPrivilege
• SeShutdownPrivilege
• SeUndockPrivilege
• SeReserveProcessorPrivilege
• SeTimeZonePrivilege

Se nenhum RID restrito estiver no token, somente os seguintes privilégios serão removidos:

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

O primeiro token de acesso, chamado de token de acesso filtrado, tem os RIDs anteriores (se presentes) marcados como USE_FOR_DENY_ONLY no token de acesso e os privilégios administrativos do Windows, não listados anteriormente, foram removidos. O token de acesso filtrado será usado por padrão quando o usuário iniciar aplicativos. O token de acesso completo não modificado, chamado de token de acesso vinculado, é anexado ao token de acesso filtrado e é usado quando são feitas solicitações para iniciar aplicativos com um token de acesso administrativo completo.

Mais informações sobre RIDs podem ser encontradas no artigo Biblioteca MSDN cadeias de caracteres SID [Segurança].

Mais informações sobre privilégios do Windows podem ser encontradas no artigo Biblioteca MSDN Constantes de autorização [Segurança].

Arquitetura do UAC

O diagrama a seguir representa o fluxo de processo para inicializações executáveis no Windows Vista.

Figura 3. Arquitetura do UAC

Veja a seguir uma descrição do fluxo de processo exibido no diagrama de arquitetura do UAC e como o UAC é implementado quando um executável tenta iniciar.

Caminho de inicialização do usuário padrão

O caminho de inicialização do usuário padrão do Windows Vista é semelhante ao caminho de inicialização do Windows XP, mas inclui algumas modificações.

• ShellExecute() chama CreateProcess().
• CreateProcess() chama AppCompat, Fusion e Installer Detection para avaliar se o aplicativo requer elevação. Em seguida, o executável é inspecionado para determinar seu requestedExecutionLevel, que é armazenado no manifesto do aplicativo do executável. O banco de dados AppCompat armazena informações para entradas de correção de compatibilidade do aplicativo. A Detecção do Instalador detecta executáveis de instalação.
• CreateProcess() retorna um código de erro Win32 informando ERROR_ELEVATION_REQUIRED.
• ShellExecute() procura especificamente esse novo erro e, ao recebê-lo, chama o serviço de Informações do Aplicativo (AIS) para tentar a inicialização elevada.

Caminho de inicialização elevado

O caminho de inicialização com privilégios elevados do Windows Vista é um novo caminho de inicialização do Windows.

• O AIS recebe a chamada de ShellExecute() e reavalia o nível de execução solicitado e Política de Grupo para determinar se a elevação é permitida e definir a experiência do usuário de elevação.
• Se o nível de execução solicitado exigir elevação, o serviço iniciará o prompt de elevação na área de trabalho interativa do chamador (com base em Política de Grupo), usando o HWND passado do ShellExecute().
• Depois que o usuário der consentimento ou credenciais válidas, o AIS recuperará o token de acesso correspondente associado ao usuário apropriado, se necessário. Por exemplo, um aplicativo que solicita um requestedExecutionLevel de highestAvailable recuperará tokens de acesso diferentes para um usuário que é apenas um membro do grupo Operadores de Backup do que para um membro do grupo administradores local.
• O AIS reemite uma chamada CreateProcessAsUser(), fornecendo o token de acesso do administrador e especificando a área de trabalho interativa do chamador.

O UAC afetará seu aplicativo?

Se seu aplicativo será afetado ou não pelo UAC depende do estado atual do aplicativo. Em vários casos, nenhuma alteração será necessária para atender aos requisitos do Microsoft Segurança do Windows. No entanto, alguns aplicativos, incluindo aplicativos lob (linha de negócios), podem exigir alterações em seus processos de instalação, função e atualização para funcionar corretamente em um ambiente UAC do Windows Vista.

Nota Se um aplicativo funcionar bem como um usuário padrão no Windows XP, ele funcionará bem como um usuário padrão no Windows Vista.

Por que preciso remover as dependências administrativas do meu aplicativo?

Uma etapa fundamental para aumentar a segurança do ambiente de computação geral é permitir que os usuários sejam executados sem usar o token de acesso administrativo. Se um aplicativo opera ou instala apenas quando o usuário é um administrador, os usuários estão sendo forçados a executar aplicativos com acesso elevado desnecessário. O problema fundamental é que, quando os usuários são sempre forçados a executar aplicativos usando tokens de acesso elevados, código enganoso ou mal-intencionado pode modificar facilmente o sistema operacional ou, pior, afetar outros usuários.

A meta da Microsoft é que os clientes entendam que os aplicativos não devem ser executados desnecessariamente como administrador e questionar sempre que forem solicitados a aprovar a solicitação de um aplicativo para serem executados como administradores. O UAC é um componente fundamental para ajudar a atingir essa meta e percorrerá um longo caminho para restaurar um ambiente de computação mais seguro para todos os usuários.

Reduzindo o custo total de propriedade do aplicativo

A conta de usuário padrão é muito atraente para os administradores de TI interessados em aumentar a segurança e o controle sobre seus computadores gerenciados, reduzindo o TCO (custo total de propriedade). Como uma conta de usuário padrão não pode fazer alterações no sistema, há uma relação direta com a redução do TCO e melhor controle da instalação do aplicativo e das modificações em todo o sistema. A conta de usuário padrão também é atraente para usuários domésticos em que os pais compartilham um computador com filhos. O Microsoft Windows Vista inclui controles parentais integrados, que só são implementados com êxito criando contas de usuários infantis como usuários padrão. As contas de usuário padrão também não podem alterar ou excluir arquivos criados por outros usuários. Eles não podem ler arquivos nos perfis de outros usuários, infectar arquivos do sistema ou alterar executáveis compartilhados pelo sistema, seja acidental ou deliberadamente. As contas de usuário padrão resultam em uma melhoria geral na segurança do computador e nos controles dos pais.

Proteger por padrão

Na Microsoft, os princípios da Iniciativa de Computação Confiável da Microsoft foram inseridos no desenvolvimento de software. Consequentemente, a segurança aprimorada tem sido parte integrante do processo de desenvolvimento do Windows Vista.

O pilar de segurança da Computação Confiável abrange três conceitos básicos: seguro por design, seguro por padrão e seguro na implantação. Como você e outros ISVs desenvolvem seus aplicativos para contribuir com a segurança geral do sistema operacional será um fator de sucesso fundamental para alcançar a Computação Confiável no Windows Vista.

O objetivo do restante deste guia é ajudar a ensinar os desenvolvedores a:

• Escrever aplicativos que não exigem que o usuário seja um administrador para executar tarefas rotineiras
• Crie pacotes de instalação com as tecnologias de aplicação de patch do UAC do Windows® Installer 4.0 que são implantadas bem na área de trabalho do usuário padrão em empresas e também são atualizadas corretamente em casa.
• Identificar a funcionalidade administrativa e de usuário padrão e extrapolar tarefas administrativas para compatibilidade do UAC
• Gravar interfaces do usuário do aplicativo que utilizam a funcionalidade UAC

É essencial para o sucesso do UAC que os desenvolvedores de aplicativos adotem a filosofia de privilégios mínimos e projetem seus aplicativos para funcionar corretamente ao executar com uma conta de usuário padrão.

Um dos objetivos da versão do Windows Vista é evangelizar e incentivar o princípio de criação para usuários e administradores padrão no modo de aprovação Administração para todos os desenvolvedores. Alcançar esse objetivo ajudará na prevenção de vários ataques contra aplicativos individuais e atenuará a possibilidade de que esses ataques comprometam a segurança do sistema. Embora essas metas possam ser cumpridas em algum grau hoje, exigindo que os administradores usem duas contas, ela tende a falhar pelos seguintes motivos:

• É quase impossível controlar um usuário que tem um token de acesso de administrador completo. Os administradores podem instalar aplicativos e executar qualquer aplicativo ou script desejado. Os gerentes de TI estão sempre buscando maneiras de criar "áreas de trabalho padrão" em que os usuários fazem logon como usuários padrão. As áreas de trabalho padrão reduzem consideravelmente os custos de suporte técnico e reduzem a sobrecarga de TI.
• Há uma sobrecarga substancial ao alternar entre contas sempre que o usuário quiser executar uma operação administrativa.
• Depois que eles executam uma operação administrativa, os usuários podem esquecer de voltar para sua conta de usuário padrão ou decidir que é muito esforço para voltar atrás.

Como resultado, os usuários podem decidir sempre fazer logon em suas contas administrativas, derrotando assim as medidas de segurança. Para ajudar a atenuar isso, o UAC apresenta o conceito de Administração Modo de Aprovação. Uma conta de usuário do modo de aprovação Administração é uma conta de usuário que é membro do grupo de administradores locais em um sistema com o UAC habilitado.

Na empresa, Administração Modo de Aprovação será usado como uma tecnologia de ponte para migração para o Windows Vista. O ideal é que as empresas executem todos os usuários como usuários padrão e desabilitem o prompt de elevação para usuários padrão. Essa configuração permite uma área de trabalho padrão gerenciada em que as instalações são implantadas com uma tecnologia de implantação de software, como o SMS (Microsoft Systems Management Server).

Importante A Microsoft ainda recomenda que os membros do grupo Administradores de Domínio continuem a manter duas contas de usuário separadas no Windows Vista: uma conta de usuário padrão e uma conta de usuário administrador de domínio. Toda a administração de domínio deve ser feita com a conta de administrador de domínio. Para aprimorar ainda mais a segurança, considere implantar uma solução de cartão inteligente em ambientes de domínio. Consulte o Guia de Planejamento do Acesso Seguro usando Cartões Inteligentes para obter mais informações.

Veja a seguir as metas de design do Windows Vista para Administração Modo de Aprovação:

• Elimine a necessidade de duas contas separadas para usuários que são membros do grupo de administradores: essa meta é cumprida executando programas apenas com um token de acesso de usuário padrão, a menos que o usuário forneça aprovação para usar o token de acesso administrativo completo.
• Proteja os processos em execução com um token de acesso administrativo completo contra serem acessados ou modificados por esses processos em execução como um usuário padrão.
• Forneça uma transição perfeita entre workspaces de administrador e de usuário padrão.

Atualmente, a maioria dos aplicativos do Windows deve ser executada como administrador, mas na verdade não executa operações administrativas. Esses aplicativos são um subproduto da filosofia de sistemas operacionais Microsoft Windows 9x: "todos são administradores".

Veja a seguir exemplos de aplicativos problemáticos:

• Aplicativos que gravam desnecessariamente em HKEY_LOCAL_MACHINE (HKLM) ou em arquivos do sistema dentro do sistema de arquivos.
• Uma instalação do ActiveX para facilitar um aplicativo de linha de negócios com uma interface da Web.
• Aplicativos que solicitam desnecessariamente acesso a recursos que exigem um token de acesso administrativo completo.

A próxima seção apresenta novas tecnologias para o Windows Vista que afetam os ISVs.

Como faço para determinar se meu aplicativo tem dependências administrativas?

Para ajudar desenvolvedores, ISVs e organizações a avaliar seus aplicativos, a Microsoft fornece o Analisador de Usuário Padrão da Microsoft. O Analisador de Usuário Padrão pode ser usado para ajudar o comportamento de identidade não compatível com UAC de um aplicativo. A Microsoft recomenda que os desenvolvedores executem essa ferramenta para identificar problemas com a execução do aplicativo em uma conta de usuário padrão. Esses testes devem ser executados, mesmo que o aplicativo já instale e seja executado corretamente em uma conta de usuário padrão no Windows XP. O aplicativo pode executar operações, como tentar gravar em locais de registro do sistema e tomar decisões com base no comportamento do sistema, como procurar uma resposta de erro. O Windows Vista pode se comportar de maneira diferente das versões anteriores do sistema operacional Windows devido à adição do novo suporte de compatibilidade de aplicativos. Portanto, é recomendável que todos os aplicativos sejam testados com a nova versão do Analisador de Usuário Padrão.

O Analisador de Usuário Padrão registrará todas as operações administrativas encontradas por um aplicativo, incluindo acesso ao sistema de arquivos/registro e chamadas à API elevadas. Esses dados são armazenados em um arquivo de log e são exibidos dentro da ferramenta. O Analisador de Usuário Padrão identifica as seguintes dependências comuns, além de muitas outras:

• Dependência de objetos que restringem o acesso solicitado somente a usuários confiáveis.

  Por exemplo, HKEY_LOCAL_MACHINE concede apenas KEY_WRITE aos administradores e ao SYSTEM— um aplicativo que solicita KEY_WRITE para HKEY_LOCAL_MACHINE não funcionará com o UAC habilitado.

• O uso de privilégios do Windows que têm ramificações de segurança, como SE_DEBUG_PRIVILEGE, que permite a depuração de processos de outros usuários e é concedido apenas aos administradores.

Quais são os requisitos se eu tiver um aplicativo de administrador legítimo?

Para aplicativos que, por design, executam operações administrativas legítimas, a Microsoft implementou uma extensão para a seção trustInfo do esquema de manifesto do aplicativo Windows XP atual. Você pode usar esses novos atributos para indicar ao sistema que você tem um aplicativo administrativo legítimo; o sistema solicitará automaticamente a aprovação do usuário para iniciar o aplicativo com um token de acesso administrativo completo. Para obter informações sobre como estender o manifesto do aplicativo, consulte a seção Criar e inserir um manifesto de aplicativo com seu aplicativo neste documento.

Criando aplicativos para o Windows Vista

A lista a seguir representa um fluxo de trabalho para criar seu aplicativo para o Windows Vista:

1. Testar a compatibilidade do aplicativo para o Windows Vista
2. Classificar seu aplicativo como um usuário padrão, administrador ou aplicativo de usuário misto
3. Reprojetar a funcionalidade do aplicativo para compatibilidade do UAC
4. Reprojetar a interface do usuário do aplicativo
5. Reprojetar o instalador do aplicativo
6. Criar e inserir um manifesto do aplicativo com seus aplicativos administrativos
7. Teste seu aplicativo
8. Assinar seu aplicativo
9. Determinar se deseja prosseguir com o programa logotipo do Windows Vista

1. Testar seu aplicativo para compatibilidade de aplicativos

O teste de compatibilidade de aplicativos com o UAC pode ser facilmente executado instalando o Analisador de Usuário Padrão.

Para utilizar a exibição de log gráfico do Analisador de Usuário Padrão, você deve instalar o Verificador de Aplicativos da Microsoft. O Verificador de Aplicativos é um download gratuito no site da Microsoft.

O procedimento a seguir ilustra como identificar aplicativos administrativos pré-Windows Vista que não são executados corretamente no Windows Vista usando o Analisador de Usuário Padrão.

Há duas abordagens que você pode adotar para utilizar o Analisador de Usuário Padrão: iniciar seu aplicativo como usuário padrão ou iniciar seu aplicativo com privilégios elevados como administrador:

Inicie seu aplicativo como usuário padrão.

Nesse caso, o Analisador de Usuário Padrão está em execução no modo de diagnóstico. O aplicativo falhará no primeiro erro encontrado e o Analisador de Usuário Padrão relatará por que ele falhou.

Inicie seu aplicativo com privilégios elevados como administrador.

Nesta instância, o Analisador de Usuário Padrão está em execução no modo de previsão. O aplicativo poderá executar seu curso e o Analisador de Usuário Padrão preverá e dará uma visão geral dos erros que o aplicativo poderá encontrar se ele for executado como usuário padrão.

Depois que os bugs forem corrigidos e resolvidos, execute esse procedimento mais uma vez como um usuário padrão sem o Analisador de Usuário Padrão para garantir que seu aplicativo esteja funcionando conforme o esperado no Windows Vista.

Para identificar problemas de compatibilidade de aplicativos para aplicativos pré-Windows Vista

1. Faça logon em um computador do Windows Vista como administrador no modo de aprovação Administração.
2. Clique em Iniciar, em Todos os Programas e em Analisador de Usuário Padrão.
3. No Analisador de Usuário Padrão, para Aplicativo de Destino, especifique o caminho de diretório completo para um aplicativo testar ou clicar no botão Procurar para localizar o arquivo executável de programas com o Windows Explorer.
4. Clique em Iniciar e, em seguida, clique em Continuar na caixa de diálogo Controle de Conta de Usuário.
5. Depois que o aplicativo de teste for iniciado, execute tarefas administrativas padrão no aplicativo e feche o aplicativo quando tiver concluído.
6. No Analisador de Usuário Padrão, examine a saída em cada guia. Use esses dados para identificar os problemas de compatibilidade que o programa pode ter.

2. Classificar seu aplicativo como um usuário padrão, administrador ou aplicativo de usuário misto

Os aplicativos administrativos no Windows Vista geralmente têm uma combinação de funcionalidade de usuário administrativo e padrão. Como resultado, várias opções devem ser consideradas ao decidir como seu aplicativo funcionará no Windows Vista. A funcionalidade administrativa pode ser removida completamente ou separada da funcionalidade de conta de usuário padrão solicitando a aprovação do usuário.

Perguntas para ajudar a classificar seu aplicativo

Responda às seguintes perguntas para determinar se seu aplicativo exigirá qualquer reprojeto para compatibilidade com o Windows Vista:

• Seu aplicativo é executado como um usuário padrão?
• A funcionalidade administrativa pode ser corrigida para não exigir mais um token de acesso de administrador?
• As seções administrativas podem ser removidas da funcionalidade do programa?

Seu aplicativo é executado como um usuário padrão?

Para responder a essa pergunta, certifique-se de que o aplicativo ou recurso seja totalmente usado pelos usuários padrão. Se qualquer parte do recurso exigir que o usuário seja um administrador, a resposta para essa pergunta será "Não".

Como verificar se o aplicativo ou painel de controle pode ser usado por usuários padrão:

• Teste minuciosamente o aplicativo ou o painel de controle como um usuário padrão e como administrador. Verifique se as interações do usuário são todas exatamente iguais para usuários padrão e administradores.
• Verifique onde as configurações são armazenadas no registro. Se alguma configuração for armazenada no HKLM, o aplicativo ou o painel de controle provavelmente exigirá um token de acesso de administrador.
• Se qualquer uma das configurações for por computador, o aplicativo ou o painel de controle exigirá um token de acesso de administrador.
• Se qualquer uma das configurações fizer qualquer coisa nos perfis de outros usuários, o aplicativo ou o painel de controle exigirá um token de acesso de administrador.

A Funcionalidade Administrativa pode ser corrigida para não Exigir mais um token de acesso de administrador?

Se seu aplicativo ou painel de controle tiver configurações ou interações que exijam um token de acesso de administrador completo, ele poderá ser alterado para funcionar corretamente como um usuário padrão? Especificamente, o programa pode armazenar informações em configurações por usuário? Se não puder, a resposta para esta pergunta é "Não".

Um bom exemplo do tipo de recurso/configuração que pode ser corrigido é Calc.exe (a Calculadora do Windows). No Windows XP, a configuração de "Scientific" versus "Standard" era uma configuração por computador, o que significava que um token de acesso administrativo completo era necessário para alterar a configuração. No Windows Vista, essa configuração é armazenada no perfil do usuário.

Como verificar se as seções administrativas podem ser removidas da funcionalidade do programa:

• Teste minuciosamente o aplicativo ou o painel de controle como um usuário padrão e como administrador. A experiência pode ser a mesma para ambos os tipos de usuários?

• É possível reduzir as ACLs (listas de controle de acesso) necessárias para gravar na chave HKLM?

  Nota Este curso não deve ser levado de ânimo leve. Tenha cuidado para não comprometer a segurança geral do sistema, reduzindo o controle proporcionado pela ACL.

• É possível alterar a interface do usuário para definir o estado por usuário em vez do estado global (e não expor a modificação de estado global por meio da interface do usuário)?

As Seções Administrativas podem ser removidas da Funcionalidade do Programa?

Seu recurso tem absolutamente que ter essa funcionalidade? Se você não puder cortar os recursos/funcionalidades administrativas, a resposta para essa pergunta será "Não".

Para determinar se as seções administrativas podem ser removidas da funcionalidade do programa, faça o seguinte:

• Teste o painel de controle como um usuário padrão, bem como um administrador. Qual é o cenário do usuário para reter esse recurso?
• Essa configuração/recurso está exposto em outro lugar? Talvez a funcionalidade no painel de controle seja redundante.

Analisando as respostas para classificar seu aplicativo

Se você respondeu "Sim" a qualquer uma das perguntas anteriores

Faça as alterações necessárias no aplicativo ou no painel de controle (se houver) para eliminar os itens que exigem que o usuário tenha um token de acesso administrativo completo.

A lista a seguir detalha os benefícios de ter um aplicativo de usuário padrão verdadeiro:

• Seu recurso é igualmente utilizável para todos os usuários. Esse é o estado ideal, pois a maioria dos recursos não deve exigir um token de acesso de administrador completo.
• Seus usuários nunca verão um prompt de elevação com seus recursos.
• Seus recursos são muito mais seguros, nunca exigindo o token de acesso do administrador.

Se você respondeu "Não" a todas as perguntas anteriores

O aplicativo ou painel de controle deve ser modificado para que o recurso funcione com o UAC.

Verifique se o aplicativo ou o Painel de Controle funciona com o UAC:

Por fim, teste o aplicativo ou o painel de controle como um usuário padrão, bem como um administrador. Verifique se outras opções (as perguntas anteriores) não podem ser usadas para este aplicativo ou painel de controle específico.

3. Reprojetar a funcionalidade do aplicativo para compatibilidade do UAC

Use as informações nesta seção depois de classificar seu aplicativo e determinar se ele deve ser reprojetado para UAC.

Um grande componente de reprojetar seu aplicativo para Windows Vista examinará o modelo de acesso do usuário do aplicativo em seu núcleo.

Requisitos para todos os aplicativos do Windows Vista

Especificar um requestedExecutionLevel

Para que o UAC opere corretamente, o sistema operacional precisa ser capaz de identificar qual código precisa de privilégios elevados e qual código não funciona.

No Windows Vista, essas alterações exigem que os aplicativos sejam marcados com informações que permitam que o sistema operacional determine em que contexto o aplicativo deve ser iniciado. Por exemplo, os aplicativos de usuário padrão precisam ser marcados para serem executados como o invocador e os aplicativos habilitados para acessibilidade precisam ser identificados pelo sistema.

Não registrar componentes com Rundll32

Alguns aplicativos usam os executáveis do Windows Rundll32 para executar componentes. No entanto, esse método não está em conformidade com os requisitos de desenvolvimento do Windows Vista. Chamar diretamente em Rundll32 resulta em problemas de compatibilidade do UAC. Quando um aplicativo depende dos executáveis Rundll32 para executar sua execução, Rundll32 chama o Serviço de Informações do Aplicativo (AIS) em nome do aplicativo para iniciar o prompt de elevação do UAC. Como resultado, o prompt de elevação do UAC não tem conhecimento do aplicativo original e exibe o aplicativo solicitando elevação como "Processo de host do Windows (Rundll32)." Sem uma descrição clara e um ícone para o aplicativo que solicita elevação, os usuários não têm como identificar o aplicativo e determinar se é seguro elevá-lo.

Se o aplicativo chamar Rundll32 para executar componentes, use o fluxo de trabalho a seguir para reprojetar a chamada de execução.

1. Crie um novo arquivo executável separado para seu aplicativo.
2. No novo arquivo executável, chame a função exportada em sua DLL que você teria especificado com Rundll32. Talvez seja necessário carregar a DLL se ela não tiver um .lib.
3. Em um arquivo de recurso, crie e adicione um novo ícone para o executável. Esse ícone será exibido no prompt de elevação controle de conta de usuário quando o aplicativo solicitar elevação.
4. Forneça um nome curto e significativo para o executável. Esse nome será mostrado no prompt de elevação controle de conta de usuário quando o aplicativo solicitar elevação.
5. Crie e insira um arquivo de manifesto do aplicativo para o executável e marque-o com o nível de execução solicitado de requireAdministrator. Esse processo é detalhado na seção Criar e inserir um manifesto de aplicativo com seu aplicativo.
6. O Authenticode assina o novo executável. Esse processo é detalhado na seção Assinar Seu Aplicativo do Authenticode.

Após a desinstalação de um aplicativo, o usuário deve ser capaz de reinstalá-lo sem erros.

Requisitos para aplicativos de usuário padrão

Aqui está um resumo das coisas a serem lembradas ao criar aplicativos que operam corretamente sob uma conta de usuário padrão. Os desenvolvedores devem ter esses requisitos em mente durante a fase de design de seus aplicativos.

Instalação

• Nunca execute ações administrativas (como concluir o processo de instalação) na primeira execução; ele deve ser feito como parte do processo de instalação inicial.
• Nunca escreva diretamente no diretório ou subdiretórios do Windows. Use os métodos corretos para instalar arquivos como fontes.
• Se você precisar atualizar automaticamente seu aplicativo, use um mecanismo adequado para uso por usuários padrão, como a aplicação de patch de Controle de Conta de Usuário do Windows Installer 4.0 para realizar a atualização.

Salvando estado

• Não escreva informações por usuário ou informações graváveis pelo usuário em arquivos de programas ou diretórios de programas.
• Não use caminhos embutidos em código no sistema de arquivos. Aproveite a API KnownFolders e o ShGetFolder para encontrar onde gravar dados.

Executar e testar em uma conta de usuário padrão

Se você estiver escrevendo um aplicativo não administrativo, como um aplicativo LOB ou um aplicativo de usuário, como um jogo, deverá sempre gravar dados do aplicativo em um local ao qual o usuário padrão tem acesso. Veja a seguir alguns dos requisitos recomendados.

• Gravar dados por usuário no perfil do usuário: CSIDL_APPDATA.
• Gravar dados por computador em Usuários\Todos os Usuários\Dados do Aplicativo: CSIDL_COMMON_APPDATA.
• O aplicativo não pode depender de nenhuma APIs administrativas. Por exemplo, um programa que espera chamar com êxito a função SetTokenInformation() do Windows falhará em uma conta de usuário padrão.

Ter reconhecimento de FUS (troca rápida de usuário)

Os aplicativos geralmente serão instalados por um usuário diferente do usuário que executará o aplicativo. Por exemplo, na página inicial, isso significa que um pai instalará o aplicativo para o filho. Na empresa, um sistema de implantação, como SMS ou Política de Grupo anúncio, instalará o aplicativo usando uma conta de administrador.

Se as configurações por usuário não existirem na primeira execução, recompile-as. Não suponha que o processo de instalação tenha cuidado das configurações.

Requisitos para aplicativos de administrador

Usar a propriedade HWND para ser reconhecida como um aplicativo em primeiro plano

Os aplicativos em segundo plano solicitarão automaticamente ao usuário elevação na barra de tarefas, em vez de ir automaticamente para a área de trabalho segura para elevação. O prompt de elevação aparecerá minimizado na barra de tarefas e piscará para notificar o usuário de que um aplicativo solicitou elevação. Um exemplo de elevação em segundo plano ocorre quando um usuário navega até um site e começa a baixar um arquivo de instalação. Em seguida, o usuário vai para marcar email enquanto a instalação é baixada em segundo plano. Depois que o download for concluído em segundo plano e a instalação começar, a elevação será detectada como uma tarefa em segundo plano, em vez de uma tarefa em primeiro plano. Essa detecção impede que a instalação roube abruptamente o foco da tela do usuário enquanto o usuário está executando outra tarefa: ler email. Esse comportamento cria uma melhor experiência do usuário para o prompt de elevação.

No entanto, alguns aplicativos em primeiro plano atualmente solicitam como aplicativos em segundo plano no Windows Vista. Esse comportamento é o resultado de um HWND pai ausente. Para garantir que o Windows Vista reconheça seu aplicativo como um aplicativo em primeiro plano, você deve passar um HWND pai com um ShellExecute, CreateElevatedComObject (COM) ou uma chamada de código gerenciado.

O mecanismo de elevação do UAC usa o HWND como parte da determinação de se a elevação é uma elevação em segundo plano ou em primeiro plano. Se o aplicativo for determinado como um aplicativo em segundo plano, a elevação será colocada na barra de tarefas como um botão piscando. O usuário deve clicar no botão, como em qualquer aplicativo que solicite acesso em primeiro plano, antes que a elevação continue. Não passar o HWND resultará na ocorrência disso, mesmo que o aplicativo possa realmente ter o primeiro plano.

O exemplo de código a seguir ilustra como passar HWND com 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;
}

O exemplo de código a seguir ilustra como passar HWND com CreateElevatedComObject usando o moniker de elevação. Ele pressupõe que você já tenha inicializado COM no thread atual. Mais informações sobre o moniker de elevação estão disponíveis na Etapa Quatro deste 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 é novo no Windows Vista. Ele é derivado de BIND_OPTS2. Ela é definida da seguinte maneira:

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

A única adição é um campo HWND, hwnd. Esse identificador representa uma janela que se torna o proprietário da interface do usuário de elevação quando a solicitação de área de trabalho segura está habilitada.

O exemplo de código a seguir ilustra como passar o HWND no código gerenciado para garantir que as caixas de diálogo pai estejam cientes do HWND e seu 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();

Não solicitar elevação no caminho de logon do usuário

Os aplicativos que começam quando o usuário faz logon e exigem elevação agora são bloqueados no caminho de logon. Sem impedir que os aplicativos solicitem elevação no caminho de logon do usuário, os usuários padrão e os administradores teriam que responder a uma caixa de diálogo Controle de Conta de Usuário em cada logon. O Windows Vista notifica o usuário se um aplicativo foi bloqueado colocando um ícone na bandeja do sistema. Em seguida, o usuário pode clicar com o botão direito do mouse neste ícone para executar aplicativos que foram impedidos de solicitar elevação à medida que o usuário fez logon. O usuário pode gerenciar quais aplicativos de inicialização estão desabilitados ou removidos dessa lista clicando duas vezes no ícone de bandeja.

Um exemplo de código C++ que ilustra como usar o Agendador de Tarefas para executar a elevação para o usuário está disponível na seção Referências deste documento.

Não usar Runas para iniciar um processo elevado

A opção Executar como... do Windows XP e do Windows Server 2003 foi substituída por Executar como administrador no menu de contexto (disponível quando você clica com o botão direito do mouse em um executável) no Windows Vista. Quando um usuário padrão seleciona a opção Executar como administrador , o usuário recebe uma lista de administradores ativos no computador local. Usuários padrão com privilégios mais altos, como membros do grupo Operadores de Backup, também são exibidos. Quando um administrador seleciona a opção Executar como administrador , uma caixa de diálogo Controle de Conta de Usuário solicita imediatamente que o usuário continue antes de executar o aplicativo.

Os usuários devem usar o comando runas no prompt de comando para executar um aplicativo como outro usuário.

Importante Lembre-se de que runas não fornece a capacidade de iniciar um aplicativo com um token de acesso elevado, independentemente de ser um usuário padrão com privilégios como um Operador de Backup ou um administrador. O comando runas concede ao usuário a capacidade de iniciar um aplicativo com credenciais diferentes. O melhor método a ser usado para iniciar um aplicativo com uma conta diferente é executar a ação programaticamente usando um serviço e não depender do usuário para executar o componente como um usuário diferente. Se o programa usar programaticamente o comando runas, verifique se ele não se destina a iniciar um processo elevado.

Se o aplicativo exigir que o usuário execute partes do aplicativo com uma conta de usuário diferente, verifique se o comando runas com a opção de prompt de comando está exposto. A tabela a seguir detalha os parâmetros disponíveis para o comando runas .

Parâmetros Runas

Parâmetro	Descrição
/noprofile	Especifica que o perfil do usuário não deve ser carregado. Isso permite que o aplicativo seja carregado mais rapidamente, mas pode causar mau funcionamento de alguns aplicativos.
/Perfil	Especifica que o perfil do usuário deve ser carregado. Essa é a configuração padrão.
/Env	Use o ambiente atual em vez do do usuário.
/netonly	Use esse parâmetro se as credenciais especificadas forem somente para acesso remoto.
/savecred	Use as credenciais salvas anteriormente pelo usuário. Essa opção não está disponível no Windows XP, Home Edition e será ignorada.
/smartcard	Use esse parâmetro se as credenciais a serem fornecidas forem de uma cartão inteligente.
/user	O nome de usuário do usuário. O nome de usuário deve ser fornecido na forma de USER\DOMAIN ou USER@DOMAIN.
/showtrustlevels	Exibe os níveis de confiança que podem ser usados como argumentos para o parâmetro /trustlevel.
/Trustlevel	Um dos níveis enumerados em /showtrustlevels.
Programa	Linha de comando para um executável.

Exemplo:

runas /noprofile /user:mymachine\Denise cmd

Observações:

• Insira a senha do usuário somente quando solicitado.
• O parâmetro /profile não é compatível com o parâmetro /netonly.
• O parâmetro /savecred não é compatível com o parâmetro /smartcard.

Requisitos para aplicativos de console

Um aplicativo de console apresenta sua saída na janela do console e não com uma interface do usuário separada. Se um aplicativo precisar de um token de acesso de administrador completo para ser executado, esse aplicativo precisará ser iniciado de uma janela de console com privilégios elevados.

Você deve fazer o seguinte para aplicativos de console:

Marque que seu aplicativo "asInvoker"

Você pode fazer isso criando o manifesto do aplicativo no qual você define RequestedExecutionLevel == asInvoker. Essa configuração permite que chamadores de contextos não elevados criem seu processo, o que permite que eles prossiga para a etapa 2.

Forneça uma mensagem de erro se o aplicativo for executado sem um token de acesso completo do administrador

Se o aplicativo for iniciado em um console não elevado, seu aplicativo deverá fornecer uma breve mensagem e sair. A mensagem recomendada é:

"Acesso negado. Permissões de administrador são necessárias para usar as opções selecionadas. Use um prompt de comando do administrador para concluir essas tarefas."

O aplicativo também deve retornar o código de erro ERROR_ELEVATION_REQUIRED após a falha na inicialização para facilitar o script.

Requisitos para scripts

Os scripts podem ser considerados como um grupo de aplicativos executados em uma ordem predefinida e os resultados de um sendo canalizado para outro.

Para tornar seus scripts compatíveis com o UAC, examine a lógica dos scripts e adicione "testes" para garantir que, antes de executar uma ação no script, você (ou a pessoa que executa o script) tenha privilégios suficientes para realizar essa tarefa.

Requisitos para operações em massa

Se uma tarefa executada pelo aplicativo consistir em ações em vários objetos e alguns deles puderem exigir o token de acesso administrativo do usuário, mostre o prompt de elevação na primeira vez que for necessário. Se o usuário aprovar a elevação, execute o restante das tarefas. Caso contrário, encerre a operação em lote. Esse comportamento seria consistente com a operação de seleção/cópia/exclusão atual.

APIs que ajudam a identificar um administrador

• IsUserAnAdmin()
• GetTokenInformation()

Permissões de acesso de registro/identificador inerentemente diferentes entre administradores e usuários padrão

• MAXIMUM_ALLOWED
• KEY_WRITE
• DELETE (quando aplicado a chaves do Registro)
• Outras palavras-chave semelhantes a HKLM (abertas com MAXIMUM_ALLOWED no XP):
• SHELLKEY_HKLM_EXPLORER
• SHELLKEY_HKLM_SHELL

Outras APIs que são redirecionadas para valores de registro HKLM e virtualização serão aplicadas

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

4. Reprojetar a interface do usuário do aplicativo para compatibilidade do UAC

Use as diretrizes nesta seção para desenvolver a interface do usuário do aplicativo para compatibilidade com o UAC. A adesão a essas diretrizes no desenvolvimento do aplicativo garantirá que seu aplicativo tenha uma experiência de usuário consistente e previsível no Windows Vista.

• Impacto do UAC na experiência do usuário do Windows
• Metas da experiência do usuário do UAC
• Prompt de elevação
• Fluxo do processo de experiência do usuário
• Pontos de entrada de elevação
• Implementação da interface do usuário
• Quando adicionar um ícone de escudo à interface do usuário do aplicativo
• Principais decisões para aplicativos somente de administrador

Importante Simplesmente refratorar a interface do usuário do aplicativo não atenderá aos requisitos de compatibilidade do UAC. A funcionalidade principal do aplicativo deve estar em conformidade com os requisitos de modelo de usuário padrão do Windows Vista. Esses requisitos foram detalhados na etapa anterior, Etapa Três: Reprojetar a funcionalidade do aplicativo para compatibilidade do UAC.

Impacto do UAC na experiência do usuário do Windows

O maior e mais imediato impacto na experiência do usuário será sentido pelos administradores. Os usuários administradores agora precisarão fornecer permissão para realizar tarefas administrativas. Juntamente com isso, os usuários padrão agora terão a capacidade de pedir aos administradores para conceder permissão para determinadas tarefas administrativas dentro da sessão conectada no momento.

Metas da experiência do usuário do UAC

A meta geral para a experiência do usuário do UAC é fornecer previsibilidade na experiência do usuário:

• Para um administrador, isso significa que o usuário sempre sabe quando precisará conceder permissão para executar uma tarefa elevada.

Esse é o ato de solicitar o token de acesso do próprio administrador do usuário para que ele possa fazer alterações necessárias ao administrador.

• Para usuários padrão, isso significa que eles saberão quando:
  • Precisará fornecer aprovação do administrador (ambientes domésticos e não gerenciados) para tarefas administrativas
  • OU quando não é possível concluir uma tarefa (ambientes gerenciados em que a elevação é explicitamente proibida) e deve entrar em contato com o suporte técnico

Metas de design

A lista a seguir compreende as metas de design do UAC.

Eliminar elevação desnecessária

Os usuários devem ter que elevar apenas para executar tarefas que exigem um token de acesso de administrador. Todas as outras tarefas devem ser projetadas para eliminar a necessidade de elevação. O software pré-Windows Vista geralmente requer um token de acesso de administrador desnecessariamente gravando nas seções do registro HKLM ou HKCR ou nas pastas arquivos de programas ou do sistema Windows.

Ser previsível

Os administradores precisam saber quais tarefas exigem elevação. Se eles não puderem prever a necessidade de elevação com precisão, eles são mais propensos a dar consentimento para tarefas administrativas quando não deveriam. Os usuários padrão precisam saber quais tarefas exigem que um administrador execute ou não possam ser executadas em ambientes gerenciados.

Exigir esforço mínimo

Tarefas que exigem um token de acesso privilegiado mais alto devem ser projetadas para exigir uma única elevação. Tarefas que exigem várias elevações rapidamente se tornam tediosas.

Reverter para Usuário Padrão

Depois que uma tarefa que requer um nível mais alto de token de acesso for concluída, o programa deverá reverter ao estado do usuário padrão.

Prompt de elevação

O prompt de elevação é criado com base em uma interface de usuário existente do Windows. O prompt de elevação exibe informações contextuais sobre a elevação de solicitação executável e o contexto é diferente dependendo se o aplicativo está assinado ou não. O prompt de elevação é visto em duas variações: o prompt de consentimento e o prompt de credencial.

Prompt de consentimento

O prompt de consentimento é exibido aos administradores no modo de aprovação Administração quando eles tentam executar uma tarefa administrativa. Essa é a experiência do usuário padrão para administradores no modo de aprovação Administração e pode ser configurada no snap-in local do Gerenciador de Políticas de Segurança (secpol.msc) e com Política de Grupo.

A figura a seguir é um exemplo de um prompt de consentimento do Controle de Conta de Usuário.

Figura 4. Solicitação de consentimento do controle de conta de usuário

Prompt de credencial

O prompt de credencial é exibido para usuários padrão quando eles tentam executar uma tarefa administrativa. Essa é a experiência padrão do usuário para usuários padrão e pode ser configurada no snap-in local do Security Policy Manager (secpol.msc) e com Política de Grupo.

A figura a seguir é um exemplo de um prompt de credencial de Controle de Conta de Usuário.

Figura 5. Solicitação de credenciais de controle de conta de usuário

Política de consentimento do prompt de elevação padrão para o Windows Vista

A tabela a seguir descreve o estilo de prompt padrão para cada tipo de conta de usuário no Windows Vista.

Comportamento padrão do prompt de elevação

Tipo de conta de usuário	Configuração do prompt de elevação
Usuário padrão	Solicita credenciais
Conta de administrador no modo de aprovação do Administração	Solicitar consentimento

Fluxo do processo de experiência do usuário

O fluxo de processo de experiência do usuário do UAC consiste em três componentes distintos:

1. Ponto de entrada de elevação (por exemplo, um controle ou link que exibe o ícone de escudo UAC).
2. Prompt de elevação (uma solicitação de consentimento ou credenciais de administrador).
3. Processo elevado.

O seguinte exemplo de fluxo de trabalho resume como os componentes anteriores estão relacionados:

1. Um administrador no modo de aprovação Administração faz logon em um computador Windows Vista.
2. Em seguida, o usuário decide adicionar outro usuário administrador para o computador.
3. O usuário clica em Iniciar, clica em Painel de Controle e, em seguida, clica no link na seção Segurança intitulada Permitir um programa por meio do Firewall do Windows, que é exibido embutido com um ícone de escudo.
4. Um prompt de consentimento é exibido solicitando aprovação ao usuário.
5. O usuário clica em Continuar e o processo elevado é criado.
6. Em Configurações de Firewall do Windows, o usuário modifica as configurações do Firewall do Windows e, em seguida, clica em OK, o que encerra o processo elevado.
7. O usuário continua a trabalhar no computador como um usuário padrão.

Nota Os pontos de entrada de elevação não se lembram do estado (por exemplo, ao navegar de volta de um local ou tarefa blindada), assim como o ponto de entrada não se lembrará de que a elevação ocorreu. Como resultado, o usuário precisará elevar novamente para inserir a tarefa/link/botão novamente.

Pontos de entrada de elevação

Para pontos de entrada, o ícone de escudo será anexado a determinados controles (por exemplo, botões, links de comando, hiperlinks) para indicar que a próxima etapa imediata requer elevação.

Ícone de escudo

O ícone de escudo é a decoração da interface do usuário principal para um ponto de elevação do UAC. Este ícone significa atividades relacionadas à segurança no Windows Vista e versões anteriores do Windows, e essa relação continua no Windows Vista.

A figura a seguir é um exemplo do ícone de escudo.

Figura 6. Ícone de proteção

O ícone de escudo desempenhará um papel crítico em todos os três componentes da experiência do usuário do UAC.

Ao exibir o sistema com o Windows Explorer, qualquer aplicativo marcado para solicitar um token de acesso de administrador quando ele for iniciado será decorado automaticamente com um glifo de escudo sobre seu ícone. Isso permite que os usuários saibam quais aplicativos, quando iniciados, solicitarão elevação.

Propriedades do ícone de escudo:

• Aparência consistente em toda a experiência do usuário do UAC.
• Não reflete nenhum estado visual (por exemplo, ativo, focalizado, desabilitado etc.).
• Não se lembra do estado.

Há três estilos de controle consistentes que um ponto de entrada marcado com um ícone de escudo pode assumir dentro da experiência do usuário:

• Botão UAC
• Hiperlink UAC
• Link de comando do UAC

Esses estilos se aplicam a todos os cenários em que esses elementos de interface do usuário podem aparecer, como Assistentes, Páginas de Propriedades, Painel de Controle Framework, Explorers etc. Cada um dos estilos implica que um prompt de elevação será exibido imediatamente depois que o usuário clicar em um controle de interface do usuário UAC.

Um quarto ponto de entrada da interface do usuário do UAC, a sobreposição do ícone UAC, também é discutido nesta seção. Se um executável recebe ou não uma sobreposição de ícone não é controlado pelo desenvolvedor do aplicativo. O Windows Vista sobrepõe um ícone de escudo nos ícones dos aplicativos para executáveis que solicitaramExecutionLevel definido como requireAdministrator.

Botão De proteção do UAC

O botão de escudo UAC deve ser usado em qualquer botão de interface do usuário que, quando pressionado, exigirá o prompt de elevação para solicitar aprovação ou credenciais ao usuário.

Os botões de escudo UAC podem ser usados como botões de confirmação (por exemplo, Avançar em um Assistente) ou como um botão para exibir uma interface do usuário de configurações adicionais (por exemplo, Alterar configurações em uma caixa de diálogo de propriedade).

O botão de escudo UAC consiste em dois componentes de interface do usuário:

• Ícone de proteção
• Text label

O botão de escudo UAC é empacotado de uma maneira para que os desenvolvedores possam usá-lo no lugar de um botão normal. O botão UAC também dá suporte à renderização do ícone de escudo no lado esquerdo ou direito do rótulo de texto. Além disso, os desenvolvedores terão a opção de ocultar/mostrar o ícone de escudo enquanto o botão UAC é exibido.

A captura de tela a seguir é um exemplo de um botão de escudo UAC.

Figura 7. Botão de escudo UAC

Hiperlink UAC

O hiperlink UAC deve ser usado em qualquer hiperlink de interface do usuário que, quando clicado, exigirá o prompt de elevação para solicitar aprovação ou credenciais ao usuário.

Um hiperlink UAC consiste nos seguintes componentes:

• Ícone de proteção
• Controle de hiperlink

O hiperlink UAC não é empacotado com o ícone de escudo para um desenvolvedor usar. Os desenvolvedores precisarão obter o recurso de ícone de escudo e renderizá-lo ao lado do hiperlink.

A captura de tela a seguir é um exemplo de um hiperlink UAC.

Figura 8. Hiperlink UAC

Link de comando do UAC

O link de comando do UAC deve ser usado em qualquer botão de interface do usuário que, quando clicado, exigirá o prompt de elevação para solicitar aprovação ou credenciais ao usuário.

Os links de comando do UAC só devem ser usados como botões de confirmação (por exemplo, "Fazer essa opção" em uma caixa de diálogo).

O link de comando do UAC consiste nos seguintes componentes:

• Ícone de proteção
• Componentes de link de comando padrão
• Texto do link
• Texto da anotação

O link de comando UAC é empacotado de uma maneira em que um desenvolvedor pode usar um link de comando UAC no lugar de um link de comando normal. O link de comando do UAC dá suporte à renderização do ícone de escudo no lado esquerdo ou direito do link de comando.

Veja a seguir um exemplo de um link de comando UAC.

Figura 9. Link de comando do UAC

Sobreposições de ícone

No Windows Vista, se um arquivo executável exigir elevação para ser iniciado, o ícone do executável deverá ser "carimbado" com um ícone de escudo para indicar esse fato. O manifesto do aplicativo do executável deve marcar "requireAdministrator" para designar o executável como exigindo um token de acesso administrativo completo. A sobreposição do ícone de escudo também será colocada automaticamente em executáveis que são considerados para exigir elevação de acordo com a heurística de detecção do instalador. Por exemplo, um arquivo chamado setup.exe receberá automaticamente uma sobreposição de ícone de escudo, mesmo que o executável não tenha um manifesto do aplicativo inserido.

A figura a seguir é um exemplo de sobreposição de ícone UAC.

Figura 10. Sobreposição de ícone do UAC

Nota As diretrizes sobre como criar e inserir um manifesto de aplicativo com um executável são fornecidas na seção Criar e inserir um manifesto do aplicativo com seu aplicativo deste documento.

Implementação da interface do usuário

Implementação e APIs de ícone de escudo

Esta seção fornece informações preliminares sobre os ícones e APIs disponíveis para os desenvolvedores à medida que eles migram ou implementam novas funcionalidades de aplicativo administrativo.

Implementação e APIs de ícone de escudo

Ícones	API
Shield	Recurso do usuário: IDI_SHIELD
Botão	Button_SetElevationRequired(hwndButton)
Syslink/Hiperlink	Layout IDI_SHIELD ao lado de syslink
Link de comando	Carregar IDI_SHIELD e definir como ícone de link de comando
Menu de contexto	Suporte de ícone no DefCM para comandos estáticos

Adicionar um ícone de escudo à interface do usuário

Adicione um pequeno ícone:

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

Adicionar um ícone grande:

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

Adicione um ícone de tamanho personalizado:

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

Nota Em geral, você não deve adicionar o ícone de escudo diretamente à interface do usuário. É recomendável usar um dos métodos de imbedding do ícone de escudo em um controle . Além disso, simplesmente adicionar um ícone de escudo na interface do usuário não garantirá a compatibilidade do UAC. Você também deve refratar a totalidade da experiência do usuário do aplicativo (adicionar um requestedExecutionLevel, corrigir quaisquer bugs de usuário padrão e garantir que a interface do usuário seja amigável e compatível com UAC).

Adicionar um ícone de escudo a um botão

O controle de botão padrão (PUSHBUTTON, DEFPUSHBUTTON) foi aprimorado para permitir que você adicione um ícone junto com o texto exibido, sem exigir que os estilos BS_ICON ou BS_BITMAP sejam definidos.

Para exibir o ícone de escudo, chame a seguinte macro (definida em commctrl.h):

Button_SetElevationRequiredState(hwndButton, fRequired);

Observe que hwndButton é o HWND do botão; fRequired determina se deve mostrar (TRUE) ou ocultar (FALSE) o ícone de escudo UAC.

Adicionar um ícone de escudo a um botão do Windows Installer

As caixas de diálogo do Windows Installer criadas usando o suporte à tabela interna podem adicionar um escudo ao último botão da sequência de diálogo da interface do usuário definindo o atributo ElevationShield no controle.

Adicionar um ícone de escudo a um botão "Avançar" em um Assistente

Importante Exibindo o ícone de escudo UAC, o botão "Avançar" só tem suporte no AeroWizards (PSH_AEROWIZARD).

Para exibir o ícone de escudo no botão "Avançar" para uma página específica em um AeroWizard, use o seguinte código:

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;

Adicionar um ícone de escudo a um botão de caixa de diálogo de tarefa

Cuidado Um botão de diálogo de tarefa nunca deve exigir um ícone de escudo UAC. Espera-se que a ação "pressione" em uma caixa de diálogo de tarefa confirme/cancele e descarte a caixa de diálogo da tarefa. Seria estranho que um botão desse tipo exibisse o prompt de elevação para o usuário.

Elevar uma caixa de diálogo modal

Use o moniker de elevação para elevar o objeto COM que representa a caixa de diálogo modal.

Tarefas:

• Mova a caixa de diálogo para um objeto COM.
• Expor um método ShowDialog().
• Use a API CreateElevatedComObject() para criar o objeto COM e chamar ShowDialog().

Essa API executará uma instância do objeto COM como administrador depois de passar pelo processo de elevação.

Nota Uma versão dessa API mais complicada de chamar está disponível. Uma versão simplificada estará disponível em uma versão posterior do Windows Vista.

Diretrizes de Educação e Assistência do Usuário

Quando uma interface do usuário foi fatorada novamente e colocada atrás de um botão, os ISVs devem avaliar se uma alteração no nome do botão é garantida. A Microsoft aconselha a não usar o Advanced como um rótulo de botão para tarefas de elevação. Em vez disso, use rótulos mais descritivos e compreensíveis, como Alterar configurações ou um termo que sugere o que está por trás do botão.

Diretrizes para interface do usuário somente administrador

Se um aplicativo sempre for iniciado por um administrador, você não precisará adicionar escudos adicionais na interface do usuário do aplicativo. Isso ocorre porque o aplicativo será elevado e tudo o que ele fizer será elevado e, portanto, não precisará de elevação adicional.

Nota Se você tiver links para outra interface do usuário de administrador em sua experiência de usuário somente administrador, a interface do usuário iniciará seu destino elevado. Portanto, você não precisa colocar escudos em um aplicativo que seja apenas administrativo.

Quando adicionar o ícone de blindagem à interface do usuário do aplicativo

Um aplicativo de escolha administrativa

Um processo elevado ou objeto COM

O aplicativo inicial é iniciado sem a necessidade de elevação. Esses itens na interface do usuário que exigiriam um token de acesso administrativo são decorados com um ícone de escudo como identificação. Essa decoração indica ao usuário que o uso desse recurso exigirá aprovação do administrador. Quando o aplicativo detecta que um desses botões foi selecionado, ele tem as duas opções a seguir.

• O aplicativo inicia um segundo programa usando ShellExeucute() para executar a tarefa administrativa. Esse segundo programa seria marcado com um requestedExecutionLevel de requireAdministrator, fazendo com que o usuário fosse solicitado a aprovar. Este segundo programa seria executado com um token de acesso administrativo completo e seria capaz de executar a tarefa desejada.
• O aplicativo inicia um objeto COM usando CreateElevatedComObject(). Essa API iniciaria o objeto COM com um token de acesso administrativo completo após a aprovação e esse objeto COM seria capaz de executar a tarefa desejada.

Esse método fornece a experiência mais rica do usuário e é o método preferencial de lidar com a funcionalidade administrativa.

A lista a seguir detalha os requisitos para um processo elevado ou objeto COM:

• O painel de controle deve implementar a decoração do escudo e sua arquitetura necessária.
• O desenvolvedor deve determinar para onde o escudo deve ir na interface do usuário.
• O desenvolvedor deve fazer o trabalho de arquitetura para separar a lógica de negócios em um objeto COM do objeto de interface do usuário.
• O desenvolvedor deve chamar o processo de elevação do UAC quando o evento OnClick para o ícone de escudo for detectado.

A lista a seguir detalha os benefícios de projetar corretamente um processo elevado ou um objeto COM:

• Essa é a melhor experiência geral do usuário para ambos os tipos de usuário. A interface do usuário será iniciada, acessível para todos e toda a funcionalidade UAC nessa interface do usuário será acessível a todos. Somente quando uma tarefa de administrador é necessária o usuário tenta elevar para concluir a tarefa.
• Fazer esse trabalho agora fará com que você esteja totalmente em conformidade com o UAC.
• A separação de interface do usuário/COM é uma boa prática arquitetônica.

Clicar em um ícone de escudo faz com que o aplicativo inicie um programa com privilégios elevados ou um objeto COM com privilégios elevados para executar a tarefa.

Aplicativo somente administrador

Nessa instância, a inicialização inicial do aplicativo requer aprovação do administrador. Esse método é chamado de "prompt antes de iniciar". Depois de iniciado, o aplicativo está em execução com um token de acesso administrativo completo e, portanto, pode executar as tarefas administrativas desejadas. Esse método é o trabalho mínimo para o desenvolvedor. O manifesto do aplicativo é marcado com um requestedExecutionLevel de requireAdministrator.

Importante Embora isso exija a menor quantidade de trabalho para o desenvolvedor, observe que, assim como outros aplicativos administrativos no Windows Vista, os administradores terão que elevar para usar esse aplicativo e que os usuários padrão não poderão usar o aplicativo.

A lista a seguir detalha os requisitos para aplicativos somente de administrador:

• O manifesto do aplicativo deve conter um conjunto de marcação requestedExecutionLevel para exigirAdministrador.
• O usuário é solicitado a aprovar o administrador antes do Windows iniciar o aplicativo com um token de acesso administrativo completo.

A lista a seguir detalha os benefícios de criar corretamente um aplicativo somente administrador:

• O sistema operacional não precisa "adivinhar" se o aplicativo de instalação for um aplicativo administrativo.
• Os usuários padrão receberão automaticamente uma dica de que a operação é uma operação administrativa. Por exemplo, quando você vê o ícone de um aplicativo marcado como requireAdministrator, o ícone tem um escudo inserido no ícone.
• No Windows Vista, se você marcar seu aplicativo como requireAdministrator, você saberá que, depois que ele for iniciado, ele será executado com um token de acesso de administrador completo. Os usuários devem elevar para executar o aplicativo (seja como administrador no modo de aprovação Administração ou usando Executar como administrador).

Nota Marcar um aplicativo requireAdministrator NÃO eleva silenciosamente o aplicativo. O usuário ainda terá que dar consentimento de elevação para iniciar o aplicativo. Não há como marcar um aplicativo no Windows Vista para elevar silenciosamente.

A lista a seguir detalha pontos de consideração para criar um aplicativo somente administrador:

• Essa experiência de usuário significa que todos os usuários verão um prompt de elevação (o prompt de credencial ou o prompt de consentimento) antes mesmo de a interface do usuário ficar visível. Isso também significa que ninguém pode simplesmente exibir as configurações atuais até depois de autenticar com credenciais de administrador
• Se você estiver marcando requireAdministrator em um aplicativo de instalação, deverá estar ciente de que o usuário que está executando a instalação é diferente do usuário que pode usar o aplicativo. Portanto, você não deve modificar HKEY_CURRENT_USER (HKCU) e outras configurações por usuário, como gravar no perfil do usuário, durante sua configuração administrativa.

Importante Você deve assumir que o usuário que executa o aplicativo administrativo é diferente do usuário normal no computador.

Os executáveis que exigem um token de acesso de administrador são marcados com uma sobreposição de ícone de escudo.

Aplicativo misto

Um aplicativo misto é aquele que pode ser executado por usuários — todos os usuários do sistema (usuários padrão, administradores no modo de aprovação Administração e aqueles entre eles, como operadores de backup). Esse também é um aplicativo "prompt antes de iniciar". O aplicativo será executado com o token de acesso do invocador e será iniciado normalmente para usuários padrão (sem prompt de elevação). Em seguida, o programa deve modificar seu comportamento em tempo de execução para desabilitar os recursos que não estariam disponíveis para o usuário com base no token de acesso administrativo obtido.

Um aplicativo misto não tem a capacidade de obter privilégios administrativos adicionais depois de iniciado; portanto, ele não fornece a flexibilidade do processo elevado ou do método de objeto COM descrito anteriormente. Isso é mais útil para aplicativos que exigem um token de acesso acima do de um usuário padrão, mas menos que um administrador completo.

Por exemplo, o MMC (Console de Gerenciamento da Microsoft) está marcado como o mais alto Disponível. Se um verdadeiro usuário padrão executar o MMC, o MMC será iniciado como um aplicativo de usuário padrão sem qualquer tentativa ou prompt de elevação. Se o usuário for um usuário de "token dividido", como um administrador no modo de aprovação Administração ou um operador de backup, o sistema operacional solicitará que o usuário obtenha consentimento para iniciar o MMC com o privilégio "mais alto" disponível do usuário. No caso de um usuário padrão que tenha privilégios de Operador de Backup, após a elevação, o MMC será iniciado com o usuário padrão + Operador de Backup, mas nada mais. Se um administrador iniciar o MMC, após a elevação, o MMC será executado como um aplicativo de administrador completo.

O benefício de projetar corretamente um aplicativo misto é que o aplicativo está disponível para todos os usuários do sistema, mesmo que alguma funcionalidade possa estar desabilitada.

A lista a seguir detalha pontos de consideração para criar aplicativos mistos:

• O desenvolvedor deve alterar dinamicamente o comportamento do aplicativo com base nos privilégios administrativos do Windows e nos direitos de usuário disponíveis do usuário.
• O usuário padrão é impedido de atuar nas funções de nível administrativo na interface do usuário. Não há nenhum potencial para elevação de prompt depois que o programa estiver em execução (os administradores devem elevar antes de abrir a interface do usuário).

Nota Há uma solução alternativa para o ponto de marcador anterior. Um administrador pode iniciar um prompt de comando com privilégios elevados no computador do usuário padrão e executar o aplicativo no prompt de comando. Por exemplo, clique com o botão direito do mouse no prompt de comando, selecione Executar como administrador e digite "applicationname.exe" no prompt de comando.

A experiência do usuário é ramificada entre o usuário padrão e o administrador no modo de aprovação Administração.

Exemplo de aplicativo misto: aplicativo de backup

O aplicativo pode ser iniciado por um membro do grupo Operadores de Backup. Em seguida, o programa verificaria se o nível mais alto de privilégios administrativos do Windows e direitos de usuário disponíveis do usuário é suficiente para a operação do programa. Para obter mais informações sobre o comportamento de inicialização do programa, consulte a seção Marcação de Manifesto do Aplicativo e Comportamento de Inicialização do Aplicativo deste documento.

Principais decisões para criar aplicativos Administrator-Only

Objetos de negócios de back-end

Esta seção fornece uma visão geral dos três modelos que um desenvolvedor pode escolher ao desenvolver um aplicativo administrativo que fornece a melhor experiência do usuário.

• O modelo Administração Broker
• O modelo de Serviço Back-End
• O modelo de objeto COM Administração

Administração Broker Model

No modelo Administração Broker, o aplicativo é dividido em dois executáveis independentes: um executável de usuário padrão e um executável administrativo. O desenvolvedor, usando um manifesto de aplicativo, marca o programa de usuário padrão com um requestedExecutionLevel de asInvoker e marca o programa administrativo com um requestedExecutionLevel de requireAdministrator. Primeiro, um usuário iniciará o programa de usuário padrão. Quando o usuário tenta executar uma operação que o programa de usuário padrão sabe que requer um token de acesso de administrador completo, ele executa um ShellExecute() e inicia o programa administrativo. A API ShellExecute() do Windows examina o manifesto e solicita a aprovação do usuário antes de executar o aplicativo com o token de acesso administrativo completo do usuário. Em seguida, o programa administrativo pode executar as tarefas administrativas.

Nota O programa executável administrativo pode habilitar a comunicação entre processos com um executável de usuário padrão usando memória compartilhada, RPC local ou pipes nomeados. Se o programa administrativo habilitar a comunicação com o executável de usuário padrão, o desenvolvedor precisará usar uma boa prática de segurança para validar todas as entradas do programa de privilégios inferiores.

Nota Não há canal de comunicação entre os dois programas quando o segundo programa é iniciado

Os detalhes da lista a seguir são usados para o modelo do agente de administração:

• Assistentes – quando o Assistente de Hardware percebe que o driver necessário não está instalado no computador ou localizado no local aprovado da empresa, ele precisa de um aplicativo elevado com a capacidade de mover um driver para o repositório de computadores.
• Autorun.exe chamando Setup.exe— Na primeira vez que você coloca um CD de jogo, a operação necessária de autorun.exe é configurar o aplicativo. Na segunda vez que você inserir o CD, a operação padrão é jogar o jogo.

Um benefício para usar o modelo de agente de administração é que provavelmente é o mecanismo mais fácil de implementar para o desenvolvedor.

A lista a seguir detalha algumas desvantagens ao usar o modelo Administração Broker:

• As transições de aplicativo para aplicativo podem ser confusas para o usuário. Pode ser difícil manter o usuário informado de por que um novo aplicativo está "aparecendo" no monitor.
• Além disso, o estado é mais difícil de passar entre esses dois aplicativos. Por exemplo, você não usaria isso para passar o estado entre um CPL (painel de controle de usuário) padrão e seu equivalente de administrador simplesmente para permitir que a mesma CPL tenha funcionalidade administrativa e não administrativa. O CPL de usuário padrão teria que armazenar seu estado em algum lugar.
• Muitas vezes, há muito código replicado ao dividir a funcionalidade entre dois programas.

Para implementar o modelo de agente de administração, crie dois programas (um usuário padrão e um administrativo), marque-os com o manifesto apropriado requestedExecutionLevel e inicie o programa administrativo do programa de usuário padrão usando ShellExecute().

O modelo de serviço Back-End

No modelo de serviço de back-end, o aplicativo é novamente dividido em dois executáveis independentes: um executável de usuário padrão que fornece a interface do usuário para o usuário e um serviço de back-end em execução no sistema. A RPC (Chamada de Procedimento Remoto) da Microsoft é usada para se comunicar entre os dois. O aplicativo front-end é marcado com um requestedExecutionLevel de asInvoker e o serviço de back-end está em execução como SYSTEM. A comunicação entre o aplicativo e o serviço de back-end é realizada com RPC.

Um uso para o modelo de serviço de back-end é controlar programas que possam afetar o sistema, como programas antivírus ou anti-spyware. O aplicativo front-end fornece os meios pelos quais o usuário conectado e os aspectos de controle do serviço.

Um dos principais benefícios de usar o modelo de serviço de back-end é que nenhuma solicitação de elevação é necessária.

A lista a seguir detalha algumas desvantagens ao usar o modelo de serviço de back-end:

• O serviço precisa limitar os tipos de atividades que o aplicativo de front-end pode dizer a ele para fazer. Por exemplo, um serviço antivírus pode permitir que um usuário padrão inicie uma verificação do sistema, mas não desabilite a verificação de vírus em tempo real.
• Adicionar um serviço desnecessário ao sistema pode afetar todo o sistema. Verifique se o serviço é realmente necessário para sua implementação do Windows Vista e se o serviço foi projetado corretamente.

Para implementar o modelo de serviço de back-end, crie um aplicativo de front-end de usuário padrão e um serviço de back-end. Instale o serviço no sistema durante o tempo de instalação do produto.

O modelo de objeto COM Administração

Esse modelo está incluído aqui, mas foi discutido detalhadamente anteriormente neste documento. O modelo de objeto COM do administrador permite que a elevação administrativa dinâmica execute operações específicas de dentro de um aplicativo ou painel de controle.

Um dos principais benefícios para usar o modelo de objeto COM de administrador é que ele apresenta a melhor experiência do usuário para o usuário.

A lista a seguir detalha algumas desvantagens ao usar o modelo de objeto COM do administrador:

• Requer o maior trabalho para o desenvolvedor, pois cada recurso de aplicativo precisa ser avaliado e testado para a funcionalidade de administrador e essa função precisa ser fornecida por um objeto COM de back-end.
• O usuário precisa fornecer aprovação de elevação.
• A "unidade" resultante do aplicativo de usuário padrão e Administração objeto COM de back-end agora é "drivável" e não é protegida por UIPI e outros mecanismos de isolamento.

Para implementar o modelo de objeto COM de administrador, crie um aplicativo de front-end de usuário padrão e inicie objetos COM de back-end elevados para executar tarefas administrativas.

5. Reprojetar o instalador do aplicativo

As práticas recomendadas a seguir são para instalações de aplicativos bem comportadas em um ambiente do Windows Vista ou UAC. Esta lista não é completa. Para obter uma explicação mais detalhada dos Requisitos de Logotipo do Windows Vista, incluindo os requisitos do UAC, consulte a documentação do Logotipo do Windows Vista e a versão detalhada do rascunho mais recente do documento de diretrizes do Logotipo do Windows Vista.

Use esses requisitos ao reprojetar seu aplicativo.

Use o Windows Installer 4.0 para seu pacote de instalação.

Muitos dos requisitos a seguir já estão integrados ao mecanismo do Windows Installer. O uso do Windows Installer para seu pacote de instalação ajudará você a seguir os requisitos de instalação do Windows Vista.

Use arquivos com versão e não faça downgrade de arquivos durante a instalação.

O controle de versão do arquivo garante que o estado de instalação final esteja correto quando a instalação for concluída. Sem versões de arquivo, algumas entregas especiais serão necessárias para garantir que sua instalação funcione corretamente para muitos cenários de instalação diferentes. Além disso, ao instalar arquivos com versão, não faça downgrade de versões, especialmente arquivos compartilhados. O downgrade de versões pode ser bom para seu aplicativo, mas frequentemente causa problemas com outros aplicativos. Ao declarar as versões corretas dos arquivos no pacote do Windows Installer, o Windows Installer dá suporte nativo a esse recurso.

Instale aplicativos e armazene dados por usuário em locais diferentes.

Os aplicativos devem ser instalados em uma pasta no diretório Arquivos de Programas. Para configurar isso, você pode usar a propriedade ProgramFilesFolder na tabela Direcotry do pacote do Windows Installer, os dados de configuração por usuário devem ser armazenados em arquivos no diretório \Users\username\AppData ou em chaves do Registro na raiz HKCU. Os dados do usuário, os modelos e os arquivos criados pelo aplicativo têm locais adequados no subdiretório \Users\username. Embora isso não tenha sido imposto no passado, como muitos usuários executariam programas com um token de acesso de administrador completo, aplicativos que não colocam informações no local correto provavelmente falharão. Isso é especialmente verdadeiro quando a virtualização é desativada.

Use um local de pasta consistente ao instalar componentes compartilhados.

Os componentes compartilhados devem ser instalados no diretório Arquivos Comuns usando a propriedade CommonFilesFolder na tabela Directory do pacote do Windows Installer. O gerenciamento de componentes compartilhados pode ser problemático e deve ser evitado, se possível. Um desenvolvedor que não instala componentes compartilhados de forma consistente pode acabar com informações de registro do COM (Component Object Model) apontando para componentes mais antigos. O MSM (Windows Installer Merge Modules) foi projetado especificamente para permitir que componentes compartilhados sejam instalados consistentemente no contexto de todos os pacotes que instalam o componente compartilhado. Outros problemas surgem quando modificações de componentes compartilhados fazem com que os aplicativos existentes falhem. Uma maneira de resolver esse problema é que os aplicativos sejam criados usando assemblies com versão do Microsoft .NET ou Win32.

Execute a reversão da instalação se uma instalação falhar.

O software parcialmente instalado pode falhar de maneiras estranhas e inesperadas, proporcionando uma experiência de usuário ruim. O Windows Installer dá suporte a esse recurso de reversão.

Não instale atalhos de aplicativo em todo o perfil do usuário.

Embora possa ser tentador adicionar o ícone do aplicativo a todos os pontos de exposição conhecidos no Windows, isso geralmente faz com que os usuários sintam que perderam o controle do computador. Em seguida, os usuários são forçados a remover manualmente esses atalhos para retornar o computador a uma aparência desejada. Se o desenvolvedor quiser adicionar ícones à área de trabalho, peça permissão ao usuário durante a instalação. O Windows Vista aborda a capacidade de descoberta de aplicativos após a instalação e a lista de aplicativos usados mais recentemente para evitar a passagem grande do menu Iniciar.

Evite iniciar automaticamente aplicativos em segundo plano no logon do usuário.

Embora seja possível adicionar programas ao grupo de inicialização ou Executar chave durante a instalação, ele adiciona sobrecarga ao sistema. Com o tempo, o desempenho do sistema do usuário pode degradar significativamente. Se o aplicativo puder se beneficiar de uma tarefa em segundo plano, permita que ele seja configurável pelo usuário. Além disso, adicionar uma tarefa de inicialização por meio da chave de execução HLKM pode impedir que uma conta de usuário padrão modifique o comportamento no futuro. Se o usuário quiser que um aplicativo seja iniciado no momento do logon, armazene as informações na chave de execução do HKCU.

Siga limpo lógica de remoção.

Um usuário pode remover um aplicativo não apenas para liberar espaço em disco, mas também para retornar o computador ao seu estado antes do aplicativo ser instalado. O processo de desinstalação do aplicativo deve remover corretamente e totalmente o aplicativo. O Windows Installer usa como padrão as seguintes regras:

• Todos os arquivos e pastas de aplicativos não compartilhados.
• Arquivos de aplicativo compartilhado cuja contagem de referência (refcount) atinge zero.
• Entradas do Registro, exceto para chaves que podem ser compartilhadas por outros programas.
• Todos os atalhos do menu Iniciar que o aplicativo criou no momento da instalação.
• As preferências do usuário podem ser consideradas dados do usuário e deixadas para trás, mas uma opção para fazer uma remoção completamente limpo deve ser incluída.
• O próprio desinstalador (se não estiver usando o Windows Installer).

6. Criar e inserir um manifesto do aplicativo com seu aplicativo

No Windows Vista, a maneira correta de marcar seus aplicativos é inserir um manifesto do aplicativo em seu programa que informa ao sistema operacional o que o aplicativo precisa. Na versão do Windows Vista, há provisionamentos para permitir que código não manifestado ou não assinado seja executado com um token de acesso administrativo completo.

Nota Em versões futuras, a única maneira de executar um aplicativo com privilégios elevados será ter um manifesto assinado que identifique o nível de privilégio de que o aplicativo precisa.

Esquema de manifesto do aplicativo

Os manifestos do aplicativo não são novos na versão do Windows Vista. Os manifestos foram usados no Windows XP para ajudar os desenvolvedores de aplicativos a identificar coisas como com quais versões de DLLs o aplicativo foi testado. Fornecer o nível de execução é uma extensão para esse esquema de manifesto existente.

O manifesto do aplicativo Do Windows Vista foi aprimorado com atributos que permitem aos desenvolvedores marcar seus aplicativos com um nível de execução solicitado. Veja a seguir o formato para isso.

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

Possíveis valores de nível de execução solicitados

Valores	Descrição	Comentário
Asinvoker	O aplicativo é executado com o mesmo token de acesso que o processo pai.	Recomendado para aplicativos de usuário padrão. Faça refratamento com pontos de elevação internos de acordo com as diretrizes fornecidas neste documento.
Highestavailable	O aplicativo é executado com os privilégios mais altos que o usuário atual pode obter.	Recomendado para aplicativos de modo misto. Planeje refratar o aplicativo em uma versão futura.
Requireadministrator	O aplicativo é executado somente para administradores e requer que o aplicativo seja iniciado com o token de acesso completo de um administrador.	Recomendado apenas para aplicativos de administrador. Pontos de elevação internos não são necessários. O aplicativo já está em execução com privilégios elevados.

Nota Os aplicativos de hospedagem só poderão se tornar aplicativos padrão somente para usuários ou administradores se derem suporte a esse determinado tipo de aplicativo hospedado. Por exemplo, MMC.exe agora apenas hospeda snap-ins administrativos e Explorer.exe apenas hospeda o código de usuário padrão.

Comportamento do sistema

Markin de Aplicativo	Virtualizar?
Desmarcado	Sim
Asinvoker	Não
Requireadministrator	Não
Highestavailable	Não

Marcação de manifesto do aplicativo e comportamento de inicialização do aplicativo

Esta seção detalha o comportamento do prompt de elevação, dependendo do token de acesso do processo pai, da configuração do Controle de Conta de Usuário: comportamento da solicitação de elevação para administradores no Administração política de Modo de Aprovação e o Controle de Conta de Usuário: Comportamento do prompt de elevação para a política de usuários padrão e a marcação de nível de execução solicitada para o aplicativo.

Se um aplicativo pode ser executado e quais direitos de usuário e privilégios administrativos do Windows ele pode obter dependem da combinação do nível de execução solicitado do aplicativo no banco de dados de compatibilidade do aplicativo e dos privilégios administrativos disponíveis para a conta de usuário que iniciou o aplicativo. As tabelas a seguir identificam o possível comportamento em tempo de execução com base nessas combinações possíveis.

Comportamento de inicialização do aplicativo para um membro do grupo local Administradores

Token de acesso do processo pai	Política de consentimento para membros do grupo administradores locais	Nenhum ou asInvoker	Highestavailable	Requireadministrator
Usuário Padrão	Sem aviso	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado com um token de acesso administrativo completo; nenhum prompt	O aplicativo é iniciado com um token de acesso administrativo completo; nenhum prompt
Usuário padrão	Solicitar consentimento	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado com um token de acesso administrativo completo; solicitar consentimento	O aplicativo é iniciado com um token de acesso administrativo completo; solicitar consentimento
Usuário padrão	Solicita credenciais	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado com um token de acesso administrativo completo; solicitar credenciais	O aplicativo é iniciado com um token de acesso administrativo completo; solicitar credenciais
Administrador (UAC desabilitado)	N/D	O aplicativo é iniciado com um token de acesso administrativo completo; nenhum prompt	O aplicativo é iniciado com um token de acesso administrativo completo; nenhum prompt	O aplicativo é iniciado com um token de acesso administrativo completo; nenhum prompt

Comportamento de inicialização de aplicativo para uma conta de usuário padrão

Token de acesso do processo pai	Política de consentimento para usuários padrão	Asinvoker	Highestavailable	Requireadministrator
Usuário padrão	Sem aviso	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado como um usuário padrão	Falha na inicialização do aplicativo
Usuário padrão	Solicita credenciais	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado como um usuário padrão	Solicitar credenciais de administrador antes de executar o aplicativo
Usuário padrão (UAC desabilitado)	N/D	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado como um usuário padrão	O aplicativo pode ser iniciado, mas falhará mais tarde

Comportamento de inicialização de aplicativo para um usuário padrão com privilégios adicionais (por exemplo, operador de backup)

Token de acesso do processo pai	Política de consentimento para usuários padrão	Asinvoker	Highestavailable	Requireadministrator
Usuário padrão	Sem prompt	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado como um usuário padrão com privilégios adicionais	Falha ao iniciar o aplicativo
Usuário padrão	Solicita credenciais	O aplicativo é iniciado como um usuário padrão	Solicitar credenciais antes de executar o aplicativo	Solicitar credenciais de administrador antes de executar o aplicativo
Usuário padrão (UAC desabilitado)	N/D	O aplicativo é iniciado como um usuário padrão	O aplicativo é iniciado como um usuário padrão com privilégios adicionais	O aplicativo pode ser iniciado, mas falhará mais tarde

Valores uiAccess

Possíveis valores uiAccess

Valor	Descrição
Falso	O aplicativo não precisa direcionar a entrada para a interface do usuário de outra janela na área de trabalho. Os aplicativos que não estão fornecendo acessibilidade devem definir esse sinalizador como false. Os aplicativos necessários para direcionar a entrada para outras janelas na área de trabalho (teclado virtual, por exemplo) devem definir esse valor como true.
True	O aplicativo tem permissão para ignorar os níveis de controle de interface do usuário para direcionar a entrada para janelas de privilégios mais altas na área de trabalho. Essa configuração só deve ser usada para aplicativos de tecnologia adaptativa da interface do usuário.

Importante Os aplicativos com o sinalizador uiAccess definido comotrue devem ser autenticados para iniciar corretamente. Além disso, o aplicativo deve residir em um local protegido no sistema de arquivos. \Arquivos de Programas\ e \windows\system32\ são atualmente os dois locais protegidos permitidos.

Como criar um manifesto inserido com o Microsoft Visual Studio

O Visual Studio fornece a capacidade de inserir automaticamente um arquivo de manifesto XML na seção de recursos da imagem PE (Executável Portátil). Esta seção aborda como usar o Visual Studio para criar uma imagem PE assinada contendo um manifesto. Portanto, esse manifesto pode incluir os atributos requestedExecutionLevel necessários, permitindo que o aplicativo seja executado com o nível de privilégio desejado no Windows Vista. Quando o programa for iniciado, as informações de manifesto serão extraídas da seção de recursos do PE e usadas pelo sistema operacional. Não é necessário usar a GUI (interface gráfica do usuário) do Visual Studio para incluir um manifesto. Depois que as alterações necessárias estiverem no código-fonte, a compilação e a vinculação usando ferramentas de linha de comando também incluirão o manifesto na imagem PE resultante.

Arquivo de Manifesto

Para marcar seu aplicativo, primeiro crie um arquivo de manifesto a ser usado com o aplicativo de destino. Isso pode ser feito usando qualquer editor de texto. O arquivo de manifesto deve ter o mesmo nome que o target.exe com uma extensão .manifest , conforme mostrado no exemplo abaixo.

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>

As partes do manifesto que precisam ser ajustadas para seu aplicativo são marcadas em negrito. Eles incluem o seguinte:

• A identidade do assembly
• O nome
• O tipo
• A descrição
• Os atributos no requestedExecutionLevel

Criando manifestos de aplicativo no código C/C++ com o Visual Studio 2005 para aplicativos somente do Windows Vista

Importante Se o aplicativo for executado no Windows Vista e no Windows XP, você deverá seguir os procedimentos detalhados na próxima seção: Compilando e inserindo um manifesto com o Microsoft Visual Studio 2005 para Aplicativos Windows XP e Windows Vista.

Em seguida, você precisa anexar o manifesto ao executável adicionando uma linha no arquivo de recurso do aplicativo (o arquivo .rc) para que o Microsoft Visual Studio insira seu manifesto na seção de recursos do arquivo PE. Para fazer isso, coloque o manifesto no mesmo diretório que o código-fonte do projeto que você está criando e edite o arquivo .rc para incluir as linhas a seguir.

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

Depois de recompilar o aplicativo, o manifesto deve ser inserido na seção de recursos do executável.

Criando e inserindo um manifesto com o Microsoft Visual Studio 2005 para aplicativos Windows XP e Windows Vista

No Visual Studio 2005, a interface IDE (ambiente de desenvolvimento integrado) C/C++ que permite a inclusão de arquivos de manifesto adicionais em um arquivo executável de destino faz algum processamento no XML, que insere uma marca xmlns duplicada. Por isso, o método documentado anteriormente sobre como incluir um manifesto em um projeto do Visual Studio 2005 C++ não poderá ser usado se o aplicativo deve ser executado no Windows Vista e no Windows XP. Os procedimentos a seguir são modificados para incluir marcas de versão explícitas na seção trustInfo.

Uma correção é planejada para a ferramenta mt.exe resolver o problema em que gera a declaração de namespace duplicada no XML. Até que uma nova versão do mt.exe esteja disponível, você poderá evitar o problema de mesclar manifestos adicionando explicitamente marcas de versão à seção trustinfo do manifesto. Um exemplo de manifesto é mostrado abaixo:

<?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>

Projeto C ou C++

O procedimento a seguir detalha como criar um manifesto para um tipo de projeto C ou C++ no Visual Studio 2005.

Para criar um manifesto para um projeto C ou C++ no Microsoft Visual Studio 2005

1. Abra seu projeto no Microsoft Visual Studio 2005
2. Em Projeto, selecione Propriedades.
3. Em Propriedades, selecione Ferramenta de Manifesto e, em seguida, selecione Entrada e Saída.
4. Adicione o nome do arquivo de manifesto do aplicativo em Arquivos de manifesto adicionais.
5. Recompile seu aplicativo.

Nota Os manifestos atualizados que incluem marcas de versão explícitas permitirão que o aplicativo seja executado corretamente no Windows Vista e no Windows XP.

Código Gerenciado (C#, J# e Visual Basic)

No momento, o Visual Studio não insira um manifesto padrão no código gerenciado. Para código gerenciado, o desenvolvedor simplesmente inseriria um manifesto padrão no executável de destino usando mt.exe. As etapas seriam as seguintes:

Para inserir um arquivo de manifesto padrão no executável de destino com mt.exe

1. Use um editor de texto, como o Bloco de Notas do Windows, para criar um arquivo de manifesto padrão, temp.manifest.
2. Use mt.exe para inserir o manifesto. O comando seria: mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

Adicionar o manifesto do aplicativo como uma etapa no Pós-build do Visual Studio

A adição do manifesto do aplicativo também pode ser automatizada como uma etapa pós-build. Essa opção está disponível para C/C++ e as duas linguagens de código gerenciado de C# e J#.

Nota Atualmente, o IDE não inclui uma opção pós-build para um aplicativo do Visual Basic.

Coloque a seguinte linha como uma tarefa pós-build em Propriedades do Projeto:

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

7. Testar seu aplicativo

Teste seu aplicativo reprojetado ou novo para compatibilidade do aplicativo com o Analisador de Usuário Padrão. Um procedimento que detalha esse processo foi descrito anteriormente neste documento na seção Testar seu aplicativo para compatibilidade do UAC.

Use o fluxo de trabalho a seguir para testar seu aplicativo.

Para testar o aplicativo para compatibilidade final do UAC

1. Teste o aplicativo com a ferramenta Analisador de Usuário Padrão.
2. Faça logon em um computador do Windows Vista como administrador no modo de aprovação Administração e execute seu programa. Verifique se você testa todas as funcionalidades e observe a experiência do usuário. Registre qualquer bug de elevação ou interface do usuário adequadamente.
3. Faça logon em um computador Windows Vista como um usuário padrão e execute seu programa. Verifique se você testa todas as funcionalidades e observe quaisquer diferenças ou falhas na experiência do usuário padrão em comparação com o administrador em Administração experiência do usuário do Modo de Aprovação. Arquive todos os bugs de elevação e experiência do usuário adequadamente.

8. Autenticar assinar seu aplicativo

O aplicativo agora contém um manifesto, que será detectado e as informações analisadas na inicialização do aplicativo. No entanto, o executável pode ser adulterado. Para evitar isso, você deve assinar o aplicativo com uma assinatura do Authenticode. Observe que o Windows Vista terá a capacidade de impedir que qualquer aplicativo não assinado seja iniciado com um token de acesso de administrador completo. Se você quiser que seu aplicativo opere corretamente em ambientes bloqueados, ao exibir uma interface de usuário mais amigável, ele deverá ser assinado com uma assinatura do Authenticode.

Para assinar o aplicativo, você pode gerar um certificado de makecert.exe ou obter uma chave de assinatura de código de uma das autoridades de certificação comercial (CAs), como VeriSign, Thawte ou uma AC da Microsoft.

Nota Você precisará de um certificado comercial se você tiver seu aplicativo para ser confiável no computador de destino de um cliente que está instalando seu aplicativo.

Se você usar o arquivo makecert.exe para gerar o par de chaves de assinatura, lembre-se de que ele gera apenas uma chave de 1024 bits. As assinaturas authenticode devem ser pelo menos uma chave de 2048 bits. O arquivo de makecert.exe só deve ser usado para fins de teste.

O procedimento a seguir detalha os requisitos de alto nível para usar makecert.exe para gerar o par de chaves de assinatura. Um exemplo e makecert.exe parâmetros seguem este procedimento.

Para usar makecert.exe para gerar seu par de chaves de assinatura

1. Gere o certificado.
2. Assine o código.
3. Instale o certificado de teste.

Exemplo de procedimento de assinatura

Os procedimentos a seguir são fornecidos como exemplos e não se destinam a ser seguidos estritamente. Por exemplo, substitua o nome do certificado de teste pelo nome do certificado e certifique-se de adaptar os procedimentos mapeados para seu ambiente específico de CA e desenvolvimento.

Etapa 1: Gerar o certificado

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

parâmetros demakecert.exe

Parâmetro	Descrição
/r	Criar certificado autoassinado
/Pe	Torna a chave privada do certificado exportável para o computador de assinatura.
/ss StoreName	O nome do repositório de certificados que armazenará o certificado de teste. Exemplo: PrivateCertStore
/n X500Name	O nome X500 da entidade do certificado. Exemplo: Contoso.com(Test)
CertificateName.cer	Nome do certificado. Exemplo: ContosoTest.cer

Etapa 2: Assinar o código

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

Etapa 3: Instalar o certificado de teste

Para instalar o certificado de teste

1. Inicie uma janela de comandos com privilégios elevados clicando com o botão direito do mouse em Prompt de Comando e selecionando Executar como administrador.
2. No Prompt de Comando, digite mmc.exe e pressione Enter.
3. No mmc, selecione Arquivo e, em seguida, selecione Adicionar/Remover Snap-in...
4. Em Adicionar ou Remover Snap-ins, selecione Certificados, clique em Adicionar e em OK.
5. Na caixa de diálogo snap-in Certificados, selecione Conta do computador e clique em Avançar.
6. Em Selecionar Computador, selecione Computador Local e clique em OK.
7. Em Adicionar ou Remover Snap-ins, clique em OK.
8. No snap-in Certificados e navegue até Autoridades de Certificação Raiz Confiáveis, clique com o botão direito do mouse em Certificados, selecione Todas as Tarefas e, em seguida, selecione Importar...
9. No Assistente de Importação de Certificados, importe o certificado de teste, ContosoTest.cer.

9. Participar do Programa de Logotipo do Windows Vista

A Microsoft oferece o programa Logotipo do Windows Vista para ajudar os clientes a identificar sistemas e periféricos que atendem a uma definição de linha de base abrangente de recursos de plataforma e metas de qualidade para garantir uma ótima experiência de computação para os usuários finais.

Implantação e aplicação de patch de aplicativos para usuários padrão

Em geral, as empresas precisarão considerar como instalarão aplicativos nas estações de trabalho de seus usuários de maneira automatizada, reduzindo assim os custos administrativos. Há fundamentalmente duas partes para esse problema: primeiro, como esses aplicativos devem ser empacotados para implantação e segundo, qual tecnologia deve ser usada para implantá-los. No caso de ambientes corporativos menores, um mecanismo de implantação robusto e automatizado pode não ser necessário.

Supondo que a empresa já tenha feito um inventário do software que é executado em seu ambiente, a próxima etapa é reempacotar esses aplicativos para implantação. A Microsoft recomenda o formato do Windows Installer porque ele tem a capacidade exclusiva de separar o gerenciamento de configurações por usuário das configurações por computador. Esse tipo de gerenciamento geralmente não é possível com outros formatos de empacotamento, especialmente executáveis de implantação que são simplesmente executados por uma conta com mais privilégios, como SYSTEM. A biblioteca MSDN contém muitos artigos sobre o Windows Installer; uma sugestão é o Roteiro para a Documentação do Windows Installer.

O formato do Windows Installer inclui a capacidade de o usuário controlar a instalação desses aplicativos por meio de Política de Grupo (Microsoft IntelliMirror) e também por meio de SMS. Para habilitar Instalar sob Demanda com a extensão de arquivo ou atalhos, as tabelas a seguir no pacote baseado no Windows Installer devem ser preenchidas com dados de publicidade: atalho, extensão, ícone e Verbo. É recomendável que você também preencha a classe MIME, ProgID e TypeLib. Leia Aplicação de patch Per-User Aplicativos Gerenciados para obter mais informações sobre o IntelliMirror e Instalar sob Demanda.

Há outras tecnologias de instalador que permitem que os aplicativos instalem por usuário e deem suporte à atualização automática, como o ClickOnce. Isso significa que o instalador não exigirá privilégios de administrador ou superior para instalar e que o usuário sempre executará a versão mais recente, desde que o computador esteja conectado à rede. Ele também coloca alguns limites na capacidade de um profissional de TI de controlar a instalação desses aplicativos.

A implantação do ClickOnce é uma tecnologia de instalação do Microsoft .NET que instala e configura automaticamente um aplicativo do lado do cliente quando um usuário clica em um link de manifesto, como um manifesto em um site, em um CD ou em um caminho UNC (convenção de nomenclatura universal). Por padrão, o aplicativo se copiará para a pasta Arquivos temporários da Internet e será executado em um ambiente restrito.

Nota Mesmo que seu aplicativo tenha sido assinado com o nome forte de TI que lhe dá Confiança Total, você ainda não pode fazer nada que exija permissões de administrador, como acessar determinadas partes do sistema de arquivos e do registro. No entanto, os aplicativos ClickOnce são direcionados como aplicativos por usuário, portanto, isso não deve ser um problema.

Importante O ClickOnce não deve ser usado para implantar aplicativos que executam operações administrativas.

Implantando em um único computador

Para implantar um aplicativo para um único computador, o administrador deve "publicar" o aplicativo nesse computador.

Implantando para todos os usuários em um domínio

Para anunciar para todos os usuários em um domínio, o administrador deve "publicar" o aplicativo por meio de Política de Grupo implantação. Atualmente, apenas o componente de implantação de software baseado em Política de Grupo dos sistemas operacionais Windows Server® 2003 e windows 2000 Server aproveita essa funcionalidade.

Aplicação de patch de aplicativos como um usuário padrão com o Windows Installer 4.0

A aplicação de patch de conta de usuário padrão permite que os autores de pacotes do Windows Installer identifiquem patches assinados que podem ser aplicados por um usuário padrão futuro. As seguintes condições devem ser atendidas para habilitar a aplicação de patch de usuário padrão com o Windows Installer 4.0:

• O aplicativo foi instalado no usando o Windows Installer 4.0.
• O aplicativo foi originalmente instalado por computador.
• A tabela MsiPatchCertificate está presente e preenchida no pacote original do Windows Installer (arquivo .msi).
• Os patches são assinados digitalmente por um certificado listado na tabela MsiPatchCertificate.
• Os patches podem ser validados em relação à assinatura digital.
• A aplicação de patch de conta de usuário padrão não foi desabilitada definindo a propriedade MSIDISABLELUAPATCHING ou a política DisableLUAPatching.

Comportamento de desinstalação do usuário padrão do Windows Installer 4.0

O comportamento esperado para um patch do Windows Installer 4.0 aplicado por um usuário padrão é que ele também pode ser removido pelo usuário padrão.

Solução de problemas comuns

As seções a seguir detalham problemas comuns encontrados com aplicativos no Windows Vista.

Entre os problemas comuns, há:

• Problemas de instalação do ActiveX
• Os documentos ActiveX não são instalados
• Aplicativo, estrutura ou suplemento necessário
• A permissão administrativa é necessária para instalação/aplicação de patch
• Locais de configurações de aplicativo por usuário
• O aplicativo usa como padrão salvar em um diretório protegido

Problemas de instalação do ActiveX

Os controles ActiveX devem ser instalados por um administrador. Os controles ActiveX normalmente são usados em aplicativos de linha de negócios para estender os recursos do navegador da Web para criar interfaces de usuário mais flexíveis ou para elevar o acesso aos recursos do computador normalmente negados a aplicativos em execução no navegador da Web. Os controles ActiveX normalmente são instalados inserindo uma referência ao controle ActiveX em uma página da Web. Isso fará com que o Microsoft Internet Explorer baixe e instale o controle se ele não existir no computador local. Normalmente, os controles ActiveX baixados dessa forma residem no diretório %HOMEPATH%\Local Settings\Temporary Internet Files, que é gravável por usuários padrão. No entanto, para funcionar na Internet Explorer, os controles devem ter entradas de vários registros, que não são possíveis para não administradores.

Resolução

Remover o controle ActiveX do aplicativo quase sempre resulta em uma perda de funcionalidade. Portanto, isso não é recomendado para correção, a menos que o controle ActiveX esteja fornecendo algum aprimoramento visual ou funcional que não faça parte da funcionalidade principal do site. Por exemplo, um ticker de ações em um portal não relacionado a ações.

Na maioria dos casos, empacotar o controle ActiveX para instalação por SMS ou Política de Grupo é a solução correta. No entanto, a maioria dos controles não será incluída na imagem base, portanto, os sites devem modificar suas páginas para falhar normalmente. Isso deve incluir a detecção do controle ActiveX ausente e o redirecionamento para a página de solicitação de software da Área de Trabalho Gerenciada.

Documentos ActiveX não são instalados

Os documentos ActiveX são uma tecnologia preterida do Microsoft Visual Basic 4 e do Microsoft Visual Basic 5. Eles podem ser baixados de maneira semelhante aos controles ActiveX.

Resolução

Como o Visual Basic 4 e o Visual Basic 5 foram preteridos, a Microsoft recomenda que você substitua o aplicativo. Deve ser possível instalar o documento ActiveX como parte de uma instalação do cliente; no entanto, as atualizações do documento serão restritas sem reimplantação por meio de SMS ou Política de Grupo.

Aplicativo, Estrutura ou Suplemento Necessário

Muitos aplicativos têm dependências de outros softwares, que podem não ser instalados por padrão, seja porque já estão disponíveis no computador ou porque o outro aplicativo não fornece binários distribuíveis para uso por terceiros. Em circunstâncias normais, o usuário seria direcionado para adquirir e instalar o software adicional. Em uma área de trabalho gerenciada, a instalação não é possível. Exemplos incluem Adobe Acrobat, Microsoft Office, componentes do Office Web, WinZip e a política de segurança do Microsoft .NET de TI.

Resolução

Depois que as dependências são identificadas, elas podem ser empacotadas com a imagem base ou disponibilizadas por meio da instalação de SMS sob demanda. O aplicativo pode ter que alterar a forma como notifica o usuário final do software ausente, direcionando o usuário para o site de instalação de SMS em vez de para o fabricante.

A permissão administrativa é necessária para instalação/aplicação de patch

Como a instalação de um programa requer a adição de arquivos aos Arquivos de Programas, ele sempre exigirá permissões administrativas e, portanto, deverá ser executado como um usuário com permissões elevadas.

Nota Você também pode "enviar por push" o patch com SMS ou Política de Grupo em conjunto com o painel de controle Adicionar ou Remover Programas (ARP). o usuário seleciona o software para instalar e o instalador do sistema faz o restante— o usuário não precisa ser um administrador. Para instalações iniciais, isso pode ser tratado empacotando o software para que um agente de instalação seja enviado por push. No entanto, alguns aplicativos dependem de atualizações automáticas frequentes que podem não se alinhar bem com um modelo de aplicativo gerenciado centralmente.

Os aplicativos que detectarem atualizações e tentarem aplicar patches por conta própria não poderão fazer isso, pois não terão permissão para modificar arquivos nos diretórios do sistema.

Resolução

• Empacote seu aplicativo/patch para implantação por SMS. Os aplicativos ainda podem detectar que uma atualização está disponível (desde que o façam sem a necessidade de permissões administrativas) e podem redirecionar para o site de provisionamento.
• Questione se o aplicativo precisa de permissões de computador elevadas, como sistema de arquivos, acesso ao Registro ou interoperabilidade COM. Caso contrário, talvez seja possível reescrever o aplicativo como um pacote de implantação do ClickOnce, que será executado na área restrita do Microsoft .NET.
• Converter em um aplicativo Web sem dependências do lado do cliente.

Per-User locais de configurações do aplicativo

Para o Windows Vista, as configurações do aplicativo que precisam ser alteradas em tempo de execução devem ser armazenadas em um dos seguintes locais:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Os documentos salvos pelo usuário devem ser armazenados em CSIDL_MYDOCUMENTS.

Nota A pasta Documentos de um usuário não é mais armazenada em Documentos e Configurações. No Windows Vista, um novo diretório raiz no sistema de arquivos chamado Usuários agora contém os perfis dos usuários do computador.

Como esses diretórios foram alterados, os desenvolvedores são incentivados a usar CSIDLs para localizar o caminho para diretórios conhecidos específicos de maneira independente do sistema. Para obter mais informações, consulte CSIDLs.

Um aplicativo precisa de acesso de gravação ao sistema de arquivos. Ao executar em uma área de trabalho gerenciada, um aplicativo só tem permissão de gravação para as pastas a seguir e seus filhos.

• CSIDL_PROFILE
• CSIDL_COMMON_APPDATA

Nota Os usuários padrão não podem gravar em Usuários\Comum.

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

Os aplicativos não devem tentar gravar em outros locais, como o seguinte:

• C:\windows.
• C:\Windows\System32.
• Arquivos de Programas\{aplicativo}.
• C:\{application}.

Nota Isso funcionará se o usuário criou a pasta , o que os membros do grupo Usuários podem fazer por padrão.

Um aplicativo está tentando criar especificamente C:\Users\Profiles\{user} não é permitido, pois o usuário só pode criar pastas em C:\Users\{user}. O local escolhido parece estar confuso com base no local em que a Microsoft armazenou a pasta Documentos em versões anteriores do sistema operacional.

As configurações de aplicativo que precisam ser alteradas em tempo de execução devem ser armazenadas em um dos seguintes locais:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Os documentos salvos pelo usuário devem ser armazenados na pasta CSIDL_MYDOCUMENTS.

Todos os caminhos não devem ser embutidos em código, mas devem usar a função Environment.GetFolderPath().

O aplicativo usa como padrão salvar em um diretório protegido

Alguns aplicativos permitem que os usuários salvem ou exportem dados para o computador local. Geralmente, a caixa de diálogo usa como padrão locais como C:\, para os quais os usuários padrão não têm permissões de gravação. Além disso, alguns aplicativos não respondem bem quando o código para gravar o arquivo falha porque, como resultado de um acesso negado do sistema operacional.

Resolução

Suponha que os usuários só possam gravar em seus próprios perfis. Para documentos salvos intencionalmente pelos usuários, inicialize as caixas de diálogo para iniciar em Documentos (Environment.GetFolderPath(Environment.SpecialFolder.Personal). Lembre-se de que a caixa de diálogo Salvar permitirá que um usuário navegue até outros locais que não o perfil do usuário, portanto, o aplicativo deve incluir lógica para garantir que ele falhe normalmente se um usuário escolher um diretório diferente daqueles localizados em seu perfil.

Referências

Esta seção inclui uma referência de virtualização e uma referência de configurações de segurança.

Referência de virtualização

Virtualização de arquivo

• Virtualize (%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(Subdirectories)
• Redirecionar para: %LOCALAPPDATA%\VirtualStore
• Executáveis binários excluídos: .exe, .dll .sys

Virtualização do Registro:

• Virtualizar (HKLM\SOFTWARE)
• Redirecionar para: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys>
• Chaves excluídas da virtualização
• HKLM\Software\Classes
• Hklm\software\microsoft\windows
• HKLM\Software\Microsoft\Windows NT

Aplicabilidade

• As lojas virtuais não são móveis
• Objetos globais correspondentes não seriam móveis
• Habilitado somente para usuários padrão interativos
• Desabilitado para processos não interativos
• Desabilitado para executáveis de 64 bits
• Desabilitado para executáveis que solicitam um nível de execução (requestedExecutionLevel) no manifesto do aplicativo, o modelo de separação
• Desabilitado para o modo kernel e chamadores representados
• Somente arquivos e chaves de registro graváveis do administrador são virtualizados

Referência de configurações de segurança do UAC

Essa referência detalha as configurações de segurança disponíveis para administrar o UAC com Política de Grupo ou a política de segurança local do computador.

Nota Os procedimentos apresentados nesta seção destinam-se à administração de computadores não gerenciados. Para usar Política de Grupo para administrar as configurações centralmente em um ambiente gerenciado, use usuários e computadores do Active Directory (dsa.msc) em vez do snap-in local do Gerenciador de Políticas de Segurança (secpol.msc).

Definindo configurações de segurança do UAC

O procedimento a seguir detalha como definir as configurações de segurança do UAC com o Gerenciador de Políticas de Segurança. O procedimento detalha a experiência do usuário padrão para um administrador no modo de aprovação Administração.

Para exibir/definir as configurações de segurança do UAC com o Gerenciador de Políticas de Segurança

1. Clique no botão Iniciar , digite secpol.msc na caixa de pesquisa e pressione Enter.
2. No prompt de consentimento do Controle de Conta de Usuário, clique em Continuar.
3. Em Configurações de Segurança Local, expanda Políticas Locais e clique em Opções de Segurança.
4. Clique com o botão direito do mouse na configuração de segurança que você deseja alterar e selecione Propriedades.

O procedimento a seguir detalha como definir as configurações de segurança do UAC com o Política de Grupo. O procedimento detalha a experiência do usuário padrão para um administrador no modo de aprovação Administração.

Para exibir/definir as configurações de segurança do UAC com o Editor de Objetos Política de Grupo

1. Clique no botão Iniciar , digite gpedit.msc na caixa de pesquisa e pressione Enter.
2. No prompt de consentimento do Controle de Conta de Usuário, clique em Continuar.
3. Em Política de Grupo, expanda Configuração do Usuário e, em seguida, expanda Opções de Segurança.
4. Clique com o botão direito do mouse na configuração de segurança que você deseja alterar e selecione Propriedades.

Configurações de segurança do UAC

A tabela a seguir lista as configurações de segurança UAC configuráveis. Essas configurações podem ser configuradas com o Gerenciador de Políticas de Segurança (secpol.msc) ou gerenciadas centralmente com Política de Grupo (gpedit.msc).

Configurações de segurança do UAC

Configuração	Descrição	Valor padrão
Controle de Conta de Usuário: Administração Modo de Aprovação para a conta de Administrador interna.	Há duas configurações possíveis: Habilitado: o administrador interno será executado como administrador no modo de aprovação Administração. Desabilitado: o administrador é executado com um token de acesso de administrador completo.	Desabilitado para novas instalações e para atualizações em que o Administrador interno não é o único administrador ativo local no computador. A conta de Administrador interna é desabilitada por padrão para instalações e atualizações em computadores ingressados no domínio. Habilitado para atualizações quando o Windows Vista determina que a conta de Administrador interna é o único administrador local ativo no computador. Se o Windows Vista determinar isso, a conta de Administrador interna também será mantida habilitada após a atualização. A conta de Administrador interna é desabilitada por padrão para instalações e atualizações em computadores ingressados no domínio.
Controle de Conta de Usuário: comportamento da solicitação de elevação de administradores no Modo de Aprovação de Administrador	Há três valores possíveis para essa configuração: Elevar sem avisar: elevar silenciosamente. Solicitar credenciais: exija que os usuários insiram sua senha de logon antes de continuar. Solicitar consentimento: peça aprovação ao usuário antes de elevar. Essa é a configuração padrão.  Essa configuração determina como o usuário é solicitado antes de executar um programa com permissões mais altas. Essa política só está em vigor quando o UAC está habilitado.	Solicitar consentimento
Controle de Conta de Usuário: comportamento da solicitação de elevação de usuários padrão	Determina como o usuário é solicitado antes de executar um programa com permissões mais altas. Essa política só está em vigor quando o UAC está habilitado. Veja a seguir as opções de configuração disponíveis para esta configuração: Negar solicitações de elevação automaticamente: os usuários não serão solicitados quando um aplicativo quiser executar uma tarefa administrativa. O aplicativo falhará ao iniciar e apresentará um erro de acesso negado ou equivalente ao usuário. Solicitar credenciais: exija que os usuários insiram sua senha de logon antes de continuar.	Solicita credenciais
Controle de Conta de Usuário: detectar instalações de aplicativos e perguntar se deseja elevar	Há dois valores possíveis: Habilitado: o usuário recebe uma solicitação de consentimento ou credenciais quando o Windows Vista detecta um instalador. Desabilitado: as instalações do aplicativo falharão silenciosamente ou falharão de maneira não determinística.	habilitado
Controle de Conta de Usuário: elevar somente executáveis assinados e validados	Há dois valores possíveis: Habilitado: somente arquivos executáveis assinados serão executados. Essa configuração impede a execução de aplicativos não assinados. Desabilitado: o código assinado e não assinado será executado.	Desabilitado
Controle de Conta de Usuário: eleve apenas aplicativos UIAccess que estejam instalados em locais seguros	Há dois valores possíveis: Habilitado: o sistema só fornecerá privilégios de UIAccess e direitos de usuário para executáveis que são iniciados em %ProgramFiles% ou %windir%. As ACLs nesses diretórios garantem que o executável não seja modificável pelo usuário (o que de outra forma permitiria a elevação de privilégios). Os executáveis UIAccess iniciados de outros locais serão iniciados sem privilégios adicionais (ou seja, eles executarão "asInvoker"). Desabilitado: as verificações de localização não são feitas, portanto, todos os aplicativos UIAccess serão iniciados com o token de acesso completo do usuário após a aprovação do usuário.	habilitado
Controle de Conta de Usuário: executar todos os administradores no Modo de Aprovação de Administrador	Há dois valores possíveis: Habilitado: os administradores e os usuários padrão serão solicitados ao tentar executar operações administrativas. O estilo de prompt depende da política. Desabilitado: o UAC está essencialmente "desativado" e o serviço do AIS está desabilitado de iniciar automaticamente.	habilitado
Controle de Conta de Usuário: alternar para a área de trabalho segura ao pedir elevação	Há dois valores possíveis: Habilitado: exibe o prompt de elevação do UAC na área de trabalho segura. A área de trabalho segura só pode receber mensagens de processos do Windows, o que elimina mensagens de software mal-intencionado. Como resultado, os prompts de consentimento e credencial não podem ser falsificados na área de trabalho segura. Desabilitado: o prompt de elevação do UAC é exibido na área de trabalho do usuário.	habilitado
Controle de Conta de Usuário: virtualizar falhas de gravação de arquivos e Registros para locais por usuário	Há dois valores possíveis: Habilitado: os aplicativos que não têm uma entrada de banco de dados de compatibilidade do aplicativo ou uma marcação de nível de execução solicitada no manifesto do aplicativo não estão em conformidade com o UAC. Ambientes que utilizam software que não está em conformidade devem manter essa configuração habilitada. Desabilitado: aplicativos compatíveis com UAC não devem gravar em áreas protegidas e causar falhas de gravação. Como resultado, os ambientes que utilizam apenas aplicativos em conformidade com o UAC devem desabilitar essa configuração. Aplicativos não compatíveis que tentam gravar em Arquivos de Programas e %systemroot% falharão silenciosamente se essa configuração estiver desabilitada.	habilitado

Nota Para a maioria das situações, a opção Elevar sem avisar não é recomendada. Elevar sem solicitar permitiria que aplicativos em execução como um usuário padrão iniciassem aplicativos administrativos sem o consentimento do usuário e ignorassem efetivamente o UAC.

Exemplo de código do agendador de tarefas

O exemplo de código C++ a seguir ilustra como usar o Agendador de Tarefas para executar a elevação para o usuário. Como resultado, o aplicativo pode elevar automaticamente durante o logon usando as credenciais de um administrador e o Windows Vista não bloqueará o aplicativo. Você deve criar um usuário administrador para seu aplicativo durante a instalação para que essa solução funcione corretamente.

//---------------------------------------------------------------------
//  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;
}