Steve Langasek <email address hidden> writes:

> This is not a PAM token, but a token that's rewritten by pam-auth-update
> when generating /etc/pam.d/common-* from these files.
>
>   https://wiki.ubuntu.com/PAMConfigFrameworkSpec
>
> "end" means "jump to the end of this group of modules" - it's replaced by a
> number once pam-auth-update knows how many modules there are, since this is
> dynamic.

Oh, okay, neat.  Yeah, this will save people quite a lot of work in doing
PAM configuration.

> True.  Perhaps this should be:
>
>   Account:
>      required      pam_krb5.so minimum_uid=1000

That's what the current documentation recommends, with the note that you
should make it sufficient (which I think is equivalent to success=end) if
you don't want to put accounts in shadow at all.  (Ideally there should be
some sort of option for people to select which behavior they want, but the
UI issues get complicated.)

> However, then we run into trouble if pam_krb5 is the /last/ module in the
> stack (i.e., the admin has chosen to disable pam_unix completely), because
> the next line after this will then be:
>
>    account requisite                       pam_deny.so
>
> ... which obviously isn't going to work.

I never liked pam_deny for the common case where there's at least one
other module that's required.  It works when you generate the
configuration with the end token, but if people then fiddle with it by
hand, they have to keep all the numbers aligned.

I never use pam_deny in any of my PAM configurations; I use combinations
of sufficient and required instead.  Maybe I'm missing some reason why
it's a good idea, though.

> Not until after lenny; unfortunately the development work for this only
> got done after lenny had gone into freeze, so it wasn't appropriate to
> completely reconfigure the PAM handling at that point.

Well, I'm currently uploading libpam-krb5 packages to experimental anyway
to avoid the freeze.  What's in experimental will go into unstable after
the lenny release.

> Ok - I have a slight aversion to enabling things that "should" be
> no-ops, and I don't know of any PAM services in Debian or Ubuntu that
> fail to call pam_setcred(); but if you recommend enabling this for
> compatibility, then we can go that way.

I have gotten bug reports saying that ticket initialization didn't work
properly for ssh unless pam-krb5 was listed in the session group, although
I don't know if that's OpenSSH or Solaris ssh or some other beast.

close_session also explicitly removes the user's ticket cache, but it does
so in the same way that pam_end should do, so I don't think that makes a
difference (assuming the application calls pam_end and doesn't just exit;
I don't know if they all do).

When adding the session block, note:

  If you use a more complex configuration with the Linux PAM [] syntax for
  the session and account groups, note that pam_krb5 returns a status of
  ignore, not success, if the user didn't log on with Kerberos.  You may
  need to handle that explicitly with ignore=ignore in your action list.

If you do [success=end default=die] or something equivalent, ignore will
cause failure.  You *should* be able to do:

    [success=end ignore=ignore default=bad]

rather than default=ignore with pam-krb5 3.11 or later and have the right
thing happen, since the module will only return failure if the user
authenticated with Kerberos and it checked Kerberos and something was bad,
not if the user just isn't using Kerberos.

-- 
Russ Allbery (<email address hidden>)               <http://www.eyrie.org/~eagle/>