一、综述
Samba通过两个程序：smbd和nmbd向局域网络提供文件服务。其中nmbd是Netbios名字解析程序，通常系统中只运行一个nmbd进程；smbd是真正提供文件服务的程序，通常每有一个客户发出请求，Samba服务器就会启动一个smbd进程。
nmbd和smbd共用一个配置文件：smb.conf。在Debian Etch中，这个文件位于/etc/samba目录下。Samba会自动每隔60s就重读一次这个文件的内容。所以，每次修改这个文件并存盘后，可以等待60s以使新的配置选项生效，也可以使用/etc/init.d/samba restart脚本手工重启进程。在正式使用一个新的进程之前，可以使用testparm来检验文件语法是否正确。
二、认证和权限
Samba的认证过程我理解分成两个步骤。
1．首先Samba将客户端提供的用户名、密码与本地数据库中的记录进行对比，如果符合，则给予客户端访问共享资源的权限。这个过程好像进一个屋子要先拿出正确的钥匙。
2．但是进入了屋子并不意味着就能随意使用屋子里面的所有东西。Samba根据某些规则，决定客户端是否能访问特定文件或使用其他资源（比如打印机）。这里的规则有在smb.conf文件里面定义的，更重要的是基于Linux文件权限系统的。smbd进程会以上一步通过验证的用户具有的权限去访问文件（这就意味这上一步传递给Sambe验证的用户名必须在服务器的/etc/passwd文件里有对应的项目）。
三、认证过程
1．Samba对客户端身份的认证有四种手段：共享级（share-level）、用户级（user-level）、服务器级（server-level）、域认证（domain-level）。后三种手段本质上很相似，区别在于验证发生的位置不同。user-level下，这一过程就发生在Samba服务器上；server-level下则发生在另一台服务器上；domain-level下，由PDC或BDC完成认证。
2．share-level和user-level是最常用的两种认证手段，user-level是Samba配置的默认值。
这两种模式在客户端的区别表现在：share-level模式下客户端不需要输入用户名，只要输入密码就可以了；user-level模式下客户端要同时输入用户名和密码才行。
而在服务器端，这两种模式的区别很小：Samba都要使用用户名、密码组合进行身份验证。user-level下，Samba会把客户端传递来的用户名和密码与本地数据库中的记录进行检验。share-level下，因为客户端没有传递用户名，Samba会使用smb.conf文件中某个资源段提供的用户名，以及编译Samba过程中置入的默认用户名分别与密码进行组合，然后与本地数据库中的记录进行对比，只要有一个组合能通过验证，就让客户端以对应用户名对应用户拥有的权限访问共享资源。假如所有的组合都没有通过验证，则拒绝客户端的访问。
在share-level下有中特殊情况是，假如某个共享资源设置了
guest ok = yes
guest only = yes
guest account = 某个用户的账户
当客户端连接时，Samba自动把guest account指定账户拥有的权限赋予客户端以访问共享资源，此时，客户端甚至不需要提供密码。
四、密码传输
不管是share-level还是user-level，都可以在smb.conf文件里指定Samba服务器如何解释接收到的客户端发来的密码：密码可以是明文的形式也可以是加密的形式。客户端采用那种方式发送密码则有客户端的操作系统决定，例如，Windows 95只能以明文形式发送密码，Windows XP默认以加密的形式发送密码，但可以在注册表里改动以使其发送明文密码。所以，假如有多种不同版本的客户端，就需要在Samba服务器上同时维护明文形式的密码数据库和加密形式的密码数据库。
在smb.conf文件里面使用encrypt passwords = yes/no来配置Samba如何解释接收到的密码。
当Samba配置成以明文形式解释传递来的密码时，它使用/etc/passwd作为检验的依据；当Samba配置成以加密形式解释传递来的密码时，它使用smbpasswd作为检验的依据（Debian Etch中，这个文件默认位于/etc/samba目录下，但可以在smb.conf文件中指定它的位置。）
（我的想法：Linux用户存储在/etc/passwd或/etc/shadow文件里面的密码也是经过加密的，但是这种加密算法，Windows客户端并不支持。这样，客户端不能在本地用同样的算法先将密码加密然后再通过网络发送，而只能将密码以明文形式传递给Samba服务器，由Samba服务器将其按照/etc/passwd支持的算法将其转换后与/etc/passwd中的记录进行对比。
密码明文传输的危险显而易见，所以Windows改成将密码先加密后在发送给服务器，但问题是Windows加密密码用的算法和/etc/passwd使用的算法不同，所以Samba不能直接将接受到的明文密码与/etc/passwd进行比较。而且Windows使用的是一种单向的算法。这就意味着Samba接收到客户端传递来的加密后的密码是不能从中恢复出密码的明文，在进一步转换后与/etc/passwd进行比较。一句话就是，在加密密码的情况下，/etc/passwd或者/etc/shadow文件不能作为验证的依据了。）
因为smbpasswd文件与/etc/passwd文件是独立的，所以Samba共享资源的用户密码可以和登录密码不同。但是smbpasswd文件里面每个用户都必须在/etc/passwd文件里面有对应的记录，因为一旦通过验证后，Samba将使用这个用户对应的权限赋予客户端以访问相应的资源。