7.4. Questions and Answers The following questions were obtained from the mailing list and also from private discussions with Windows network administrators. F.A.Q. | 1. Q: | We use NIS for all UNIX accounts. Why do we need winbind? | | A: | You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted passwords that need to be stored in one of the acceptable passdb backends. Your choice of backend is limited to smbpasswd or tdbsam. Winbind is needed to handle the resolution of SIDs from trusted domains to local UID/GID values. On a domain member server, you effectively map Windows domain users to local users that are in your NIS database by specifying the winbind trusted domains only. This causes user and group account lookups to be routed via the getpwnam() family of systems calls. On an NIS-enabled client, this pushes the resolution of users and groups out through NIS. As a general rule, it is always a good idea to run winbind on all Samba servers. | | 2. Q: | Our IT management people do not like LDAP but are looking at Microsoft Active Directory. Which is better? | | A: | Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos infrastructure. Most IT managers who object to LDAP do so because an LDAP server is most often supplied as a raw tool that needs to be configured and for which the administrator must create the schema, create the administration tools, and devise the backup and recovery facilities in a site-dependent manner. LDAP servers in general are seen as a high-energy, high-risk facility. Microsoft Active Directory by comparison is easy to install and configure and is supplied with all tools necessary to implement and manage the directory. For sites that lack a lot of technical competence, Active Directory is a good choice. For sites that have the technical competence to handle Active Directory well, LDAP is a good alternative. The real issue is, What type of solution does the site want? If management wants a choice to use an alternative, they may want to consider the options. On the other hand, if management just wants a solution that works, Microsoft Active Directory is a good solution. | | 3. Q: | We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible to use NIS in place of LDAP? | | A: | Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping the Windows (SMB) encrypted passwords database correctly synchronized across the entire network. Workstations (Windows client machines) periodically change their domain membership secure account password. How can you keep changes that are on remote BDCs synchronized on the PDC? LDAP is a more elegant solution because it permits centralized storage and management of all network identities (user, group, and machine accounts) together with all information Samba needs to provide to network clients and their users. | | 4. Q: | Are you suggesting that users should not log on to a domain member server? If so, why? | | A: | Many UNIX administrators mock the model that the personal computer industry has adopted as normative since the early days of Novell NetWare. The old perception of the necessity to keep users off file and print servers was a result of fears concerning the security and integrity of data. It was a simple and generally effective measure to keep users away from servers, except through mapped drives. UNIX administrators are fully correct in asserting that UNIX servers and workstations are identical in terms of the software that is installed. They correctly assert that in a wellsecured environment it is safe to store files on a system that has hundreds of users. But all network administrators must factor into the decision to allow or reject general user logins to a UNIX system that is principally a file and print server the risk to operations through simple user errors. Only then can one begin to appraise the best strategy and adopt a site-specific policy that best protects the needs of users and of the organization alike. From experience, it is my recommendation to keep general system-level logins to a practical minimum and to eliminate them if possible. This should not be taken as a hard rule, though. The better question is, what works best for the site? | | 5. Q: | In my smb.conf file, I enabled the parameter winbind enable local accounts on all domain member servers, but it does not work. The accounts I put in /etc/passwd do not show up in the options list when I try to set an ACL on a share. What have I done wrong? | | A: | The manual page for this smb.conf file parameter clearly says, "This parameter controls whether or not winbindd will act as a stand-in replacement for the various account management hooks in smb.conf (for example, add user script). If enabled, winbindd will support the creation of local users and groups as another source of UNIX account information available via getpwnam() or getgrgid(), etc...." By default this parameter is already enabled; therefore, the action you are seeing is a result of a failure of identity resolution in the domain. These are the accounts that are available for Windows network domain logons. Providing identity resolution has been correctly configured on the domain controllers as well as on domain member servers. The domain user and group identities automatically map to a valid local UID and GID pair. | | 6. Q: | We want to ensure that only users from our own domain plus from trusted domains can use our Samba servers. In the smb.conf file on all servers, we have enabled the winbind trusted domains only parameter. We now find that users from trusted domains cannot access our servers, and users from Windows clients that are not domain members can also access our servers. Is this a Samba bug? | | A: | The manual page for this winbind trusted domains only parameter says, "This parameter is designed to allow Samba servers that are members of a Samba-controlled domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users in the hosts primary domain. Therefore, the user SAMBA\user1 would be mapped to the account user1 in /etc/passwd instead of allocating a new UID for him or her." This clearly suggests that you are trying to use this parameter inappropriately. A far better solution is to use the valid users by specifying precisely the domain users and groups that should be permitted access to the shares. You could, for example, set the following parameters: [demoshare] path = /export/demodata valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users" | | 7. Q: | What are the benefits of using LDAP for my domain member servers? | | A: | The key benefit of using LDAP is that the UID of all users and the GID of all groups are globally consistent on domain controllers as well as on domain member servers. This means that it is possible to copy/replicate files across servers without loss of identity. When use is made of account identity resolution via winbind, even when an IDMAP backend is stored in LDAP, the UID/GID on domain member servers is consistent, but differs from the ID that the user/group has on domain controllers. The winbind allocated UID/GID that is stored in LDAP (or locally) will be in the numeric range specified in the idmap uid/gid in the smb.conf file. On domain controllers, the UID/GID is that of the POSIX value assigned in the LDAP directory as part of the POSIX account information. | | 8. Q: | Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into my DNS configuration? | | A: | Samba depends on correctly functioning resolution of hostnames to their IP address. Samba makes no direct DNS lookup calls, but rather redirects all name-to-address calls via the getXXXbyXXX() function calls. The configuration of the hosts enTRy in the NSS /etc/nsswitch.conf file determines how the underlying resolution process is implemented. If the hosts enTRy in your NSS control file says: hosts: files dns wins this means that a hostname lookup first tries the /etc/hosts. If this fails to resolve, it attempts a DNS lookup, and if that fails, it tries a WINS lookup. The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS is the preferred name resolution technology. This usually makes most sense when Samba is a client of an Active Directory domain, where NetBIOS use has been disabled. In this case, the Windows 200x autoregisters all locator records it needs with its own DNS server or servers. | | 9. Q: | Our Windows 2003 Server Active Directory domain runs with NetBIOS disabled. Can we use Samba-3 with that configuration? | | A: | Yes. | | 10. Q: | When I tried to execute net ads join, I got no output. It did not work, so I think that it failed. I then executed net rpc join and that worked fine. That is okay, isn't it? | | A: | No. This is not okay. It means that your Samba-3 client has joined the ADS domain as a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication. |
Example 7.3.1. Samba Domain Member in Samba Domain Using LDAP smb.conf File # Global parameters [global] unix charset = LOCALE workgroup = MEGANET2 security = DOMAIN username map = /e t c/samba/smbusers log level = 10 syslog = 0 log file = /var/log/samba/%m max log size = 50 smb ports = 139 name resolve order = wins bcast hosts printcap name = CUPS wins server = 192.168.2.1 ldap suffix = dc=abmas, dc=biz ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap admin dn = cn=Manager, dc=abmas, dc=biz idmap backend = ldap : ldap : //lapdc.abmas.biz idmap uid = 10000 20000 idmap gid = 10000 20000 winbind trusted domains only = Yes printer admin = root printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [printers] comment = SMB Print Spool path = /var/spool/samba guest ok = Yes printable = Yes browseable = No [print$] comment = Printer Drivers path = /var /lib/samba/drivers admin users = root, Administrator write list = root Example 7.3.2. LDIF IDMAP Add-On Load File File: /etc/openldap/idmap.LDIF dn: ou=Idmap,dc=abmas,dc=biz objectClass: organizationalUnit ou: idmap structuralObjectClass: organizationalUnit Example 7.3.3. Configuration File for NSS LDAP Support /etc/ldap.conf URI ldap://massive.abmas.biz ldap://massive.abmas.biz:636 host 192.168.2.1 base dc=abmas,dc=biz binddn cn=Manager,dc=abmas,dc=biz bindpw not24get pam_password exop nss_base_passwd ou=People,dc=abmas,dc=biz?one nss_base_shadow ou=People,dc=abmas,dc=biz?one nss_base_group ou=Groups,dc=abmas,dc=biz?one ssl no Example 7.3.4. NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf passwd: files ldap shadow: files ldap group: files ldap hosts: files dns wins networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files aliases: files Example 7.3.5. Samba Domain Member Server Using Winbind smb.conf File for NT4 Domain # Global parameters [global] unix charset = LOCALE workgroup = MEGANET2 security = DOMAIN username map = /etc/samba/smbusers log level = 1 syslog = 0 log file = /var/log/samba/%m max log size = 0 smb ports = 139 name resolve order = wins bcast hosts printcap name = CUPS wins server = 192.168.2.1 idmap uid = 10000 20000 idmap gid = 10000 20000 template primary group = "Domain Users " template shell = /bin /bash winbind separator = + printer admin = root hosts allow = 192.168.2., 192.168.3., 127. printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [printers] comment = SMB Print Spool path = /var/spool/samba guest ok = Yes printable = Yes browseable = No [print$] comment = Printer Drivers path = /var /lib/samba/drivers admin users = root, Administrator write list = root Example 7.3.6. Samba Domain Member Server Using Local Accounts smb.conf File for NT4 Domain # Global parameters [global] unix charset = LOCALE workgroup = MEGANET3 netbios name = BSDBOX security = DOMAIN username map = /etc/samba/smbusers log level = 1 syslog = 0 add user script = /usr /sbin /useradd m '%u' add machine script = /usr /sbin /useradd M '%u' add group script = /usr /sbin /groupadd '%g ' winbind enable local accounts = Yes log file = /var/log/samba/%m max log size = 0 smb ports = 139 name resolve order = wins bcast hosts printcap name = CUPS wins server = 192.168.2.1 printer admin = root hosts allow = 192.168.2., 192.168.3., 127. printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [printers] comment = SMB Print Spool path = /var/spool/samba guest ok = Yes printable = Yes browseable = No [print$] comment = Printer Drivers path = /var /lib/samba/drivers admin users = root, Administrator write list = root Example 7.3.7. Samba Domain Member smb.conf File for Active Directory Membership # Global parameters [global] unix charset = LOCALE workgroup = LONDON realm = LONDON.ABMAS. BIZ server string = Samba 3.0.20 security = ADS username map = /etc/samba/smbusers log level = 1 syslog = 0 log file = /var/log/samba/%m max log size = 50 printcap name = CUPS ldap ssl = no idmap uid = 10000 20000 idmap gid = 10000 20000 template primary group = "Domain Users " template shell = /bin/bash winbind separator = + printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [printers] comment = SMB Print Spool path = /var/spool/samba guest ok = Yes printable = Yes browseable = No [print$] comment = Printer Drivers path = /var/lib/samba/drivers admin users = root, Administrator write list = root Example 7.3.8. Example smb.conf File Using idmap_rid # Global parameters [global] workgroup = KPAK netbios name = BIGJOE realm = CORP.KPAK.COM server string = Office Server security = ADS allow trusted domains = No idmap backend = idmap_rid :KPAK=500100000000 idmap uid = 500 100000000 idmap gid = 500 100000000 template shell = /bin/bash winbind use default domain = Yes winbind enum users = No winbind enum groups = No winbind nested groups = Yes printer admin = "KPAK\Domain Admins" Example 7.3.9. Typical ADS Style Domain smb.conf File # Global parameters [global] workgroup = SNOWSHOW netbios name = GOODELF realm = SNOWSHOW.COM server string = Samba Server security = ADS log level = 1 ads :10 auth :10 sam:10 rpc :10 ldap admin dn = cn=Manager, dc=SNOWSHOW, dc=COM ldap idmap suffix = ou=Idmap ldap suffix = dc=SNOWSHOW, dc=COM idmap backend = ldap : ldap : //ldap.snowshow.com idmap uid = 150000 550000 idmap gid = 150000 550000 template shell = /bin /bash winbind use default domain = Yes Example 7.3.10. ADS Membership Using RFC2307bis Identity Resolution smb.conf File # Global parameters [global] workgroup = BUBBAH netbios name = MADMAX realm = BUBBAH.COM server string = Samba Server security = ADS idmap uid = 150000 550000 idmap gid = 150000 550000 template shell = /bin /bash winbind use default domain = Yes winbind trusted domains only = Yes winbind nested groups = Yes Example 7.3.11. SUSE: PAM login Module Using Winbind # /etc/pam.d/login #%PAM-1.0 auth sufficient pam_unix2.so nullok auth sufficient pam_winbind.so use_first_pass use_authtok auth required pam_securetty.so auth required pam_nologin.so auth required pam_env.so auth required pam_mail.so account sufficient pam_unix2.so account sufficient pam_winbind.so user_first_pass use_authtok password required pam_pwcheck.so nullok password sufficient pam_unix2.so nullok use_first_pass use_authtok password sufficient pam_winbind.so use_first_pass use_authtok session sufficient pam_unix2.so none session sufficient pam_winbind.so use_first_pass use_authtok session required pam_limits.so Example 7.3.12. SUSE: PAM xdm Module Using Winbind # /etc/pam.d/gdm (/etc/pam.d/xdm) #%PAM-1.0 auth sufficient pam_unix2.so nullok auth sufficient pam_winbind.so use_first_pass use_authtok account sufficient pam_unix2.so account sufficient pam_winbind.so use_first_pass use_authtok password sufficient pam_unix2.so password sufficient pam_winbind.so use_first_pass use_authtok session sufficient pam_unix2.so session sufficient pam_winbind.so use_first_pass use_authtok session required pam_dev perm.so session required pam_resmgr.so Example 7.3.13. Red Hat 9: PAM System Authentication File: /etc/pam.d/system-auth Module Using Winbind #%PAM-1.0 auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_winbind.so use_first_pass password required /lib/security/$ISA/pam_cracklib.so retry=3 type= # Note: The above line is complete. There is nothing following the '=' password sufficient /lib/security/$ISA/pam_unix.so \ nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_winbind.so use_first_pass password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session sufficient /lib/security/$ISA/pam_unix.so session sufficient /lib/security/$ISA/pam_winbind.so use_first_pass |