Labels

new blog 2.0

2008/06/14

0x05. [LPIC-302] User and Group Management

Managing User Accounts and Groups
Candidates should be able to manage user and group accounts in a mixed environment

Exploring this chapter some knowledge about SIDs can be useful (See Terms Glossary). Basically every object, be it a group, user, domain or machine has it's SID. Samba provides you with the "net" program to find out about SIDs and not only. E.g.

# net getlocalsid
# net sam show oozie
Users can be added with 'smbpasswd -a' which stores the information about the password in three possible locations:
  • smbpasswd file, if passdb backend = smbpasswd
  • TDB file, if passdb backend = tdbsam
  • LDAP directory, if passdb backend = ldapsam
Mapping users
Since usernames on Microsoft systems can violate the rules applied to Unix usernames, Samba provides the administrator with username mapping functionality. This is independent from the backend used. For translating Windows to Unix usernames Samba can use dictionary file, typically called smbusers, or a script/program that takes the windows username as it's first argument and returns it's Unix counterpart. smb.conf options to achieve that are:
  • username map = filename
  • username map script = /absolute/path/to/script
Username map dictionary has a simple syntax of 'map_to_username = map_from'. If the entry is prefixed with &,@ or a + then it makes it a NIS or Unix netgroup.

Samba associates Unix groups with Windows SIDs and this way presents it to Windows clients.
Group attributes can be modified with 'net groupmap'.

smbpasswd cheatsheet

smbpasswd -a = adds a user
smbpasswd -d = disables an account
smbpasswd -e = reenables an account
smbpasswd (without options) = changes user's password
smbpasswd -x = remove account
smbpasswd -n = set accounts password to null value

force user / force group
The options named above force authenticated users to perform operations on the shares as some other users. This is useful, especially in case of 'force group', to either restrict or extend file sharing. Please refer to smb.conf for more details.

Identity mapping (IDMAP)
If Samba operates as a standalone server there is no need for extensive identity mapping, because the users and groups are managed locally. A need for IDMAP facility occures when Samba is a member of
  • Windows NT4 domain
  • Active Directory domain
  • Samba Domain
hence it requires a running instance of winbindd. There is a number of situations for which we deploy the winbind server to help with IDMAP.

Authentication and Authorization
Candidates should understand the various authentication mechanisms and configure access control

Setting up a local password database can be achieved by setting 'passdb backend' to smbpasswd or tdbsam. The former setting will use flat database (text) file of the following format:

username:uid:LM hash:NT hash:flags:last_change

where flags are:
  • U - a user a account
  • N - no password
  • D - account disabled
  • W - machine trust account
... whereas the latter will store passwords in passdb.tdb.

Password Synchronization

There are many reasons why Samba administrators want Samba users to have a common password for SMB and Unix. Normally, a user has to change her password twice, with Unix passwd command and then with smbpasswd. This will almost certainly not keep consistency between databases. Here is where pam_smbpass.so comes in handy. It is used to keep /etc/shadow and smbpasswd consistent.
Please find examples for pam_smbpass.so config here.

Winbind
Candidates should be able to install and configure the Winbind service


Winbind combines together PAM, NSS and MSRPC and allows "Windows NT domain users to appear and operate as UNIX users on a UNIX machine" (quotation from Samba Howto - Chapter24). It includes two core functalities:
  • Authentication of users with help of PAM and ntlm_auth program. This comprises:
    • obtaining user/group information
    • authentication
    • password changing

  • Identity resolution used for IDMAP and maintanance of IDMAP table. winbind stores the mappings into tdb file as it goes along and finds out about new ones.
The main binary lives in /usr/sbin/winbindd or /usr/local/sbin/winbindd. To read the configuration winbind refers to smb.conf. Below is a snippet extracted from Samba howto:
[global]
# separate domain and username with '\', like DOMAIN\username
winbind separator = \
# use uids from 10000 to 20000 for domain users
idmap uid = 10000-20000
# use gids from 10000 to 20000 for domain groups
idmap gid = 10000-20000
# allow enumeration of winbind users and groups
winbind enum users = yes
winbind enum groups = yes
# give winbind users a real shell (only needed if they have telnet access)
template homedir = /home/winnt/%D/%U
template shell = /bin/bash
pam_winbind.so is the PAM module responsible for talking to winbind.

Do not run NSCD on a computer that runs winbindd at the same time. If you do, it will be impossible to resolve domain users and groups for directory system controls.

2 comments:

Anonymous said...

I've done LPI-302 ~month ago and to me it felt much easier than LPIC-3.

OOZIE said...

I agree that LPI-302 was easier than LPI-301.