Comment 1 for bug 349504

I've been looking into this bug, and the problem comes from how adduser (which calls useradd) places an account into /etc/shadow. Based on the default options, here is what a test account from /etc/shadow looks like

test:$6$34MquWg3$Nar6/FMoE6Aj3AgcpNgbPQq.Ww2CowvAWeujm7qt9AdqskPtrLj3we4hYw8JsGSA6KN3t4dhlTL4uJmxi9RuJ/:0:0:99999:7:::

Breaking this down, this account has the following settings

Username: test
Encrypted Password (which is test): $6$34MquWg3$Nar6/FMoE6Aj3AgcpNgbPQq.Ww2CowvAWeujm7qt9AdqskPtrLj3we4hYw8JsGSA6KN3t4dhlTL4uJmxi9RuJ/
Days since epoch that the password was last changed: 0
Days before password may be changed: 0
Days after which a password must be changed: 99999 (libshadow considers this infinite)
Days before password is to expire that user is warned: 7
Days after password expires that account is disabled: NULL
Days since epcoh that account is disabled: NULL

According to the source code, for an account that should not be disabled should have the last and max fields blank, and not zero:

Relevant sourcecode:
 /*
  * The last and max fields must be present for an account
  * to have an expired password. A maximum of >10000 days
  * is considered to be infinite.
  */

 if (sp->sp_lstchg == -1 ||
     sp->sp_max == -1 || sp->sp_max >= (10000L * DAY / SCALE))
  return 0;

(just to ease any confusion, a blank field is returned -1).

Changing the test shadow line to:
test:$6$34MquWg3$Nar6/FMoE6Aj3AgcpNgbPQq.Ww2CowvAWeujm7qt9AdqskPtrLj3we4hYw8JsGSA6KN3t4dhlTL4uJmxi9RuJ/:::99999:7:::

allows successful login.

Running a few tests, and poking adduser's source reveals the problem is with useradd. useradd has a command line switch for setting an expiration date, but by default, generates a shadow line that looks like this:

test2:!:0:0:99999:7:::

So in the end, its a bug in useradd, it simply should omit the field vs. placing a zero in it.