OpenBSD Journal

openbsd & samba fileserver with nt domain authentication

Contributed by Dengue on from the domain-member dept.

robert p lessard writes :
Setting Up an Openbsd/Samba Fileserver with NT Domain Authentication
- by Robert P Lessard

Project Goals

  • OpenBSD 3.1 operating system
  • Samba 2.2.5 SMB file sharing
  • Windows NT 4.0 domain authentication
  • SWAT remote admin from Windows client
  • Minimize server overhead

Fileserver summary (what I had to work with)
  • Intel PIII 500mhz
  • 192mb SDRAM
  • 8 gb EIDE HDD
  • Standard FDD/IDE CDROM
  • Integrated 1mb video
  • Standard keyboard
  • No sound, no mouse
Primary Domain Controller (NT domain settings)
  • Windows NT 4.0 sp4
  • Domain name: test.org
  • Host/netbios: pdc.test.org/pdc
  • Ip: 172.16.38.141/255.255.254.0
  • Gateway: 172.16.38.1
  • Primary WINS server
  • Primary DNS server
Step-by-step procedure

I used a snapshot of -current dated 9/4/2002. Otherwise, you can use the standard release and apply patches up to that date and duplicate my setup. The standard release was missing some files required to use the Samba 2.2.5 distribution without a work around- the update installed those files.

This is just a training PC for me, so you’ll have to apply any patches for your system as applicable.

After logging into the system as root, I installed the following packages:

  • pico-4.2.tgz
  • samba-2.2.5.tgz
  • zap-1.3.tgz
Note: the latest Samba release at the time of this writing at the above site was samba-2.2.3a.tgz but someone compiled the newer version on one of the mirror sites. I simply did an internet search for “samba-2.2.5.tgz” and found it.

Why these packages?

Pico is a text editor. VI is the text editor that comes with the default install. Unless you are smart on all the VI commands, I would recommend pico. It is a lot more forgiving and has a command legend at the bottom of the screen if you forget what to type.

Samba is the SMB software that allows us to provide services for Windows clients. Specifically, it allows us to share folders and printers, be an application server in a Windows network and it even has some limited domain controller capabilities.

Zap is a utility that makes killing a process on OpenBSD easier. Typically, you would need to use the “ps” command to get a list of processes and kill each one by process number. Zap streamlines this process.

That’s all I installed on my PC. I wanted the lowest overhead on the server that I could tolerate. Samba is required for what we want to do and the other tools are tiny and save me heartache. The only other overhead we will have is the ability to edit the Samba configuration remotely with SWAT- just in case we are not at the computer. We will set that up to “start on demand” and shut down when not needed.

Testing that Samba installed

To make sure Samba actually installed type:

find / -name smbd -print
You should get back this response:
/usr/local/libexec/smbd
This is the location of the smbd (server message block) daemon. If you type the following:
cd /usr/local/libexec; ls
You will see that the nmbd (netbios) daemon and SWAT (Samba remote admin) are also installed.

We could set up SWAT at this point and use a friendlier GUI tool, but one of the limitations of SWAT is that it resaves your smb.conf file without comments. That means that any notes or config lines you have rem’d out will be lost.

With that said, let’s edit the smb.conf file on the OpenBSD computer with pico and then we can adjust it with SWAT later. Type

pico /etc/samba/smb.conf
This brings up smb.conf to edit. Remove appropriate “#” or “;” marks and add lines to achieve the following setup in the global section:
Workgroup = test.org
Netbios name = fileserver
Server string = OpenBSD Samba FileServer
Interfaces = 172.16.38.141 172.16.38.142
Security = domain
Encrypt passwords = yes
Password server = pdc
Passwd program = /usr/bin/password %u
Passwd chat = *Newspassword:*%nn*Retypesnewspassword:*
Unix password sync = yes
Log level = 1
Log file = /var/log/smbd.%m
Max log size = 500
Add user script = /usr/sbin/adduser –batch %u
Delete user script = /usr/sbin/userdel %u
Os level = 0
Preferred master = false
Local master = no
Domain master = false
Dns proxy = no
Wins server = 172.16.38.141
Host allow = 172.16.38.141 172.16.38.142 127.0.0.1
Be careful with spelling, some of these parameters are misspelled by convention. Use the same parameter lines but substitute the functional equivalents for your network (ie hosts allowed may be your network ID/mask). An explanation of the use of these items may be found at the Samba web site under the documentation section: http://www.samba.org/

Each time you make changes to the smb.conf file, the Samba daemons must be restarted.

Checking smb.conf for proper syntax

Type the following command:

testparm
This should return feedback about how you setup the parameters. It will not tell you that Samba is fully functional. Note: the “unix password sync” parameter was misspelled in my distribution’s sample file and testparm caught it.

Set up Samba to start at boot

Type the following command:

pico /etc/rc.local

After the rc.local file opens, add the following lines and save:

echo “smbd” && /usr/local/libexec/smbd –D echo “nmbd” && /usr/local/libexec/nmbd -D
Setup the system to listen to the SWAT port

Type the following command:

pico /etc/services
After the services file opens, add the following line at the appropriate place in the list of ports and save:
swat 	901/tcp
Now, we don’t want SWAT running continuously because it would waste server resources but we want it to stop when we attempt to connect by typing the following command:
pico /etc/inetd.conf
adding the following line, and saving the updated inetd.conf file.
swat 	stream 	tcp 	nowait.400 root /usr/local/libexec/swat swat
Reboot the system and let the new setting take affect.

Check to see if the Samba daemons started at boot

Type the following command:

ps –x
You should see smbd and nmbd as running processes.

Check for current connections

Of course in our test computer we will not have any connections to the file server but we can get an idea if Samba is running correctly by typing the following command:

smbstatus
When I typed this, the computer gave me a peculiar error about a “failed locking database”. This is a fairly common thread on the chat pages. Don’t panic, this appears normal on the first attempt. It has to do with the fact that no one has actually attempted to attach to Samba yet.

Try to connect to Samba

Type the following command:

smbclient –L fileserver
It will then ask you for the root password. If you get an error at this point about “NT security”, don’t worry about it yet. It is because you must add the root user to the smbpassword database which we will do shortly if it did not occur automatically. Remember, our setup is for domain security and “root” is not an NT account.

Try to type the following command again:

smbstatus
This time the locking database error should not appear. Samba automatically created a locking directory and some files upon the first connection attempt with smbclient. Those were missing and caused the error previously.

Join the fileserver to the domain

So far the Samba server has not participated in any network operations as it does not have a domain account.

At the pdc, use server manager to add a computer account for “fileserver” (or whatever yours is called). Select the non bdc account option.

In dns manager, add the appropriate host record for the Samba server. I also added an entry in the Samba hosts file for the pdc as follows:

172.16.38.141 pdc.test.org  pdc
The last step is to actually “join” the domain. This transfers some domain sid information that Samba needs for authenticating clients. Type the following command:
smbpasswd –j test.org –r pdc.test.org (use your domain/host names)
Samba should return a confirmation that your have joined the domain.

Connect to Samba with SWAT

From the pdc or another Windows client, launch the internet browser and type in the following URL: http://fileserver:901

SWAT will start on the Samba server and ask for the root account and password. If you have a problem connecting try substituting the Samba server ip address instead of the netbios name in the URL. If that works, you have a WINS conflict to troubleshoot.

Once I got in SWAT, I went to the password section, entered the root account and password and selected the change password option. This was just to confirm that the smbpassword file matched the OpenBSD password file. After that, running smbclient from the samba server yielded no errors.

From SWAT, you can go into the status section and restart the Samba daemons whenever you want. If you are hitting roadblocks, it may be because you made changes that need to be assimilated by Samba by restarting those daemons.

Attaching to the fileserver as a domain user

Logon to the domain from the pdc or a Windows NT client and map a network drive to the fileserver.

The first time I logged on as a typical user, there was a pause.

Remember, the first time you log on, there are a number of steps that must be performed by Samba and there is actually no record of your account on the fileserver- neither at the OpenBSD or Samba level. Based on how I have the smb.conf file set up, the following steps occur on the first connection of a user:

  • Since we have selected the “security = domain” and “password server” parameters, Samba requests authentication of your account from the domain controller
  • Samba then looks for the existence of an OpenBSD account for the user
  • Since there is no OpenBSD entry for the user and we have specified the “user add script” parameter, the user account is created on the fly and added to the OpenBSD database
  • At this point, there is no password associated with the OpenBSD account, but we have selected the “unix password sync”, “passwd program” and the “passwd chat” parameters that will update that information
Subsequent connections were much faster with the above complete.

Note: if you haven’t noticed yet, SWAT is not being encrypted! As I mentioned before, this is not a problem for my test environment, but for a production server, I will be looking for a more secure means of remote admin. Test the password update feature

  • Restart the Samba server
  • Log out of the pdc and log back on
  • Change your NT password
  • Map a drive to your personal folder
Final thoughts

There are many other considerations, such as security, that are beyond the scope of my project. For many people, including myself, just getting OpenBSD and Samba set up for domain level authentication has been quite a challenge. This is the first step but a significant learning experience for me and I hope I have save someone many hours of frustration.

Thanks to Robert P. Lessard for providing a SAMBA Howto.

(Comments are closed)


Comments
  1. By Ben Goren () ben@trumpetpower.com on http://www.trumpetpower.com/

    First, thanks for taking the time to write and publish this. It's something that a lot of people have wanted to do for a long time and have had a lot of trouble getting to work.

    Having said that...people reading it shouldn't take it as complete gospel. There are a bunch of little things that are the author's preference and not necessarily the ``right'' way to do something. For example, you generally don't want to blindly attempt to launch things from /etc/rc.local. Instead, you should check that the program you're launching is executable and the reqiured configuration files exist. Or, in other words, follow the pattern set in the rest of rc.local.

    I won't go point-by-point picking the article appart. What you want to do is extract the information on Samba and apply it using the best practices described throughout the OpenBSD documentation.

    Cheers,

    b&

  2. By Anonymous Coward () on

    Call me a party pooper, but many many many such how-tos have been written. Why a new one where the only difference is the 'OpenBSD' in the title? Everyone says how we need more documentation, but it looks like people either aren't using it, or are duplicating the effort several times over.

    Comments
    1. By schubert () on

      Some people have this silly idea ingrained in their mind that somehow openbsd is radically different on the surface than FreeBSD or Linux, when its not. When your average user probably couldn't explain what the real major differences are. They assume all that documentation out there doesn't apply because it doesn't explicitly state "OpenBSD", heaven forbid they actually just read it to see what they can learn from it.

      Comments
      1. By Anonymous Coward () on

        but there are differences, aren't there? it's good to know where they are.

    2. By Anonymous Coward () on

      call me dense, but this is the first article i've seen that ties all this information together. i was looking for exactly this setup, so it was nice to see it all in one place. the more this information is replicated around the internet, the easier it will be to find.

  3. By Warthog () warthog@yonderway.com on mailto:warthog@yonderway.com

    DISCLAIMER: I'm pretty ill right now and not thinking straight. I have not taken the time to double check these suggestions, but my experience and recollection of how Samba works tells me you can make a few refinements here.

    Great HOWTO. I'd suggest a few changes.

    I believe the following statement is incorrect:
    Each time you make changes to the smb.conf file, the Samba daemons must be restarted.

    Try making a change and not restarting Samba. IIRC, Samba is smart enough to periodically recheck its own config.

    SWAT is not necessary and IMHO could unnecessarily introduce security problems down the line. IMHO it is best to just ssh in to make changes.

    If you really feel like replacing NT 4 top to bottom, check out OpenLDAP and some of the new stuff in Samba for dealing with that. I successfully set up for a client a pseudo PDC to replace an NT4 PDC and it worked pretty darned well. Unfortunately that project is on the back burner right now while I build training materials for them on the stuff I've already put into place. The problem is, you might not be able to do that on OpenBSD because IIRC there is some dependency on PAM and of course OpenBSD is still in the 1980's on the authentication front. (I love the platform but you have to be able to admit to shortcomings when they are there so direct flames to /dev/null)

    All in all very good. OpenBSD specific stuff needs to be put out there because it is NOT Linux and there ARE differences.

    Comments
    1. By Brad () brad@comstyle.com on mailto:brad@comstyle.com

      >The problem is, you might not be able to do that on OpenBSD because IIRC there is some dependency on PAM and of course OpenBSD is still in the 1980's on the authentication front.

      Get a clue, PAM sucks. We have BSD auth which is
      better and works on all of our architectures, PAM can't.

      Comments
      1. By Warthog () warthog@yonderway.com on mailto:warthog@yonderway.com

        Alright kid aren't you supposed to be at school or something?

        I was going to go into a debate about why PAM is needed but I'm not wasting my keystrokes on someone who's brightest contribution to this thread is "Get a clue, PAM sucks." I shall not cast pearls before swine.

        Comments
    2. By Anonymous Coward () on

      I'm not sure, but I think samba reads the configuration file when it forks to handle a new connection.

  4. By Anonymous Coward () anonymous@coward.com on http://www.coward.com

    Would recompiling a kernel with specific cache values not help running one of these things too?

    Performance tuning:
    http://www.openbsd.org/faq/faq11.html

    I was thinking about:
    option NMBCLUSTERS
    option BUFCACHEPERCENT

    Thanks for writing the article.

    Comments
    1. By Jean-Yves Burlett () on

      There is no need to recompile a kernel for this, just use config.
      In fact, a custom kernel is almost never required, and using the GENERIC kernel eases support.

      Just use config -e -o /bsd.new /bsd
      type 'help', and use the commands nmbclust, nkmempg and cachepct.

      Comments
      1. By Peter Hessler () spambox@theapt.org on http://www.sfobug.org

        As a gernal policy, /any/ changes to GENERIC (even option OBIOVERBOSE) mean: `cp GENERIC NEWKERN && $favorite_editor NEWKERN` and when I ask for help on various problems that require a DMESG, I include `diff -u GENERIC NEWKERN`.

        Is that cool? (I know it is lots for a newbie to do, but I want to make sure the GENERIC kernel is w/o anything extra, even patches that are not fetched via cvs mean a new kernel name.)

  5. By Jake () on

    I like how deadly.org publishes these step by step walk throughs but after so many articles they aren't there for easy access anymore...

    Walkthroughs like this need to saved in a permant place, so that they are easy to find.

    Comments
    1. By jose () on http://www.monkey.org/~jose/

      the author didn't give us his email address. i wanted to have this posted somewhere else but was unable to contact him.

  6. By Anonymous Coward () on

    I believe the following statement is incorrect: Each time you make changes to the smb.conf file, the Samba daemons must be restarted.
    so you'd rather have it wait till on down the line when it picks up the updated config until you know if you've goofed, before which perhaps you've made a few other changes (now, which one is the cause of failure?) or maybe you just left for vacation before it picked up the change and sputtered... better get a higher wattage bulb, amigo, or make sure your pager-service is paid up. it's absolutely fantastic someone's contributing something that's overall useful. great job on the document! i liked it.

    Comments
    1. By Anonymous Coward () on

      kill -HUP
      that should work I think

  7. By Jeroen () on

    Great howto, but I wouldn't recommend/use SWAT either. I'd state in the howto that it is optional and therefore _not_ necessary.

    Also, I'd recommend nano instead of pico.

    Comments
    1. By Anonymous Coward () on

      What's wrong with vi? Or vim if you want more bells&whistles

      Everyone has his/her favorite editor, so let's just s/pico/your-personal-favorite-editor :)

      Comments
      1. By Ben Johnson () on

        Agreed!

        I happen to think the VI learning curve sucks - but here's the important part: VI is *everywhere* and it works well in low bandwidth situations.


    2. By Ben Johnson () on

      IMHO:

      If the fileserver is behind a firewall - then Swat is darnright nesessary due so that normall users can break file locks themselves. It's easy to train them how to use it - and is used frequently my my clinets.

      For example: Quickbooks file locks into ulslessness when one of it's 'clints' crashes in the middle of doing somthing, MS Access has the same problem.

      For noodleing around remotly, though, your are entirely correct - SWAT is a security problem waiting to happen. No offense at all to the SWAT programmers as securty is not their problem, ease of use is.




  8. By Anonymous Coward () on

    I'd like to see a topic about firewalling Samba; because it doesn't appear to be as easy as other stuff like http.

    I now have the following in my pf.conf:

    # 10.0.0.0/24 = LAN, ne3 = only if in this box

    # Default block & log
    block in log on ne3 all
    # Samba uses tcp ports 137->139
    pass in on ne3 proto tcp from 10.0.0.0/24 to ne3 port 136>139 and multicast!
    # (hence we have to use 'to any' and not 'to ne3'
    pass in on ne3 proto udp from 10.0.0.0/24 to any port 136> <140
    # Outgoing traffic is ok; keep state
    pass out all keep state

    That works, except from nmblookup, since the answers to my NMB queries get blocked (thx tcpdump :)). They appear to come on random ports (well, on a port chosen by nmblookup), and I have yet to find a way to get those replies through without opening up everything... :(

    Anyone who can give me some advice on this?

    Comments
    1. By Anonymous Coward () on

      Oops, I messed up the formatting there...

      # 10.0.0.0/24 = LAN, ne3 = only if in this box

      # Default block & log
      block in log on ne3 all
      # Samba uses tcp ports 137->139
      pass in on ne3 proto tcp from 10.0.0.0/24 to ne3 port 136><140 flags S/SA keep state
      # Samba also uses udp ports 137->139 and multicast!
      # (hence we have to use 'to any' and not 'to ne3'
      pass in on ne3 proto udp from 10.0.0.0/24 to any port 136><140
      # Outgoing traffic is ok; keep state
      pass out all keep state

  9. By Shane J Pearson () shanep AT ign com au on mailto:shanep AT ign com au

    "For many people, including myself, just getting OpenBSD and Samba set up for domain level authentication has been quite a challenge."

    About 18 months ago, I had to set up Samba with domain level auth. I was worried that it would be difficult. I read the help, configured appropriately and it worked fine right away.

    What problems do people have with it?

  10. By Robert P Lessard () on

    Thanks for the comments folks. One person eluded to this kind of setup being a breeze. It probably is for the 'nix people out there. For the record, this was my first attempt at setting up a samba system, and hence, my struggle. One of the things that I have found is that all the info is out there, but it seems, to me at least, to be scattered and was somewhat overwhelming at first.

    This post was for those people who were like me in that they are willing converts from the dark side :-). I just don't want them to look at a couple web sites, get discouraged and give up on the cause.

    FWIW, I set up a OpenBSD/Samba 2.2.5 Primary Domain Controller this past week in a test environment. It feels alright logging into the domain knowing there are no msft servers. When I get a chance, I'll try to post a follow up with the PDC differences/lessons learned.

    Thanks again,
    Rob

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]