Não é possível adicionar usuário local no sistema usando a autenticação ldap para o samba [closed]

1

Tentando adicionar um usuário local a um sistema CentOS 6.3 que está usando o ldap para autenticação do Samba, mas sendo bloqueado pela entrada existente do usuário no ldap.

[root@samba ~]# adduser wchandy
adduser: user 'wchandy' already exists

[root@samba ~]# useradd wchandy
useradd: user 'wchandy' already exists

O usuário ainda não é um usuário local:

[root@edgar2 ~]# grep wchandy /etc/passwd

Mas eles são usuários do Samba no ldap:

[root@edgar2 ~]# smbldap-usershow wchandy | grep uid
dn: uid=wchandy,ou=people,dc=ucsc,dc=edu
uid: wchandy
uidNumber: 30490

adduser não possui uma opção local. Como um adduser para funcionar corretamente para adicionar usuários locais na presença de autenticação ldap.

Outras coisas a considerar:

  • Atualmente, há usuários locais que compartilham um uid com uma entrada ldap (com um uidNumber diferente) que pode acessar o samba e o ssh independentemente.
  • Não, não quero editar o usuário diretamente em / etc / passwd e / etc / group. Eu gostaria de corrigir o problema subjacente. Além disso, a entrada local interfere no acesso ao samba.
  • Não, não quero depender do ldap para login ssh local.
  • Não, não quero usar um uid diferente para o usuário.

Eu originalmente configurei minha autenticação samba-ldap com o prático (mas aparentemente irreversível) comando authconfig:

[root@samba ~]# authconfig --enableshadow --enablemd5 --enableldap \
--enableldapauth --enableldaptls --enablemkhomedir \
--ldapserver=dir.mydomain.com --ldapbasedn="dc=mydomain,dc=com" \
--enablelocauthorize --updateall

Meu / etc / sysconfig / authconfig tem esta aparência:

IPADOMAINJOINED=no
USEMKHOMEDIR=yes
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=no
USESHADOW=yes
USEWINBIND=no
PASSWDALGORITHM=sha512
FORCELEGACY=no
USEFPRINTD=yes
USEHESIOD=no
FORCESMARTCARD=no
USEDB=no
USELDAPAUTH=yes
IPAV2NONTP=no
USELDAP=yes
USECRACKLIB=yes
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELOCAUTHORIZE=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=no
USEPASSWDQC=no

Minha configuração do samba foi migrada de um sistema RHEL4.x para o CentOS 6.3. Agora, em vez do mashup kludgy de nss e pam e quem sabe o que, o CentOS 6.x usa o sssd bastante elegante e fácil.

Meu /etc/sssd/sssd.conf tem esta aparência:

[domain/default]

cache_credentials = True
#cache_credentials = False
ldap_search_base = dc=mydomain,dc=com
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://dir.mydomain.com/
ldap_tls_cacertdir = /etc/openldap/cacerts
#ldap_tls_reqcert = allow

entry_cache_timeout = 5

debug_level = 31

[sssd]
config_file_version = 2
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
# domains = LDAP
domains = default

#debug_level = 31

[nss]

[pam]

debug_level = 31

Obrigado pela ajuda. Se eu conseguir fazer com que minha autenticação local e de samba-ldap funcione independentemente, eu ficarei feliz.

UPDATE: Embora existam algumas soluções razoavelmente suficientes abaixo, aqui está uma parapharse do conselho que recebi dos especialistas da lista sssd_users: "Sim, pode ter funcionado em versões anteriores do SO usando nss e pam, não era a melhor prática para permitir UIDs compartilhados. Novos sistemas usando o sssd evitam isso. " Embora meu caso de uso fosse perfeitamente válido, meu sistema impedia o que eu queria fazer por intenção.

No entanto, nunca encontrei uma maneira de desfazer ou reverter qualquer uma das muitas alterações que o authconfig fez em meu sistema. Então, se os parâmetros que eu dei ao authconfig estavam errados, não havia como voltar atrás.

    
por Wes Modes 26.07.2013 / 22:59

2 respostas

1

Nenhuma dessas duas soluções alternativas são ótimas, mas dão aos sysadmins uma maneira de avançar se elas se encontrarem na situação complicada em que o LDAP e o arquivo passwd local estão bloqueando um ao outro.

Solução alternativa 1: Criei um usuário local com um UID (nome de usuário) diferente para dar acesso ssh a uma pessoa que já tinha uma entrada LDAP / Samba. Possivelmente a solução de sysadmin mais audaciosa que já fiz em anos.

Solução alternativa 2: Um pouco mais complicado, mas se resume a adicionar o usuário local com o mesmo uidNumber que no LDAP.

  1. uidNumber de LDAP de pesquisa com getent, ldapsearch ou smbldap-usershow
  2. Desative temporariamente o usuário no LDAP para adicionar o usuário local sem conflitos
  3. Crie a conta local que corresponde ao uidNumber com o LDAP
  4. Reabilite o usuário no LDAP

Ambos funcionam, mas não abordam o problema subjacente de permitir que a autenticação use o LDAP exclusivamente para a autenticação do Samba e / etc / passwd para a autenticação local. Mas na ausência de outra solução, isso terá que ser feito.

    
por 10.08.2013 / 00:22
1

Minha última resposta foi ruim, ignore isso.

Eu acredito que sua única opção é a edição manual de /etc/passwd ( vipw é o preferido porque você evita erros próprios). A opção -o permite que você crie vários nomes para um UID, mas não há uma opção equivalente para informar passwd para ignorar o nome já existente quando ele executa uma pesquisa NSS.

getent passwd mostrará como os uids se formam quando você adiciona o usuário; a primeira entrada ganha. Certifique-se de que o uid seja idêntico para evitar problemas com permissões de mudança. (seus exemplos não incluíram -u syntax)

    
por 26.07.2013 / 23:45