Bug 220780

Please provide the YaST log files.
http://en.opensuse.org/Bugs/YaST

I am unable to reproduce it again, might be a user error, I'll close this bug and open a new one, if it happens again, then with a yast log.

Created attachment 109588 [details]
the requested yast 2 log file

it happended again, see uploaded logfile

Sorry, I'm not able to realize where the problem is from current logfiles. It could be possible if I provide you with some patches, enhancing the log with more debug messages. But for this, I need to know better what did you do.

How exactly did you reproduce the problem? Was it changing of shell value again or something different? Does it reproduce every time you want to change the shell value or do you have to do some other steps?

what I have done:
I started up yast, 
opened security and users 
opened the users configuration
set the filter to show the ldap users
changed the shell of about 5 users from csh to bash
saved it and exited.

I'll check if I can reproduce it on every time when I change the shell.

Any news?

I think I found out how to reproduce it:
issue the passwd command on the command line, provide the old LDAP password, and enter a new one twice.

Then start yast
go to security and users -> user management
then set the filter for the ldap users and log in
then change the shell and save and leave user management

then try ssh localhost, and see a permission denied, try again.
this worked three times in a row.

the issueing of the passwd command and running yast were on the same host.

Does it work the same way if you change any other value than shell?

Could you please save the ldapsearch output for that one specific user (just before you open yast), than do the yast action and do the ldapsearch again and see the exact difference between those 2 outputs?

Created attachment 112972 [details]
patch for /usr/share/YaST2/modules/UsersLDAP.pm

Before running YaST, please patch your     /usr/share/YaST2/modules/UsersLDAP.pm with this patch and after the test, attach also new y2logs. And please, tell me the name of user which is the being tested. Thanks!

the user is sre

I changed the (LDAP) group association, and it also breaks the password, therefore the problem is not only bound to the shell.

here the requested diff of the ldapsearch output, and indeed, the password changes:
diff ldapsearch*
40d39
< userPassword:: e2NyeXB0fSQxJE81QkMwQ0R0JFAvcnlJcjVLenMzdWI3RThEUEo4Mi4=
42,44c41
< entryCSN: 20070115173306Z#000001#00#000000
< modifiersName: uid=sre,ou=people,dc=intern
< modifyTimestamp: 20070115173306Z
---
> userPassword:: e21kNX17Y3J5cHR9JDEkTzVCQzBDRHQkUC9yeUlyNUt6czN1YjdFOERQSjgyLg=

the original password was: TESTtestTEST
(just for testing ;)


the y2log file, with the patch will be appended.

Created attachment 113016 [details]
requested log file

the log file, while adding user sre to a ldap group.

BTW, what is your version of yast2-users?
The bug seems like a duplicate of bug 213574 (please do the same check as in comment 3 of that bug).

# userconfiguration, ldapconfig, intern
dn: cn=userconfiguration,ou=ldapconfig,dc=intern
susePasswordHash: MD5

I use following version:
yast2-users-2.13.16-10

in /etc/default/passwd is following defined:

# This file contains some information for
# the passwd (1) command and other tools
# creating or modifying passwords.

# Define default crypt hash
# CRYPT={des,md5,blowfish}
CRYPT=md5

# Use another crypt hash for group passwowrds.
# This is used by gpasswd, fallback is the CRYPT entry.
# GROUP_CRYPT=des


# We can override the default for a special service
# by appending the service name (FILES, YP, NISPLUS, LDAP)

# for local files, use a more secure hash. We
# don't need to be portable here:
CRYPT_FILES=md5
# sometimes we need to specify special options for
# a hash (variable is prepended by the name of the
# crypt hash).
BLOWFISH_CRYPT_FILES=10

# For NIS, we should always use DES:
CRYPT_YP=des
~

Created attachment 113280 [details]
patch for /usr/share/YaST2/modules/UsersLDAP.pm

Could you try this new patch (with new y2logs if it is not succesful)?

this new patch seems to fix the problem
1. I chaged the password on command line
2. then changed ldap group association in Yast and saved it
3. still possible to login with password

thanks a lot

So it is a dup.

*** This bug has been marked as a duplicate of bug 213574 ***