Kerberos SSO e VPN no Mac: compare os dois caminhos de início de sessão

Dois mecanismos produzem o mesmo resultado amigável num Mac e comportam-se de forma completamente diferente por baixo. Um obtém tíquetes Kerberos através de uma extensão SSO e entrega-os às aplicações participantes. O outro mantém uma sessão de navegador junto de um fornecedor de identidade e deixa que as aplicações web a reconheçam. Diferem no que precisam na rede, em quanto tempo duram as suas credenciais e no que acontece no momento em que o túnel cai.

Dois mecanismos, um ecrã de início de sessão

O caminho baseado em tíquetes depende de um domínio Kerberos, de um centro de distribuição de chaves e de um relógio que concorde com ele. O caminho do navegador depende de um fornecedor de identidade acessível, de um cookie ou token e de uma aplicação que confie nesse emissor. Ambos podem ser configurados para começar no início de sessão, e é por isso que são confundidos com a mesma funcionalidade. As aplicações decidem qual dos dois aceitam, e um Mac pode executar legitimamente os dois ao mesmo tempo.

Compare-os perguntando o que a aplicação verifica quando um utilizador a abre. Um serviço de ficheiros associado ao domínio Kerberos quer um tíquete de serviço, e nenhuma quantidade de sessão de navegador o satisfará. Uma aplicação web atrás de um fornecedor de identidade moderno quer o token desse fornecedor e ignora completamente o tíquete Kerberos. Quando sabe que verificação ocorre, as perguntas de implementação tornam-se específicas em vez de gerais.

O que a extensão Kerberos precisa na rede

O guia da extensão Kerberos SSO da Apple descreve a autenticação nativa do Active Directory com obtenção proativa de tíquetes, emparelhada com contas locais em vez de uma ligação ao domínio. O que não consegue fazer é inventar um caminho até aos controladores de domínio. O Mac precisa de um resolvedor que responda aos registos de serviço Kerberos e de uma rota que chegue até eles através do túnel aprovado. Um perfil que se instala sem erros não prova nada até o domínio poder realmente ser descoberto a partir do cliente.

Verifique a descoberta antes de verificar as credenciais: os registos SRV do domínio Kerberos têm de ser resolvidos, e os endereços que devolvem têm de ser acessíveis assim que a VPN estiver ativa. O tempo é tão importante como a acessibilidade, porque o Kerberos rejeita pedidos de um relógio que se desviou para além da sua tolerância, e o erro que produz parece uma falha de autenticação. Um Mac que não alcança uma fonte de tempo enquanto o túnel está em baixo voltará a falhar no momento em que ele regressar. Corrija a fonte de tempo como parte da implementação e não como resposta a um incidente.

klist
sudo sntp -sS time.apple.com

A VPN por aplicação decide se a extensão pode funcionar

Um túnel completo encaminha tudo e esconde este problema. Uma configuração por aplicação encaminha apenas as aplicações nomeadas no perfil de VPN, e a extensão SSO é ela própria um processo que precisa da rede para obter tíquetes. Se não estiver no mapeamento, o início de sessão local tem sucesso, o túnel sobe para o navegador e a obtenção de tíquetes continua a falhar.

Leia a configuração da VPN e liste cada aplicação que ela deve cobrir, depois acrescente o componente SSO através do mecanismo de mapeamento documentado em vez de adivinhar um identificador de pacote. Mapear o cliente visível e não o componente por trás dele é a versão clássica deste erro. Mantenha o mapeamento no mesmo perfil gerido da extensão, para que uma alteração num não possa invalidar silenciosamente o outro. Teste com um utilizador que nunca tenha iniciado sessão nesse Mac, porque um tíquete em cache pode fazer um caminho quebrado parecer saudável, e depois teste novamente após uma alteração de palavra-passe.

Uma sessão de identidade no navegador é outro contrato

Uma sessão de navegador não tem domínio Kerberos, nem tíquete de serviço, nem tolerância de relógio no sentido de Kerberos. Tem um emissor, uma vida útil do token e um caminho de renovação, e os seus modos de falha são redirecionamentos que nunca terminam e cookies que uma janela privada descarta. Tratá-la como substituto do caminho de tíquetes só é seguro onde a própria aplicação aceita esse emissor. Copiar uma resposta de autenticação do portal da VPN para um serviço não relacionado não é integração, por mais conveniente que o atalho pareça.

Quando ambos os mecanismos estão implementados, documente que aplicações usam qual, porque a conversa de suporte depende disso. Um utilizador que relata estar com sessão iniciada mas não conseguir abrir uma partilha de ficheiros está a descrever dois sistemas, e a resposta é que o caminho de tíquetes nunca correu. Um utilizador que consegue abrir a partilha mas não o portal de intranet descreve o contrário, e nomear o mecanismo no tíquete poupa uma ronda de perguntas.

Percorra a sequência, não as peças

Percorra toda a cadeia com uma conta inscrita comum: início de sessão local, túnel, obtenção de tíquetes e depois uma operação real contra um serviço. Repita-o depois de o túnel se reconectar e depois de uma alteração de palavra-passe deliberada, porque cada um desses casos exercita uma parte diferente da lógica de vida útil. Que cada etapa passe por si só não é o mesmo que a cadeia funcionar. A cadeia é o que o utilizador experiencia, e é o que o caso de aceitação tem de cobrir.

Registe o proprietário do perfil, o método de autenticação da VPN, o caminho de descoberta do domínio e o mapeamento de aplicações da extensão num único lugar. Esse registo é o que torna o fluxo reproduzível por alguém que não o construiu. Depois verifique a falha que mais provavelmente vai encontrar, um tíquete expirado enquanto o túnel está em baixo, e confirme que o cliente recupera sem reiniciar, porque uma implementação que só funciona a partir de um arranque a frio não está terminada.

Anote também o proprietário de cada etapa, porque um domínio Kerberos que ninguém mantém torna-se obsoleto. Uma cadeia que ninguém consegue descrever é uma cadeia que ninguém consegue depurar.