Comment 1 Philipp Hahn 2014-04-14 18:23:39 CEST

The minimum is 1000: modules/univention/admin/allocators.py:
>168 »···»···return acquireRange(lo, position, type, _type2attr[type], [{'first':1000,'last':55000},{'first':65536,'last':1000000}], scope = _type2scope[type])
# id phahn
uid=1000(phahn) gid=1009(Tech) Gruppen=1009(Tech),5001(Domain Users),5011(Users)

There's now the new UCRV pam/krb5/minimum_uid=1000.
r49337 | Bug #34315 PAM: Fix $PATH fro ucr
r49336 | Bug #34315 PAM: Limit password change to remote accounts
r49335 | Bug #34315 PAM: Add unit test for /etc/pam.d/common-*
r49334 | Bug #34315 PAM: Fix deprecation warning
r49333 | Bug #34315 PAM: Update copyright

r49338: 2014-04-14-univention-pam.yaml

Comment 2 Felix Botner 2014-04-22 12:36:27 CEST

Now i can change the password with passwd without typing the old password.

-> abcd@master:~$ id
uid=112(abcd) gid=65534(nogroup) Gruppen=65534(nogroup)
-> abcd@master:~$ passwd
Passwort: 
Geben Sie das neue Passwort erneut ein: 
passwd: Passwort erfolgreich geändert

Is that OK?

Comment 3 Philipp Hahn 2014-05-06 19:39:47 CEST

(In reply to Felix Botner from comment #2)
> Now i can change the password with passwd without typing the old password.
...
> Is that OK?

No, the change unhides a bug already present in our previous PAM configuration.

Out current PAM-Stack contains those lines:
 password requisite  pam_cracklib.so
 password sufficient pam_unix.so ... use_first_pass use_authtok
 password required pam_krb5.so use_first_pass use_authtok

Notice that "unix" and "krb5" both use "use_first_pass", which have slightly different semantics for the two modules:
$ man pam_unix
 use_first_pass
  The argument use_first_pass forces the module to use a previous stacked modules password and *will never* prompt the user - if no password is available or the password is not appropriate, the user will be denied access.

The denial is ignored because control=sufficient!

$ man pam_krb5
 use_first_pass
  Use the password obtained by a previous authentication module to authenticate the user without prompting the user again.  If no previous module obtained the user's password for either an authentication or password change, *fall back on prompting* the user.
...
 force_first_pass
  Use the password obtained by a previous authentication or password module to authenticate the user without prompting the user again.  If no previous module obtained the user's password, *fail without prompting* the user.  Also see try_first_pass and use_first_pass for weaker versions of this option.

With the addition of "minimum_uid=1000" pamk5_password_auth() is no longer called, as this is special handled:
$ less api-password.c
     * If we do ignore this user, and we're not in the preliminary check
     * phase, still prompt the user for the new password, but suppress our
     * banner.  This is a little strange, but it allows another module to be
     * stacked behind pam-krb5 with use_authtok and have it still work for
     * ignored users.
     *
     * We ignore the return status when prompting for the new password in this
     * case.  The worst thing that can happen is to fail to get the password,
     * in which case the other module will fail (or might even not care).

This does NOT work in our configuration as "krb5" is only listed 2nd after "unix", which already completed the stack with "sufficient":
$ man pam_sm_chauthtok.3
DESCRIPTION
...
  The PAM library calls this function twice in succession. The first time with PAM_PRELIM_CHECK and then, if the module does not return PAM_TRY_AGAIN, subsequently with PAM_UPDATE_AUTHTOK. It is only on the second call that the authorization token is (possibly) changed.
...
 PAM_PRELIM_CHECK
  If the control value sufficient is used in the password stack, the PAM_PRELIM_CHECK section of the modules following that control value is not always executed.

Previously pamk5_password_auth() was prompting for the "Current Kerberos password", because the retrieved password — which was not set — is empty:
$ less auth.c
        if (pass == NULL || *pass == '\0') {
...
            retval = pamk5_get_password(args, prompt, &pass);

So now there is NO module which asks for the old password during the preliminary round.
"cracklib" also never does that by itself and is only invoked as the first module during the 2nd "update" round, where it can decline the password change.


I rewrote etc/pam.d/common-password to get this situation fixed:
r49898 | Bug #34315 PAM: Fix PAM stack for password change
1. UNIX is still the first mode to allow login even without a working network connection.
2. Adapt jump style from Debian /etc/pam.d/common-password
Works with both a local user and a Kerberos user.
r49899 | Bug #34315 PAM: Fix PAM stack for password change YAML


Also read
$ zless /usr/share/doc/libpam-heimdal/NEWS.Debian.gz
The meaning of use_authtok has changed in this version to only affect the new password when changing passwords. ... If you were using it in the password group, you should add try_first_pass, use_first_pass, or force_first_pass depending on how you want to handle prompting for the old password.

$ zless /usr/share/doc/libpam-heimdal/README.gz
...
$ man 5 pam.d

Comment 4 Felix Botner 2014-06-17 10:51:24 CEST

OK - password change of local users (gdm, ssh, passwd)
OK - password of domain users (gdm, ssh, passwd)

OK - YAML

Comment 5 Moritz Muehlenhoff 2014-07-02 11:28:46 CEST

http://errata.univention.de/ucs/3.2/132.html