Skip to content

Slap’d SMB services

Yet again the internets fail. I have simple requirements, and I can’t get simple answers.

  • Manage accounts via LDAP (outside of AD for various reasons)
  • Provide file services against LDAP accounts
  • Set access controls and log everything

No one site has all the answers, nor do they hint what parts are missing. This is how it works.

  1. When authenticates users against LDAP, it does so by comparing the client-provided encrypted hash to the implicitly cleartext hash string stored in the LDAP directory. This is analogous to how Windows works, where the client hashes the user input then uses the hash to communicate with the server so that actual mechanisms are not transmitted over the wire. As a result, the LDAP server must be hardened via ACL’s and SSL and firewall rules for protection.
  2. The slapd configuration needs to have the samba schema loaded. For cn=config methods, you will need to slaptest in the schema, strip the output, copy to the cn=schema folder, and restart slapd. The schema is obtained from the base ‘samba’ package.
  3. Filesystem ACL’s are necessarily still managed by the OS. Therefore, the OS must know about the user accounts and groups. Use pam_ldap and nsswitch settings to delegate system authentication to LDAP. For Centos/RHEL, use ‘authconfig-tui’ for easy setup. Samba manages the network access as an application. Samba queries the samba password hashes in LDAP to authenticate users. Samba queries the posix attributes in LDAP to dynamically map users/groups to OS mappings. Test LDAP by ssh’ing into your server with an LDAP account not in the local passwd.
  4. The smb.conf file needs to be setup for ldap auth. See for all options.
  5. The ‘ldap admin dn’ specified in the conf file needs it’s password loaded into secrets.tdb with ‘smbpasswd -w cleartext’. This also populates content into the LDAP tree, such as the sambaDomainName.
  6. User accounts at this point will *not* work with Samba, as they are missing lots of mandatory attributes. Get the smbldap-tools from Also mkntpwd can be helpful for initial testing.
  7. Crank up the logging in smb as you will need lots of details. Split the logs by host (default) and set auth loglevel to 5~10.
  8. A raw posix / inetorgperson object will initially fail due to the lack of sambaNTPassword attributes. mkntpwd can generate these for you, but use smbldap-passwd instead. You’ll want to link all these scripts in to your smb.conf file.
  9. ‘ldap passwd sync’ in the smb.conf file can be used to link posix userPassword changes to changes initiated >from< samba, but not necessarily the other direction. Mainly for domain usage context.
  10. Don’t forget about ‘testparm -v’ to capture all the defaults as well as syntax sanity checks. The defaults should generally be xp/vista/7 compatible now, you shouldn’t need to do anything exotic.
  11. When you connect to a network share at this point, if your Windows username is not found in LDAP with the objectClass of sambaSamAccount you’ll get a sam authentication failure NT_STATUS_NO_SUCH_USER.
  12. Missing sambaNTPassword attribute *OR* a hash mismatch will give you NT_STATUS_WRONG_PASSWORD
  13. The next attribute set you will run into is sambaPwdCanChange and sambaPwdMustChange, with the associated sambaKickoffTime and sambaPwdLastSet. See list of NT_STATUS codes here. This is a ‘good’ thing if you have the attribute values set properly, but is the same nuisance value for the default of zero (equivalent to 1/1/1970). You’ll need the smbldap-tools package to set these sanely. Note that the Centos 6 package on repoforge is 0.9.5 and won’t update the perl requirements, get the 0.9.7 noarch from instead.
  14. moar to follow…