pam-auth-update ignores debconf settings

It is by design of debconf that settings on the system take precedence over any values set in the debconf database. There is a valid use case for being able to preseed the set of modules that you want to install, but it's difficult to implement this while maintaining the requirement to respect any local changes to the config files; so for the moment this isn't going to be fixed.

Hm, didn't think about that. Makes sense though.

In case anyone else runs into this, my workaround is to delete /etc/pam.d/common-* before running pam-auth-update. Still requires special handling in the install scripts, but at least the config is in debconf where it belongs.

Here is the workaround I came up with. Rather than try preseed, we can simply answer the questions at the time they are asked using debconf.

The EDITOR frontend essentially dumps the debconf array into a file, reads it back and uses the results to modify the debconf array.
So rather than even bother with the output it created for us, I just pass in the values I know/want to set - the rest will use defaults.
/root/test.sh would obviously be replaced by something a little more robust but it's good to illustrate the point.
Saves me writing a new Frontend, can re use an existing one.

root@gaz4:~# grep ldap /etc/pam.d/common-auth
root@gaz4:~# cat test.sh
#!/bin/sh
cat > $1 <<EOF
libpam-runtime/profiles="Unix authentication, LDAP Authentication"
EOF
root@gaz4:~# EDITOR=/root/test.sh DEBIAN_FRONTEND=editor pam-auth-update
root@gaz4:~# grep ldap /etc/pam.d/common-auth
auth [success=1 default=ignore] pam_ldap.so use_first_pass
root@gaz4:~#

Also facing this issue, it's weird that newer pam-auth-update also ignores default option in pam configs. So now it's not possible to non-interactively enable new profile (but it was working in trusty).
Here's updated script to add one profile (mkhomedir) to current set of profiles:

#!/bin/sh

PROFILES=$(debconf-get-selections | grep libpam-runtime/profiles | cut -d ' ' -f 2- | sed s/\,\ mkhomedir//g)
PROFILES="${PROFILES}, mkhomedir"

for profile in /usr/share/pam-configs/*; do
 profile_name=$(grep Name: $profile | cut -d ' ' -f 2-)
 PROFILES=$(echo $PROFILES | sed s,$(basename $profile),"${profile_name}",g)
done

cat > $1 <<EOF
libpam-runtime/profiles="${PROFILES}"
EOF

It was working in trusty but is being broken once again in xenial.

Came by to report this same issue. /usr/share/pam-config/mkhomedir is being ignored on Ubuntu 16.04 with this configuration:

Name: Create home directory during login
Default: yes
Priority: 900

Session-Type: Additional
Session:
        required pam_mkhomedir.so umask=0077 skel=/etc/skel

It was working perfectly fine on Ubuntu 14.04.

It seems to be impossible to manage some pam auth settings non-interactively due to this bug.

For example, I want to fetch user/group info from LDAP on a server so I install 'libnss-ldap'. This automatically enables ldap authentication in PAM (this already seems like a bad idea) which I don't want, I just want the user/group info available. My first attempt to avoid this is just edit /etc/pam.d/common-auth to not use ldap. However, this manual edit will get silently reverted anytime the libnss-ldap package gets updated (or pam-auth-update gets run for some other reason).

Ok, so I research pam-auth-update which claims that "Debconf is the correct interface to use for management of PAM config files" (https://wiki.ubuntu.com/PAMConfigFrameworkSpec). Ok so I use debconf-setselections to remove "ldap" from "libpam-runtime/profiles". I try running "dpkg-reconfigure libnss-ldap" and it completely wipes my manual debconf settings and re-enables ldap authentication!

There has to be __some__ way to avoid this behavior and not have it silently re-enabled behind my back.

For those trying to non-interactively enable mkhomedir module, here's what I did:

sed -i '/mkhomedir/d' /var/lib/pam/seen
pam-auth-update --package

After running pam-auth-update, mkhomedir was present in /etc/pam.d/common-session. Found this solution here https://ubuntuforums.org/showthread.php?t=2278852

Same issue in #6 with Xenial. Same chef cookbook that works on 14.04 doesn't work on 16.04 because of the "seen" issue.

Just come up against this issue whilst trying to automate deployments via puppet. Can we please get some feedback/movement on this issue from someone? This make RedHats authconfig look sleek and polished!

Status changed to 'Confirmed' because the bug affects multiple users.

This VERY ugly hack works on Ubuntu 18.04...

-- /usr/share/pam-config/mkhomedir -----
Default: yes
Priority: 0
Session-Type: Additional
Session:
 required pam_mkhomedir.so skel=/etc/skel umask=0027
------------------------

apt-get install debconf-utils
echo libpam-runtime libpam-runtime/profiles multiselect mkhomedir | debconf-get-selections
rm /var/lib/pam/seen
rm /etc/pam.d/common-*
DEBIAN_FRONTEND=noninteractive pam-auth-update --force

...sorry ^^^ - %s/debconf-get-selections/debconf-set-selections/

of course :-)