Monday, April 7, 2008

Step by Step: Using Samba to join a Windows Domain

by Judith Myerson
04/01/2008

In this article, I give you the steps you need to use Samba to join to a Windows domain. The primary domain controller (PDC) will serve as the password server for the domain. If Samba and winbind services are running, turn them off. I will show you how turn them on after you join to the Windows domain. You should save your files at any point in your "work-in-progress" and restore your originals if you intend to reboot. You should make note of your hard devices listed in your fstab file. Before you start you should ping the server from your intended Linux workstation.

Step 1. Join the Samba Server

You must join the Samba server before you join the Linux client and then test the Linux password. If the Samba server already has been joined, go to Step 3.

To join the server to the domain, you must have name resolution to your password server and an administrative account so you can join your Linux workstation to the domain. To do this, you first create the domain account to change a user's SMB password and then test winbind and local system accounts and groups.

To create the password, run as a root user. Type:

smbpasswd
[ - j MYDOMAIN] [ - r PDC ] [-U user-name]

Here is how each option in the password works.

Option 1: -j MYDOMAIN

-j MYDOMAIN lets you add a Samba server into a Windows Domain. When invoked with -U, that username (and optional password) are used to contact the PDC to create a machine account, and to set a password on it.

Option 2: -r PDC

PDC is the full name of your PDC server in the format of DomainMaster.MYWORK.com. You can specify what machine you wish to use to change your password or another user's password. If you do not specify, smbpasswd defaults to the local host.

Option 3: -U user_name

user_name is the domain username who has been assigned administrative privileges. On that machine, you can specify the username whose password will be changed.

If the password test is successful, you can then test winbind to allow Windows domain users and groups to appear and operate as Linux users and groups on a Linux machine. Winbind uses a UNIX implementation of Microsoft RPC calls, Pluggable Authentication Modules (PAMs), and the name service switch (NSS).

To get users, type:

# wbinfo - u

To get groups, type:

# wbinfo - g

To test connections, type:

# wbinfo - t

When the results are successfully returned you should see MYDOMAIN=user.
Step 2. Test Linux Password

Test the Linux system password assuming you already have changed the nsswitch.conf file to include winbind options. If you did not include those options in the nsswitch file, go to step 3 and then repeat step 2. Upon a successful test, the system should see domain resources along with the local Linux machine accounts.

To get a list of Linux users, type:

# getent passwd

To get a list of Linux groups, type:

# getent group

Step 3. Edit nsswitch Configuration File

First, backup your nsswtich.conf file in case something goes wrong, like this:

# cp nsswtich.conf
nsswitch.bak

After you open nsswtich.conf, add winbind to the end of the passwd: and group: lines at the beginning of the line, like this:

passwd: compat winbind

group: compat winbind

If winbind does not work properly, go to step 4 and then repeat step 3. Otherwise, when you are done with the nsswitch.conf file, run idconfig to activate the changes, like this:

#/sbin/idconfig

Step 4. Edit the winbind Section in the Samba Configuration File

If you discover that the winbind section is missing from the smb.conf file, add it. If you find it, make a few changes to look like this:

#winbind options

winbind operator = +

winbind uid = 15000-25000

winbind gid = 15000-25000

winbind cache time = 15

winbind enum users = yes

windbind enum groups = yes

template homedir = /home/winnt/%D/%U

template shell = /bin/shell

What this section says is that you can separate domain and username with "+" or even "\" and use uids and gids from 15000 to 25000 for domain users and groups respectively. You can allow enumeration of winbind users and groups and give users a real shell for those who have telnet access.
Step 5. Create a Domain Home Root Directory

In step 5 I have included template homedir = /home/%D/%U in the configuration file. This means you must check if a domain home directory exists. If it does not exist, you must create the %D (domain) directory. The %U (user) will be created automatically when the user logs on.

Here is an example:

# cd /home
# mkdir MyWork
# chmod 777 MyWork

So now when a user logs in MyWork+DAVE the Samba script will put the user in /home/MyWork/ and will automatically create DAVE's home directory.
Step 6. Update Linux System Password

You need to allow passwords to change from Windows to update Linux System Password, like this:

unix password sync = Yes

passwd program = /usr/bin/passwd %u

passwd chat =*Type_new_password*
%n\n

*Retype_new_password* %n\n

*Password_updated_successfully*

After this, you may make further password updates using PAM's password change control flag for Samba. You must enable the control flag so you can use PAM for password changes when requested by an SMB client instead of the program listed in the passwd program. Chat parameter is:

Pam password change =yes

Step 7. Check the Global Section in the Samba Configuration File

At this point we are not quite done with the smb.conf file. Let's take a closer look at the global section in the configuration file particularly where you may need to make the changes.

[global]

workgroup = MYWORK

os level = 2

time server = Yes

unix extensions = Yes

encrypt passwords = Yes

map to guest = Bad User

printing = CUPS

printcap name = CUPS

password server = DomainMaster.MYWORK.com

socket options = SO_KEEPALIVE IPTOS_LOW DELAY
TCP_NO DELAY

wins support = No

veto files = /*.eml/*.nwd/ched32.dll/*.{*}/

security = domain

netbios name = my-Linux

The os level option is largely auto-configured in the Samba-3 release series and it is seldom necessary to manually override the default setting. When the map to guest option is set to Bad User, the system rejects user logins with an invalid password. The printing parameter controls how printer status information is interpreted on your system. CUPS is one of the printing styles. To use the CUPS printing interface set printcap name = cups.

The socket options configuration options are set on a per-connection basis and can be reset by Samba on the sockets in the smb.conf file to increase throughput. An explanation of each option follows.

TCP_NODELAY, a default value, tells the server to send as many packets as necessary, so you will have no or low delay. This will give you up to a 30 percent speedup.

IPTOS_LOWDELAY trades off throughput for lower delay. This applies to routers and other systems, not the server. Set IPTOS_LOWDELAY whenever you set TCP_NODELAY. You will get an increase in speed up to around 20%.

SO_KEEPALIVE initiates a periodic check every four hours to see if the client is still there. It eventually arranges to close dead connections, returning unused memory to the operating system.

The wins support option controls if the nmbd process in Samba will act as a WINS server. You should not set this to yes unless you have a multi-subnetted network and you wish a particular nmbd to be your WINS server. Note that you should NEVER set this to yes on more than one machine in your network.

Use the veto files option if you want to prevent users from seeing certain files and directories completely. Each entry in the list must be separated by a '/', which allows spaces to be included in the entry. '*' and '?' can be used to specify multiple files or directories. One feature of this option is that if a directory you are trying to delete contains only the veto files, the deletion will fail unless you also set the delete veto files option to yes.
Step 8. Edit PAM Files

Backup the PAM files, before you start editing three files, stored in the etc directory You should be logged on as root when you backup the login, xdm, samba files, like this:

# cp login login.bak

# cp xdm xdm.bak

# cp samba samba.bak

Edit the login file to add pam_winbind.so and pam_mkhomedir.so. PAM starts reading the file from the top and goes down to the next line only if the credentials supplied are good to pass the current line.

#%PAM-1.0
auth required pam_securetty.so
auth required pam_env.so
auth sufficient pam_unix2.so nullok
auth sufficient pam_winbind.so use_first_pass
auth required pam_deny.so
auth required pam_nologin.so
account sufficient pam_winbind.so
account required pam_unix2.so
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session sufficient pam_unix2.so none # debug or trace
session sufficient pam_limits.so

When you edit the xdm file, add the pam_winbind.so parameters.

#%PAM-1.0
auth sufficient pam_winbind.so
auth sufficient pam_unix2.so use_first_pass nullok #set_secrpc
account sufficient pam_winbind.so
account required pam_unix2.so
password required pam_unix2.so #strict=false
session required pam_unix2.so debug # trace or none
session required pam_devperm.so
session required pam_resmgr.so

When you edit the Samba file, make sure it looks like the:

#%PAM-1.0
auth required pam_unix.so
account required pam_unix.so

Step 9. Test PAM Settings

You need to perform two tests: console login and X-windows login.

Console login test: In performing a console login test, you first press Ctrl+ALT+F1 to start a new console session as a back door for testing your PAM setting. At the login prompt test your login using the local root account. After you have verified that you can log in using the machines local account you can test a console login of a domain account. The username is specified as DOMAIN+USER.

X-windows login test: You do this test after you successfully logged in using both the local root account and a domain account. This is what you have to do:

* Log in as root from the same console session.
* Change back to your Windows session, using Ctrl+ALT+ F1.
* Log out of the X-window session and return to the login window.
* Test the login using a local machine account, then log out after login is complete.
* Test domain login using username specified as DOMAIN+USER

Step 10. Check the Results

The results should show in your login dialog all the account names that exist on the domain. This is fine for a small user base. If you have a large user base and do not wish to display all the user names you can disable this option in the login manager under system administration. Go to the users tab and change the show user to "none."

Once you are satisfied with the results, you can change ownership of files and folders by specifying the user (e.g., DOMAIN + USER), like this:

# chown DOMAIN+USER filename

Step 11. Check Samba and winbind Services

Skip this step if you already modified or set up your Samba and winbind services. Otherwise, do the following:

From the console cd over to the etc/rc.d directory where you can view, change or modify your systems services. You need to setup these services to ensure they start every time when you boot up.

Use the chkconfig script to see if smb and winbind services are on. These services should be on for runlevels 3 and 5. Type:

# chkconfig --list smb

If the results show the services are not set to on for runlevels 3 and 5 turn them on using the chkconfig, like this:

# chkconfig smb on

# chkconfig winbind on

Next we disable the nscd service which interferes with the proper functioning of winbind, like this:

#chkconfig nscd off

Now turn off the nscd service, like this:

#./nscd stop

We are now ready to start smb and winbind, if it is running already restart them:

#./smb start
#./winbind start

Judith Myerson is a systems architect and engineer. Her areas of interest include enterprise-wide systems, database technologies, network & system administration, security, operating systems, programming, desktop environments, software engineering, web development, and project management. You can contact her at jmyerson@c2040.com

No comments: