Collection of web resources to understand SAMBA configuration:

Old Windows clients send plaintext passwords over the wire. Samba can check these passwords by encrypting them and comparing them to the hash stored in the UNIX user database.

Newer Windows clients send encrypted passwords (LanMan and NT hashes) instead of plaintext passwords over the wire. The newest clients will send only encrypted passwords and refuse to send plaintext passwords unless their registry is tweaked.

Many people ask why Samba cannot simply use the UNIX password database. Windows requires passwords that are encrypted in its own format. The UNIX passwords can’t be converted to Windows-style encrypted passwords. Because of that, you can’t use the standard UNIX user database, and you have to store the LanMan and NT hashes somewhere else.

In addition to differently encrypted passwords, Windows also stores certain data for each user that is not stored in a UNIX user database: for example, workstations the user may logon from, the location where the user’s profile is stored, and so on. Samba retrieves and stores this information using a passdb backend. Commonly available backends are LDAP, tdbsam, and plain text file. For more information, see the man page for smb.conf regarding the passdb backend parameter.

Resolution of SIDs to UIDs:


Resolution of UIDs to SIDs:


My prefered method to integrate a SAMBA server into a Windows domain (AD member server):

Time synchro: ntp                      : must be in-sync with the AD domain time to avoid clock skew and kerberos tickets problems

Kerberos: krb5.conf                  : must contain AD DC servers

Nsswitch.conf                           ; must contain: files winbind

Stop nscd                                 ; to avoid problems with naming resolution

Resolv.conf                              ; must resolve AD domain (DNS)

Net ads join                              ; to join the Samba servers to the GAD