Project

General

Profile

Actions

Bug #5525

closed

User management technique not setting password entry on SLES

Added by Florian Heigl about 10 years ago. Updated over 7 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Techniques
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Getting started - demo | first install | level 1 Techniques
Effort required:
Small
Priority:
52
Name check:
Fix check:
Regression:

Description

I've tested adding a user via the User management technique.

On SLES 11SP3, it adds the user but doesn't update /etc/shadow with a password.
Accordingly, the newly created user cannot SSH in, a pam error is logged.
Once you manually set a password for the user, it is able to log in.

I checked the same technique works against a Debian wheezy VM, adding a user with a password.

I also tried switching the encryption from SHA512 to MD5, no luck.

SLES:

rudderc4:~ # tail -1 /etc/passwd
abcdef:x:1001:100:My Test user:/home/some:/usr/bin/ksh
rudderc4:~ # tail -1 /etc/shadow
abcdef:!:16325:0:99999:7:::

Debian:
well, just the way it should look...

Actions #1

Updated by François ARMAND about 10 years ago

  • Assignee set to Matthieu CERDA

Thanks for that report.
I think Matthieu could know more about that one ?

For information, could you let me know what is you Rudder & Technique version ?

Thanks,

Actions #2

Updated by Florian Heigl about 10 years ago

Hi,

I reinstalled yesterday, so no clipboard :/

Setup I could produce this:

all SLES OS in this Lab SLES11 SP3

techniques sles 2.11.2 (updated, just in case)
server: 2.11.1 (all but techniques)
agent: 2.11.1

I'm expecting to hear about result from the other lab (SLES11SP2 + 2.11.2) pretty soon.
Tbh I doubt it'll be different though :)

Actions #3

Updated by Florian Heigl about 10 years ago

Hi,

I had a very close look at the usermanagement techique. I don't fully understand it, but I noticed the difference between pwoneshot and pweverytime.
After seeing this differentitation I changed the password check policy to "every time" and voila, the password got set.

I think this is a design problem, if the user is added there must be some race condition that misses the update to /etc/shadow.
Later it's not checked any more and so the valid hash is never written to shadow.

I have no idea why it would happen on SLES but not on Debian, but this is what it looks like :)

Actions #4

Updated by François ARMAND about 10 years ago

  • Assignee changed from Matthieu CERDA to Nicolas CHARLES

Thank you veery much for the deep analysis.
Nicolas, I think you are the best to know what to do next on that case.

Thanks again,

Actions #5

Updated by Benoît PECCATTE over 9 years ago

  • Category set to Techniques
  • Target version set to 2.10.14
Actions #6

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.10.14 to 2.10.15
Actions #7

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.10.15 to 2.10.16
Actions #8

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.10.16 to 2.10.17
Actions #9

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.10.17 to 2.10.18
Actions #10

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.10.18 to 2.10.19
Actions #11

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.10.19 to 2.10.20
Actions #12

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 2.10.20 to 277
Actions #13

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 277 to 2.11.18
Actions #14

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 2.11.18 to 2.11.19
Actions #15

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.19 to 2.11.20
Actions #16

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.20 to 2.11.21
Actions #17

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.21 to 2.11.22
Actions #18

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.22 to 2.11.23
Actions #19

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.23 to 2.11.24
Actions #20

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 2.11.24 to 308
Actions #21

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 308 to 3.1.14
Actions #22

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.14 to 3.1.15
Actions #23

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.15 to 3.1.16
Actions #24

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.16 to 3.1.17
Actions #25

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 3.1.17 to 3.1.18
Actions #26

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 3.1.18 to 3.1.19
Actions #27

Updated by François ARMAND over 7 years ago

  • Severity set to Major - prevents use of part of Rudder | no simple workaround
  • User visibility set to Getting started - demo | first install | level 1 Techniques
  • Effort required set to Small
  • Priority set to 52
Actions #28

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.19 to 3.1.20
Actions #29

Updated by Jonathan CLARKE over 7 years ago

  • Assignee deleted (Nicolas CHARLES)
Actions #30

Updated by Alexis Mousset over 7 years ago

  • Status changed from New to Rejected

Could not reproduce on 3.1 with SLES11.3, User Management technique in version 7.1.

Rejecting, please reopen if the problem still occurs.

Actions

Also available in: Atom PDF