The "maxPwdAge" attribute can be set to arbitrary values, but the possible values should be in the range of: maxPwdAge: -864000000001 to maxPwdAge: -9223372036854775808 (-0x8000000000000000ULL)
Björn, could you please provide more details how you set this value? How can this be reproduced?
Since around commit 1d266b493894ad55c6c30e73a4cf9bc6aa28f559 we seem to ignore values that are out of this range, at least in some places. In 'samba-tool domain passwordsettings set' we do checks at the python level, but if you hack a little bit of python, you can set the value there to any int64. Values >0 are returned back to 'samba-tool domain passwordsettings show' as if they were negated (e.g. 99999 is the same as -99999). As for the specified range, [MS-SAMR] says "maxPwdAge MUST be less than or equal to 0". I don't see much else. I'm guessing the multiples of 1 day thing is an observed limit.
(In reply to Douglas Bagnall from comment #2) > you can set the value there to any int64 I should add, only admin users can do this, so we're not talking nasty tricks here, just foot-shooting potential. Samba-tool has safety catches for the simplest foot-shooting, but it does have more subtle problems. Invalid values (e.g. maxPwdAge = -1 == 100ns) are treated as never expiring in source4/dsdb/samdb/ldb_modules/operational.c. While never expiring is probably not what you meant by a 100ns timeout, it is at least handled. But it IS a problem that 'samba-tool domain passwordsettings show' will incorrectly show invalid values of maxPwdAge as if they were valid. That's because the timestamp_to_mins() function has an abs() in it. That is, you can (as admin, perhaps through bad LDIF experiments) set the maxPwdAge to a value that evaluates as eternity but shows as 3 days.