pam-krb5 2.6 released

[Markus Moeller]

Russ,

yes I use MIT 1.3.1.  I'll try your suggestion.

Thanks
Markus

"Russ Allbery" <rra at stanford.edu> wrote in message 
news:87ac1q7zt3.fsf at windlord.stanford.edu...
> Markus Moeller <huaraz at moeller.plus.com> writes:
>
>> I have a setup where I have two domains with trust and would like to
>> have users from either domain to login to my Unix machine to
>> applications which can't use GSSAPI so I need to use pam_krb5 to have
>> some form of SSO. My Unix system is in DOMAIN1.COM which is configured
>> to be the default domain in krb5.conf . I configured pam (on Solaris
>> 2.8) as follows:
>
>> #authentication
>> other auth sufficient      pam_krb5-2.6.so.1 minimum_uid=100 debug
>> other auth sufficient      pam_krb5-2.6.so.1 minimum_uid=100
>> realm=DOMAIN2.COM use_first_pass debug
>> other auth required       pam_unix.so.1 try_first_pass debug
>> # account
>> other account sufficient   pam_krb5-2.6.so.1 minimum_uid=100 debug
>> other account sufficient   pam_krb5-2.6.so.1 minimum_uid=100
>> realm=DOMAIN2.COM debug
>> other account required    pam_unix.so.1 debug
>> # session
>> other session required     pam_default.so.1 debug
>
>> The problem I have is that despite setting the realm to DOMAIN2.COM the
>> system always tries to connect to kdcs of DOMAIN1.COM never DOMAIN2.COM
>> despite getting an unknown user from DOMAIN1 for users of DOMAIN2 as it
>> should be. It seems that the kerberos context of the first
>> pam_sm_authenticate call is still used for the second despite changing
>> the realm.
>
> Yup, you're using MIT Kerberos 1.3 or earlier, aren't you.  :)
>
> Someone else just helped me track this down.  There's a bug in MIT
> Kerberos prior to 1.4 where the realm is stored in a static variable in
> the library and then reused even if you create a new context and change
> the default realm.  I'm going to work around this in the next version of
> the PAM module.
>
> In the meantime, upgrading to 1.4 will fix this problem, but I know that
> may not be that viable if you're using RHEL.  I don't have a patch for the
> problem yet that I've tested, but this compiles and should be close:
>
> === modified file 'support.c'
> --- support.c 2006-11-18 01:16:25 +0000
> +++ support.c 2006-12-15 00:43:04 +0000
> @@ -48,6 +48,36 @@
>
>
> /*
> + * Fill in ctx->princ from the value of ctx->name.
> + *
> + * This is a separate function rather than just calling krb5_parse_name 
> so
> + * that we can work around a bug in MIT Kerberos prior to 1.4, which 
> store the
> + * realm in a static variable inside the library and don't notice 
> changes.  If
> + * no realm is specified and a realm is set in our arguments, append the 
> realm
> + * to force krb5_parse_name to do the right thing.
> + */
> +static krb5_error_code
> +parse_name(struct context *ctx, struct pam_args *args)
> +{
> +    char *user = ctx->name;
> +    size_t length;
> +    krb5_error_code k5_errno;
> +
> +    if (args->realm != NULL && strchr(ctx->name, '@') == NULL) {
> +        length = strlen(ctx->name) + 1 + strlen(args->realm) + 1;
> +        user = malloc(length);
> +        if (user == NULL)
> +            return KRB5_CC_NOMEM;
> +        snprintf(user, length, "%s@%s", ctx->name, args->realm);
> +    }
> +    k5_errno = krb5_parse_name(ctx->context, user, &ctx->princ);
> +    if (user != ctx->name)
> +        free(user);
> +    return k5_errno;
> +}
> +
> +
> +/*
>  * Used to support trying each principal in the .k5login file.  Read 
> through
>  * each line that parses correctly as a principal and use the provided
>  * password to try to authenticate as that user.  If at any point we 
> succeed,
> @@ -90,11 +120,11 @@
>     filename[len] = '\0';
>     strncat(filename, "/.k5login", len - strlen(pwd->pw_dir));
>
> -    /* If there is no file, do this the easy way. */
> +    /*
> +     * If there is no file, do this the easy way.  Assume ctx->princ is
> +     * already set properly.
> +     */
>     if (access(filename, R_OK) != 0) {
> -        k5_errno = krb5_parse_name(ctx->context, ctx->name, &ctx->princ);
> -        if (k5_errno != 0)
> -            return PAM_SERVICE_ERR;
>         *retval = krb5_get_init_creds_password(ctx->context, creds,
>                      ctx->princ, pass, pamk5_prompter_krb5, ctx->pamh, 0,
>                      in_tkt_service, opts);
> @@ -199,13 +229,27 @@
>         krb5_get_init_creds_opt_set_renew_life(&opts, 
> args->renew_lifetime);
>
>     /* Fill in the principal to authenticate as. */
> -    retval = krb5_parse_name(ctx->context, ctx->name, &ctx->princ);
> +    retval = parse_name(ctx, args);
>     if (retval != 0) {
>         pamk5_debug_krb5(ctx, args, "krb5_parse_name", retval);
>         retval = PAM_SERVICE_ERR;
>         goto done;
>     }
>
> +    /* Log the principal we're attempting to authenticate as. */
> +    if (args->debug) {
> +        char *principal;
> +
> +        retval = krb5_unparse_name(ctx->context, ctx->princ, &principal);
> +        if (retval != 0)
> +            pamk5_debug_krb5(ctx, args, "krb5_unparse_name", retval);
> +        else {
> +            pamk5_debug(ctx, args, "attempting authentication as %s",
> +                        principal);
> +            free(principal);
> +        }
> +    }
> +
>     /*
>      * If try_first_pass or use_first_pass is set, grab the old password 
> (if
>      * set) instead of prompting.  If try_first_pass is set, and the old
>
>
>
> -- 
> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>