Russ,

I have a couple of issues with the latest module.

1) in prompting.c line 202 there are two ;; at the end of the line and my
gcc on Solaris doesn't like it
2) in auth.c line 449 the goto done creates an infinite loop if the password
is wrong.

Also I don't think

/* Check .k5login. */
pamret = pamk5_authorized(args);
if (pamret != PAM_SUCCESS)
goto done;

belongs into pam_sm_authenticate it is an authorisation. If I want to use
authentication only from an application with ldap authorisation for example
the above part would be simply giving wrong results.

Thanks
Markus


"Russ Allbery" wrote in message
news:87irg81wmf.fsf@windlord.stanford.edu...
>[ Reposting from the mailing list since the mail to news gateway isn't
> working at the moment. ]
>
> I'm pleased to announce release 3.0 of pam-krb5. This release features
> PKINIT support for the current Heimdal release candidates, based on code
> contributed by Douglas Engert (which I probably broke in the process of
> integrating it). Quite a bit of code has changed in this release, so
> please test carefully and be cautious before deploying it in a production
> environment.
>
> pam-krb5 is a Kerberos v5 PAM module for either MIT Kerberos or Heimdal.
> It supports ticket refreshing by screen savers, configurable authorization
> handling, authentication of non-local accounts for network services,
> password changing, and password expiration, as well as all the standard
> expected PAM features. It works correctly with OpenSSH, even with
> ChallengeResponseAuthentication and PrivilegeSeparation enabled, and
> supports configuration either by PAM options or in krb5.conf or both.
>
> Changes from previous release:
>
> Add preliminary PKINIT support, contributed by Douglas E. Engert.
> I reorganized and refactored the code extensively and it therefore may
> not compile; until it has received more testing, it should be
> considered alpha-quality. Currently, PKINIT support requires Heimdal
> 0.8rc1 or later.
>
> Add a keytab configuration option to use a different keytab for
> initial credential validation.
>
> Add a ticket_lifetime configuration option to set the lifetime of
> obtained credentials.
>
> Add the banner and expose_account configuration options, which control
> the prompts for authentication and password changing. Provide more
> informative prompts when changing passwords.
>
> Work around a bug in MIT Kerberos prior to 1.4 causing the library to
> cache the default realm and assume a particular realm even if the
> default realm is later changed. This bug prevented running two
> instances of pam-krb5 with different realm settings in the same PAM
> stack. Thanks, Dave Botsch.
>
> Honor PAM_SILENT when the Kerberos library prompts for more
> information, passing to the application only prompts.
>
> If PAM_USER is set to a fully-qualified principal that the Kerberos
> library can map to a local account name, reset PAM_USER to that local
> account name after authentication.
>
> Avoid memory leaks in the Kerberos prompter by freeing the PAM
> response strings. We were already doing this elsewhere and the world
> didn't end, so assume that it's safe for the PAM module to do this.
> Also avoid memory leaks in some unusual error conditions.
>
> Return unknown user rather than internal error when attempting
> authentication of a user we're supposed to ignore.
>
> When debug is enabled, report the principal for which we're attempting
> authentication to help catch realm configuration errors.
>
> Document the broken behavior of old versions of OpenSSH, which tell
> PAM to refresh credentials rather than opening a session. Thanks,
> Michael C. Garrison.
>
> Add a link to the distribution page to the pam-krb5 man page.
>
> Extensive refactoring and reorganization of the code.
>
> You can download it from:
>
>
>
> Debian packages will be uploaded to Debian unstable after the etch
> release.
>
> Please let me know of any problems or feature requests not already listed
> in the TODO file.
>
> --
> Russ Allbery (rra@stanford.edu)

Reproducing the mail sent privately (I hadn't realized that this was
posted as well):

Markus Moeller writes:

> I have a couple of issues with the latest module.

> 1) in prompting.c line 202 there are two ;; at the end of the line and my
> gcc on Solaris doesn't like it
> 2) in auth.c line 449 the goto done creates an infinite loop if the password
> is wrong.

Thanks, these have both been fixed. I'm surprised that gcc no longer
apparently diagnoses the former; the latter is a pure mistake on my part.

> Also I don't think

> /* Check .k5login. */
> pamret = pamk5_authorized(args);
> if (pamret != PAM_SUCCESS)
> goto done;

> belongs into pam_sm_authenticate it is an authorisation. If I want to use
> authentication only from an application with ldap authorisation for example
> the above part would be simply giving wrong results.

This has been in the module from the beginning, and after several
discussions with PAM experts, is indeed necessary. The problem is that
PAM is about authenticating the user to a local account and doesn't have a
clear authentication vs. authorization breakdown, so if you defer all
authorization of this type to the account stack, you will open security
holes.

Take a look at pamk5_authorized, though. It will do the right thing even
for services that are authenticating non-local users. You can also use
ignore_k5login to bypass any .k5login even if the file exists.

In some unusual situations, it is necessary to use those configuration
options to avoid checks that are spurious in a particular environment, but
the alternative has some disturbing security implications. Going the way
that I did towards more security (if possibly incorrect) by default was a
conscious choice.

--
Russ Allbery (rra@stanford.edu)

Russ Allbery writes:

>
>
> Debian packages will be uploaded to Debian unstable after the etch
> release.

Hi Russ,

very good work.
Will you provide backports for etch?

Regards
Daniel

Daniel J Priem writes:
> Russ Allbery writes:

>>
>>
>> Debian packages will be uploaded to Debian unstable after the etch
>> release.

> Hi Russ,

> very good work.
> Will you provide backports for etch?

I hadn't planned to initially, but I suppose I could. Most of the new
features are only of interest in unusual situations, although the new
password changing prompts are nice to have.

--
Russ Allbery (rra@stanford.edu)

Hello,

Russ Allbery wrote:
> Take a look at pamk5_authorized, though. It will do the right thing even
> for services that are authenticating non-local users. You can also use
> ignore_k5login to bypass any .k5login even if the file exists.

I'm using LDAP to store my user information along with PADL's nss_ldap
on the client hosts and using your module to handle the Kerberos
authentication (MIT Kerberos 1.5.1). ignore_k5login is set. When I try
to login using a non-local account that is in LDAP,
krb5_aname_to_localname in pamk5_authorized fails. For instance, I can
login using "jason" (which has an entry in /etc/passwd, etc.), but
using "jason/admin" fails even though there is an appropriate LDAP
entry.

If I bypass pamk5_authorized (source hackery), I can login just fine
into non-local accounts, so it seems to me that Kerberos/pam-krb5
aren't using NSS. Any thoughts/ideas would be appreciated.

> --
> Russ Allbery (rra@stanford.edu)

Thanks,
-Jason

jpetsod writes:

> I'm using LDAP to store my user information along with PADL's nss_ldap
> on the client hosts and using your module to handle the Kerberos
> authentication (MIT Kerberos 1.5.1). ignore_k5login is set. When I try
> to login using a non-local account that is in LDAP,
> krb5_aname_to_localname in pamk5_authorized fails. For instance, I can
> login using "jason" (which has an entry in /etc/passwd, etc.), but using
> "jason/admin" fails even though there is an appropriate LDAP entry.

> If I bypass pamk5_authorized (source hackery), I can login just fine
> into non-local accounts, so it seems to me that Kerberos/pam-krb5
> aren't using NSS. Any thoughts/ideas would be appreciated.

Right, krb5_aname_to_localname doesn't permit principals with non-NULL
instances. You're the first person I've ever heard of who has local
accounts where the username contains an instance portion of the principal.
I'm surprised that the / in the username doesn't break other software.

I'm not sure how this should work. The PAM module needs to be sure that
the principal with which you've authenticated maps to the account into
which you're logging in, and the only way that it has available to do that
right now is krb5_aname_to_localname. I suppose I could add yet another
option that tells the PAM module to always assume a pure one-to-one
correspondance between Kerberos principals and local account names even
when there's an instance, but given how unusual of a situation this is,
maybe it would be better to set up aname_to_localname mappings yourself in
krb5.conf.

For instance, you could use:

[realms]
EXAMPLE.COM = {
auth_to_local_names = {
jason/admin = jason/admin
}
}

where EXAMPLE.COM is your realm. Or, more generally, something like:

[realms]
EXAMPLE.COM = {
auth_to_local = {
RULE:[2:$1/$2]
DEFAULT
}
}

which allows any principal with one instance value and maps it to an
account with the same name.

--
Russ Allbery (rra@stanford.edu)

Russ Allbery wrote:
> Right, krb5_aname_to_localname doesn't permit principals with non-NULL
> instances. You're the first person I've ever heard of who has local
> accounts where the username contains an instance portion of the principal.
> I'm surprised that the / in the username doesn't break other software.

Ahh... using "jason/admin" was purely for testing and an easy way out as
a username that wasn't local but was in LDAP. I tested with a "normal",
non-instanced username.

Thanks!

-Jason