☰

Não é possível desativar o logon único (SSO) do Kerberos

tag-icon • tag-icon active-directory iis-7.5 kerberos single-sign-on
Não é possível desativar o logon único (SSO) do Kerberos

Tenho explorado o Kerberos Single Sign On (SSO) para substituir o NTLM por um aplicativo da Web hospedado internamente em um domínio do Windows.

Depois de criar nomes principais de serviço (SPN) para um serviço de teste (setspn -s), posso ver claramente - usando Fiddler ou WireShark - que a autenticação mudou de NTLM para Kerberos.

Tendo uma equipe de infraestrutura cautelosa, gostaria de provar que a mudança pode ser revertida de forma rápida e fácil. Não desejo forçar o NTLM através da configuração do servidor Web. Da mesma forma, os SPNs são excluídos (setspn -d) e sua exclusão é confirmada (setspn -q).

Eu executo o seguinte comando para remover todos os tíquetes de serviço do cliente:

C:\>klist purge

Current LogonId is 0:0x521ac
        Deleting all tickets:
        Ticket(s) purged!

C:\>

Quando ocorre mais interação com o aplicativo Web, outro tíquete de serviço é criado e o Kerberos continua a ser o mecanismo de autenticação SSO. Isso vale para usuários que não usaram o serviço anteriormente. Este é o caso no dia seguinte, após toda a interação ter ficado inativa durante a noite (12 a 14 horas).

Embora eu tenha feito repetidas pesquisas para encontrar uma explicação para a persistência observada, não encontrei nada. No entanto, acho que encontrei uma pista no artigo;A função LsaLookupSids pode retornar o nome de usuário antigo em vez do novo nome de usuário se o nome de usuário tiver sido alterado:

A autoridade de segurança local (LSA) armazena em cache o mapeamento entre o SID e o nome de usuário em um cache local no computador membro do domínio. O nome de usuário armazenado em cache não está sincronizado com os controladores de domínio. O LSA no computador membro do domínio consulta primeiro o cache SID local. Se um mapeamento existente já estiver no cache SID local, o LSA retornará as informações de nome de usuário armazenadas em cache em vez de consultar os controladores de domínio. Esse comportamento tem como objetivo melhorar o desempenho.

As entradas de cache atingem o tempo limite, mas é provável que consultas recorrentes por aplicativos mantenham a entrada de cache existente ativa durante o tempo de vida máximo da entrada de cache.

Alguém pode confirmar se o Key Distribution Center (KDC) armazena em cache as entradas do SPN de maneira semelhante (ou fornecer uma explicação alternativa)? Em caso afirmativo, quais são os tempos de vida máximos da entrada de cache?

Responder1

Eu descobri o problema. O registro DNS do serviço não era um registro “A”, mas na verdade um registro “CNAME”. Isso significa que o navegador estava criando uma chave para a conta de serviço. Isso está relacionado à configuração "useAppPoolCredentials" no site/servidor que foi definido como "False" (o padrão). Os SPNs nos quais eu estava fazendo alterações não participavam da autenticação Kerberos que estava ocorrendo.

informação relacionada