Alguns aplicativos e APIs exigem acesso a informações de autorização em objetos de conta

Este artigo descreve que algumas APIs (interfaces de programação de aplicativos e aplicativos) devem ter acesso ao atributo TGGAU (token-groups-global-and-universal) em objetos de conta de usuário ou em objetos de conta de computador no serviço de diretório do Active Directory.

Aplica-se a: Windows Server 2012 R2
Número de KB original: 331951

Resumo

Alguns aplicativos têm recursos que leem o atributo TGGAU (token-groups-global-and-universal) em objetos da conta de usuário ou em objetos de conta de computador no serviço de diretório do Microsoft Active Directory. Algumas funções Win32 facilitam a leitura do atributo TGGAU. Os aplicativos que leem esse atributo ou que chamam uma API (conhecida como uma função no restante deste artigo) que lê esse atributo não têm êxito se o contexto de segurança de chamada não tiver acesso ao atributo.

Por padrão, o acesso ao atributo TGGAU é determinado pela decisão de Compatibilidade de Permissão (tomada quando o domínio foi criado durante o processo de DCPromo.exe). A compatibilidade de permissão padrão para novos domínios do Windows Server 2003 não concede acesso amplo ao atributo TGGAU. O acesso à leitura do atributo TGGAU pode ser concedido conforme necessário ao novo grupo WAA ( Acesso à Autorização do Windows ) no Windows Server 2003.

Mais informações

O atributo TGGAU (token-groups-global-and-universal) é um valor computado dinamicamente em objetos de conta de computador e em objetos de conta de usuário no Active Directory. Esse atributo enumera as associações de grupo global e as associações de grupo universais para a conta de usuário ou conta de computador correspondente. Os aplicativos podem usar as informações de grupo fornecidas pelo atributo TGGAU para tomar várias decisões sobre um usuário específico quando o usuário não estiver conectado.

Por exemplo, um aplicativo pode usar essas informações para determinar se um usuário recebeu acesso a um recurso para o qual o aplicativo controla o acesso. Os aplicativos que exigem essas informações podem ler o atributo TGGAU diretamente usando interfaces de Protocolo de Acesso do Diretório Leve ou Interfaces do Active Directory Services. No entanto, o Microsoft Windows Server 2003 introduziu várias funções (incluindo a função AuthzInitializeContextFromSid e a função LsaLogonUser) que simplificam a leitura e a interpretação do atributo TGGAU. Portanto, os aplicativos que usam essas funções podem, sem saber, estar lendo o atributo TGGAU.

Para que os aplicativos possam ler diretamente esse atributo ou ler indiretamente esse atributo (por meio do uso de uma API), o contexto de segurança em que o aplicativo é executado deve ter recebido acesso de leitura ao objeto TGGAU nos objetos do usuário e nos objetos do computador. Você não espera que os aplicativos assumam que eles têm acesso ao TGGAU. Portanto, você pode esperar que os aplicativos não sejam bem sucedidos quando o acesso for negado. Nessa situação, você (o usuário) pode receber uma mensagem de erro ou uma entrada de log que explica que o acesso foi negado ao tentar ler essas informações e que fornece instruções sobre como obter acesso (conforme descrito posteriormente neste artigo).

Vários aplicativos existentes dependem das informações fornecidas pelo TGGAU porque as informações estão disponíveis por padrão no Microsoft Windows NT 4.0 e em sistemas operacionais anteriores. Assim, nos sistemas operacionais Microsoft Windows 2000 e Windows Server 2003, o acesso de leitura ao atributo TGGAU é concedido ao grupo de Acesso Compatível pré-Windows 2000 .

Para domínios que usam aplicativos existentes, você pode lidar com esses aplicativos adicionando os contextos de segurança que esses aplicativos executam quanto ao grupo de Acesso Compatível pré-Windows 2000 . Em vez disso, você pode selecionar a opção "Permissões compatíveis com servidores pré-Windows 2000" durante o processo DCPromo ao criar um domínio. (No Windows Server 2003, essa opção é formulada da seguinte maneira: "Permissões compatíveis com sistemas operacionais de servidor pré-Windows 2000".) Essa seleção adiciona o grupo Todos ao grupo Acesso Compatível pré-Windows 2000 e, assim, concede ao grupo Todos acesso de leitura ao atributo TGGAU e a muitos outros objetos de domínio.

Quando um novo domínio do Windows Server 2003 é criado, a seleção de compatibilidade de acesso padrão é compatível apenas com sistemas operacionais Windows 2000 ou Windows Server 2003. Quando essa opção é definida, o grupo acesso de compatibilidade pré-Windows 2000 inclui apenas o identificador de segurança interno Usuários Autenticados e o acesso de leitura ao atributo TGGAU em objetos é limitado. Nesse caso, aplicativos que exigem acesso ao grupo TGGAU têm acesso negado, a menos que a conta em que os aplicativos são executados tenha direitos de administrador de domínio ou direitos de usuário semelhantes.

Habilitando aplicativos para ler o atributo TGGAU

Para simplificar o processo de concessão de acesso de leitura no atributo TGGAU (token-groups-global-and-universal) aos usuários que devem ler o atributo, o Windows Server 2003 apresenta o grupo WAA (Windows Authorization Access).

Em novas instalações de domínios do Windows Server 2003, o grupo WAA recebe acesso ao atributo TGGAU de leitura em objetos de usuário e em objetos de grupo.

Domínios do Windows 2000

Se o domínio estiver no modo de acesso à compatibilidade pré-Windows 2000, o grupo Todos terá acesso de leitura ao atributo TGGAU em objetos da conta de usuário e em objetos de conta de computador. Nesse modo, aplicativos e funções têm acesso ao TGGAU.

Se o domínio não estiver no modo de acesso de compatibilidade pré-Windows 2000, talvez seja necessário habilitar determinados aplicativos para ler o TGGAU. Como o Grupo de Acesso à Autorização do Windows não existe no Windows 2000, é recomendável criar um grupo local de domínio para essa finalidade e adicionar a conta de usuário ou computador que requer acesso ao atributo TGGAU a esse grupo. Esse grupo teria que ter acesso ao tokenGroupsGlobalAndUniversal atributo em objetos de usuário, em objetos de computador e em iNetOrgPerson objetos.

Domínios de modo misto e domínios atualizados

Quando um controlador de domínio do Windows Server 2003 é adicionado a um domínio do Windows 2000, a seleção de compatibilidade de acesso que foi selecionada anteriormente não é alterada. Portanto, domínios e domínios de modo misto que foram atualizados para o Windows Server 2003 que estavam no modo de acesso de compatibilidade pré-Windows 2000 continuam a ter o grupo Todos no grupo acesso de compatibilidade pré-Windows 2000 . Além disso, o grupo Todos ainda tem acesso ao atributo TGGAU. Nesse modo, aplicativos e funções têm acesso ao TGGAU.

Se o domínio de modo misto não estiver no modo de acesso de compatibilidade pré-Windows 2000, você poderá conceder permissões por meio do grupo WAA:

• O grupo WAA é criado automaticamente quando um controlador de domínio do Windows Server 2003 é promovido para o Servidor de Operações Mestre Única Flutuante.
• O grupo WAA não tem acesso automaticamente ao atributo TGGAU em domínios de modo misto e em domínios atualizados.

Depois que o grupo WAA (Windows Authorization Access) tiver acesso ao atributo TGGAU, você poderá colocar as contas que exigem acesso no grupo WAA.

Novos domínios do Windows Server 2003

Se o domínio estiver no modo de acesso à compatibilidade pré-Windows 2000, o grupo Todos terá acesso de leitura ao atributo TGGAU em objetos da conta de usuário e em objetos de conta de computador. Nesse modo, aplicativos e funções têm acesso ao TGGAU.

Se o domínio não estiver no modo de acesso de compatibilidade pré-Windows 2000, adicione ao grupo WAA as contas que exigem acesso ao TGGAU. Em novas instalações do Windows Server 2003, o grupo WAA já tem acesso de leitura ao TGGAU em objetos de usuário e em objetos de computador.