Configurando o arquivo krb5.conf do Kerberos para manipular o domínio 'clonado' primário e secundário

Question

(Prefácio do newbie obrigatório: nunca joguei muito com o Kerberos, então me trate gentilmente aqui!)

Temos dois domínios foo.local e .test .

.test foi clonado de foo.local e, uma vez conectado a um servidor dentro de .test , o domínio acha que é o domínio foo.local .

por exemplo. myserver.foo.local tem um endereço IP 10.250.20.10 e myserver.test tem um endereço IP 10. 253 .20.10 quando dentro da foo.local domain, mas se vê como 10.250.20.10 quando está dentro do domínio .test .

Além disso, myserver.foo.local pode alcançar myserver.test , mas o oposto não é verdadeiro.

Além disso, myserver.foo.local ao entrar em myothersever.foo.local realmente atinge um servidor que está dentro do domínio foo.local , mas quando myserver.test se conecta a myotherserver.foo.local , fica preso dentro do domínio .test .

Isso tudo dito, aqui está o meu arquivo /etc/krb5.conf (que eu estou mais do que feliz em saber que está mal configurado):

[libdefaults]
  default_realm = FOO.LOCAL

[realms]
    FOO.LOCAL = {
        kdc = foo-dc01.foo.local
    }

    TEST = {
        kdc = foo-dc02.test
    }

A vida é boa quando se conecta a servidores dentro de foo.local e, na verdade, meu kinit funciona como um tratamento. Test nem tanto.

myLogin$ kinit -V  mylogin@test
mylogin@test's password: 
kinit: krb5_get_init_creds: unable to reach any KDC in realm test, tried 0 KDCs

Então, perguntas:

1) Quais etapas estou faltando para autenticar no domínio de teste - como eu configuro o kinit para usar o servidor de domínio foo-dc02.test para autenticar (ou mesmo, se meu LoginId e senha do Windows são os mesmos? )?

2) Uma vez feito, como eu asseguro que ao se conectar ao myserver.test ele use o token derivado do kinit mylogin@test ao tentar uma conexão?

Informações do sistema: Todos os servidores do AD são Windows, agora meus testes POC são do meu MacBook, mas os clientes que executam no Windows, Macs e Linux precisarão trabalhar eventualmente.

    

Answer 1

e.g. myserver.foo.local has an IP address of 10.250.20.10 and myserver.test has an IP address of 10.253.20.10 when inside the foo.local domain, but sees itself as 10.250.20.10 when inside the .test domain.

O endereçamento é geralmente irrelevante para o Kerberos, contanto que os clientes possam resolver os nomes DNS e falar com os servidores (enviar / receber pacotes IP).

myLogin$ kinit -V mylogin@test
mylogin@test's password:
kinit: krb5_get_init_creds: unable to reach any KDC in realm test, tried 0 KDCs

Você está tentando autenticar no test realm. Para o Kerberos, isso não é o mesmo que o TEST realm que você tem em krb5.conf - ao contrário dos domínios DNS ou domínios do AD, um nome de território Kerberos faz distinção entre maiúsculas e minúsculas.

Como o minúsculo test realm não está em [reinos] em seu krb5.conf, kinit usa outros métodos para localizar o servidor KDC - ele procura por registros SRV _kerberos._udp.<realm> do DNS após a conversão o reino de volta para um domínio DNS.

Por exemplo, quando você estiver fazendo a autenticação em relação a …@test ou …@TEST e não houver uma subseção [reinos] correspondente, você precisará de registros SRV em _kerberos._udp.test no mínimo. (O Active Directory deve adicioná-los automaticamente.)

Use kinit mylogin@TEST com o caso correto ou ajuste a configuração [realms] ou verifique se há registros SRV no seu domínio test DNS apontando para o controlador de domínio.

(Além disso: Se você optar por usar o kinit mylogin@test minúsculo, os KDCs do Active Directory reconhecerão o formato minúsculo, mas os tickets retornados terão o reino em maiúsculas canônicas e a maioria das versões kinit rejeitará o resposta incompatível. Você permitirá a canonização usando kinit -C .)

Se o seu software cliente for o MIT Krb5, use export KRB5_TRACE=/dev/stderr para obter mais informações sobre o que exatamente ele está fazendo. (macOS provavelmente usa Heimdal embora.)

2) Once done, how do I ensure that when connecting to myserver.test it uses the token derived from the kinit mylogin@test when attempting a connection?

Verifique qual tipo de cache de credenciais está sendo usado (como mostrado por klist em "Cache de ticket" ou definido na variável de ambiente $ KRB5CCNAME).

O cache de credenciais "FILE:" tradicional só pode ter tickets para um principal de cliente em primeiro lugar. Se você kinit como mylogin @ TEST, você sempre estará usando tickets para mylogin @ TEST. Nesse caso, você terá que alternar manualmente entre diferentes caches, configurando $ KRB5CCNAME para diferentes caminhos.

$ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_prod" && kinit user@PROD && klist
$ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_test" && kinit user@TEST && klist

$ kset() { export KRB5CCNAME="FILE:/tmp/krb5cc_$(id -u)_$1"; }
$ kset prod && kinit user@PROD && klist

Ao usar o MIT Krb5, as caches de credenciais "DIR:" e (no Linux) "KEYRING:" suportam vários princípios de cliente de uma só vez. Você pode simplesmente copiar várias vezes, depois alternar a entidade 'ativa' usando kswitch ou até definir regras personalizadas no arquivo ~/.k5identity (man 5 k5identity).

Infelizmente, alguns programas importantes (como o smbclient ou o Apache Directory Studio) não entendem caches "DIR:" ainda (ou qualquer coisa exceto FILE: na verdade).

Ao usar o macOS, o mesmo que acima se aplica, mas acredito que o tipo de cache de credencial padrão seja "KCM:", o que pode provavelmente conter vários princípios do cliente. Ou talvez não ¯ \ _ (ツ) _ / ¯

O Windows funciona de maneira diferente; o cache do ticket é strongmente ligado à sua sessão de login e (novamente) suporta apenas um principal do cliente. Para iniciar programas como outro principal sem um logout / login completo, use runas /netonly :

runas /netonly /user:mylogin@test cmd