CentOS 6 + LDAP + NFS. A propriedade do arquivo está presa em "nobody"

11

Eu tenho tentado obter a autenticação LDAP e os diretórios iniciais exportados pelo NFS no CentOS 6 funcionando por alguns dias agora. Cheguei ao ponto em que agora posso fazer login na máquina cliente usando o nome de usuário e a senha no LDAP. No cliente, / home e / opt são montados no fstab sobre NFS. No entanto, todos os arquivos em / opt e / home são de propriedade de nobody:nobody (uid: 99, gid: 99) no cliente.

No entanto, meu uid e gid parecem estar definidos corretamente:

-bash-4.1$ id
uid=3000(myusername) gid=3000(employees) groups=3000(employees)

O que mais posso verificar? Aqui estão alguns arquivos de configuração no meu cliente:

/etc/nsswitch.conf

passwd:     files sss
shadow:     files sss
group:      files sss

hosts:      files dns

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   files sss

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus

/etc/sssd/sssd.conf

[sssd]
config_file_version = 2
services = nss, pam

domains = default
[nss]

[pam]


[domain/default]
auth_provider = ldap
ldap_id_use_start_tls = True
chpass_provider = ldap
cache_credentials = True
krb5_realm = EXAMPLE.COM
ldap_search_base = dc=mycompany,dc=com
id_provider = ldap
ldap_uri = ldaps://server.subdomain.mycompany.com
krb5_kdcip = kerberos.example.com
ldap_tls_cacertdir = /etc/openldap/cacerts

# Configure client certificate auth.
ldap_tls_cert = /etc/openldap/cacerts/client.pem
ldap_tls_key = /etc/openldap/cacerts/client.pem
ldap_tls_reqcert = demand

/ etc / fstab

/dev/mapper/vg_main-lv_root /                       ext4    defaults        1 1
UUID=4e43a15d-4dc0-4836-8fa6-c3445fde756c /boot                   ext4    defaults        1 2
/dev/mapper/vg_main-lv_swap swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
storage1:/nas/home  /home  nfs   soft,intr,rsize=8192,wsize=8192
storage1:/nas/opt  /opt  nfs   soft,intr,rsize=8192,wsize=8192

saída do authconfig:

[root@test1 ~]# authconfig --test
caching is disabled
nss_files is always enabled
nss_compat is disabled
nss_db is disabled
nss_hesiod is disabled
 hesiod LHS = ""
 hesiod RHS = ""
nss_ldap is enabled
 LDAP+TLS is enabled
 LDAP server = "ldaps://server.subdomain.mycompany.com"
 LDAP base DN = "dc=mycompany,dc=com"
nss_nis is disabled
 NIS server = ""
 NIS domain = ""
nss_nisplus is disabled
nss_winbind is disabled
 SMB workgroup = ""
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
 Winbind template shell = "/bin/false"
 SMB idmap uid = "16777216-33554431"
 SMB idmap gid = "16777216-33554431"
nss_sss is disabled by default
nss_wins is disabled
nss_mdns4_minimal is disabled
DNS preference over NSS or WINS is disabled
pam_unix is always enabled
 shadow passwords are enabled
 password hashing algorithm is sha512
pam_krb5 is disabled
 krb5 realm = "EXAMPLE.COM"
 krb5 realm via dns is disabled
 krb5 kdc = "kerberos.example.com"
 krb5 kdc via dns is disabled
 krb5 admin server = "kerberos.example.com"
pam_ldap is enabled
 LDAP+TLS is enabled
 LDAP server = "ldaps://server.subdomain.mycompany.com"
 LDAP base DN = "dc=mycompany,dc=com"
 LDAP schema = "rfc2307"
pam_pkcs11 is disabled
 use only smartcard for login is disabled
 smartcard module = ""
 smartcard removal action = ""
pam_fprintd is enabled
pam_winbind is disabled
 SMB workgroup = ""
 SMB servers = ""
 SMB security = "user"
 SMB realm = ""
pam_sss is disabled by default
 credential caching in SSSD is enabled
 SSSD use instead of legacy services if possible is enabled
pam_cracklib is enabled (try_first_pass retry=3 type=)
pam_passwdqc is disabled ()
pam_access is disabled ()
pam_mkhomedir or pam_oddjob_mkhomedir is enabled ()
Always authorize local users is enabled ()
Authenticate system accounts against network services is disabled
    
por jamieb 28.02.2012 / 19:53

6 respostas

18

Resolvido!

Por acaso, observei esta linha em /var/log/messages no meu servidor NFS quando eu estava tentando montar uma exportação do cliente remoto:

Feb 28 15:54:02 storage1 rpc.idmapd[1651]: nss_getpwnam: name 'nobody' does not map into domain 'localdomain'

Isso me fez olhar as primeiras linhas de /etc/idmapd.conf :

[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
#Domain = local.domain.edu

Em seguida, adicionei Domain=subdomain.mycompany.com na linha "Domínio" comentada. Salvou, saiu e, em seguida, executou /etc/init.d/rpcidmapd restart e /etc/init.d/nfs restart .

    
por 28.02.2012 / 22:12
22

Uma nota para adicionar a isso para os usuários do Google - nós tivemos o mesmo problema onde, não importa o que fizemos, a montagem do nfs não mapearia os IDs do usuário corretamente.

O problema foi que o idmapd armazenou em cache os ids incorretos da configuração defeituosa, e nenhum conserto da configuração iria classificá-lo.

O comando no centos para corrigir isso foi nfsidmap -c (limpar cache).

Espero que isso ajude alguns usuários desesperados ...

    
por 01.11.2012 / 12:52
1

Encontrei uma postagem no blog que pode resolver seu problema: link que eu encontrado na seguinte postagem no fórum: link

    
por 28.02.2012 / 22:14
0

O seu servidor NFS está executando o Centos / RHEL 5 por acaso?

Se sim, está exportando o NFSv3. O NFSv4 é agora o padrão para o Centos6 (e variantes recentes do Ubuntu).

A solução rápida é adicionar "vers = 3" nas opções de montagem em / etc / fstab.

por exemplo,

// 10.0.0.1:/home / home Padrões do nfs, vers = 3, rw, noatime 0 0

    
por 28.02.2012 / 20:57
0

Tudo sendo mapeado para "nobody" parece que all_squash está ativado.

Dê uma olhada:

link

e verifique se o arquivo / etc / exports do servidor NFS não involuntariamente esmaga os UIDs. "no_all_squash" deve ser o padrão, mas você pode tentar defini-lo explicitamente e ver o que acontece.

    
por 28.02.2012 / 21:17
0

A correção para mim é garantir que o registro DNS exista para a máquina local. Também ajuda se o registro de pesquisa inversa também existir. Como resultado, o usuário e o grupo nobody foram substituídos pelo root. Quão simples é isso?!? P.S. lembre-se de reiniciar a máquina local assim que os registros DNS forem criados.

    
por 12.09.2014 / 03:13