Segurança da Informação · FGV · 2026 | Questão sqc-fg126846

Segurança da InformaçãoKerberos

Código: fg126846
Banca: FGV
Órgão: AL-RO
Ano: 2026
Nível: Superior

Cargo: Analista Legislativo (Engenharia Eletrônica e Telecomunicação)

Uma equipe de TI está configurando o Active Directory (AD) para controlar o acesso a um sistema legislativo interno com os seguintes requisitos:• Somente membros do grupo “Comissoes_TI” podem acessar o sistema;• Os servidores de aplicação consultam o AD via LDAP sobre TLS (LDAPS) na porta 636;• O controle de acesso deve ser feito por Group-Based Access Control (GBAC), utilizando tokens Kerberos para autenticação;• Um usuário reporta que, apesar de estar no grupo correto, não consegue acessar o sistema; o log do servidor mostra falha no atributo memberOf durante o processo de autorização.Após uma análise cuidadosa, a equipe verifica que:• O usuário realmente pertence ao grupo “Comissoes_TI”;• As consultas LDAP são recebidas corretamente no Controlador de Domínio;• O sistema realiza bind válido usando autenticação Kerberos; e• A política de domínio está configurada para token group enumeration padrão.Considerando o cenário, assinale a opção que apresenta a causa mais provável da falha de autorização e a ação correta para resolver o problema.

AO usuário deve ser movido para uma OU (Organization Unit) com política de Kerberos mais permissiva, pois tokens Kerberos não incluem atributos LDAP como memberOf.
BO grupo “Comissoes_TI” provavelmente é um grupo local da máquina do servidor, e não um grupo global ou universal do AD; é necessário convertê-lo para Universal ou garantir que seja um grupo Global do domínio.
CO LDAPS deve ser alterado para porta 389 (LDAP sem TLS), pois memberOf não é retornado corretamente em consultas criptografadas.
DO usuário deve ser adicionado manualmente ao arquivo krb5.ini, já que o Kerberos do Windows não atualiza automaticamente o cache de grupos LDAP.
EO problema é causado pela ordem de criação do grupo: devese excluir e recriar o grupo para sincronizar o atributo memberOf com o token Kerberos.

Revelar gabarito e comentário

GabaritoB — O grupo “Comissoes_TI” provavelmente é um grupo local da máquina do servidor, e não um grupo global ou universal do AD; é necessário convertê-lo para Universal ou garantir que seja um grupo Global do domínio.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Kerberos e Active Directory: Falha na Autorização GBAC

Gabarito: letra B. A causa mais provável é que o grupo "Comissoes_TI" seja um grupo local da máquina do servidor, e não um grupo global ou universal do domínio Active Directory. Como a autorização consulta o atributo memberOf via LDAP, grupos locais não são retornados em consultas ao Controlador de Domínio (DC). A correção é garantir que o grupo seja um grupo de domínio (Global ou Universal).

Alternativa	Descrição	Correta?	Motivo
A	Mover usuário para OU com política de Kerberos mais permissiva	❌	Token Kerberos não inclui `memberOf`; mover OU não altera escopo do grupo
B	Grupo "Comissoes_TI" é local da máquina; converter para Global/Universal do AD	✅	Grupos locais não são retornados em consultas LDAP ao DC; grupos de domínio resolvem
C	Alterar LDAPS (636) para LDAP sem TLS (389)	❌	TLS não interfere no atributo `memberOf`; reduziria segurança
D	Adicionar usuário manualmente ao `krb5.ini`	❌	Arquivo usado em Unix/Linux, não no Windows AD; cache é automático
E	Excluir e recriar o grupo para sincronizar `memberOf`	❌	Atributo `memberOf` é dinâmico; ordem de criação não afeta escopo do grupo

Alternativa A — ❌ Incorreta

Afirma que o token Kerberos não inclui memberOf e sugere mover o usuário para outra OU. Embora seja verdade que tokens Kerberos não contêm atributos LDAP, a falha está na consulta LDAP, não no token. Mover a OU não altera o escopo do grupo. A ação é ineficaz.

Alternativa B — ✅ Correta ⟵ GABARITO

Se o grupo é local da máquina, ele não aparece nas consultas LDAP ao domínio. A autorização falha porque o atributo memberOf não inclui grupos locais de máquina. Converter o grupo para Global ou Universal do AD resolve, pois esses são reconhecidos pelo LDAP.

Alternativa C — ❌ Incorreta

Mudar LDAPS (porta 636) para LDAP sem TLS (porta 389) não corrige o problema. O TLS não interfere na presença do atributo memberOf. Além disso, a segurança seria reduzida.

Alternativa D — ❌ Incorreta

O arquivo krb5.ini é usado em sistemas Unix/Linux para configuração Kerberos, não no Windows com Active Directory. O cache de grupos é mantido automaticamente pelo sistema.

Alternativa E — ❌ Incorreta

A ordem de criação do grupo não afeta o atributo memberOf. Este atributo é dinâmico e calculado pelo AD. Excluir e recriar o grupo não alteraria o escopo (local vs domínio).

NÃO CAIA NESSA!

A banca explora a confusão entre grupos locais de máquina e grupos de domínio no Active Directory. O candidato pode achar que basta autenticar via Kerberos, mas a autorização depende da consulta LDAP, que só vê grupos de domínio.

Gabarito: letra B

Link permanente: /questoes/fg126846