Samba and PAM [ Re: VFS Implementation and user authentication]b

[Nicolas Williams]

I am writing a draft on using Andrew Morgan's PAM binary prompts to
enable PAM and PAM modules to be involved in authentication schemes
other than initial authentication, i.e., pass-through authentication,
e.g., NTLM, Kerberos, SASL, GSS-API, etc...

Essentially it will allow PAM config for Samba, telnet and such services
to look like this:

auth sufficient pam_sso_krb5
auth sufficient pam_sso_ntlm
auth required pam_deny

or

auth optional pam_sso_sasl
auth optional pam_sso_gss
auth sufficient pam_sso_krb5
auth sufficient pam_sso_ntlm
auth required pam_deny

or

auth optional pam_sso_sasl
auth optional pam_sso_gss
auth optional pam_sso_krb5
auth optional pam_sso_ntlm
auth optional pam_surs
auth required pam_sso_mgmt
account required pam_k5login
account required pam_sso_mgmt min_qop=integrity

The proposal involves several protocols, not network protocols, but
protocols by which the apps and PAM modules should interact with each
other.

One protocol allows modules to drive the authentication token exchange
with the client via PAM binary prompts. This protocol would be optional
as the app can do the exchange wholly on its own.

Another protocol would allow the app to pass stuff like Kerberos and GSS
contexts the modules when the app does the token exchange on its own.
Alternatively, when a module drives the token exchange it can use this
protocol to pass stuff like Kerberos and GSS contexts, principal names,
etc... to the app.

A third protocol allows the modules to communicate with each other via
PAM module data (see pam_set_data() and pam_get_data()). This is useful
so modules implementing authentication systems like SASL or GSS-API that
encapsulate sub-mechanism can share the sub-mechanism data with the
corresponding PAM modules, and also so that pam_sso_mgmt can check on
mechanism data and enforce policy, such as minimum session
quality-of-protection.

Finally, a veneer library could be written such that apps need not even
concern themselves with any detail of the underlying authentication
technologies beyond those details needed to negotiate authentication and
send/receive tokens.

Note that network protocols wouldn't have to be changed in order to
modify server software to use this system.

Note also that this an abstraction of the authentication systems' APIs,
not of the authentication tokens, whereas GSS-API and SASL are both. The
main reason for wanting to do this is PAM is that PAM provides things
which GSS-API and SASL don't (yet?), namely account authorization,
credentials management and session management. And in the future, when
other extensions are made to PAM, such as adding a PAM_REALM item or a
PAM events system, the value of PAM being useable in pass-through
authentication will increase.

Also, no changes to libpam are needed. This scheme can work with
LinuxPAM as is. To make it work with Solaris PAM one would need only
define the PAM binary prompt type constants, methinks.

I know, I have to finish writing this up...

Nico
--