☰

Sincrepl LDAP com autenticação Kerberos

tag-icon • tag-icon ldap replication openldap kerberos
Sincrepl LDAP com autenticação Kerberos

Estou tentando configurar um servidor de replicação para LDAP usando o syncrepl. Gostaria de usar o Kerberos para autenticar o consumidor, porque temos ele configurado e parece mais seguro. As definições de 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 configuro o consumidor para obter um TGT válido? Eu li algumas fontes mais antigas que recomendam o uso do k5start ou de um cron job. Essa ainda é a maneira de fazer isso?

As páginas de manual do slapd.conf afirmam que authcide authzidpodem ser usadas em conjunto com bindmethod=sasl, mas não especificam como elas devem ser formatadas. Devo colocar um DN aqui ou um principal Kerberos ou talvez outra coisa? Preciso especificá-los?

obrigado pela 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

Responder1

Acho que isso significa que o consumidor não tem um TGT válido.

Sim, é exatamente isso que significa.

Como configuro o consumidor para obter um TGT válido? Eu li algumas fontes mais antigas que recomendam o uso do k5start ou de um cron job. Essa ainda é a maneira de fazer isso?

Não tenho certeza sobre o cron, mas o k5start ainda é um bom método.

Mas o recente Kerberos do MIT suporta um método integrado chamadoiniciação do keytab do cliente, que é muito mais simples de configurar: basta adicionar $KRB5_CLIENT_KTNAMEao ambiente do slapd e apontar para o mesmo arquivo que $KRB5_KTNAME. (Isso pressupõe que você tenha um keytab separado para ldap/*. Você deveria.)

E finalmente você pode dizer ao slapd para usar o gss-proxy, que é como o ssh-agent para Kerberos. Defina GSS_USE_PROXY=1e configure /etc/gssproxy para reconhecer o slapd como iniciador (cliente) e aceitador (servidor).

As páginas de manual do slapd.conf afirmam que authcid e authzid podem ser usados ​​em conjunto com bindmethod=sasl, mas não especifica como eles devem ser formatados. Devo colocar um DN aqui ou um principal Kerberos ou talvez outra coisa? Preciso especificá-los?

Não me lembro qual o propósito doautcidserve com GSSAPI (se houver) – IIRC, esse mecanismo usa automaticamente a identidade determinada em seu ticket, portanto não há necessidade de especificá-la manualmente.

Do lado da 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 usarauthz-regexp(também conhecido comoolcAuthzRegexp) para traduzi-lo para um DN melhor.

Enquanto isso,autorizadofunciona da mesma maneira independente do mecanismo. É opcional, mas se você especificá-lo, deverá ser um DN prefixado com dn:ou um nome de usuário prefixado com u:. (Os nomes de usuário aqui, como authcids, são convertidos em um pseudo-DN e passam porolcAuthzRegexp, 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.)

Responder2

Consegui o syncrepl com autenticação Kerberos trabalhando com a seguinte configuração.Esse sitesobre nslcd.conf diz que authziddeve ter o formato "dn:<nome distinto>" ou "u:<nome de usuário>". Também usei o k5start para criar um arquivo de cache para someuser@REALMat /tmp/krb5cc_55e o fiz chown ldap:ldap. Observe que 55 é o ldap uid; no entanto, não tenho certeza se é necessário nomear o arquivo assim. Na configuração do meu provedor, especifiquei someusercomo rootdnpara permitir que ele tenha acesso a todo o banco de dados.

Só quero esclarecer que foi isso que funcionou para mim, mas tenho um conhecimento limitado de 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"

informação relacionada