LDAP syncrepl com autenticação kerberos

Question

Estou tentando configurar um servidor de replicação para LDAP usando o syncrepl. Eu gostaria de usar o Kerberos para autenticar o consumidor, porque ele está configurado e parece mais seguro. As definições do banco de dados para meu provedor e consumidor estão abaixo.

Quando inicio o consumidor, recebo este erro:

GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information 
(Credentials cache file '/tmp/krb5cc_55' not found)

Acho que isso significa que o consumidor não tem um TGT válido. Como faço para configurar o consumidor para obter um TGT válido? Eu li algumas fontes antigas que recomendam o uso do k5start ou de um cron job. Ainda é este o caminho para o fazer?

As páginas de manual do slapd.conf informam que authcid e authzid podem ser usadas em conjunto com bindmethod=sasl , mas não especifica como devem ser formatadas. Devo colocar um DN aqui ou um kerberos principal ou talvez outra coisa? Preciso especificar isso?

Obrigado pela sua ajuda

Configuração do consumidor:

database        bdb
suffix          "dc=example"
rootdn          "uid=someuser,cn=realm,cn=gssapi,cn=auth"
directory       /var/lib/ldap
dirtyread
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncrepl rid=1
    provider=ldap://provider.realm
    type=refreshAndPersist
    starttls=yes
    searchbase="dc=example"
    schemachecking=off
    bindmethod=sasl
    saslmech=gssapi
    retry="10 +"

Configuração do provedor

database        bdb
suffix          "dc=example"
rootdn          "uid=someuser,cn=realm,cn=gssapi,cn=auth"
directory       /var/lib/ldap
dirtyread
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

    

Answer 1

Eu obtive o syncrepl com a autenticação do kerberos, trabalhando com a seguinte configuração. Este site sobre o nslcd.conf diz que authzid deve estar no formato "dn: < nome distinto > ou "u: < nome do usuário >". Também usei o k5start para criar um arquivo de cache para someuser@REALM at /tmp/krb5cc_55 e fiz chown ldap:ldap . Note que 55 é o ldap uid; no entanto, não tenho certeza se é necessário nomear o arquivo para isso. Na configuração do meu provedor, eu especifiquei someuser como rootdn para permitir que ele tivesse acesso ao banco de dados inteiro.

Eu só quero esclarecer que isso é o que funcionou para mim, mas eu tenho uma compreensão limitada do ldap, então não posso garantir que funcionará em outro lugar, e não sei se tudo nesta configuração é necessário.

syncrepl rid=1
    provider=ldap://provider.realm
    type=refreshAndPersist
    starttls=yes
    searchbase="dc=realm"
    schemachecking=off
    retry="10 +"
    tls_cacert="/path/to/ca.crt"
    bindmethod=sasl
    saslmech=gssapi
    authcid="someuser@REALM"
    authzid="uid=someuser,cn=realm,cn=gssapi,cn=auth"

    

Answer 2

I think this means that the consumer doesn't have a valid TGT.

Sim, é exatamente isso o que significa.

How do I configure the consumer to get a valid TGT? I've read some older sources that recommend using k5start or a cron job. Is this still the way to do it?

Em geral, o cron ou o k5start ainda é o método principal.

No entanto, o mais recente MIT Kerberos suporta um método interno chamado iniciação keytab do cliente , que é muito mais simples para configurar: basta adicionar $KRB5_CLIENT_KTNAME ao ambiente do slapd e apontá-lo no mesmo arquivo que $KRB5_KTNAME . (Isto é supondo que você tenha um keytab separado para ldap/* . Você deveria.)

The slapd.conf manual pages state that authcid and authzid can be used in conjunction with bindmethod=sasl, but it doesn't specify how these should be formatted. Should I put a DN here or a kerberos principal or maybe something else? Do I need to specify these?

Não consigo lembrar qual finalidade a authcid atende com GSSAPI (se houver alguma) - IIRC, esse mecanismo usa automaticamente a identidade determinada pelo ticket, portanto, não é necessário especificá-lo manualmente .

No lado de aceitação, o slapd converterá o principal Kerberos recebido em um pseudo-DN como uid=foo@realm,cn=gssapi,cn=auth , e você poderá usá-lo diretamente nas ACLs ou usar authz-regexp (< em> olcAuthzRegexp ) para traduzi-lo para um DN mais agradável.

Enquanto isso, o authzid funciona da mesma maneira, independente do mecanismo. É opcional, mas se você especificá-lo, deve ser um DN prefixado com dn: ou um nome de usuário com prefixo u: . (Nomes de usuários aqui, como authcids, são convertidos em um pseudo-DN e passam por olcAuthzRegexp , e o DN resultante é usado.)

Se as políticas permitirem, o slapd concederá a você os privilégios que o authzid possui. (É como sudo para LDAP.)