From: Andreas Schneider Date: Fri, 5 Dec 2025 10:19:32 +0000 (+0100) Subject: docs-xml: Update krb5_ccache_type documentation in pam_winbind.5 manpage X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f2013d5209983ea4cb6a3b6ca05bad424c2d5784;p=thirdparty%2Fsamba.git docs-xml: Update krb5_ccache_type documentation in pam_winbind.5 manpage Signed-off-by: Andreas Schneider Reviewed-by: Alexander Bokovoy --- diff --git a/docs-xml/manpages/pam_winbind.conf.5.xml b/docs-xml/manpages/pam_winbind.conf.5.xml index 3d9cb491505..b87c210c13c 100644 --- a/docs-xml/manpages/pam_winbind.conf.5.xml +++ b/docs-xml/manpages/pam_winbind.conf.5.xml @@ -115,38 +115,56 @@ by enabling the krb5_auth option, it can store the retrieved Ticket Granting Ticket (TGT) in a credential cache. The type of credential cache can be - controlled with this option. The supported values are: - KCM or KEYRING - (when supported by the system's Kerberos library and - operating system), - FILE and DIR - (when the DIR type is supported by the system's Kerberos - library). In case of FILE a credential cache in the form of - /tmp/krb5cc_UID will be created - in case of DIR you NEED - to specify a directory. UID is replaced with the numeric - user id. The UID directory is being created. The path up to - the directory should already exist. Check the details of the - Kerberos implementation. - - When using the KEYRING type, the supported mechanism is - KEYRING:persistent:UID, which uses the Linux - kernel keyring to store credentials on a per-UID basis. - The KEYRING has its limitations. As it is secure kernel memory, - for example bulk storage of credentials is not possible. - - When using the KCM type, the supported mechanism is - KCM:UID, which uses a Kerberos credential - manager to store credentials on a per-UID basis similar to - KEYRING. This is the recommended choice on latest Linux - distributions, offering a Kerberos Credential Manager. If not - we suggest to use KEYRING as that is the most secure and - predictable method. - - It is also possible to define custom filepaths and use the "%u" - pattern in order to substitute the numeric user id. - Examples: + controlled with this option. + + The following simple type names are supported (these will + generate default paths with the user's UID): + + KCM + Uses Kerberos Credential Manager + (generates KCM:<UID>). This is the + recommended choice on latest Linux distributions + offering a Kerberos Credential Manager. + + + KEYRING + Uses Linux kernel keyring + (generates KEYRING:persistent:<UID>). + The KEYRING has its limitations. As it is secure + kernel memory, for example bulk storage of + credentials is not possible. This is a good + fallback if KCM is not available. + + + FILE + Uses file-based credential cache + (generates FILE:/tmp/krb5cc_<UID>). + + + + WRFILE + Uses file-based credential cache with + write-only mode (generates WRFILE:/tmp/krb5cc_<UID>). + + + + + It is also possible to specify custom paths with explicit + prefixes. The following prefixes are recognized: + KEYRING:type, + DIR:/path, + FILE:/path, and + WRFILE:/path. + You can use the %u pattern to substitute the + numeric user ID. Examples: + + + + krb5_ccache_type = KEYRING:session:%u + This will use a session keyring for the credential cache. + krb5_ccache_type = DIR:/run/user/%u/krb5cc This will create a credential cache file in the specified directory. @@ -155,9 +173,13 @@ krb5_ccache_type = FILE:/tmp/krb5cc_%u This will create a credential cache file. + + krb5_ccache_type = WRFILE:/var/lib/sss/ccache/ccache_%u + This will create a write-only credential cache file. + - Leave empty to just do kerberos authentication without + Leave empty to just do kerberos authentication without having a ticket cache after the logon has succeeded. This setting is empty by default.