Docs/SysAdmin/Server/Samba/ThreeDC
From Mandriva Community Wiki
[edit] Implementing a Samba 3.x LDAP Primary Domain Controller on Mandriva versions 9.1, 9.2 , 10.0 and 10.1
Author: Jim Collings
UPDATED: 23 Apr 2005
Note: This document doesn't cover LE 2005 but soon I will write one that does. :-)
The example server box is i686 Mandriva Linux 10.0 Official with all the updates I can get my hands on. To cut down on network traffic and to ease security, it houses both the OpenLDAP server and Samba. My client systems are all XP Pro boxes. I'm hoping that users of other Windows clients will be willing to add their input to this document. Packages I am using are:
perl-ldap-0.31-2mdk samba-client-3.0.2a-3mdk samba-swat-3.0.2a-3mdk samba-doc-3.0.2a-3mdk samba-server-3.0.2a-3mdk samba-common-3.0.2a-3mdk
This document is meant to be complimentary to the linsec.ca OpenLDAPAuth article and this section of Samba-3 by Example by John H. Terpstra. Many thanks and all credit due to the authors of these documents. If you find a problem here, you can reach me at .
Basic procedure for implementing this HOWTO should be as follows:
1. Implement the article on OpenLDAP authentication with the following caveats:
- Ignore the section on Configuring Samba to use LDAP. I intend to cover that here with updated procedures.
- Ignore the section on Configuring Server ACLs. Don't change /etc/openldap/slapd.access.conf. The defaults that come with the version of OpenLDAP that accompanies Mandriva Linux 10.0 Official are greatly improved for our purposes.
- I've some explanatory comments of my own to add to the section on Using SSL/TLS with OpenLDAP
This will eliminate the Linux based authentication portion. When finished, return to this article.
2. Implement this article (the one you are reading) which is basically just this section of Samba-3 by Example annotated and adjusted for Mandriva Linux.
While you are implementing these articles, read very carefully. Errors are easy to make. I recommend using the GUI LDAP browser/editor called gq so that you can easily see exactly what is occurring in the database and easily delete records if you don't quite get it right the first time. This is particularly important in regards to computer accounts because the script smbldap-userdel which would normally be used, cannot delete the account if it is not in the same OU as other user accounts. Here is the article on OpenLDAP authentication and gq is located on the contribs CD. One might acquire it by adding a contribs source using the commands found at Easy urpmi. Having done this facilitates the use of urpmi [package name]
If you wish to migrate from Samba 2.2.x series systems, migrating old *userids* over may be something to put off until a fully functioning system has been established. In this way, we will also be able to take advantage of the special scripts provided by IDEALX for this purpose.
Performance of a certain amount of complexity management will also be worth while. One such trick that I've used is increasing the font size from within Mozilla using [SHIFT]-[MOUSE WHEEL]. I've found that this makes it harder to miss "the fine print", as it were, and also increases the accuracy of one's cut and pastes ( i.e. you wont miss ridiculously important characters at the beginning/end, etc. ). Take things one step at a time. In the same spirit, if you've never installed a Samba PDC without LDAP, it is probably wise to give that a try before moving on to this, the next level. This can be performed with OpenLDAP installed and configured without any harm. The Samba rpm packages can also be acquired using urpmi or the rpmdrake GUI. In previous releases of Samba, it was often necessary to recompile the packages in order to get LDAP support. This is no longer required as of Samba 3.x
Ensure that you have the NetBIOS ports 136,137 and 138 available to both the OpenLDAP / Samba server and the client systems. While doing this, it may also be desirable to check on OpenLDAP ports 389 and 636. Especially if your OpenLDAP and Samba servers are not on the same box. Don't forget to start the daemons first as shown below.
[root@massive root]# service ldap start; service smb start
OK, you've made it this far, now you are ready for cross-platform authentication using Samba and LDAP. Because we've performed step 1, we already have a working and at least minimally populated OpenLDAP database.
[edit] OpenLDAP Server Configuration
(Samba-3 by Example: OpenLDAP Server Configuration)
Having already implemented Vincent Danen's article, all we need to do is change these lines in /etc/openldap/slapd.conf
index objectClass,uid,uidNumber,gidNumber eq index cn,mail,surname,givenname eq,subinitial
to read as follows:
# Indices to maintain index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index member eq index default sub
This should be all that we need from OpenLDAP Server Configuration Note the addition of indices such as sambaSID etc. This will enable our server to quickly find our Samba accounts. Save the file and then at the command line execute:
[root@massive root]# service ldap restart;slapindex
This will restart the server with the new configuration and rebuild our indices for us.
Tip If your ldap server seems to be running slow, re-indexing is one thing to try that might speed it up a little.
[edit] OpenLDAP Structural Adjustments
Previous editions of this document used OpenLDAP's root access to allow Samba to communicate. This may be a good approach for debugging a Primary Domain Controller but it is not a good approach if you actually want a scaleable setup that is still reasonably easy to debug after having grown a bit. There are several problems, for example, if you have more than one Domain Controller, you will notice that they all use the same access and that you cannot tell from the system logs which DC is doing what in the database. Furthermore, on a production system we might be using OpenLDAP to serve any number of things that we wont want Samba to have write access to. Samba has no buisness messing with our secureity certificates for our webserver, for example.
Later we will set up the basic accounts and groups that Samba will use but right now what we need is an additional group to which domain controllers can belong that also has access to only the appropriate areas of the LDAP database. As of the writing of this section of the HOWTO, we cannot use the normal "Domain Controllers" group which will be created later on because it is composed of a outdated posixGroup object class. The only syntax I can find for making posixGroup work in OpenLDAP's Access Control Lists doesn't function properly because you are not supposed to put something with the syntax of a dn into a memberUid attribute. In the mean time we can use the following workaround. Basically what we have to do is keep a set of duplicate groups with an object class that actually does work.
Great, so let's begin. First we need a place, specifically an organizational unit (OU), in which to keep our duplicate record set. We'll call this new ou, "ou=Access Groups,dc=mylan,dc=net" and we'll add it by first creating the following text file which we will name AccessGroupsOU.ldif:
dn: ou=Access Groups,dc=mylan,dc=net ou: Access Groups objectClass: top objectClass: organizationalUnit objectClass: domainRelatedObject associatedDomain: mylan.net
Having created this file, we must now add the new ou to the database as follows:
[root@massive root]$ ldapadd -x -D "cn=root,dc=mylan,dc=net" -W -f AccessGroupsOU.ldif Enter LDAP Password: adding new entry "ou=Access Groups,dc=mylan,dc=net"
Now that we have a place to keep it, we will create a new group of the objectClass "groupofnames". Much as before, create a text file named groupofnames.ldif that contains the following:
dn: cn=Domain Controllers,ou=Access Groups,dc=mylan,dc=net objectclass: groupofnames cn: Domain Controllers description: IT security group member: cn=massive.mylan.net,ou=Hosts,dc=mylan,dc=net
Next, add it using:
[root@massive root]$ ldapadd -x -D "cn=root,dc=mylan,dc=net" -W -f groupofnames.ldif Enter LDAP Password: adding new entry "cn=Domain Controllers,ou=Access Groups,dc=mylan,dc=net" [root@massive root]$
In our new "Domain Controllers" group in the "Access Groups" ou, we have an attribute called member. Notice that it is pointing at the host record of the Primary Domain Controller. If we wanted to add more domain controllers, we could just add them as additional member attributes of this group. This is not enough however. In order for this to work we also need to add a userPassword attribute to each domain controller's host record. We can do this easily enough by adding the simpleSecureityObject class to it. I did this by using the gq LDAP client. I got the password by using:
[root@massive openldap]$ read -sp "Enter password to be used:" pw;echo;slappasswd -s $pw;unset pw
Enter password to be used:
{SSHA}4FMerwu0qcafPYXwxlpTxuRcdtTTvZN6
[root@massive openldap]$
Tip The technique above prevents display of the password entered to the screen and also keeps it out of the command history. You can type "clear" from the command line to clear the password off your screen once you have pasted it.
Last thing we have to do is update /etc/openldap/slapd.access.conf to provide access to members of the duplicate "Domain Controllers" group. For each line that matches this one:
by group="cn=Domain Controllers,ou=Group,$2" write
We need to add another one so that each "access to" entry containing the line above now looks like this:
by group="cn=Domain Controllers,ou=Group,$2" write by group="cn=Domain Controllers,ou=Access Groups,$2" write
Having made these changes, you will need to restart your OpenLDAP server.
Groups composed of the type groupOfNames cannot be mapped to Samba groups and can't be used to provide access to files on Linux either, however our old entries still can be. By the same token, it is probably a good idea to keep non-posixGroup records out of the area that the Linux authentication system will be seeking them. The downside is that now we have two groups (or sets of groups) to manage rather than one and there are no script tools available for managing groupOfNames objects. For now, the best I can tell you is to keep gq handy until the posixGroup schema is updated.
[edit] Samba-3 PDC Configuration
(Samba-3 by Example: Samba-3 PDC Configuration)
In this section, for steps 1, 2, 4, 5, 6 and 7, skipping over 3, use this example smb.conf below which has been adjusted for Mandriva.
[global] unix charset = LOCALE workgroup = MEGANET2 netbios name = MASSIVE #Substitute what ever interface or interfaces you want your server to talk on for eth0 below #but ensure that you have lo here as the server wont be able to speak to localhost (i.e. itself) without it. #Most small time or experimental setups don't have two ethernet cards on the server anyway. interfaces = eth0, lo bind interfaces only = Yes #We are using localhost because we assume that the LDAP server and the Samba server are in the same box. #If this were not the case, we might be interested in using SSL or TLS encryption when talking to the server. #ssl Example: #ldap ssl = on #passdb backend = ldapsam:ldaps://massive.mylan.net #start_tls Example: # ldap ssl = start_tls #passdb backend = ldapsam:ldap://massive.mylan.net #Default for ldap ssl is start_tls which is pointless overhead on a system like ours, #where both the LDAP server and the Samba server are on the same machine. ldap ssl = off passdb backend = ldapsam:ldap://localhost # Default is no username map. # We are going to comment it out because the defaults contained in it # will cause mapping errors with users that already have Samba accounts. # Specifically, we don't want Guest or Administrator re-mapped to nobody/root respectively. # username map = /etc/samba/smbusers log level = 1 ;Example of using multiple log levels for different parts of Samba: ;log level = 5 auth: 1 ;The above means we want log level 5 for auth but log level 1 for everything else. ;So we could do something like: ;log level = 5 auth: 3 acls: 2 printdrivers: 1 ;Currently known debug classes: ; all ; tdb ; printdrivers ; lanman ; smb ; rpc_parse ; rpc_srv ; rpc_cli ; passdb ; sam ; auth ; winbind ; vfs ; idmap ; quota ; acls syslog = 0 log file = /var/log/samba/%m max log size = 50 smb ports = 139 445 name resolve order = wins bcast hosts time server = Yes unix password sync = Yes passwd program =/usr/bin/passwd %u #The IDEALX scripts for Mandriva live in /usr/share/samba/scripts/ add user script = /usr/share/samba/scripts/smbldap-useradd.pl -a -m '%u' delete user script = /usr/share/samba/scripts/smbldap-userdel.pl %u add group script = /usr/share/samba/scripts/smbldap-groupadd.pl -p '%g' delete group script = /usr/share/samba/scripts/smbldap-groupdel.pl '%g' add user to group script = /usr/share/samba/scripts/smbldap-groupmod.pl -m '%u' '%g' delete user from group script = /usr/share/samba/scripts/smbldap-groupmod.pl -x '%u' '%g' set primary group script = /usr/share/samba/scripts/smbldap-usermod.pl -g '%g' '%u' add machine script = /usr/share/samba/scripts/smbldap-useradd.pl -w '%u' logon script = scripts\logon.bat #Below is for Windows XP Pro, NT, 2K Pro logon path = \\%L\profiles\%U #Below is for Windows 95 clients. logon home = \\%L\%U\profiles logon drive = Z: domain logons = Yes preferred master = Yes wins support = Yes ldap suffix = dc=mylan,dc=net ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Group ldap idmap suffix = ou=Idmap #The ldap admin setting below is what we will be using to get access to the database and #incidentally, it is what will show up in the system logs when this domain controller does so. ldap admin dn = cn=massive.mylan.net,ou=Hosts,dc=mylan,dc=net idmap backend = ldap:ldap://localhost idmap uid = 10000-20000 idmap gid = 10000-20000 map acl inherit = Yes #Unnecessary share for just a basic PDC setup but a good example. #[apps] #comment = Application Files #path = /apps #admin users = bjordan #read only = No [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon guest ok = Yes locking = No [profiles] comment = Profile Share path = /var/lib/samba/profiles read only = No profile acls = Yes #Use this share if you want to use mandatory profiles. #[profdata] #comment = Profile Data Share #path = /var/lib/samba/profdata #read only = No #profile acls = Yes [homes] comment = Home Directories valid users = %S read only = No browseable = No #This example share is accessible to all domain users [public] path = /home/storeage read only = No guest ok = Yes
[edit] Install and Configure Idealx SMB-LDAP Scripts
(Samba-3 by Example: Install and Configure Idealx SMB-LDAP Scripts)
We don't have to do much with Chapter 6. We can skip 1-4 and 6 because our rpm installation has already performed these items for us. For step 5 we should use the following basic settings:
$SID='PLACE_SID_HERE '; $slaveLDAP = "127.0.0.1"; $slavePort = "389"; $masterLDAP = "127.0.0.1"; $masterPort = "389"; $suffix = "dc=mylan,dc=net"; $usersou = q(People); $computersou = q(People); $groupsou = q(Group); #Where mylan is the name of our domain. It should be the same as the #workgroup setting in '/etc/samba/smb.conf' $binddn = "cn=massive.mylan.net,ou=Hosts,$suffix" $bindpasswd = "place password belonging to the binddn above, here"; $_userLoginShell = q(/bin/bash); $_userHomePrefix = q(/mnt/home); $_defaultUserGid = 513; $_defaultComputerGid = 515; $_userSmbHome = q(\\\\MASSIVE\\profiles); $_userProfile = q(\\\\MASSIVE\\profiles\\); #Note: Use a drive letter below that is not being used, otherwise #there will be trouble. I'm going to use 'Z:' but you can use anything that is free on all #systems. $_userHomeDrive = q(Z:);
Tip Be sure that you set $SID and $bindpasswd above in accordance with the instructions in step 5 of the section before this one.
[edit] LDAP Initialization and Creation of User and Group Accounts
(Samba-3 by Example: LDAP Initialization and Creation of User and Group Accounts)
When you execute smbldap-populate.pl you may get errors to the effect that the script tried to create some things that were already there. This is fine for items previously created in Vincent's article. The "People" and "Group" OU's will pre-exist for example. Or primary concern is the creation of proper user and group domain accounts that have correct references to each other, the correct RID settings, etc.
One of the problems encountered with this script was that it insisted on having settings for the Administrator and nobody user accounts' userSmbHome and userProfile. Unfortunately the script cannot provide the correct settings for these and our setup specifies these settings in /etc/smb.conf regardless. We don't want the user's settings to override them. What we have to do then is set them as we have in Install and Configure Idealx SMB-LDAP Scripts above, use the script, comment out those lines in /etc/samba/smbldap_conf.pm and then erase those settings in the Administrator and nobody user accounts. I would use gq to do this, since it appears that the smbldap-usermod script also cannot set these to a blank setting. Setting them to something that is invalid like "." and then commenting /etc/samba/smbldap_conf.pm should work also but having them all the same is best for uniformity. I prefer blank because there may be checking overhead otherwise.
So the modified process for this section is:
1. Skip steps 1 and 2.
2. Execute smbldap-populate as noted in step 3.
3. Comment out $userSmbHome and $userProfile lines from /etc/samba/smbldap_conf.pm.
4. Set the Administrator's sambaHomePath and sambaProfilePath to blank using gq or some other means.
5. Proceed with steps 11, 16, and 18 through 21.
[edit] Some Comments On User Records
It is important to know that using smbldap-useradd -a -P username will add a Windows user with a Unix password only. You must execute smbldap-passwd if you want both Windows and Unix passwords set. Furthermore, you may want to force your users to set their own passwords by using smbldap-usermod -B 1 username . You could also make this change in your smb.conf:
add user script = /usr/share/samba/scripts/smbldap-useradd.pl -a -m '%u';/usr/share/samba/scripts/smbldap-usermod -B 1 '%u'
Another piece of information that does not seem to be commonly available would be the meanings of the user account flags. The best information I currently have on this is as follows. If you do:
smbldap-usershow username
You may notice something like this in the response:
sambaAcctFlags: [U ]
These are flags that have special meaning for the user's account.
sambaAcctFlags can have any of, and possibly many of, the following settings:
[NDHTUMWSLKI]
...or
N - ? %BR% D - Disabled %BR% H - Home dir required %BR% T - ? %BR% U - User account %BR% M - ? %BR% W - Workstation account %BR% S - ? %BR% L - ? %BR% K - ? %BR% I - Domain trust account %BR%
And the following aren't listed in your group of flags:
X - Password does not expire
[edit] Profile Directory Attributes
We only have just a few more details left to cover. Now we'll deal with permissions and ownership of /var/lib/samba/profiles . It should be set as follows:
[root@massive root]# chmod 1770 /var/lib/samba/profiles [root@massive root]# chown root."Domain Users" /var/lib/samba/profiles
Notice the "1" in the first line? That is the sticky bit. With it we are saying that anybody in the Domain Users group can have full access to this directory, however they may not alter or delete files that do not belong to them. The end result is that when a new user logs on, his or her profile is created under this directory automatically.
If you wish to ensure that your uses cannot dump a bunch of huge ISO files into /var/lib/samba/profiles then you can try something like this:
[root@ldap]# chmod 755 /var/lib/samba/profiles [root@ldap]# chown root.root /var/lib/samba/profiles
Then you add this line exactly as it is to the profiles share:
root preexec = PROFILE=/var/lib/samba/profiles/%u; if [ ! -e $PROFILE ]; \ then mkdir -pm700 $PROFILE; chown "%u"."%g" $PROFILE;fi
This is basically a super short script which will be executed as root before accessing the profile service. It tests to see if the users profile directory exists. If it does not, the script creates it on the fly with the correct permissions and ownership.
Tip A sneaky person might avoid the checking overhead of using the preexec script by writing a wrapper script for smbldap-useradd instead. Said script could create the users profile directory either before or after running smbldap-useradd.
[edit] Some Comments on LDAP SSL
The two protocols, TLS and SSL differ in that TLS normally occurs on the same port that regular clear text communications do. This means that you must have clear text communications available if you intend to use TLS. Since I would rather that all communications outside of the local machine be encrypted, I always use SSL.
If you install the new cooker source rpm samba-3.0.5-0.pre1.3mdk.src.rpm , you may find that one of the installed dependencies for compiling the source code interferes with LDAP SSL communications with your client systems. The way that I fixed this was by simply installing those dependancies on the clients also as it seems to be a simple matter of cross-version compatibility. This may not be desireable however, if you have clients that you cannot upgrade remotely or via script or if you have a great many of them. Instead you may want to use rpm -qa --last | more to retrieve a list of the last rpms installed, so that you can replace them after successfully building the binary rpm files.
[edit] Important Notes on Symbolic Links
Samba can now use symbolic links on operating systems that support them. Let the reader beware however, as there is currently a bug that can provide the user global access in circumstances where the profile and homes directories are combined. I am not certain of the specifics regarding this bug but because of it, I will have to strongly discourage the use of links between the user's profile directory and the homes share. On the flip side, links can be used to reduce data redundancy. If, for example, the user uses Mozilla for mail on Windows as well as Linux, there is no reason why links could not be used to allow cross platform usage of the data files and settings for Mozilla.
[edit] Performance Issues
The bad news is that the users profile is downloaded *in it's entirety* each time a user logs in. When the user logs out, any changed files are synchronized with the server. This means trouble because a users profile includes the My documents and Application Data directories. Furthermore, users who are used to using single user operating systems will often put files in bad places. Downloading to the desktop is one of these bad habits. Heck, even I do it on Windows XP.
[edit] The Desktop Problem
My solution to this problem is that we can just move all files that are not shortcuts before the user leaves.
I've installed a modified (by me) version of rmtotrash found here. Just download, and use tar xvzf dl-0.3.tgz to extract the files and then run the install.mdk script. Next add the following line to your profiles share:
root postexec = /bin/su -c "/usr/local/bin/dl /var/lib/samba/profiles/%u/Desktop/*[^.lnk]" %u
This will cause all files that are not shortcuts to be moved to the user's trash bin in the home directory. This provides two advantages. The user can still put things on their desktop as a temporary place and if anything important gets moved it will still be available until the trash gets dumped. Trash can be dumped either manually by the user or one may make an entry in their super user's crontab file for the trash dumping script included.
[edit] Folder Re-direction and Default Users
So the problem here is that one has to at least re-direct My Documents and Application Data in order to expect any real performance out of Samba. This is a Windows thing of course. Samba itself is written by open-source guys who know better. ;-)
We will begin addressing this by creating a user named "Default User".
[root@massive root]# smbldap-useradd -a -m "Default User";smbldap-passwd "Default User"
Next join your Windows client to the Domain using these techniques:
A. Logon to the Windows machine as a local Administrator.
B. Right click on My Computer from the desktop or click on System in the Control Panel.
C. Click on the Computer Name tab and select Change.
D. Select the Domain radio button and enter the name of the domain to be joined.
E. Click OK.
F. Supply a Domain Admins' ( i.e. any user belonging to this group ) userid and password. If successful you will be presented with a welcome screen and instructed to restart.
After restarting, log into the Windows machine as "Default user". Don't forget to select the domain using the "Log on to:" drop down list box provided. When the desktop comes up, you may be presented with what looks to be an error but is actually a text file in your "Startup" menu. You can delete this by going Start > All Programs > Startup. Right click on it and select delete.
N.B.:There *will* be trouble if you join a domain and then delete the computer account before having your client Windows box leave the domain. As a rule of thumb, it is best to avoid deleting computer accounts unless you are testing the ability to create or remove them.
OK, so we have up what is to become our default desktop. Change anything you like but remember that in the future all new users will have to start with it. The most important changes we will make will be in the registry, so when it looks like you want it to, open a DOS prompt and type "regedit". What we are going to do now is re-direct My Documents and Application Data for the default user so that all new users will start with correct settings. Next, navigate to:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Note the settings herein. Look familiar? It should as most of it is found in a users profile. Change these settings according to your needs. If you make a change, ensure that you change it throughout HKEY_CURRENT_USER for uniformity. You should also be aware that the registry editor can Export these settings to a text based reg file.
Tip Remember that registry settings are different on each Windows client architecture. Although it's possible, you can't expect settings for NT to be identical on 2K or XP Pro. Despite this issue, correct usage of the "a" (a for architecture) macro in smb.conf directory specs can result in users being able to log in safely from most Windows systems. You would have to set up Default User's for each architecture though as well as include the %a macro in the directory specs for netlogon and profile. Ditto for profdata if it is also in use.
This is not usually required but it is good if, for example, you have a large number of freshly migrated users who have incorrect registry settings. What you do is change all of the non-blank settings in
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
and in
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]
So that they read correctly. Best off to use the most generic settings possible, so it's probably best to use Windows environment variables such as HOMESHARE and USERPROFILE profusely. Then when you are done, export these each to a reg file and then combine the two. Great! Now what you can do is put this file in the root of your netlogon directory along with a logon.bat file that contains:
regedit /s [name of the reg file]
Now every time a user logs in, the registry settings will be reset to thier generic defaults for that user. Manually applying it to a user, say the Default User for example, is as easy as double clicking on the file. It contains the following redirections:
Application Data is redirected to HOMESHARE/.Application Data
My Documents and all subdirectories of My Documents are redirected to HOMESHARE/Documents
Local AppData is redirected to HOMESHARE/.Local AppData
PrintHood is redirected to HOMESHARE/Printhood
Tip You can place directories in /etc/skel and all new users will then have these directories if the "-m" flag is used withsmbldap-useradd . This is one way to automatically set up targets for your redirections because, of course, if you don't actually have these directories in the user's home directory, there will be trouble.
After making your changes, log out. You may get errors to the extent that Windows cannot find files. Obviously because we just changed things around. This is actually a good sign and the errors can be safely ignored.
If you want to test your re-directions, log back in and use a program that you know for a fact uses one of the folders you've redirected. My test involved simply starting Mozilla as I know that it uses Application Data. Then all you have to do is check and see if the program placed files where we would expect them. My Documents can be checked simply by right clicking on the desktop icon and selecting properties. The "Target" should be pointing where we expect it.
OK, now that we have our default user all set up, log out and then get on the Linux box and do this:
mv /var/lib/samba/profiles/Default\ User /var/lib/samba/netlogon/Default\ User chmod -R 755 /var/lib/samba/netlogon/Default\ User chown -R root."Domain Users" /var/lib/samba/netlogon/Default\ User
That's it. Every new user should now start with the correct default settings. In theory we can make Samba work very close to the way NFS does for Linux users in a single sign-on scenario by redirecting each directory in the profile. Furthermore, the correct redirection settings for other clients such as NT or Windows 2K should be very similar. You can now delete the Default User account. Later, if you wish to make more changes, you can recreate the account and simply log in. The old default settings will be copied from the netlogon share when you do providing you with a nice starting point.
Now, my research on the web turned up a couple of possibilities for doing this. One was to implement Windows "policies" and the other is to use these registry hacking techniques. I've found the policy editors hard to come by. Also, Microsoft sometimes wants money for them and that is precisely what many of us are trying to avoid by using Samba.
[edit] Simple Print Services
Figure 7.2, found here in the The Official Samba-3 HOWTO and Reference Guide, shows how to set up basic pass-through (to CUPS) print services. This section on printing assumes that you have already set up the printer or printers in question using printerdrake. Below is a version that has been edited for our setup. Just add the global settings to the global section of /etc/samba/smb.conf and tack the printers section onto the end.
[global] printing = cups printcap name = cups [printers] comment = All Printers path = /var/spool/samba printer admin = @"Domain Admins" guest ok = Yes printable = Yes use client driver = Yes browseable = No
On Windows XP, the client side setup deviate's a bit from the norm in that you are setting up a *local* printer and port rather than a network printer. So you go Start > Printers and Faxes > Add A Printer and then select Local printer attached to this computer but make sure that you uncheck Automatically detect and install my Plug and Play printer and then select Next. Now select the Create a new type of port radio button and then select Local port from the drop down list box. In the box provided, you would enter something like //MASSIVE/[CUPS printer name goes here].
Now, if you're like me and you have a Lexmark Z53 for a printer, you may find that you have to disable some check boxes for bi-directional printing support.
[edit] Serving CUPS drivers with Samba
We would really rather not have to check out a copy of the drivers disk to our users each time they want to add the printer. It would be far better if we could get the server to provide those files on request. This process entails copying the files to the appropriate directory under /var/lib/samba/printers and then registering those drivers in secrets.tdb Now the underlying system is CUPS (Common Unix Printing System) so why not just use Samba to provide a set of drivers for CUPS? We can do this if we:
1. Download and install the drivers.
2. Make some changes to our /etc/samba/smb.conf
3. Change ownership on the drivers directory.
4. Install the drivers using cupsaddsmb.
Tip Amongst other things, cupsaddsmb uses smbclient to register the drivers into etc/samba/secrets.tdb
The drivers can be downloaded at the site mentioned above. The process is straightforward:
[root@massive temp]tar xvzf cups-samba-5.0rc3.tar.gz [root@massive temp]./cups-samba.install
Next we add or change the following share to our /etc/smb.conf :
[print$] comment = Printer Drivers path = /var/lib/samba/printers browseable = Yes guest ok = No read only = No
We also have to make sure that we have use client driver = Yes commented out or set to "No" in the printers section.
To ensure that we have the correct ownerships and permissions:
[root@massive samba]# chmod -R 765 /var/lib/samba/printers [root@massive samba]# chown -R Administrator.'Domain Admins' /var/lib/samba/printers
OK, now restart samba or cause it to re-load it's configureation files by using this command:
[root@massive root] killall -HUP smbd
Great, now we'll install the CUPS drivers into Samba. We do this by using the cupsaddsmb command which is really just a front end for smbclient. The cupsaddsmb command installs a set of generic ( but superb! ) postscript drivers into Samba that are compatible with Windows NT, 2000 and XP. If you want similar files for Windows 95/98/ME series OS's they can be had from Adobe's website. Install the files into Samba using the following command:
[root@massive root]# cupsaddsmb -H massive -U Administrator [Name of CUPS printer]
To find out what printer drivers you have installed use:
rpcclient [server name] -U 'user%passwd' -c 'enumdrivers'
To delete an old printer driver, try something like:
rpcclient [server name] -U 'user%passwd' -c 'deldriver [printer driver]'
Then remove the files related to the printer in the driver directory.
If you want to learn more about this process, perhaps so that you can disseminate a greater variety of printer drivers, you may want to use the verbose mode to see what is happening. To find out more about cupsaddsmb use:
[root@massive root]# man cupsaddsmb
For more information about pass-through printing or driver downloading try CUPS-printing in The Official Samba HOWTO Guide and Reference and Chapter 7 of the same manual.
[edit] Recycle Bins for Your Shares
If you delete a file while logged into the Domain, you will find that it winds up in the Recycle Bin on the local machine. This doesn't help you much when you change machines and need that file you deleted an hour ago. We can use Virtual File System Objects to address this problem. If, for example, we add these statements to our homes share we can get the users Unix trash directory to double as a Windows Recycle Bin:
vfs objects = recycle recycle:keeptree = Yes recycle:touch = Yes recycle:versions = Yes recycle:maxsize = 209715200 recycle:exclude = *.tmp|*.temp|*.o|*.obj|~$*|*.~?? recycle:excludedir = /tmp|/temp|/cache recycle:repository = ./Desktop/Trash
For my profile share I also have a Recycle Bin:
vfs objects = recycle recycle:keeptree = Yes recycle:touch = Yes recycle:versions = Yes recycle:maxsize = 209715200 recycle:exclude = *.tmp|*.temp|*.o|*.obj|~$*|*.~?? recycle:excludedir = /tmp|/temp|/cache recycle:noversions = *.doc|*.xls|*.ppt recycle:repository = ../../../../../home/%U/Desktop/Trash
With this setup, both files deleted from the users homes share and files deleted from the users profile will be dumped into the users Unix Trash directory. Note that if you have My Documents redirected then you will find that Windows creates a RECYCLE directory on its own as a subdirectory of My Document. This may be due to the mapped drive Z. The maxsize setting can be determined by deciding on the largest size allowable in megabytes or kilobytes, etc. and then typing something like "How many bytes in 200 megabytes" into Google. Google returns the answer rather than search pages. For more information on these settings and what exactly they do, see this section in Official Samba-3 HOWTO and Reference Guide.
[edit] Virus Protection with ClamAV
Most of us know that Linux is virtually immune to viruses. This doesn't prevent Windows based viruses from using your Linux based Samba server as a means to proliferate. So in order to begin, we must first install the following RPM packages:
clamd libclamav1 clamav-db clamav samba-vscan-clamav
Then start the clamav daemons with:
[root@massive root]$ service clamd start;service freshclam start Starting Clam AntiVirus Daemon: [ OK ] Starting Clam AntiVirus Update Daemon: [ OK ] [root@massive root]$ chkconfig clamd on [root@massive root]$ chkconfig freshclam on [root@massive root]$
OK, so we have the ClamAV scanner up and running. Next we have to add the clamav user to the 'Domain Admins' group so that the scanner may scan what it pleases. The RPM's create this user in /etc/passwd upon install. Because this user is not in our LDAP database, we cannot add it to 'Domain Admins' using our smbldap tools.
We can get around this in two different ways:
If all you have access to are the smbldap tools, duplicate both the =clamav= user and group. When I say duplicate, I mean that the uidNumber and gidNumber attributes in the LDAP users record should be identical to thier counter parts in the /etc/passwd and /etc/group directories. Then add the clamav user to the Domain Admins group.
That was the hard way, now here is the easy way. If you have access to gq, you can simply add a memberUid attribute with the value of {{{1}}} to the Domain Admins group.
OK, now the scanner will be able to scan anything it needs to. Next it is a good idea to browse through /etc/clamd.conf and /etc/samba/vscan-clamav.conf and decide what options we want.
Last of all, you need to add these two lines to each of your shares:
vfs object = vscan-clamav vscan-clamav: config-file = /etc/samba/vscan-clamav.conf
Want make sure it works? Try:
tail -f /var/log/syslog | grep clamav
Then use your windows box to create a simple text file on a share and watch the log. Then open the file from your windows box and make some changes and check again.
[edit] Congratulations!
You've just finished your samba-ldap PDC! Remember to make any necessary adjustments to your client systems in accordance with standard Samba PDC procedure then use the Administrator user's userid and password to add your machine to the domain.
According to discussion on the OpenLDAP lists, these next comments do not pertain to the smbldap-tools package (i.e. the Perl scripts in /usr/share/samba/scripts) but they are important if you are going to write scripts in languages other than Perl. Now, if you have things set such that you never have more than one entity, either an administrator or a script etc., making changes at one time you may safely ignore these issues. Otherwise you may be interested in the information below.
OpenLDAP is a trimmed down Object Orientated DBMS as opposed to an RDBMS or Relational DBMS. Trimmed down means that some of the functions one might normally find in a DBMS have been omitted. This lack of function is not by any means a bad thing as it facilitates speed and compatibility across different versions of LDAP. However because of this, some creativity is frequently required when writing scripts that manage the system.
Specifically, the lack of record-locking facilities. This issue can be resolved by using a data structure called a semaphore in our local scripts. Also, by specifying the entire dn, including the value to be modified, in the script such that if the value is modified by another script before we can finish our modification, our modification will fail because the dn no longer exists. Semaphores exist in Perl, PHP and also I believe in Python. To find out more about them, use an on-line reference appropriate to the script language you wish to use. Most of these explain the concept sufficiently so that even one who does not know the script language in question can understand it.
Finally, you need to do the paperwork, specifically documenting what was done, and why.
[edit] More To Come!
I am always updating this document and I have many improvements to research. For example:
1. I need to do a re-write for LE 2005 as there are some differences and an annoying little bug to be noted.
2. We could get more out of our LDAP server by adding other information to it. Addressbooks, SSL certificates, etc.
3. Client-side management using usrmgr.exe and srvmgr.exe
[edit] Credits
The amount of help I received in compiling this article was phenomenal. When I started, I was new to authentication, OpenLDAP and Samba PDC's. The guidance I received from the folks listed here was invaluable. Doubly so since the original HOWTO was a direct contribution to my graduate thesis on Cross-platform User Authentication. I owe a great number of people thanks however it is likely that I will not be able to list them all. The listed sources then, are those to whom I feel especially indebted. Special thanks to Mr. Terpstra for his books The Official Samba-3 HOWTO and Reference Guide and Samba-3 By Example.
- Anne Wilson
- John H. Terpstra
- Buchan Milne
- Vincent Danen
- Upendra Gandhi
- The online Samba Community
- The online OpenLDAP Community
