PAM 借由一个与程序相同文件名的配置文件来进行一连串的认证分析需求。我们同样以passwd 这个指令的调用 PAM 来说明好了。 当你执行 passwd 后，这支程序调用 PAM 的流程是：
1. 使用者开始执行 /usr/bin/passwd 这支程序，并输入密码；
2. passwd 调用 PAM 模块进行验证；
3. PAM 模块会到 /etc/pam.d/ 找寻与程序 （passwd） 同名的配置文件；
4. 依据 /etc/pam.d/passwd 内的设置，引用相关的 PAM 模块逐步进行验证分析；
5. 将验证结果 （成功、失败以及其他讯息） 回传给 passwd 这支程序；
6. passwd 这支程序会根据 PAM 回传的结果决定下一个动作 （重新输入新密码或者通过验证）
下面是/etc/pam.d/passwd 这个配置文件的内容：
在这个配置文件当中，除了第一行宣告 PAM 版本之外，其他任何“ # ”开头的都是注解，而每一行都是一个独立的验证流程， 每一行可以区分为三个字段，分别是验证类别（type）、控制标准（flag）、PAM的模块与该模块的参数。
你会发现在我们上面的表格当中出现的是“ include （包括） ”这个关键字，他代表的是“请调用后面的文件来作为这个类别的验证”， 所以，上述的每一行都要重复调用/etc/pam.d/system-auth 那个文件来进行验证的意思。
第一个字段：验证类别 （Type）
验证类别主要分为四种，分别说明如下：
auth 是 authentication （认证） 的缩写，所以这种类别主要用来检验使用者的身份验证，这种类别通常是需要密码来检验的， 所以后续接的模块是用来检验使用者的身份。
account account （帐号） 则大部分是在进行 authorization （授权），这种类别则主要在检验使用者是否具有正确的使用权限， 举例来说，当你使用一个过期的密码来登陆时，当然就无法正确的登陆了。
session session 是会议期间的意思，所以 session 管理的就是使用者在这次登陆 （或使用这个指令） 期间，PAM 所给予的环境设置。 这个类别通常用在记录使用者登陆与登出时的信息！例如，如果你常常使用 su 或者是 sudo 指令的话， 那么应该可以在/var/log/secure 里面发现很多关于 pam 的说明，而且记载的数据是“session open,session close”的信息。
password password 就是密码。所以这种类别主要在提供验证的修订工作，举例来说，就是修改/变更密码。
这四个验证的类型通常是有顺序的，不过也有例外就是了。 会有顺序的原因是，（1）我们总是得要先验证身份 （auth） 后， （2）系统才能够借由使用者的身份给予适当的授权与权限设置 （account），而且（3）登陆与登出期间的环境才需要设置， 也才需要记录登陆与登出的信息 （session）。如果在运行期间需要密码修订时，（4）才给予 password 的类别。
第二个字段：验证的控制旗标 （control flag）
required 此验证若成功则带有 success （成功） 的标志，若失败则带有 failure 的标志，但不论成功或失败都会继续后续的验证流程。 由于后续的验证流程可以继续进行，因此相当有利于数据的登录 （log） ，这也是 PAM 最常使用 required 的原因。
requisite 若验证失败则立刻回报原程序 failure 的标志，并终止后续的验证流程。若验证成功则带有 success 的标志并继续后续的验证流程。 这个项目与 required 最大的差异，就在于失败的时候还要不要继续验证下去？由于 requisite 是失败就终止， 因此失败时所产生的 PAM 信息就无法通过后续的模块来记录了。
sufficient 若验证成功则立刻回传 success 给原程序，并终止后续的验证流程；若验证失败则带有 failure 标志并继续后续的验证流程。 这玩意儿与 requisits 刚好相反。
optional 这个模块控制项目大多是在显示讯息而已，并不是用在验证方面的。
如果将这些控制旗标以图示的方式配合成功与否的条件绘图，会有点像下面这样：
图13.5.2、PAM 控制旗标所造成的回报流程
程序运行过程中遇到验证时才会去调用 PAM ，而 PAM 验证又分很多类型与控制，不同的控制旗标所回报的讯息并不相同。 如上图所示， requisite 失败就回报了并不会继续，而sufficient 则是成功就回报了也不会继续。 至于验证结束后所回报的信息通常是“succes 或failure ”而已，后续的流程还需要该程序的判断来继续执行才行。
