Linux SSO para vários domínios do Windows

Question

Implementei com êxito o SSO no apache para usuários do Windows no mesmo domínio do AD em que o servidor apache está: Domínio do AD = example.com Servidor Linux = linux.example.com KDC = ad.example.com

Eu configurei o KrbLocalUserMapping como ON no httpd.conf, já que o aplicativo no qual os usuários estão se conectando precisa da parte @ example.com do nome de usuário a ser removido.

Agora, quero permitir que os usuários das filiais também façam login no aplicativo, mas eles vêm de um domínio diferente = branches.example.com. Ambos os domínios estão em um relacionamento confiável.

Quando os usuários de branches.example.com tentam fazer o login, recebem "Internal Server Error" e o log de erros do apache diz "Krb5_aname_to_localname () não encontrou nenhum mapeamento para o usuário [email protected]"

Meu palpite é que os usuários provenientes do subdomínio branches.example.com não estão retirando a parte do domínio do nome de usuário.

O que eu preciso mudar e onde (provavelmente krb5.conf?). Preciso gerar um keytab separado para o subdomínio branches?

Além disso, como é um servidor de produção que não posso reiniciar arbitrariamente, quais serviços eu preciso reiniciar depois de alterar as coisas no krb5.conf?

    

Answer 1

Acabei de acertar o mesmo problema que você e, graças a este tópico aqui, encontrei a resposta!

Depois de ativar um segundo domínio (confiável) em minhas configurações de mod_auth_kerb e colocar as coisas certas no keytab, se eu tentasse entrar com um usuário do segundo domínio, eu estava recebendo erros no log do httpd como :

[auth_kerb:notice] [pid 1234] [client X.X.X.X:12345] krb5_aname_to_localname() found no mapping for principal [email protected]

A boa notícia é que resolvi! Detalhes abaixo ...

Em primeiro lugar, na sua configuração do Apache HTTPD, você quer algo como:

# Use this one for both Examples and Branches together
KrbAuthRealms EXAMPLE.COM BRANCHES.EXAMPLE.COM

# Strip the realm from the username
KrbLocalUserMapping On

Isso indica ao mod_auth_kerb para aceitar usuários do domínio do domínio principal ou dos ramos um e remover o domínio do nome de usuário. Isso significa que [email protected] vai para o administrador, enquanto [email protected] vai para guest

Em seguida, assumindo os kerberos do MIT, você precisa editar seu arquivo /etc/krb5.conf e dizer como mapear os principais em nomes de usuários. Por vários motivos históricos, isso não é feito em uma seção libdefaults , como você poderia esperar. Também não é feito em uma seção por realm, que me pegou. Em vez disso, é feito com auth_to_local entradas na seção [realm] da região padrão.

Por padrão, a função krb5_aname_to_localname() libkrb5 removerá a região da região padrão e a deixará lá de outra forma. Então, nós temos que adicionar uma entrada para dizer para tirar o reino do reino dos ramos também. (Regras mais complexas também são possíveis, veja a página krb5.conf man para mais)

Então, queremos que nossa configuração seja algo assim:

[libdefaults]
  default_realm = EXAMPLE.COM

[realms]
   EXAMPLE.COM = {
     kdc = dc.example.com
     admin_server = dc.example.com
     auth_to_local = RULE:[1:$1@$0](^.*@BRANCHES\.EXAMPLE\.COM)s/@.*//
     auth_to_local = DEFAULT
   }
   BRANCHES.EXAMPLE.COM = {
     kdc = dc.branches.example.com
     admin_server = dc.branches.example.com
   }

Observe como a regra de mapeamento BRANCHES.EXAMPLE.COM não reside em seu território, mas no principal EXAMPLE.COM realm, que é o domínio padrão.

Also, since it is a production server which I cannot arbitrarily restart, what services do i need to restart after changing things in the krb5.conf?

Apenas o serviço HTTPD do Apache precisa ser reiniciado após as alterações