BIG FAT NOTE: I'm not saying that I wrote this from scratch, This pre-article was collected from the Linux PAM FAQ, Documentation, From google, From the man pages, Mixed with some dead brain cells.

PAM = Pluggable Authentication Modules.

The PAM Idea is very simple:
Any application require authentication or want to authenticate users can link against PAM. But suppose that we have 2 methods for authentication: password files and ldap for example, In this case if we are not using PAM, and we are writing an application to authenticate the users, we'll have to implement both authentication methods, and if we want to add a 3rd method later, then we'll have to implement it again. This maybe simple for 1 or 2 apps. but now we have login, ftpd, sshd, telnetd, samba, ........ All of them need authentication.

The idea was simple, PAM, We'll write a library, this library'll be asked to do the actual authentication. and various authentication backends can be implemented as "plugins" or modules, So when we want to add a new authentication method "NIS For example" we'll have to only write a "module" for PAM and then all the PAM aware application can use it immediately.
So to authenticate a user via a PAM aware application, The application request that the user be authenticated, and PAM'll handle all the dirty stuff ;-)

Linux-PAM deals with four separate types of management tasks:

• authentication management: this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Secondly, the module can grant group membership (independently of the /etc/groups file discussed above) or other privileges through its credential granting properties.
• account management: this module performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user---`root' login only on the console.
• session management: primarily, this module is associated with doing things that need to be done for the user before/after they can be given service. Such things include the logging of information concerning the opening/closing of some data exchange with a user, mounting directories, etc.
• password management: this last module type is required for updating the authentication token associated with the user. Typically, there is one module for each `challenge/response' based authentication (auth) module-type.

control-flag:

A PAM application will either exit with success or with failure. A control flag tells PAM what to do with this exit status. There are different kinds of control flags, or behavior in handling exit status:

• required: The success of the module is required for the module-type facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.
• requisite: like required, however, in the case that such a module returns a failure, control is directly returned to the application. The return value is that associated with the first required or requisite module to fail. Note, this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.
• sufficient: the success of this module is deemed `sufficient' to satisfy the Linux-PAM library that this module-type has succeeded in its purpose. In the event that no previous required module has failed, no more `stacked' modules of this type are invoked. (Note, in this case subsequent required modules are not invoked.). A failure of this module is not deemed as fatal to satisfying the application that this module-type has succeeded.
• optional: as its name suggests, this control-flag marks the module as not being critical to the success or failure of the user's application for service. In general, Linux-PAM ignores such a module when determining if the module stack will succeed or fail. However, in the absence of any definite successes or failures of previous or subsequent stacked modules this module will determine the nature of the response to the application. One example of this latter case, is when the other modules return something like PAM_IGNORE.

Arguments which are likely to be understood by any module:

• debug: Use the syslog(3) call to log debugging information to the system log files.
• no_warn: Instruct module to not give warning messages to the application.
• use_first_pass: The module should not prompt the user for a password. Instead, it should obtain the previously typed password (from the preceding auth module), and use that. If that doesn't work, then the user will not be authenticated. (This option is intended for auth and password modules only).
• try_first_pass: The module should attempt authentication with the previously typed password (from the preceding auth module). If that doesn't work, then the user is prompted for a password. (This option is intended for auth modules only).
• use_mapped_pass: This argument is not currently supported by any of the modules in the Linux-PAM distribution because of possible consequences associated with U.S. encryption exporting restrictions. Within the U.S., module developers are, of course, free to implement it (as are developers in other countries). For compatibility reasons we describe its use as suggested in the DCE-RFC 86.0, see section ``bibliography'' for a pointer to this document. The use_mapped_pass argument instructs the module to take the clear text authentication token entered by a previous module (that requests such a token) and use it to generate an encryption/decryption key with which to safely store/retrieve the authentication token required for this module. In this way the user can enter a single authentication token and be quietly authenticated by a number of stacked modules. Obviously a convenient feature that necessarily requires some reliably strong encryption to make it secure. This argument is intended for the auth and password module types only.
• expose_account: In general the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as users names or home directories, or preferred shell, can be used to attack a user's account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user's full name when asking them for a password in a secured environment could also be called being 'friendly'. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as it is deemed appropriate by the local administrator.