Suse 9.0 Window Active Directory / Domain How-to:
Purpose: This document will guide the setup of Suse 9.0 to support unified login as well as file and directory permission compatibility with in a Microsoft windows domain or active directory environment.
Software and disclaimer:
This document was intended for Suse Linux 9.0 running samba-2.2.8a-107 only. Though there are common settings that can carry over to other Linux distributions this is what this document was written for. The pam structure differs the most between different Linux distribution's, documentation for redHat and Mandrake can be found on the web. Since this document was written the hard way through trial and error using bits and pieces of documentation found through books and on the web it may have faults that I am unaware of.
Packages used in the creation of this document:
pam_smb-1.1.6-528
samba-2.2.8a-107
Windows Structure:
Below I will define a fictional network, the network will consist of two machines the first listed is the domain controller running windows and the second machine will be our Linux workstation the domain name is also listed. The domain controller will also serve as the password server for the domain. Before you get started be aware that you must have a domain administrator account to put your Linux client in the domain.
Windows Side:
DomainMaster.MyCompany.com
Domain Name: MyCompany.com
Linux Side:
my-linux.MyCompany.com
DNS:
Before you get to far make sure that you have DNS name resolution to your domain controller from your Linux client, you should be able to ping it using the full domain name. (Note do not try to ping it by short name Linux is not using wins). If you cannot ping it then add the name to your hosts file located in the /etc directory.
Samba Configuration files:
1.From the console login as root using the su command.
Example:
# su
2.Change to the /etc/samba directory and make a backup of your smb.conf file.
Example:
# cp smb.conf smb.org
3.Edit the smb.conf global section, the following example uses MYCOMPANY as the domain and the domain controller is DomainMaster.MYCOMPANY.com. Substitute to suit your own network. Most of these lines will already be in your smb.conf file for the items that are not add them, for the lines that are different, change them. (note, you can add more then one password server just leave a space between the entries.)
[global]
workgroup = MYCOMPANY
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.MYCOMPANY.com
socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
wins support = No
veto files = /*.eml/*.nwd/riched20.dll/*.{*}/
security = domain
netbios name = my-Linux
4.Next we will setup the winbind section of the file , add these parms after the global section.
#winbind options per rmgl 03-02-04:
winbind separator = +
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind cache time = 15
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/%D/%U
template shell = /bin/bash
#Allow password changing from Windows to update Linux System Password:
unix password sync = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *New*password* %n\n *Retype*new*password* %n\n *password:*all*authentication*tokens*updated*succe ssfully
#Use PAM's password change control flag for Samba. If enables,
#then PAM will be used for password changes when requested by
#an SMB client instead of the program listed in the passwd program.
#It should be possible to enable this without changing your passwd
#chat parameter for most setups.
Pam password change = yes
5.Save the smb.conf file and close it, next run the testparm command to test the smb.conf file for syntax errors. If you have errors go back and fix them and then re-run testparm.
Example:
# testparm smb.conf
NSSWICH configuration:
1.Backup your nsswitch.conf file (note that I use the .org which stands for original, I will go back later and make copies of the working files as .bak)
Example:
# cp nsswitch.conf nsswitch.org
2.After your nsswitch.conf open it and add winbind to the end of the passwd: and group: lines at the beginning of the line. Then save and close the file when you are finished.
Example:
passwd: compat winbind
group: compat winbind
3.After you are finished editing the nsswitch.conf file run ldconfig to activate the changes.
Example:
# /sbin/ldconfig
Samba Service:
From the console cd over to the etc/rc.d directory , this is where you can view , change or modify your systems services, in the next few steps we will setup these services to ensure they start every time and then we will also start them.
1.From the console use the chkconfig script to see if smb and winbind services are on. We are looking for these services to be on for runlevels 3 and 5.
Example:
# chkconfig --list smb
2.If the services are not already set to on for runlevels 3 and 5 turn them on using the chkconfig
Example: (turn on smb and winbind:)
# chkconfig smb on
# chkconfig winbind on
3. Next we will have to disable the nscd service which interferes with the proper functioning of winbind.
Example:
#chkconfig nscd off
4. Now turn off the nscd service:
Example:
#./nscd stop
5.We are now ready to start smb and winbind, if it is running already restart them:
Example: (note that the two lines are separate commands)
Example:
#./smb start
#./winbind start
Join the Domain:
Joining the domain requires that you have name resolution to your password server (PDC) and an administrative account that can move machines into the domain. We will first create the domain account and then we will test winbind and local system accounts and groups to ensure they are both pulling the correct information.
1.From the console as root join the domain the syntax format is explained below:
DOMAIN = the name of your domain (upper case)
PDC = Full name of your PDC server ServerName.Domain.com
user_name = The domain username with admin privileges
Example:
# smbpasswd -j DOMAIN -r PDC -U user_name
2.We will now test winbind to ensure we can pull user and group into from the domain. Users should show up as DOMAIN+USER when the results are returned.
Example: (get users)
# wbinfo -u
Example: (get groups)
# wbinfo -g
Example: (tests connection)
# wbinfo -t
3. Next test the Linux system password, by changing the nsswitch.conf file the system should now see domain resources along with the local Linux machine accounts (note sometimes this command takes a long time to return)
Example: (list of users)
# getent passwd
Example: (list groups)
#getent group
PAM configuration:
(WARNING!!! DO EDIT ANY PAM FILES BEFORE BACKING THEM UP, DO NOT REBOOT UNTIL YOU HAVE TESTED YOUR CHANGES, NOT DOING SO CAN LOCK YOU OUT OF YOUR SYSTEM!!!!)
Were almost finished, the pam configuration is the last major component to configure. In this section we will setup the pam files to allow login to the system and we will also setup the base home directory. It would be wise to create a boot disk at this point, the installation CD can also serve as a point of rescue as well just make note of your hard devices listed in your fstab file, trying to find this info later can be hard if you are locked out of your system.
1.The first step will be to backup the pam files we will be working with, in this document there are only three files that will be edited. The pam files are stored in the etc/pam.d , you should be logged on as root, backup the following files, login, samba, and xdm
Example:
# cp login login.org
#cp samba samba.org
#cp xdm xdm.org
2.Edit the login file to add your winbind info below is an example of the file I created, remember the order of the lines matters, pam reads the file from the top down allowing you to go on to the next line only if the credentials supplied are good to pass the current line. Lines using pam_winbind.so and pam_mkhomedir.so were added.
#%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
3. Edit the xdm file and add the pam_winbind.so parameters below is an example of my file.
#%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
4.Next edit the samba file and ensure it looks like the following example below.
#%PAM-1.0
auth required pam_unix.so
account required pam_unix.so
Create domain home root directory:
Remember in the samba file we specified, template homedir = /home/%D/%U this means that we will have to create the %D (domain) directory and the %U (user) will be created automatically when the user logs on.
Example: (change MyDomain to the name of your domain.)
# cd /home
# mkdir MyDomain
# chmod 777 MyDomain
So now when a user logs in MyDomain+FRED the samba script will put the user in /home/MyDomain/ and will automatically create FRED's home directory.
Testing PAM Settings:
The following steps are required before you move on if you are not able to perform all the steps below you must correct your pam configuration files so you can. If you get stuck on any of the steps ensure you do not reboot your machine without restoring your original pam files.
Console Login Test:
1.Using Ctrl+ALT+F1 start a new console session we will use this as a back door for testing our PAM setting. At the login prompt test your login using the local root account.
2.After you have verified that you can login using the machines local accounts you can test a console login of a domain account, the username is specified as DOMAIN+USER.
X-windows Login Test:
If you successfully managed to login using both the local root account and a domain account the next step is to test X-windows.
1.From the same console session that you performed the previous tests login as root.
2.Using Ctrl+ALT+F1 change back to your windows session
3.Logout of the X-windows session and return to the login window. (note this will take a long time because the login will pull all the domain accounts to add to the list, don't worry about this now we will change the settings later)
4.Test the login using a local machine account then logout after login is compete.
5.Test domain login using username specified as
DOMAIN+USER
If all tests were good congratulation's, if your still "work in process" you can save your pam files with the work you have done to this point but remember to restore your originals if you intend to reboot.
X-window login box:
As you seen during the test, our login box pulled all the account names that exist on the domain, this should be 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 from within yast2 under system administration ==> login manager , select the users tab and change the show users to "none" .
Changing File and folder ownership from the console:
Changing ownership of files and folders isn't to different from what you would normally do from a console only now you have to specify the user using the domain scheme of DOMAIN+USER, below is an example.
Example:
# chown DOMAIN+USER filename
Part II Server Setup in a Domain Environment:
After you have completed the client install and verified everything is working you can setup the server side. The goal is to setup your Linux machine to support the identical scheme for directories and file permissions and shares as a Microsoft server would. To do this your linux machine must have the following configuration or software installed.
-ACL kernel support (using ext2 or ext3 "rieser filesystem"), by default Suse 9 has this option enabled in the kernel. The ACL option will have to be enabled though on the volume you wish to export your Samba shares.
-The above client setup must be enabled in order for Samba to successfully use the domain as a back end for file and folder permissions.
-If not already installed install the acl tools package to allow acl manipulation and querying from the linux side, at the time of this document the current package is acl-2.2.15-23
ALC support:
By default ACL support is already built into the Suse 9.X kernel , as long as your using a filesystem that supports ACL we are in good shape (ext2 and ext3). To enable ACL we will simply edit our /etc/fstab file and add the ACL option to the mount command of the volume where we will be exporting our Samba shares.
1.Using the console login as root using the su command, cd to the /etc directory and make a backup of your fstab file.
Example:
# cp fstab fstab.bak
2.Next edit your fstab and add the acl option towards the end of the file.
Example:
Before: /def/hda1 / reiserfs defaults, 1 1
After: /def/hda1 / reiserfs defaults,acl 1 1
3.Save the fstab file and reboot the machine, if you have any problems it more then likely you using a filesystem that does not support ACL.
Samba Configuration:
The samba configuration will take place in two parts, we will first setup our shares on the the linux side and then we will change ownership of the shares to our Microsoft domain accounts from there to setup permissions and access to the shares. You can later adjust the default permission and creation modes on the samba side if you don't like how I have them here but for the sake of sanity use the default setting I use first.
1.Create the directories you would like to use for your Samba exports, after you have created them run a chmod and then chown to your domain account you will be using later to setup the permissions on the domain side.
Example:
# mkdir workgroup-files
# chmod 770 workgroup-files
#chown -R DOMAIN+USER workgroup-files
2.Next create a backup of your working smb.conf file then edit it. For your shares using the following format, repeat the format for each share you wish to export.
Example Share:
[share]
comment = share
path = /home/share
fstype = NTFS
browseable = Yes
writeable = Yes
acl support = Yes
security mask = 0750
directory mask = 0750
force security mode = 0750
force directory security mode = 0750
directory security mask = 0750
3. After you have setup your shares save the smb.conf file and restart both your smb and winbind services located in /etc/rc.d directory.
Example:
# ./smb restart
#./winbind restart
4. From your windows machine (WINNT, WIN2K , or XP) map to your shares using the account you gave ownership to on the Linux side. Once your mapped you can right click on the share itself to define the share defaults for file creation and default permissions. Individual folders can be manipulated as you would normally. Use a few accounts to connect as different users to test your stetting and ensure it works as you intend it to.
ACL from the Linux Side:
A standard ls or dir command will not show you the ACL info from the linux side , you can use the getfacl and the setfacl command to query or manipulate ACL information from the console.
Example:
# getfacl DirectoryName
.\r