Use um nome de usuário preferido, mas autentique-se contra o principal do Kerberos

3

O que desejo fazer deve ser bem simples.

Eu tenho uma caixa do Ubuntu 10.04. Está atualmente configurado para autenticar usuários em um território do kerberos (EXAMPLE.ORG). Existe apenas um reino no arquivo krb5.conf e é o reino padrão.

[libdefaults]
    default_realm = EXAMPLE.ORG

O PAM é configurado para usar o módulo pam_krb5, portanto, se uma conta de usuário for criada na máquina local e esse nome de usuário corresponder à credencial [email protected], esse usuário poderá efetuar login fornecendo sua senha kerberos.

O que eu gostaria de fazer, em vez disso, é criar uma conta de usuário local com um nome de usuário diferente

Por exemplo, o principal do kerberos é [email protected] . Eu gostaria de criar a conta local preferred.name e de alguma forma configurar o kerberos que quando alguém tenta efetuar login como preferred.name , ele usa o principal [email protected] .

Eu tentei usar o auth_to_local_names no krb5.conf, mas isso não parece funcionar.

[realms]
    EXAMPLE.ORG = {
            auth_to_local_names = {
                    full.name = preferred.name
            }

Eu tentei adicionar [email protected] a ~ preferred.name / .k5login.

Em todos os casos, quando tento efetuar login como preferred.name@host e insiro a senha para full.name, obtenho acesso negado.

Eu até tentei usar auth_to_local no krb5.conf, mas não consegui acertar a sintaxe.

É possível ter um nome de usuário local (distinto) que, para todos os propósitos, se comporta exatamente como um nome de usuário correspondente? Se sim, como isso é feito?

    
por Jason R. Coombs 17.12.2010 / 16:33

1 resposta

4

Eu percebi isso. Não precisei usar auth_to_local. Eu poderia usar .k5login no diretório pessoal do usuário. Primeiro,

cat > ~preferred.name/.k5login
[email protected]

Depois, tive que configurar o PAM para honrar o .k5login. Em /etc/pam.d/common-auth, onde eu localizo auth sufficient pam_krb5.so , anexe a opção search_k5login .

A partir de então, qualquer tentativa de login como preferred.name aceitará a senha para [email protected].

    
por 24.12.2010 / 19:04

Tags