Reinos Múltiplos e TGTs Múltiplos sob o MIT Kerberos para Windows

Question

Meu computador local usa o Windows 7 Pro e pertence à região LR, gerenciada por servidores AD. Eu faço o login no meu computador enquanto estiver conectado à rede desse reino. Eu posso ver o TGT com o MIT Kerberos para Windows ver. 4.0.1.

Eu quero acessar recursos em um reino estrangeiro, FR. Não há confiança Kerberos entre LR e FR, mas eles permitem o tráfego TCP entre si. Eu solicito um TGT para FR com seu KDC (Red Hat IdM / FreeIPA) e insiro com sucesso minha senha quando desafiado. Mais uma vez, posso ver o TGT com o MIT Kerberos for Windows ver. 4.0.1. Agora eu posso acessar recursos em FR sobre SSH sem ser solicitado por uma senha, apesar de ter origem em LR.

O problema é quando recebo o TGT para FR, o TGT para meu principal LR desaparece. Apenas o FR TGT é visível no MIT Kerberos. Se eu bloquear meu computador e, em seguida, desbloquear com a minha senha, agora o FR TGT se foi, substituído por um novo LR TGT.

Parece que o MIT Kerberos para Windows só pode armazenar um TGT de cada vez. Cada TGT trabalha completamente para o seu reino para todos os efeitos. Como posso configurar o MIT Kerberos para permitir que eu tenha dois TGTs ao mesmo tempo, um para cada região? É possível "compartimentar" com várias instâncias do cliente, cada uma apontando para um KRB5_CONFIG diferente e um keytab local? Se eu não puder, há uma implementação alternativa do Windows do Kerberos 5 do lado do cliente que ocorrerá, mesmo quando não houver relações de confiança entre domínios?

P.S. - Eu não quero uma confiança. Não é possível obter uma confiança.

ATUALIZAÇÃO: deixei de fora alguns desses detalhes anteriormente porque achei que poderia confundir o problema. Mas com base na resposta de Brad, isso pode ser garantido. Espero que o mais software local use a implementação interna do Windows do Kerberos e use sempre o keytab LR.

No entanto, usuários avançados como eu usam o heimdal no Cygwin para o SSH no FR. Eu espero que qualquer coisa passando por DLLs do Cygwin para usar heimdal e nunca ver o LR TGT (o que não acontece, pelo menos não por padrão). Eu explicitamente faço xixi e continuo.

A parte complicada vem dos usuários que não são usuários avançados que eu tenho que suportar e que não usam o Cygwin, mas usam o PuTTY. O PuTTY permite que você especifique o caminho da biblioteca e a DLL para a implementação do GSSAPI. Por exemplo, estou configurando sessões SSH para usar DLLs MIT Kerberos em vez de DLLs internas do Windows. Eu estava esperançoso de que havia uma DLL por aí que nunca tentou encontrar o LR TGT (como o heimdal) ou permitiu múltiplos TGTs de múltiplos reinos. Ele não precisa ter uma janela de GUI como o MIT Kerberos, mas ajuda.

    

Answer 1

OK, eu criei uma solução de trabalho que precisa de um pouco mais de polimento, então talvez não funcione em todos os ambientes.

Isso funciona com:

1. MIT Kerberos para Windows 4.0.1 com ferramentas de suporte do Windows (KSETUP.EXE, KTPASS.EXE)
2. PuTTY 0,63
3. Windows 7 SP1

Eu estava procurando na fonte do Kerberos do MIT e encontrei o README para Windows . De particular interesse foram os diferentes valores para o Cache de Credenciais . Ele adota um valor padrão de API: , mas surpreendentemente localizei meu registro usando MSLSA: em seu lugar.

Eu brinquei com valores diferentes de ccname em HKEY_CURRENT_USER\Software\MIT\Kerberos5 . Eu tentei MEMORY: em primeiro lugar, o que levou a um comportamento interessante. Ao abrir uma sessão do PuTTY, minha janela do MIT Kerberos Ticket Manager restauraria e viria para o primeiro plano, solicitando que eu insira as credenciais. Uau! Isso nunca aconteceu antes, mas, infelizmente, o PuTTY o rejeitaria. O valor que fez o truque para mim foi FILE:C:\Some\Full\File\Path . Eu não sei exatamente como proteger o acesso ao arquivo especificado, então vou deixar isso como um exercício para o leitor. Eu tenho o mesmo comportamento de janela para o primeiro plano, apenas PuTTY gostou desta vez. A janela Gerenciador de tickets também finalmente exibiu os tickets LR e FR. Os tickets foram comprovados como sendo transitáveis e sobreviveriam a vários bloqueios / desbloqueios do Windows. OBSERVAÇÃO: não se esqueça de sair completamente e reiniciar as edições de registro do Gerenciador de tíquete entre elas. Ainda não experimentei um ccname da API: .

Não sei se isso faz diferença ou não, mas também brinquei com o KSETUP antes de começar a funcionar. No início, um KSETUP sem parâmetros apenas me mostraria informações sobre o LR. Eu adicionei algumas informações sobre o FR na minha estação de trabalho local.

ksetup /AddKdc FOREIGN.REALM KDC.FOREIGN.REALM
ksetup /AddRealmFlags FOREIGN.REALM TcpSupported Delegate NcSupported

    

Answer 2

Bem, eu não direi que NÃO PODE ser feito com o Windows, mas direi que a limitação é baseada em sessão. O problema é que, para cada sessão, o Windows armazena um ticket em cache. Quando você bloqueia seu computador, em seguida, desbloqueá-lo, outra sessão é iniciada e uma nova chave é solicitada ao KDC. A mesma coisa acontece quando você faz logoff no seu computador novamente. Esse método é, na verdade, como as permissões do usuário também são determinadas para sessões do servidor, significando que a chave / ticket pode ser armazenada em cache para que cada recurso ou sessão do servidor iniciado não precise pedir sua senha, mas nunca ouvi / li / pesquisei para poder armazenar mais de um.

Agora, você provavelmente já sabe que, tendo em conta seu conhecimento da sua pergunta, vou dizer que, com base no fato de o Windows armazenar a chave que você obtém quando um TGT é emitido e é baseado em sessão, Não pense que é possível com o JUST Windows. O MIT Kerberos para Windows pode ter uma maneira de iniciar duas sessões em um usuário, mas, mesmo assim, não tenho certeza de como os recursos que você está acessando saberão qual par de tíquetes / chaves usar. Isso faz sentido?

Por favor, veja isto para uma descrição de como o Windows armazena TGTs / pares de chaves.

Muito boa pergunta pelo caminho.

    

Answer 3

Para mim, parece que há um bug no Kerberos para Windows.

Eu encontrei o seguinte:

Se eu usar a opção "obter permissão" na janela do KfW 4.0.1, ela simplesmente funciona (TM); Eu posso clicar no botão "Obter ingresso" e adquirir ingressos adicionais para os ingressos originais que recebi quando eu fizer logon.

Se eu clicar na opção "tornar padrão" na janela do KfW, a partir desse ponto toda vez que eu clicar em "obter passagem", o novo ticket substituirá qualquer que seja o valor padrão do que adicionar outra entrada à lista de tickets conhecidos. Verificar o registro nesse ponto mostrará que uma entrada ccname (como na resposta de Toddius) foi adicionada. Remover essa entrada irá, surpreendentemente, restaurar o comportamento anterior de permitir vários tickets.

    

Answer 4

Seguindo a resposta de Toddius, tenho um colega de trabalho em uma situação semelhante (Windows 7 Enterprise 64 bits, associado a um domínio do AD, também executando o MIT Kerberos para Windows 4.0.1): Sua cópia do Kerberos Ticket Manager só permitiria que ele tivesse um diretor / um TGT. Sempre que ele usasse o botão "Get Ticket" para obter um TGT para um principal diferente, o principal anterior desapareceria.

Eu analisei o README , e a maioria das chaves do registro foi definida como esperado, < strong> exceto para a chave ccname no caminho HKEY_CURRENT_USER\Software\MIT\Kerberos5 . Essa chave foi definida para o valor MSLSA: . Nossa correção foi mudar isso para API: . Mais especificamente, os passos foram:

1. Encerre o Kerberos Ticket Manager, juntamente com todos os outros aplicativos (desde que você estará reiniciando).
2. No caminho do Registro HKEY_CURRENT_USER\Software\MIT\Kerberos5 , altere a chave ccname para API: (A-P-I, depois, dois pontos).
3. Saia do regedit e reinicie.
4. Depois de fazer login novamente, execute o Kerberos Ticket Manager e use o botão Obter ticket para obter o TGT do principal que não é do AD.

Com os passos acima, tudo funcionou, e eu agora sou capaz de ver vários diretores / TGTs ao mesmo tempo.

A propósito, o MIT Kerberos para Windows traz seu próprio conjunto de programas de linha de comando (como klist), e esses programas suportam múltiplos caches de credenciais. No meu sistema de 64 bits, quando executo "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A" depois de obter vários TGTs, vejo meu principal do Active Directory no cache do MSLSA e, em seguida, tenho um cache de API para cada entidade adicional.

P.S. Esta é a minha primeira entrada neste site, então não pude adicioná-la como um comentário à resposta de Toddius. Desculpas!