NFSv4 + SSSD + Diretório ativo: permissões 'nobody' quando ldap_id_mapping desativado

1

Eu estou tentando configurar o NFSv4 com autenticação KRB5 de acordo com a recomendações atuais , usando o SSSD para acessar o Active Directory. O servidor NFS, nesse caso, é um dispositivo NAS, que manipula o mapeamento de usuários entre contas de usuário @ domínio e UIDs / GIDs extraídos do AD / LDS. Desativei o mapeamento de ID no SSSD, pois o NAS não possui o mesmo método hash + modulus disponível para calcular IDs "caseiros".

Em seu estado atual, o NAS reconhece a propriedade do usuário e do grupo para permissões de arquivo e as aplica conforme o esperado. No entanto, ls output do cliente exibe nobody nobody em quaisquer arquivos / pastas pertencentes a um usuário de domínio.

[root@nfsclient ~]# ls -al /mnt/nfs4test/
total 0
drwxr-xr-x. 1 nobody nobody  0 Jul 17 10:46 .
drwxr-xr-x. 3 root   root   22 Jul 17 10:47 ..

Com o detalhamento de logging maxed para idmapd e sssd, o único evento que vi indicando qualquer problema é: Jul 17 11:48:23 nfsclient nfsidmap[10601]: nss_getpwnam: name 'nfsadmin' not found in domain 'testdomain.local'

Também confirmei por meio da captura de pacote que as strings de nome de usuário / grupo esperadas estão sendo retornadas para proprietário e grupo (não IDs) na resposta de pesquisa:

fattr4_owner: [email protected]
fattr4_owner_group: Domain [email protected]

O ambiente consiste em um cliente 2012R2 DC, CentOS 7.3 e um dispositivo NAS proprietário de fornecedor (baseado em CentOS) que atua como servidor. Além de instalar pacotes de requisitos e configuração de IP / NTP, estas são as etapas de configuração no cliente:

  • Adicione Domain = testdomain.local ao /etc/idmapd.conf
  • Inscreva-se no domínio do AD com realm join testdomain.local -U nfsadmin
  • Permitir o acesso SSH de todos os usuários do domínio (permitir domínio)
  • Defina ldap_id_mapping = False em /etc/sssd/sssd.conf
  • Ativar / iniciar / reiniciar sssd.service rpcgssd rpcidmapd e nfs-secure
  • Monte a exportação com sec=sys para alterar a propriedade para o usuário do domínio
  • Montar novamente com sec = krb5

Se você usa sec = sys ou sec = krb5, raiz ou uma conta de domínio, a saída ls é a mesma.

As únicas soluções aplicáveis que encontrei na minha pesquisa apontaram para a necessidade de criar contas locais para os usuários, mas parece que isso iria frustrar o propósito da integração do AD. Eu esperaria que fosse possível criar um novo usuário do AD, adicioná-los aos grupos apropriados para permissões de acesso, definir o UID / GID, então esse usuário deveria poder acessar os arquivos na exportação assim que eles tivessem SSH para o máquina cliente.

A configuração do cliente está apenas obtendo dados do Active Directory (somente o servidor / NAS utiliza AD / LDS). UIDs / GIDs no diretório ativo foram preenchidos manualmente por meio do PowerShell (por exemplo, Get-ADUser "nfsadmin" | Set-AdUser -replace @{uidNumber=10001} - tentando tornar este 2016 compatível e evitar o uso de adminui / nis ou da guia Atributos do UNIX, embora eu esteja testando no 2012R2 no momento)

Como posso obter o NSS / nfsidmap para traduzir corretamente nomes de usuários / grupos de domínio retornados pelo servidor?

Eu preferiria strongmente algo que não envolva a criação manual de contas locais para cada usuário individual, de modo que escalar para milhares de usuários não se torna uma grande dor. Além disso, forçar o servidor (dispositivo NAS nesta instância) a retornar IDs em vez de nomes não é possível.

    
por JimNim 17.07.2017 / 20:48

1 resposta

0

idmapd estava usando o nsswitch como padrão neste caso, mas os métodos de integração do AD detalhados no documento mencionado acima não têm referência a nenhuma modificação do idmapd.conf.

Comentários no estado idmapd.conf "Os métodos distribuídos incluem nsswitch, umich_ldap e static." Esta não é uma lista abrangente de plugins no entanto, e serviços de segurança do sistema (sss) devem ser usados neste caso.

/etc/idmapd.conf:

[General]
Domain = testdomain.local

[Translation]
Method = sss

Isso ficou claro para mim quando percebi que sss estava lidando perfeitamente com mapeamento quando o ldap_id_mapping ainda estava habilitado (mas causando problemas de mapeamento no servidor com o dispositivo NAS), e o erro "não foi encontrado no domínio" estava sendo relatado por nss_getpwnam.

Ainda não estou claro por que o NSS não conseguiu realizar o trabalho quando sss é um dos bancos de dados listados para passwd e group em nsswitch.conf, mas a alteração acima faz o trabalho.

    
por 17.07.2017 / 23:22