A alteração de senha SSSD não funciona com o backend LDAP

1
Environment info:

AD on win 2k8r2  
Ubuntu 12.04.5 LTS  
SSSD v1.8.6  

everything is in the same vlan

Eu tenho uma solução LDAP / SSSD em uso nos nossos servidores Ubuntu. O processo de autenticação funciona corretamente - ou seja, os usuários podem fazer login e fazer o que precisarem.

quando alguém tenta alterar a sua senha, vê isto:

user@host:~$ passwd
Current Password: 
New Password: 
Reenter new Password: 
Password change failed. 
passwd: Authentication token manipulation error
passwd: password unchanged

A nova senha atende a todos os requisitos do AD.

Eu vejo isso em /var/log/auth.log:

Aug 18 15:22:12 hostname passwd[7544]: pam_unix(passwd:chauthtok): user "user" does not exist in /etc/passwd
Aug 18 15:22:16 hostname passwd[7544]: pam_unix(passwd:chauthtok): user "user" does not exist in /etc/passwd
Aug 18 15:22:21 hostname passwd[7544]: pam_sss(passwd:chauthtok): system info: [Generic error (see e-text)]
Aug 18 15:22:21 hostname passwd[7544]: pam_sss(passwd:chauthtok): User info message: Password change failed. 
Aug 18 15:22:21 hostname passwd[7544]: pam_sss(passwd:chauthtok): Password change failed for user user: 20 (Authentication token manipulation error)

Eu tentei usar algumas configurações diferentes em sssd.conf para ldap_default_bind_dn, todas permitindo que os usuários autentiquem, mas não alterem sua senha. Não faço ideia do que está parando - parece que deve ser apenas uma alteração de configuração e tudo ficará bem, mas não tenho certeza do que preciso mudar.

arquivos de configuração:

/etc/sssd/sssd.conf

[sssd]  
config_file_version = 2  
domains = LDAP  
services = nss, pam  
debug_level = 10  

[nss] 

[pam]

[domain/LDAP]
enumerate = false
id_provider = ldap
#ldap_access_filter = memberOf=cn=XXXX,cn=XXXX,dc=XXXX,dc=XXXX
ldap_uri = ldap://xxx.xxx.xxx.xxx # AD server ip
ldap_search_base = ou=XXXX,dc=XXXX,dc=XXXX
ldap_tls_reqcert = demand
ldap_id_use_start_tls = false
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_schema = rfc2307bis
ldap_user_object_class = person
ldap_group_object_class = group
ldap_default_bind_dn = cn=XXXX,cn=XXXX,dc=XXXX,dc=XXXX
ldap_default_authtok_type = password
ldap_default_authtok = *********
ldap_user_gecos = displayName
ldap_user_home_directory = unixHomeDirectory
min_id = 10000
ldap_user_principal = userPrincipalName
ldap_force_upper_case_realm = True

auth_provider = krb5
chpass_provider = krb5
krb5_server = xxx.xxx.xxx.xxx # AD server ip
krb5_kpasswd = xxx.xxx.xxx.xxx # AD Server ip
krb5_realm = XXXX.XXXX #Upper caseof the domain
krb5_changepw_principle = kadmin/changepw
krb5_auth_timeout = 15
krb5_store_password_if_offline = true
krb5_renewable_lifetime = 14d
krb5_renew_interval = 60
debug_level = 9

/etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = XXXX.XXXX # capitalised domain
realm = XXXX.XXXX # capitalised domain
dns_lookup_realm = true
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_etypes = arcfour-hmac-md5
default_etypes_des = des-cbc-crc
default_tkt_enctypes = arcfour-hmac-md5
default_tgs_enctypes = arcfour-hmac-md5

[realms]
XXXX.XXXX= {
kdc = xxx.xxx.xxx.xxx:88 # AD Server IP
kpasswd_server = xxx.xxx.xxx.xxx:464 #AD server IP
default_domain = XXXX.XXXX # Capitalised domain
}

[domain_realm]
.xxxx.xxxx = XXXX.XXXX # lower = CAP domain
xxxx.xxxx = XXXX.XXXX

/etc/pam.d/common-password:

password    [success=2 default=ignore]  pam_unix.so obscure sha512
password    sufficient                  pam_sss.so
password    requisite           pam_deny.so
password    required            pam_permit.so
    
por drinxy 18.08.2014 / 07:48

3 respostas

1

Depois de muita pesquisa e teste. Aqui está a resposta para permitir que os usuários usem a função passwd para alterar sua senha quando estiverem usando o SSSD com o backend do ldap. Se eles realmente podem autenticar com sua senha via ssh para o cliente SSSD, então o problema de alterar sua senha, que produz o seguinte: "passwd: erro de manipulação de token de autenticação" vem da ACL LDAP. Precisa de acesso de gravação automática ao atributo userPassword

Adicione o seguinte ao seu arquivo de configuração do ldap ao usar o olc. Editar olcDatabase={2}bdb.ldif olcAccess :

{0}to attrs=userPassword,shadowLastChange by self write by anonymous 
            auth by dn="cn=Manager,dc=domain.com" write by * none

Certifique-se de adicionar um pouco mais para permitir leituras e gravações de outros atributos desejados.

olcAccess: {2}to * by * read by users read by anonymous auth

Você só precisa fazer isso uma vez para todos os usuários. {0}to attrs=userPassword ... assim como eu listei acima é aplicado como uma ACL ao servidor ldap e aplicado globalmente. Se você editar o olcDatabase={2}bdb.ldif olcAccess manualmente, você terá que alterar o CRC, mas isso é fácil, pois há muitos readmes sobre isso.

O outro usuário postou a alteração das credenciais de ligação nos clientes /etc/sssd/sssd.conf da seguinte forma:

ldap_default_bind_dn = cn=Manager,dc=mydomain,dc=fqdn.com ldap_default_authtok_type = password ldap_default_auttok = secret

A modificação em /etc/sssd/sssd.conf credenciais de ligação não funcionou para mim, mas permitir que os usuários auto-escrevessem seu atributo userPassword ... Você pode nem sempre querer isso, mas para usar a função passwd em clientes linux com backend SSSD e LDAP você precisa disso.

    
por user402350 28.04.2015 / 16:36
0

fixo

Foi feito com a ligação ao ldap no sssd.conf. Como um trabalho temporário eu usei o user / pass administrador lá e eu posso mudar a senha usando o passwd. Eu não sei nada sobre o AD, então vou brincar mais com ele, mas pelo menos eu sei que o problema está nas permissões do usuário do bind.

    
por drinxy 19.08.2014 / 07:01
0

Adicione o seguinte ao seu /etc/sssd/sssd.conf:

[domain/LDAP]
...
# changing passwords not working otherwise
# see https://fedorahosted.org/sssd/ticket/2204
krb5_use_enterprise_principal = false
    
por Ilya Semenov 29.04.2016 / 16:37