App-DocKnot

 view release on metacpan or  search on metacpan

t/data/generate/pam-krb5/docknot.yaml  view on Meta::CPAN

          login session required /usr/lib/security/pam_unix_session.so.1
      ```

      A similar configuration could be used for other services, such as ssh.
      See the pam.conf(5) man page for more information.  When using this
      module with Solaris login (at least on Solaris 8 and 9), you will
      probably also need to add `retain_after_close` to the PAM configuration
      to avoid having the user's credentials deleted before they are logged
      in.

      The Solaris Kerberos library reportedly does not support prompting for a
      password change of an expired account during authentication.  Supporting
      password change for expired accounts on Solaris with native Kerberos may
      therefore require setting the `defer_pwchange` or `force_pwchange`
      option for selected login applications.  See the description and
      warnings about that option in the pam_krb5(5) man page.

      Some configuration options may be put in the `krb5.conf` file used by
      your Kerberos libraries (usually `/etc/krb5.conf` or
      `/usr/local/etc/krb5.conf`) instead or in addition to the PAM
      configuration.  See the man page for more details.

      The Kerberos library, via pam-krb5, will prompt the user to change their
      password if their password is expired, but when using OpenSSH, this will
      only work when `ChallengeResponseAuthentication` is enabled.  Unless
      this option is enabled, OpenSSH doesn't pass PAM messages to the user
      and can only respond to a simple password prompt.

      If you are using MIT Kerberos, be aware that users whose passwords are
      expired will not be prompted to change their password unless the KDC
      configuration for your realm in `[realms]` in `krb5.conf` contains a
      `master_kdc` setting or, if using DNS SRV records, you have a DNS entry
      for `_kerberos-master` as well as `_kerberos`.
  - title: Debugging
    body: |
      The first step when debugging any problems with this module is to add
      `debug` to the PAM options for the module (either in the PAM
      configuration or in `krb5.conf`).  This will significantly increase the
      logging from the module and should provide a trace of exactly what
      failed and any available error information.

t/data/generate/pam-krb5/docknot.yaml  view on Meta::CPAN

      ```

      During the first `pam_authenticate`, we can't obtain credentials and
      therefore a ticket cache since the password is expired.  But
      `pam_authenticate` isn't called again after `pam_chauthtok`, so
      `pam_chauthtok` has to create a ticket cache.  We however don't want it
      to do this for the normal password change (`passwd`) case.

      What we do is set a flag in our PAM data structure saying that we're
      processing an expired password, and `pam_chauthtok`, if it sees that
      flag, redoes the authentication with password prompting disabled after
      it finishes changing the password.

      Unfortunately, when handling password changes this way, `pam_chauthtok`
      will always have to prompt the user for their current password again
      even though they just typed it.  This is because the saved
      authentication tokens are cleared after `pam_authenticate` returns, for
      security reasons.  We could hack around this by saving the password in
      our PAM data structure, but this would let the application gain access
      to it (exactly what the clearing is intended to prevent) and breaks a
      PAM library guarantee.  We could also work around this by having
      `pam_authenticate` get the `kadmin/changepw` authenticator in the
      expired password case and store it for `pam_chauthtok`, but it doesn't
      seem worth the hassle.
  - title: History and Acknowledgements

t/data/generate/pam-krb5/output/readme  view on Meta::CPAN

      login account required /usr/lib/security/pam_unix_account.so.1
      login session required /usr/local/lib/security/pam_krb5.so retain_after_close minimum_uid=100
      login session required /usr/lib/security/pam_unix_session.so.1

  A similar configuration could be used for other services, such as ssh.
  See the pam.conf(5) man page for more information.  When using this
  module with Solaris login (at least on Solaris 8 and 9), you will
  probably also need to add retain_after_close to the PAM configuration to
  avoid having the user's credentials deleted before they are logged in.

  The Solaris Kerberos library reportedly does not support prompting for a
  password change of an expired account during authentication.  Supporting
  password change for expired accounts on Solaris with native Kerberos may
  therefore require setting the defer_pwchange or force_pwchange option
  for selected login applications.  See the description and warnings about
  that option in the pam_krb5(5) man page.

  Some configuration options may be put in the krb5.conf file used by your
  Kerberos libraries (usually /etc/krb5.conf or /usr/local/etc/krb5.conf)
  instead or in addition to the PAM configuration.  See the man page for
  more details.

  The Kerberos library, via pam-krb5, will prompt the user to change their
  password if their password is expired, but when using OpenSSH, this will
  only work when ChallengeResponseAuthentication is enabled.  Unless this
  option is enabled, OpenSSH doesn't pass PAM messages to the user and can
  only respond to a simple password prompt.

  If you are using MIT Kerberos, be aware that users whose passwords are
  expired will not be prompted to change their password unless the KDC
  configuration for your realm in [realms] in krb5.conf contains a
  master_kdc setting or, if using DNS SRV records, you have a DNS entry
  for _kerberos-master as well as _kerberos.

DEBUGGING

  The first step when debugging any problems with this module is to add
  debug to the PAM options for the module (either in the PAM configuration
  or in krb5.conf).  This will significantly increase the logging from the
  module and should provide a trace of exactly what failed and any

t/data/generate/pam-krb5/output/readme  view on Meta::CPAN

      pam_open_session

  During the first pam_authenticate, we can't obtain credentials and
  therefore a ticket cache since the password is expired.  But
  pam_authenticate isn't called again after pam_chauthtok, so
  pam_chauthtok has to create a ticket cache.  We however don't want it to
  do this for the normal password change (passwd) case.

  What we do is set a flag in our PAM data structure saying that we're
  processing an expired password, and pam_chauthtok, if it sees that flag,
  redoes the authentication with password prompting disabled after it
  finishes changing the password.

  Unfortunately, when handling password changes this way, pam_chauthtok
  will always have to prompt the user for their current password again
  even though they just typed it.  This is because the saved
  authentication tokens are cleared after pam_authenticate returns, for
  security reasons.  We could hack around this by saving the password in
  our PAM data structure, but this would let the application gain access
  to it (exactly what the clearing is intended to prevent) and breaks a
  PAM library guarantee.  We could also work around this by having
  pam_authenticate get the kadmin/changepw authenticator in the expired
  password case and store it for pam_chauthtok, but it doesn't seem worth
  the hassle.

t/data/generate/pam-krb5/output/readme-md  view on Meta::CPAN

    login session required /usr/local/lib/security/pam_krb5.so retain_after_close minimum_uid=100
    login session required /usr/lib/security/pam_unix_session.so.1
```

A similar configuration could be used for other services, such as ssh.
See the pam.conf(5) man page for more information.  When using this module
with Solaris login (at least on Solaris 8 and 9), you will probably also
need to add `retain_after_close` to the PAM configuration to avoid having
the user's credentials deleted before they are logged in.

The Solaris Kerberos library reportedly does not support prompting for a
password change of an expired account during authentication.  Supporting
password change for expired accounts on Solaris with native Kerberos may
therefore require setting the `defer_pwchange` or `force_pwchange` option
for selected login applications.  See the description and warnings about
that option in the pam_krb5(5) man page.

Some configuration options may be put in the `krb5.conf` file used by your
Kerberos libraries (usually `/etc/krb5.conf` or
`/usr/local/etc/krb5.conf`) instead or in addition to the PAM
configuration.  See the man page for more details.

The Kerberos library, via pam-krb5, will prompt the user to change their
password if their password is expired, but when using OpenSSH, this will
only work when `ChallengeResponseAuthentication` is enabled.  Unless this
option is enabled, OpenSSH doesn't pass PAM messages to the user and can
only respond to a simple password prompt.

If you are using MIT Kerberos, be aware that users whose passwords are
expired will not be prompted to change their password unless the KDC
configuration for your realm in `[realms]` in `krb5.conf` contains a
`master_kdc` setting or, if using DNS SRV records, you have a DNS entry
for `_kerberos-master` as well as `_kerberos`.

## Debugging

The first step when debugging any problems with this module is to add
`debug` to the PAM options for the module (either in the PAM configuration
or in `krb5.conf`).  This will significantly increase the logging from the
module and should provide a trace of exactly what failed and any available

t/data/generate/pam-krb5/output/readme-md  view on Meta::CPAN

```

During the first `pam_authenticate`, we can't obtain credentials and
therefore a ticket cache since the password is expired.  But
`pam_authenticate` isn't called again after `pam_chauthtok`, so
`pam_chauthtok` has to create a ticket cache.  We however don't want it to
do this for the normal password change (`passwd`) case.

What we do is set a flag in our PAM data structure saying that we're
processing an expired password, and `pam_chauthtok`, if it sees that flag,
redoes the authentication with password prompting disabled after it
finishes changing the password.

Unfortunately, when handling password changes this way, `pam_chauthtok`
will always have to prompt the user for their current password again even
though they just typed it.  This is because the saved authentication
tokens are cleared after `pam_authenticate` returns, for security reasons.
We could hack around this by saving the password in our PAM data
structure, but this would let the application gain access to it (exactly
what the clearing is intended to prevent) and breaks a PAM library
guarantee.  We could also work around this by having `pam_authenticate`
get the `kadmin/changepw` authenticator in the expired password case and
store it for `pam_chauthtok`, but it doesn't seem worth the hassle.

## History and Acknowledgements

t/data/update/pam-krb5/docknot.yaml  view on Meta::CPAN

        login session required /usr/local/lib/security/pam_krb5.so retain_after_close minimum_uid=100
        login session required /usr/lib/security/pam_unix_session.so.1
    ```

    A similar configuration could be used for other services, such as ssh.
    See the pam.conf(5) man page for more information.  When using this module
    with Solaris login (at least on Solaris 8 and 9), you will probably also
    need to add `retain_after_close` to the PAM configuration to avoid having
    the user's credentials deleted before they are logged in.

    The Solaris Kerberos library reportedly does not support prompting for a
    password change of an expired account during authentication.  Supporting
    password change for expired accounts on Solaris with native Kerberos may
    therefore require setting the `defer_pwchange` or `force_pwchange` option
    for selected login applications.  See the description and warnings about
    that option in the pam_krb5(5) man page.

    Some configuration options may be put in the `krb5.conf` file used by your
    Kerberos libraries (usually `/etc/krb5.conf` or
    `/usr/local/etc/krb5.conf`) instead or in addition to the PAM
    configuration.  See the man page for more details.

    The Kerberos library, via pam-krb5, will prompt the user to change their
    password if their password is expired, but when using OpenSSH, this will
    only work when `ChallengeResponseAuthentication` is enabled.  Unless this
    option is enabled, OpenSSH doesn't pass PAM messages to the user and can
    only respond to a simple password prompt.

    If you are using MIT Kerberos, be aware that users whose passwords are
    expired will not be prompted to change their password unless the KDC
    configuration for your realm in `[realms]` in `krb5.conf` contains a
    `master_kdc` setting or, if using DNS SRV records, you have a DNS entry
    for `_kerberos-master` as well as `_kerberos`.
  title: Configuring
- body: |
    The first step when debugging any problems with this module is to add
    `debug` to the PAM options for the module (either in the PAM configuration
    or in `krb5.conf`).  This will significantly increase the logging from the
    module and should provide a trace of exactly what failed and any available
    error information.

t/data/update/pam-krb5/docknot.yaml  view on Meta::CPAN

    ```

    During the first `pam_authenticate`, we can't obtain credentials and
    therefore a ticket cache since the password is expired.  But
    `pam_authenticate` isn't called again after `pam_chauthtok`, so
    `pam_chauthtok` has to create a ticket cache.  We however don't want it to
    do this for the normal password change (`passwd`) case.

    What we do is set a flag in our PAM data structure saying that we're
    processing an expired password, and `pam_chauthtok`, if it sees that flag,
    redoes the authentication with password prompting disabled after it
    finishes changing the password.

    Unfortunately, when handling password changes this way, `pam_chauthtok`
    will always have to prompt the user for their current password again even
    though they just typed it.  This is because the saved authentication
    tokens are cleared after `pam_authenticate` returns, for security reasons.
    We could hack around this by saving the password in our PAM data
    structure, but this would let the application gain access to it (exactly
    what the clearing is intended to prevent) and breaks a PAM library
    guarantee.  We could also work around this by having `pam_authenticate`
    get the `kadmin/changepw` authenticator in the expired password case and
    store it for `pam_chauthtok`, but it doesn't seem worth the hassle.
  title: Implementation Notes
- body: |

t/data/update/pam-krb5/old/sections/configuring  view on Meta::CPAN

    login session required /usr/local/lib/security/pam_krb5.so retain_after_close minimum_uid=100
    login session required /usr/lib/security/pam_unix_session.so.1
```

A similar configuration could be used for other services, such as ssh.
See the pam.conf(5) man page for more information.  When using this module
with Solaris login (at least on Solaris 8 and 9), you will probably also
need to add `retain_after_close` to the PAM configuration to avoid having
the user's credentials deleted before they are logged in.

The Solaris Kerberos library reportedly does not support prompting for a
password change of an expired account during authentication.  Supporting
password change for expired accounts on Solaris with native Kerberos may
therefore require setting the `defer_pwchange` or `force_pwchange` option
for selected login applications.  See the description and warnings about
that option in the pam_krb5(5) man page.

Some configuration options may be put in the `krb5.conf` file used by your
Kerberos libraries (usually `/etc/krb5.conf` or
`/usr/local/etc/krb5.conf`) instead or in addition to the PAM
configuration.  See the man page for more details.

The Kerberos library, via pam-krb5, will prompt the user to change their
password if their password is expired, but when using OpenSSH, this will
only work when `ChallengeResponseAuthentication` is enabled.  Unless this
option is enabled, OpenSSH doesn't pass PAM messages to the user and can
only respond to a simple password prompt.

If you are using MIT Kerberos, be aware that users whose passwords are
expired will not be prompted to change their password unless the KDC
configuration for your realm in `[realms]` in `krb5.conf` contains a
`master_kdc` setting or, if using DNS SRV records, you have a DNS entry
for `_kerberos-master` as well as `_kerberos`.

t/data/update/pam-krb5/old/sections/implementation-notes  view on Meta::CPAN

```

During the first `pam_authenticate`, we can't obtain credentials and
therefore a ticket cache since the password is expired.  But
`pam_authenticate` isn't called again after `pam_chauthtok`, so
`pam_chauthtok` has to create a ticket cache.  We however don't want it to
do this for the normal password change (`passwd`) case.

What we do is set a flag in our PAM data structure saying that we're
processing an expired password, and `pam_chauthtok`, if it sees that flag,
redoes the authentication with password prompting disabled after it
finishes changing the password.

Unfortunately, when handling password changes this way, `pam_chauthtok`
will always have to prompt the user for their current password again even
though they just typed it.  This is because the saved authentication
tokens are cleared after `pam_authenticate` returns, for security reasons.
We could hack around this by saving the password in our PAM data
structure, but this would let the application gain access to it (exactly
what the clearing is intended to prevent) and breaks a PAM library
guarantee.  We could also work around this by having `pam_authenticate`
get the `kadmin/changepw` authenticator in the expired password case and
store it for `pam_chauthtok`, but it doesn't seem worth the hassle.