no kerberos support for pam-auth-update?

Bug #275169 reported by Brian J. Murrell
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libpam-krb5 (Ubuntu)
Fix Released
Medium
Steve Langasek
pam (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

On up-to-date intrepid (Sept. 26, 2008), I can see pam-auth-config profiles for "unix" and "ldap" I can't seem to find one for kerberos.

Please advise.

Related branches

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote :

Maybe this should be filed under libpam-krb5. I'm not sure what the organization here is for such a pam supporting module. I will let you decide and reassign if necessary.

Revision history for this message
Steve Langasek (vorlon) wrote :

Yes, this should be assigned to libpam-krb5.

I'll have a look at this for Ubuntu 8.10.

Changed in pam:
assignee: nobody → vorlon
status: New → Triaged
Revision history for this message
Philip Lowman (philip-yhbt) wrote :

Is there any update for this? From my point of view pam-auth-update seems to be a step backwards from auth-client-config so long as there is no built-in support for configuring kerberos. I guess it's back to configuring /etc/pam.d manually?

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote :

Or you could just put your own config for krb5 in place such as I did:

$ cat /usr/share/pam-configs/krb5
Name: Kerberos Authentication
Default: yes
Priority: 300
Auth-Type: Primary
Auth-Initial:
 [success=end default=ignore] pam_krb5.so
Auth-Final:
 [success=end default=ignore] pam_krb5.so use_first_pass
Account-Type: Primary
Account-Final:
 [success=end default=ignore] pam_krb5.so
Password-Type: Primary
Password-Initial:
 [success=end user_unknown=ignore default=die] pam_krb5.so
Password-Final:
 [success=end user_unknown=ignore default=die] pam_krb5.so use_authtok try_first_pass
Session-Type: Additional
Session-Final:
 optional pam_krb5.so

No guarantees to how correct it is, but it seems to work here.

Revision history for this message
Adam Sommer (asommer) wrote : Re: [Bug 275169] Re: no kerberos support for pam-auth-update?

On Mon, Jan 5, 2009 at 1:56 PM, Philip Lowman <email address hidden> wrote:

> Is there any update for this? From my point of view pam-auth-update
> seems to be a step backwards from auth-client-config so long as there is
> no built-in support for configuring kerberos. I guess it's back to
> configuring /etc/pam.d manually?
>

I'm not sure if this solves your problem, but if you're trying to configure
a Linux system to use Kerberos for authentication you can use
auth-client-config:

  *sudo auth-client-config -a -p kerberos_example*

The Server Guide has some more info:
https://help.ubuntu.com/8.10/serverguide/C/kerberos.html#kerberos-linux-client

--
Party On,
Adam

Revision history for this message
Steve Langasek (vorlon) wrote :

For comparison, here's the /usr/share/pam-configs/krb5 I've been using locally for testing:

Name: Kerberos authentication
Default: yes
Priority: 704
Auth-Type: Primary
Auth:
 [success=end default=ignore] pam_krb5.so minimum_uid=1000 try_first_pass
Auth-Initial:
 [success=end default=ignore] pam_krb5.so minimum_uid=1000
Account-Type: Primary
Account:
 [success=end new_authtok_reqd=done default=ignore] pam_krb5.so
Password-Type: Primary
Password:
 requisite pam_krb5.so use_authtok try_first_pass minimum_uid=1000
Password-Initial:
 requisite pam_krb5.so minimum_uid=1000

Bryan, does this config look like it's compatible with your setup? Could you test that it works in your environment, in which case I'll upload it to jaunty?

BTW, I've never needed to use the pam_krb5 session module. As far as I'm aware, that only exists as a workaround for services that don't call pam_setcred() as expected. Do you know of specific cases where this is needed in your environment?

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote :

On Wed, 2009-01-07 at 08:13 +0000, Steve Langasek wrote:
> For comparison, here's the /usr/share/pam-configs/krb5 I've been using
> locally for testing:

Looks fairly similar. There seems to be a difference of "<section>" and
"<section>-Final" between our two. I'm not sure how significant that is
though.

> Bryan, does this config look like it's compatible with your setup?

TBH, my config is purely a config-by-example. I would defer to your
knowledge in this situation.

> Could you test that it works in your environment, in which case I'll
> upload it to jaunty?

Seems to work.

> BTW, I've never needed to use the pam_krb5 session module. As far as
> I'm aware, that only exists as a workaround for services that don't call
> pam_setcred() as expected. Do you know of specific cases where this is
> needed in your environment?

Not really. See above about config-by-example. :-)

b.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Wed, Jan 07, 2009 at 02:11:55PM -0000, Brian J. Murrell wrote:

> Looks fairly similar. There seems to be a difference of "<section>" and
> "<section>-Final" between our two. I'm not sure how significant that is
> though.

It's a backwards-compatible syntax change; along the way I realized that
"-Final" was a bad name for a default option.

> > Could you test that it works in your environment, in which case I'll
> > upload it to jaunty?

> Seems to work.

Ok, great - I'll upload to jaunty later this week then.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Russ Allbery (rra-debian) wrote :

Steve Langasek <email address hidden> writes:

> For comparison, here's the /usr/share/pam-configs/krb5 I've been using
> locally for testing:

> Account-Type: Primary
> Account:
> [success=end new_authtok_reqd=done default=ignore] pam_krb5.so

What does end do? It's not documented in the PAM manual. Is that
equivalent to done?

I believe "done" would bypass all local account expiration checks, meaning
that if an account were locally locked, they would still be able to log on
via Kerberos, which is something the recommended configuration is careful
not to do.

> Bryan, does this config look like it's compatible with your setup?
> Could you test that it works in your environment, in which case I'll
> upload it to jaunty?

Is this something that should also be included in the Debian package?

> BTW, I've never needed to use the pam_krb5 session module. As far as
> I'm aware, that only exists as a workaround for services that don't call
> pam_setcred() as expected. Do you know of specific cases where this is
> needed in your environment?

Is there any reason *not* to run it? As upstream maintainer, I would
certainly recommend adding pam_krb5 to the session configuration. Under
most circumstances, it's a no-op, but the module recognizes when it is,
and there are applications that don't call setcred.

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

Revision history for this message
Steve Langasek (vorlon) wrote :

On Wed, Jan 07, 2009 at 06:38:24PM -0000, Russ Allbery wrote:
> Steve Langasek <email address hidden> writes:

> > For comparison, here's the /usr/share/pam-configs/krb5 I've been using
> > locally for testing:

> > Account-Type: Primary
> > Account:
> > [success=end new_authtok_reqd=done default=ignore] pam_krb5.so

> What does end do? It's not documented in the PAM manual. Is that
> equivalent to done?

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.

> I believe "done" would bypass all local account expiration checks, meaning
> that if an account were locally locked, they would still be able to log on
> via Kerberos, which is something the recommended configuration is careful
> not to do.

True. Perhaps this should be:

  Account:
     required pam_krb5.so minimum_uid=1000

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.

So it looks like there's a need for a full range of
(Initial,Medial,Final,Isolate) semantics after all, and I'll have to add
that back into the spec and get it into the pam-auth-update implementation.

That'll push back the libpam-krb5 upload by a couple of days, at least.

> Is this something that should also be included in the Debian package?

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.

> > BTW, I've never needed to use the pam_krb5 session module. As far as
> > I'm aware, that only exists as a workaround for services that don't call
> > pam_setcred() as expected. Do you know of specific cases where this is
> > needed in your environment?

> Is there any reason *not* to run it? As upstream maintainer, I would
> certainly recommend adding pam_krb5 to the session configuration. Under
> most circumstances, it's a no-op, but the module recognizes when it is,
> and there are applications that don't call setcred.

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.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Changed in pam:
importance: Undecided → Medium
status: New → Triaged
Steve Langasek (vorlon)
Changed in libpam-krb5:
importance: Undecided → Medium
Revision history for this message
Russ Allbery (rra-debian) wrote :
Download full text (3.5 KiB)

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:

    [s...

Read more...

Revision history for this message
Philip Lowman (philip-yhbt) wrote :
Download full text (9.2 KiB)

On Mon, Jan 5, 2009 at 1:56 PM, Philip Lowman <email address hidden> wrote:

>> Is there any update for this? From my point of view pam-auth-update
>> seems to be a step backwards from auth-client-config so long as there is
>> no built-in support for configuring kerberos. I guess it's back to
>> configuring /etc/pam.d manually?
>>

>I'm not sure if this solves your problem, but if you're trying to configure
>a Linux system to use Kerberos for authentication you can use
>auth-client-config:
>
> *sudo auth-client-config -a -p kerberos_example*

Adam,

Yeah, I tried this starting from the stock PAM configuration that comes with Ubuntu 8.10 and for some reason it didn't work on our systems (although I've done this before on Ubuntu 8.04 with success). I didn't mean to blame pam-auth-update for the problem, I wasn't sure what the issue was exactly a couple of days ago, I was just frustrated that things didn't "just work".

I looked a little closer at the issue today and I believe the problem has something to do with pam_unix.so and pam_krb5.so lines in common-auth being swapped. Here they are in my Ubuntu 8.04 common-auth

Ubuntu 8.04 common-auth:
============
auth [success=done default=ignore] pam_unix.so nullok_secure debug
auth [authinfo_unavail=ignore success=1 default=2] pam_krb5.so use_first_pass debug
auth [default=done] pam_ccreds.so action=validate use_first_pass
auth [default=done] pam_ccreds.so action=store
auth [default=bad] pam_ccreds.so action=update

And here they are along with the other PAM config files and auth.log in Ubuntu 8.10 after running "auth-client-config -a -p kerberos_example".

Ubuntu 8.10...
common-auth:
============
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# pre_auth-client-config # # here are the per-package modules (the "Primary" block)
# pre_auth-client-config # auth [success=1 default=ignore] pam_unix.so nullok_secure
# pre_auth-client-config # # here's the fallback if no module succeeds
# pre_auth-client-config # auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
# pre_auth-client-config # auth required pam_permit.so
# pre_auth-client-config # # and here are more per-package modules (the "Additional" block)

# pre_auth-client-config # # end of pam-auth-update config
auth [authinfo_unavail=ignore success=1 default=2] pam_krb5.so use_first_pass ignore_root debug
au...

Read more...

Revision history for this message
Philip Lowman (philip-yhbt) wrote :

Steve,

The krb5 configuration file you uploaded works fine in our environment as well. Thank you for sharing it. Also thank you for including minimum_uid=1000. I based our common-auth off of some documentation I found online that didn't mention this very useful option (or ignore_root for that matter).

Revision history for this message
Steve Langasek (vorlon) wrote :
Download full text (3.6 KiB)

On Wed, Jan 07, 2009 at 09:55:44PM -0000, Russ Allbery wrote:
> > 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.

Well, if people fiddle with it by hand they're going to have annoying
debconf prompts on upgrades, too. My goal is certainly to get this working
well enough that they have no cause to fiddle.

The pam_deny is useful because it simplifies the writing of the config
snippets; modules don't in general have to know they're the last module in
the stack and be handled differently, so it's less error-prone from that end
than having to juggle up to four different variant lines for the same module
and PAM type.

Anyway, I think I figured out a way to plug pam_krb5 into the stack the way
we want, without having to extend the syntax - given that we explicitly want
(pam_unix or pam_ldap) *and* pam_krb5, that's already doable by making
pam_krb5 'additional' for the 'account' type.

Doing that gives me:

account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000

which should be more or less equivalent, in spite of the differing module
order.

> 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.

Ah. I don't have any plans to upload pam to experimental in the meantime,
though, so it would just have an unsatisfiable dependency. :)

> 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]

Ok. I don't think there's a need for anything more than 'optional' here,
really.

Next take at the config:

Name: Kerberos authentication
Default: yes
Priority: 704
Auth-Type: Primary
Auth:
 [success=end default=ignore] pam_krb5.so minimum_uid=1000 try_first_pass
Auth-Initial:
 [success=end default=ignore] pam_krb5.so minimum_uid=1000
Account-Type: Additional
Account:
 required pam_krb5.so minimum_uid=1000
Password-Type: Primary
Password:
 requisite pam_krb5.so use_authtok try_first_pass minimum_uid=1000
Password-Initial:
 requisite pam_krb5.so minimum_uid=1000
Session-Type: Additional
Sessi...

Read more...

Changed in pam:
status: Triaged → Invalid
Revision history for this message
Russ Allbery (rra-debian) wrote :

Steve Langasek <email address hidden> writes:

> Well, if people fiddle with it by hand they're going to have annoying
> debconf prompts on upgrades, too. My goal is certainly to get this
> working well enough that they have no cause to fiddle.
>
> The pam_deny is useful because it simplifies the writing of the config
> snippets; modules don't in general have to know they're the last module
> in the stack and be handled differently, so it's less error-prone from
> that end than having to juggle up to four different variant lines for
> the same module and PAM type.

Yeah, that makes sense. I can see where it would help when you're
automatically generating the configuration.

> Anyway, I think I figured out a way to plug pam_krb5 into the stack the
> way we want, without having to extend the syntax - given that we
> explicitly want (pam_unix or pam_ldap) *and* pam_krb5, that's already
> doable by making pam_krb5 'additional' for the 'account' type.
>
> Doing that gives me:
>
> account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
> account requisite pam_deny.so
> account required pam_permit.so
> account required pam_krb5.so minimum_uid=1000

That works. That should do exactly what you want.

> Ok. I don't think there's a need for anything more than 'optional'
> here, really.

session should be fine with optional. account should be required
(although in practice the authorization checks are also done in auth since
too many broken programs don't check the return status of account, so it
won't *really* matter).

> Next take at the config:

It looks good to me on visual inspection, although I don't have a system
on which to test.

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

Revision history for this message
Steve Langasek (vorlon) wrote :

Ok, I'm confident enough in the correctness of the incremental changes that I'm going to go ahead with uploading this to jaunty.

Russ, the debdiff against 3.11-3 is attached; let me know if there's a different way you'd like to receive this (such as an explicit Debian bug).

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libpam-krb5 - 3.11-3ubuntu1

---------------
libpam-krb5 (3.11-3ubuntu1) jaunty; urgency=low

   * debian/libpam-krb5.{pam-auth-update,install,postinst,prerm},
     debian/rules, debian/dirs: enable pam_krb5 by default using the new
     pam-auth-update support. LP: #275169.
   * debian/control: depend on libpam-runtime (>= 1.0.1-4ubuntu1) for the
     above.

 -- Steve Langasek <email address hidden> Thu, 08 Jan 2009 09:42:55 +0000

Changed in libpam-krb5:
status: Triaged → Fix Released
Revision history for this message
Russ Allbery (rra-debian) wrote :

Steve Langasek <email address hidden> writes:

> Ok, I'm confident enough in the correctness of the incremental changes
> that I'm going to go ahead with uploading this to jaunty.
>
> Russ, the debdiff against 3.11-3 is attached; let me know if there's a
> different way you'd like to receive this (such as an explicit Debian
> bug).
>
> ** Attachment added: "debdiff"
> http://launchpadlibrarian.net/21040483/libpam-krb5-275169.diff

I try to subscribe in Launchpad to Ubuntu bugs for all my packages as a
matter of course, so attachments here are normally fine. (Although if you
don't get a reply from me here, a Debian bug is of course the most
reliable way of contacting me about a package.)

The only question I had, and this is just another iteration of the typical
"how do maintainer scripts get called in errors?" question, is that the
prerm is limited to only the remove case. Wouldn't you also want to
remove the pam-krb5 configuration on deconfigure as well? (I think that
since libpam-krb5 will continue to be installed, it doesn't make sense to
remove it on either upgrade or failed-upgrade.)

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

Revision history for this message
Steve Langasek (vorlon) wrote :

On Fri, Jan 09, 2009 at 05:06:41AM -0000, Russ Allbery wrote:
> The only question I had, and this is just another iteration of the typical
> "how do maintainer scripts get called in errors?" question, is that the
> prerm is limited to only the remove case. Wouldn't you also want to
> remove the pam-krb5 configuration on deconfigure as well? (I think that
> since libpam-krb5 will continue to be installed, it doesn't make sense to
> remove it on either upgrade or failed-upgrade.)

That's a good question. The purpose of the prerm "pam-auth-update --remove"
call is to ensure that the named profile is removed from the active config
before the files disappear from disk, rather than after, to reduce the
chances that this will result in a broken stack (or a log-spammy stack).
However, deconfiguration can happen as part of a dist-upgrade; in extreme
cases, it would be possible for all the PAM modules to be deconfigured at
the same time as a result, so having the modules be removed from the config
on deconfigure would *also* result in a broken stack.

It would certainly be wrong for libpam-modules to call pam-auth-update
--remove on deconfigure. OTOH, so far I've assumed that as a dependency of
(Essential: yes) login, libpam-modules will never be removed, so I don't
call pam-auth-update --remove /at all/ for that package. For other packages
it may make more sense to call --remove on deconfigure -- but not with the
current pam-auth-update implementation, since --remove also wipes the
preferences for whether the named config is enabled or disabled, and we
don't want to lose this information every time a package is deconfigured.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Russ Allbery (rra-debian) wrote :

Steve Langasek <email address hidden> writes:

> It would certainly be wrong for libpam-modules to call pam-auth-update
> --remove on deconfigure. OTOH, so far I've assumed that as a dependency
> of (Essential: yes) login, libpam-modules will never be removed, so I
> don't call pam-auth-update --remove /at all/ for that package. For
> other packages it may make more sense to call --remove on deconfigure --
> but not with the current pam-auth-update implementation, since --remove
> also wipes the preferences for whether the named config is enabled or
> disabled, and we don't want to lose this information every time a
> package is deconfigured.

Okay, that makes sense, although that raises an additional question:
wouldn't preferences be considered local configuration, and hence should
only be removed on purge? (This would be future work for pam-auth-update,
of course, not something that could be fixed right away.)

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

Revision history for this message
Steve Langasek (vorlon) wrote :

On Fri, Jan 09, 2009 at 08:12:06PM -0000, Russ Allbery wrote:
> Okay, that makes sense, although that raises an additional question:
> wouldn't preferences be considered local configuration, and hence should
> only be removed on purge? (This would be future work for pam-auth-update,
> of course, not something that could be fixed right away.)

Yes, probably so - bug #319446 opened to track this issue.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Michael Kofler (michael-kofler) wrote :

using libpam_krb5 with automatic configuration through pam-auth-update, I am unable to change passwords (both locally and via kerberos); I reported this as a separate bug:

https://bugs.launchpad.net/ubuntu/+source/libpam-krb5/+bug/334795

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.