Autenticando o Windows 7 contra o MIT Kerberos 5

5

Eu tenho quebrado meu cérebro tentando fazer com que o Windows 7 se autentique contra um MIT Kerberos 5 Realm (que está sendo executado em um servidor Arch Linux).

Eu fiz o seguinte no servidor (também conhecido como dc1):

  • Instalou e configurou um servidor de horário NTP
  • DHCP e DNS instalados e configurados (configuração para o domínio tnet.loc)
  • Kerberos instalados da origem
  • Configure o banco de dados
  • Configurou o keytab
  • Configure o arquivo ACL com: * @ TNET.LOC *
  • Adicionada uma política para meu usuário e minha máquina:
addpol users
addpol admin
addpol hosts
ank -policy users [email protected]
ank -policy admin tom/[email protected]
ank -policy hosts host/wdesk3.tnet.loc -pw MYPASSWORDHERE

Em seguida, fiz o seguinte para o cliente do windows 7 (também conhecido como wdesk3):

  • Verifiquei se o endereço IP foi fornecido pelo meu servidor DHCP e pings dc1.tnet.loc ok
  • Defina o servidor de horário da internet para meu servidor linux (também conhecido como dc1.tnet.loc)
  • Usou o ksetup para configurar a região:
ksetup /SetRealm TNET.LOC
ksetup /AddKdc dc1.tnet.loc
ksetip /SetComputerPassword MYPASSWORDHERE
ksetip /MapUser * *
  • Depois de algumas pesquisas, descobri que a criptografia DES foi desativada pelo Windows 7 por padrão e liguei a política para oferecer suporte à criptografia DES sobre o Kerberos
  • Depois, reiniciei o cliente do Windows

No entanto, depois de fazer tudo isso, ainda não consigo fazer login no meu cliente Windows. : (

Olhando para os logs no servidor; o pedido parece bem e tudo funciona muito bem, eu acho que o problema é que a resposta do KDC não é reconhecida pelo cliente Windows e aparece um erro genérico de login: "Falha de login: nome de usuário ou senha é inválida".

O arquivo de log do servidor se parece com isso (eu fiz o tail, então sei que está acontecendo quando a máquina do Windows tenta fazer o login): Captura de tela: link

Se eu fornecer um domínio inválido na janela de login, recebo uma mensagem de erro completamente diferente, então não acho que seja um problema de conexão do cliente para o servidor? Mas não consigo encontrar nenhum log de erro na máquina do Windows? (alguém sabe onde eles estão?)

Se eu tentar: runas / netonly /user:[email protected] cmd.exe tudo funciona (embora eu não consiga nada aparecer nos logs do servidor, então estou me perguntando se não está tocando o servidor para isso ??), mas se eu executar: runas /user:[email protected] cmd.exe recebo o mesmo erro de autenticação.

Quaisquer gurus do Kerberos que possam me dar algumas idéias sobre o que tentar em seguida? por favor, por favor?

    
por tommed 06.04.2010 / 20:20

4 respostas

3

Confira pGina . Não tem um plugin do Kerberos, então você terá que escrever um. Alternativamente, você pode usar o OpenLDAP como proxy e usar o plugin pGina LDAP.

    
por 02.05.2010 / 20:15
2

Aparentemente, o AD é absolutamente necessário se você tiver clientes Windows, pois os clientes Windows exigem uma pequena extensão para o ticket Kerberos padrão que o AD anexa.

O MIT Kerberos Server não pode autenticar clientes Windows por conta própria no momento.

(Informação recuperada no Newsgroup MIT Kerberos)

    
por 07.04.2010 / 13:43
1

@jyvenard - o que o mais provável que acabamos fazendo foi usar o SSH ou algum outro método para autenticar sua caixa. Se ele usou SSH (o que eu provavelmente faria nessa circunstância), então ele provavelmente tem o host que ele autenticou contra o uso de kerberos.

Em um método como este:

[cliente] --ssh - > [host] --pam suporte para ssh - > [Servidor KDC]

[cliente] < - ssh-- [host] < - sucesso ou falha-- [servidor KDC]

Isso usa o kerberos para autenticar o usuário em seu sistema cliente tentando ssh em um host que tenta verificar suas credenciais em relação a um KDC, mas um ticket do kerberos nunca é realmente adquirido pelo cliente, apenas um sucesso ou falha no sessão ssh.

    
por 09.12.2010 / 18:45
0

É possível, mas como o documento abaixo indica, você precisará mapear os usuários locais para os kerberos pricipals.

Suponho que alguma forma de script de login possa ser usada para fazer isso dinamicamente. O login no Windows é um processo separado. pGina pode ajudar com isso, como indicado por ptman.

Usando um KDC MIT com uma estação de trabalho Windows 2000 autônoma

Para que a estação de trabalho Windows 2000 use um Kerberos KDC, você deve configurar o servidor Kerberos KDC e a estação de trabalho, conforme descrito a seguir.

Para configurar o servidor Kerberos KDC e a estação de trabalho do Windows 2000

  1. Execute o utilitário Ksetup para configurar o servidor e a região do Kerberos KDC (para obter detalhes, consulte a seção Ksetup mais adiante neste documento).

    • Na região do Kerberos, crie uma entidade principal para o computador. Use o comando:

    Kadmin q "senha pw ank host / machine-name.dns-domain_name"

    Por exemplo, se o nome da estação de trabalho do Windows 2000 for W2KW e o nome da região do Kerberos for REALM.RESKIT.COM, o nome principal será host / w2kw.realm.reskit.com.

    O Kadmin é um utilitário que faz parte da distribuição do MIT Kerberos.

    • Como uma região do Kerberos não é um domínio do Windows 2000, o computador deve ser configurado como membro de um grupo de trabalho. Isso é automático quando você define o domínio Kerberos e adiciona um servidor KDC da seguinte forma:
    C:> Ksetup /setdomain REALM.RESKIT.COM
    C:> Ksetup /addkdc REALM.RESKIT.COM kdc.realm.reskit.com
    • Defina a senha da conta da máquina local, da seguinte maneira:
    C:> Ksetup /setmachpassword password
  2. Reinicie o computador para que as alterações entrem em vigor. (Esta é uma etapa obrigatória.) Sempre que forem feitas alterações na configuração externa do KDC e do território, será necessário reiniciar o sistema.

  3. Use Ksetup para configurar o logon único em contas de estações de trabalho locais. Definir os mapeamentos de conta; isso mapeará contas de máquinas locais para os principais do Kerberos. Por exemplo:

    C:> Ksetup /mapuser [email protected] guest C:> Ksetup /mapuser * *

    Observe que o segundo comando mapeia clientes para contas locais com o mesmo nome.

  4. Use Ksetup sem argumentos para ver as configurações atuais. (Observe que o servidor KDC [s] não é mostrado.)

por 07.06.2013 / 00:24