pam-krb5 2.6 released - Kerberos

This is a discussion on pam-krb5 2.6 released - Kerberos ; I'm pleased to announce release 2.6 of my Kerberos v5 PAM module. This is a bug-fix release; the feature improvements that were intended to be in this release have been deferred to the next release. pam-krb5 is a Kerberos v5 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: pam-krb5 2.6 released

  1. pam-krb5 2.6 released

    I'm pleased to announce release 2.6 of my Kerberos v5 PAM module. This is
    a bug-fix release; the feature improvements that were intended to be in
    this release have been deferred to the next release.

    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:

    Don't assume the pointer set by pam_get_user is usable over the life
    of the PAM module; instead, save a local copy.

    Avoid a use of already freed memory when debugging is enabled.

    Use __func__ instead of __FUNCTION__ and provide a fallback for older
    versions of gcc and for systems that support neither. Should fix
    compilation issues with Sun's C compiler.

    On platforms where we know the appropriate compiler flags, try to
    build the module so that symbols are resolved within the module in
    preference to any externally available symbols. Also add the
    hopefully correct compiler flags for Sun's C compiler.

    You can download it from:



    Debian packages will be uploaded to Debian unstable once I have approval
    from the release managers.

    Please let me know of any problems or feature requests not already listed
    in the TODO file.

    --
    Russ Allbery (rra@stanford.edu)

  2. Re: pam-krb5 2.6 released

    Russ,

    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.

    Thanks
    Markus

    BTW Is it intention to use different defines for the below ?

    # grep KRB5_GET_INIT *.[ch]
    config.h:/* #undef HAVE_KRB5_GET_INIT_OPT_SET_DEFAULT_FLAGS */
    support.c:#ifdef HAVE_KRB5_GET_INIT_CREDS_OPT_SET_DEFAULT_FLAGS
    #


    "Russ Allbery" wrote in message
    news:871wnnyy8j.fsf@windlord.stanford.edu...
    > I'm pleased to announce release 2.6 of my Kerberos v5 PAM module. This is
    > a bug-fix release; the feature improvements that were intended to be in
    > this release have been deferred to the next release.
    >
    > 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:
    >
    > Don't assume the pointer set by pam_get_user is usable over the life
    > of the PAM module; instead, save a local copy.
    >
    > Avoid a use of already freed memory when debugging is enabled.
    >
    > Use __func__ instead of __FUNCTION__ and provide a fallback for older
    > versions of gcc and for systems that support neither. Should fix
    > compilation issues with Sun's C compiler.
    >
    > On platforms where we know the appropriate compiler flags, try to
    > build the module so that symbols are resolved within the module in
    > preference to any externally available symbols. Also add the
    > hopefully correct compiler flags for Sun's C compiler.
    >
    > You can download it from:
    >
    >
    >
    > Debian packages will be uploaded to Debian unstable once I have approval
    > from the release managers.
    >
    > Please let me know of any problems or feature requests not already listed
    > in the TODO file.
    >
    > --
    > Russ Allbery (rra@stanford.edu)




  3. Re: pam-krb5 2.6 released

    Markus Moeller 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@stanford.edu)

  4. Re: pam-krb5 2.6 released

    Russ,

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

    Thanks
    Markus

    "Russ Allbery" wrote in message
    news:87ac1q7zt3.fsf@windlord.stanford.edu...
    > Markus Moeller 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@stanford.edu)




+ Reply to Thread