Bom dia a todos,

Como referi recentemente, tenho andado ocupado andado a migrar as aplicações e serviços que tenho em execução no meu homelab, para uma filosofia de autenticação centralizada, desde aplicações com .htaccess em apache, a acessos openvpn / ipsec, passado por IOT’s que suportem LDAPs ou Kerberos para autenticação.

Uma das que configurei, foi precisamente uma das minhas instâncias de Nextcloud – num post futuro falaremos de adicionar 2FA a ela – que dá suporte de cloud files a minha família.
Ao efetuar isto, passei principalmente a ter a vantagem de ter uma autenticação centralizada – deixou de ser tema um acesso funcionar no webmail, mas não funcionar no nextcloud – a somar com a possibilidade de um self care de credenciais para quem esteja na rede interna segura da minha casa.

O processo tem vários passos, sendo que em primeiro lugar é necessário adicionar a máquina que corre o processo apache e que serve o nextcloud a um FreeIPA.
Caso isto não seja possível, ou nenhum cliente de enrolment para essa distro esteja disponível, será então necessário adicionar ao trust de CA’s do servidor em questão, o CA o FreeIPA:

 

 

Para Red Hat / CentOS ou derivados:

wget -O /tmp/ca.crt http://ipaserver.net.xpto/ipa/config/ca.crt
openssl x509 -in /tmp/ca.crt -out /etc/pki/trust/anchors/CA.net.xpto.pem -outform PEM
update-ca-certificates

ou para SuSE:

wget -O /tmp/ca.crt http://ipaserver.net.xpto/ipa/config/ca.crt
openssl x509 -in /tmp/ca.crt -out /etc/pki/trust/anchors/CA.net.xpto.pem -outform PEM
update-ca-certificates

Em seguida, será necessário dizer ao apache onde encontrar os certificados para comunicação segura com o nosso servidor IPA/LDAPS.
Isto consegue-se através da adição de um novo ca.ldap.conf file dentro da estrutura de conf.d do apache.

LDAPTrustedGlobalCert CERT_BASE64 /etc/pki/ca-trust/source/anchors/CA.net.xpto.pem
LDAPVerifyServerCert on
LDAPTrustedMode SSL

Em seguida, e estou a assumir que já tenham o Nextcloud configurado, é altura de ativar o plugin de autenticação centralizada (secção apps) e aceder ao menu de configuração :

Lá dentro, no primeiro campo é necessário configurar o servidor ou servidores LDAP. No meu caso, prefiro usar um balanceador TCP sem SSL offload por questões de gosto pessoal.

No primeiro campo, colocamos a descrição que queremos dar ao nosso servidor. Na linha de baixo, o FQDN dele, e a porta onde ele está a escuta. Se usarem SSL, o que é o meu caso, tem de indicar a porta SSL do LDAPS do FreeIPA.
Nota: É mandatório fazer a configuração do passo anterior de adicionar a CA do FreeIPA como uma CA valida ao apache.

Em seguida, será necessário colocar um bind user que tem de existir no vosso FreeIPA para validar a autenticação. No campo seguinte será a password do vosso utilizador de bind.
É recomendável que tenha um bind user por aplicação que autentique no IPA, por questões de segurança. desaprovisionamento ou lockdown caso seja necessário.
Após isto, é altura de configurar o base DN. Tipicamente basta colocar o base até ao DC, mas para não deixar a aplicação viajar na maionese, tranquei ela dentro de um grupo (o grupo tem de existir e ser válido).

cn=nextcloud_group,cn=groups,cn=accounts,dc=net,dc=xpto

Passamos então para o tab seguinte (users) para continuar a nossa configuração:

Nesta tab iremos configurar quais os utilizadores tem acesso ao Nextcloud.
Por exemplo, os meus familiares podem aceder a sites que tenho com fotografias familiares usando a sua autenticação pessoal, mas não vão conseguir aceder ao nextcloud, nem criar conta no mesmo.
Isto consegue-se construindo uma sintaxe ldap relativamente simples:

(&(objectclass=*)(memberof=nextcloud_group,cn=groups,cn=accounts,dc=net,dc=xpto))

Para o exemplo acima, todos os utilizadores tem de estar no grupo nextcloud_group para se conseguirem autenticar. Se não estiverem, o nextcloud irá devolver uma mensagem de password errada.

Em seguida será a vez de configurar a tab Login Atributes, que irá indicar ao Nextcloud quais das referencias será usada como login para o nosso processo de autenticação:

A query é simples e utilizando os mesmos nomes da tab anterior temos:

(&(objectclass=*)(memberof=cn=nextcloud_group,cn=groups,cn=accounts,dc=net,dc=xpto)(uid=%uid))

Chegamos finalmente a ultima tab, a de groups:
Nesta tab iremos configurar os grupos e nested groups que irão agrupar apenas dentro do nextcloud, por exemplo filhos, pais, todos, etc.

 

Usando novamente a nomenclatura anterior usei:

(cn=nextcloud_group_nested)

Após esta configuração já deveremos conseguir efetuar testes de autenticação.
Em todas as tabs existem campos de verificação e teste. Caso tudo esteja bem, o icon irá ser mostrado a verde, mas efetuem os testes quando tiverem todos os campos partilhados.

Cuidados especiais incluem a atenção típica ao vosso bind user pois sem ele toda a autenticação irá parar, e caso a vossa instância seja partilhada entre várias pessoas que não querem que saibam que estão a partilhar o mesmo espaço, recomendo ir á  secção de admin, sharing e em seguida desativar o seguinte campo:

Isto porque o search users irá procurar dentro do vosso base DN por utilizadores e mostrar eles todos. Assim, com este campo desativado terão de escrever o username á mão quando quiserem fazer uma partilha, mas em contrapartida, só conseguem achar alguém se souberem mesmo o seu username dentro do nexcloud.
Isto é debatido neste link caso queiram ler mais em como apertar ainda mais a malha.
Finalmente, quando utilizarem esta configuração, utilizadores que não foram provisionados via o processo tradicional, usando apenas a autenticação centralizada do nextcloud, ou seja utilizadores IPA que estão no grupo que escolheram e que tenham acedido diretamente, no filesystem, a sua home será o ipaUniqueID e não o username como habitualmente.

Caso tenham duvidas, sabem onde me encontrar.

Até ao próximo post, onde irei mostrar como configurar autenticação 2FA no Nextcloud.

Um abraço!
Nuno