Vários domínios e vários TGTs no MIT Kerberos para Windows

Question

Meu computador local usa o Windows 7 Pro e pertence ao domínio LR, gerenciado por servidores AD. Eu faço login no meu computador enquanto estou conectado à rede desse reino. Posso visualizar o TGT com o MIT Kerberos para Windows versão. 4.0.1.

Quero acessar recursos em um reino estrangeiro, FR. Não há confiança Kerberos entre LR e FR, mas eles permitem tráfego TCP entre si. Solicito um TGT para FR com seu KDC (Red Hat IdM/FreeIPA) e insiro minha senha com sucesso quando desafiado. Novamente, posso visualizar o TGT com o MIT Kerberos para Windows versão. 4.0.1. Agora posso acessar recursos em FR por SSH sem que uma senha seja solicitada, apesar de ser originário de LR.

O problema é que quando obtenho o TGT para FR, o TGT do meu principal LR desaparece. Apenas o FR TGT é visível no MIT Kerberos. Se eu bloquear meu computador e depois desbloquear com minha senha, o FR TGT desaparecerá, sendo substituído por um novo LR TGT.

Parece que o MIT Kerberos para Windows só pode armazenar um TGT por vez.Cada TGT funciona perfeitamente para seu domínio, para todos os efeitos. Como posso configurar o MIT Kerberos para permitir dois TGTs ao mesmo tempo, um para cada região? É possível "compartimentar" com múltiplas instâncias de clientes, cada uma apontando para um KRB5_CONFIG e keytab local diferentes? Se não puder, existe uma implementação alternativa do Windows do Kerberos 5 do lado do cliente, mesmo quando não há relações de confiança entre domínios?

PS - Não quero confiança. Não consigo uma confiança.

ATUALIZAR:Deixei de fora alguns desses detalhes anteriormente porque pensei que isso poderia confundir o problema. Mas com base na resposta de Brad, isso pode ser justificado. eu esperomaioriao software local usaria a implementação interna do Kerberos no Windows e sempre usaria o keytab LR.

No entanto, usuários avançados como eu usam heimdal no Cygwin para SSH em FR. Espero que qualquer coisa que passe pelas DLLs do Cygwin use o heimdal e nunca veja o LR TGT (o que não acontece, pelo menos não por padrão). Eu explicitamente kinit e sigo em frente.

A parte complicada surge para usuários não avançados que tenho que oferecer suporte e que não usam Cygwin, mas usam PuTTY. PuTTY permite especificar o caminho da biblioteca e a DLL para a implementação GSSAPI a ser usada. Por exemplo, estou configurando sessões SSH para usar DLLs Kerberos do MIT em vez de DLLs internas do Windows. Eu estava esperançoso de que houvesse uma DLL por aí que nunca tentasse encontrar o LR TGT (como heimdal) ou permitisse vários TGTs de vários reinos. Não precisa ter uma janela GUI como o MIT Kerberos, mas ajuda.

Answer 1

Bem, não vou dizer que isso NÃO PODE ser feito com o Windows, mas direi quea limitação é baseada na sessão. O problema então é que para cada sessão o Windows armazena em cache um ticket. Quando você bloqueia seu computador e depois o desbloqueia, outra sessão é iniciada e uma nova chave é solicitada ao KDC. A mesma coisa acontece quando você faz logoff e logon no computador novamente. Este método também é como as permissões do usuário são determinadas para sessões do servidor,o que significa que a chave/ticket pode ser armazenada em cache para que cada recurso ou sessão do servidor que você iniciar não precise solicitar sua senha, mas nunca ouvi/li/pesquisei sobre ela para poder armazenar em cache mais de uma.

Agora, você provavelmente já sabe que, dado o conhecimento que exibiu em sua pergunta, direi que com base no fato de que o Windows armazena a chave que você obtém quando um TGT é emitido e é baseado em sessão, não acho que é possível com APENAS o Windows. O MIT Kerberos para Windows pode ter uma maneira de iniciar duas sessões sob um usuário, mas mesmo assim, não tenho certeza de como os recursos que você está acessando saberiam qual par de ticket/chave usar. Isso faz sentido?

Consulte isto para obter uma descrição de como o Windows armazena TGTs/pares de chaves.

A propósito, muito boa pergunta.

Answer 2

OK, criei uma solução funcional que precisa de mais polimento, então pode não funcionar em todos os ambientes.

Isso funciona com:

1. Kerberos do MITpara Windows 4.0.1 com ferramentas de suporte do Windows (KSETUP.EXE, KTPASS.EXE)
2. Massa0,63
3. Windows 7 SP1

Eu estava procurando na fonte Kerberos do MIT e me deparei com oLEIA-ME para Windows. De particular interesse foram os diferentes valores paraCache de credenciais. Ele defende um valor padrão deAPI:, mas surpreendentemente encontrei meu registro usandoMSLSA:em vez de.

Eu brinquei com diferentes valores deccnomesob HKEY_CURRENT_USER\Software\MIT\Kerberos5. tenteiMEMÓRIA:no início, o que levou a algum comportamento interessante. Ao abrir uma sessão PuTTY, minha janela do MIT Kerberos Ticket Manager seria restaurada e voltaria ao primeiro plano, solicitando que eu inserisse credenciais. Uau! Isso nunca aconteceu antes, mas, infelizmente, PuTTY rejeitaria. O valor que funcionou para mim foi FILE:C:\Some\Full\File\Path. Não sei exatamente como proteger o acesso ao arquivo especificado, então deixarei isso como exercício para o leitor. Obtive o mesmo comportamento da janela para o primeiro plano, só que PuTTY gostou desta vez. A janela do Ticket Manager também exibiu finalmente os tickets LR e FR. Foi comprovado que os tickets podem ser encaminhados e sobreviveriam a vários bloqueios/desbloqueios do Windows.OBSERVAÇÃO:certifique-se de sair completamente e reiniciar o Ticket Manager entre as edições do registro. Eu não experimentei umccnomedeAPI:ainda.

Não sei se isso faz diferença ou não, mas também brinquei comKSETUPantes que isso começasse a funcionar. A princípio, um KSETUP sem parâmetros apenas me mostraria informações sobre o LR. 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 3

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

Eu encontrei o seguinte:

Se eu usar a opção "obter ticket" na janela do KfW 4.0.1, Just Works(TM); Posso clicar no botão "Obter ingresso" e adquiriradicionalingressos aos ingressos originais que recebi quando fiz logon.

Se eu clicar na opção "tornar padrão" na janela do KfW, a partir desse momento, toda vez que eu clicar em "obter ticket", o novo ticket serásubstituirqualquer ticket é o padrão, em vez de adicionar outra entrada à lista de tickets conhecidos. A verificação do registro nesse ponto mostrará que uma ccnameentrada (como na resposta de Toddius) foi adicionada.Removendoessa 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 de 64 bits, associado a um domínio AD, também executando o MIT Kerberos para Windows 4.0.1): Sua cópia do Kerberos Ticket Manager seria permitir que ele tenha apenas um diretor/um TGT. Sempre que ele usasse o botão “Obter Ticket” para obter um TGT para um principal diferente, o principal anterior desapareceria.

Eu revisei oLeia-me, e a maioria das chaves de registro foram definidas conforme o esperado,excetopara occnomechave no caminho HKEY_CURRENT_USER\Software\MIT\Kerberos5. Essa chave foi definida com o valor MSLSA:. Nossa solução foi mudar isso para API:. Mais especificamente, as etapas foram:

1. Saia do Kerberos Ticket Manager, juntamente com todos os outros aplicativos (já que você irá reiniciar).
2. Em Caminho do registro HKEY_CURRENT_USER\Software\MIT\Kerberos5, altere occnomechave para API:(API, 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 seu principal não AD.

Com as etapas acima, tudo funcionou e meu colega de trabalho agora pode ver vários principais/TGTs de uma só vez.

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 vários caches de credenciais. No meu sistema de 64 bits, quando executo "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"após obter vários TGTs, vejo meu principal do Active Directory no cache MSLSA e, em seguida, tenho um cache de API para cada principal adicional.

PS Esta é minha primeira entrada neste site, então não consegui adicioná-la como comentário à resposta de Toddius. Desculpas!