SAMBA 4 Released! Let’s get installing!

So, as many of you have heard, SAMBA 4 was finally released… and holy crap, it’s the closest LDAP service I’ve ever seen to the real Active Directory. As well it should be too, I mean, Microsoft actually helped work on it! This release of SAMBA is huge. It’s really going to change the game of LDAP, file sharing between Linux/Unix and Windows, and authentication. You can read the news release from the SAMBA team HERE or visit their website HERE

What is really huge about it all is that you can setup a SAMBA 4 server to take over, literally, all functions of a Windows AD Domain Controller. It can process authentication requests, hand out Group Policies, process MSRPC communications and more. Think about if you could replace most of your Windows AD DCs with free software. How much will that save you in cost?

So naturally, I’m in the process of getting it up and running. I figure I just got my home systems to authenticate to Active Directory, why not replace one of the Domain Controllers with a SAMBA Domain Controller? So, I’m basing this on a Debian 6 machine. I figure that’s the best place I can put it since I plan on it being around for a while. Why do I plan on it being around for a while? Because rebuilding AD from scratch sucks! And with Debian being a rolling-release operating system, I’ll never have to reinstall the OS on the next release! Pretty damn convenient if you ask me.

So I downloaded the small .iso installer file from Debian , provisioned a new VM, and installed Debian 6. It really doens’t take too long, and when it’s done, you dont have to update it, it’s totally patched and ready to go from the start, it’s so easy to work with!

After getting the OS up and running, I had some house keeping to do:

sudo apt-get install gcc make python-dev linux-headers-2.6.32-5-all

Then I was able to install VMware Tools. You’d have to do the same thing on a VirtualBox system, and you’ll need that stuff for installing SAMBA anyways, so you might as well just install this stuff now and get it over with.

So now we need to actually get the SAMBA4 code, which we can do two separate ways. I’m sure in the future that SAMBA 4 is going to start becoming available in repositories so how you do this is up to you. The two options I recommend are GIT and WGET, which are outlined here:

My Debian 6 machine didn’t have GIT installed so a simple “sudo apt-get install git” solved the issue.

cd ~
mkdir samba4
cd samba4
git clone git:// samba-master


cd ~
mkdir samba4
cd samba4

From here it’s simple. If you downloaded the tarball, just extract it like this:

tar -zxvf samba-4.0.0.tar.gz

Now, whether you have performed either the GIT or the TAR method, you’re in the same place.
Just enter your “samba-master” or “samba-4.0.0” directory to continue.

From here we’re going to compile everything, starting with





sudo make install clean

Durring the configure, make and install you’ll see a ton of scrollback. I set my scrollback to “Unlimited” in my terminal so that I can go back through it if there are issues. I forgot that the “make install clean” needs to be run as root or you can sudo that command:

steve@ncis-samba:~/samba/samba-master$ sudo !!
sudo make install clean
[sudo] password for steve:
WAF_MAKE=1 python ./buildtools/bin/waf install
./buildtools/wafsamba/ DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import md5
Waf: Entering directory `/home/steve/samba/samba-master/bin'
* creating /usr/local/samba/etc
* creating /usr/local/samba/private
* creating /usr/local/samba/var
* creating /usr/local/samba/private
* creating /usr/local/samba/var/lib
* creating /usr/local/samba/var/locks
* creating /usr/local/samba/var/cache
* creating /usr/local/samba/var/lock
* creating /usr/local/samba/var/run
* creating /usr/local/samba/var/run
    Selected embedded Heimdal build
Checking project rules ...
Project rules pass
(scrollback omitted)
Waf: Leaving directory `/home/steve/samba/samba-master/bin'
'install' finished successfully (1m42.653s)
WAF_MAKE=1 python ./buildtools/bin/waf clean
./buildtools/wafsamba/ DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import md5
    Selected embedded Heimdal build
'clean' finished successfully (0.765s)

And we’re done! Well, at least for installing this software.

You now have SAMBA 4 installed on a Debian 6 System! 🙂

steve@ncis-samba:~/samba/samba-master$ ls -alh /usr/local/samba/
total 40K
drwxr-sr-x 10 root staff 4.0K Dec 15 13:18 .
drwxrwsr-x 11 root staff 4.0K Dec 15 13:18 ..
drwxr-sr-x  2 root staff 4.0K Dec 15 13:20 bin
drwxr-sr-x  2 root staff 4.0K Dec 15 13:18 etc
drwxr-sr-x  7 root staff 4.0K Dec 15 13:18 include
drwxr-sr-x 14 root staff 4.0K Dec 15 13:19 lib
drwxr-sr-x  2 root staff 4.0K Dec 15 13:18 private
drwxr-sr-x  2 root staff 4.0K Dec 15 13:20 sbin
drwxr-sr-x  7 root staff 4.0K Dec 15 13:20 share
drwxr-sr-x  7 root staff 4.0K Dec 15 13:18 var

You probably want to make SAMBA start when your server boots, right? Well, lets get that going.

The people over at SAMBA have made this super easy. So lets get some wget action going on this.

Just use wget like this:

wget -O /etc/init.d/samba4

If that link doesnt work, I’ve posted the script on my site, here:

From here, you just need to make sure this script is executable:

chmod 755 /etc/init.d/samba4

Now you can add this to your init scripts:

update-rc.d samba4 defaults

As for configuring SAMBA 4, that’ll be in my next blog. If it’s anything like setting up and configuring a Microsoft AD Domain Controller (which I’m sure it’ll be much MORE difficult than that) then I’m sure the next blog will be pretty long…



VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Open Source: Managing Debian and Ubuntu Linux with Active Directory

I talked about this in my last blog post: We had a need for Authentication on our Linux/Unix systems to be done by Active Directory. So my co-worker and I set off on a mission to fulfill this request. We’d tried some software that wasn’t free, heard about some other software that wasn’t free and then is struck us. “Why Pay?”

All the work had previously been done for us in the Open Source community… why not leverage them directly? So this is my homage to the Open Source community. I’m going to try to give back by writing this blog about my trials and tribulations in setting up this functionality. I’ll forewarn you, this blog entry is very long and gets into a lot of detail, but I assure you, at the end of the day, this works!

My testbed here is my home network. I’m running a 2008 Server with AD installed. Nothing special, very vanilla, no crazy GPOs to deal with, no delegations to worry about and I’ve secured the environment fairly well (IMHO). There are virtually no extra roles, services or features installed other than a base install of AD Services, but I do have Exchange Server 2010 installed, so the schema has been extended for that. But it shouldn’t affect your environment if you aren’t running Exchange.

I want to get one last statement in here: I am by no means a Linux or Unix Expert, but I can troubleshoot and read. The way I have this setup here is the way I figured out to do it and the best I can say is that it works, it’s secure, and it doesn’t take long to do. I’ve done a bunch of research and I’m going to attempt to regurgitate that knowledge back into this blog as best I can. If you know how to do something better here, please contact me at my LinkedIn page 🙂 .

So lets get down to brass tacks here… I have some Debian based systems (Linux Mint 13, Debian 6 and two Ubuntu 10.04 Servers), a Red Hat server (REL 6), an Oracle Enterprise Linux 6 Server, 3 Windows Server 2008 domain controllers, an Exchange 2010 server and some other systems on my home network. I wanted to extend my AD capabilities by getting my Debian based systems to authenticate to my 2008 Domain Controllers (DCs).

To start, you’ll need to know a couple peices of information. You’ll need to know what DC is holding the PDC FSMO role. Easiest way to do that is to log onto a DC, fire up AD Users and Computers, right click on the domain name and then click on Operations Masters. In the window that appears on your screen click on the PDC tab and document the FQDN of the server that currently holds that role.

Operations Master

After you identify this system, the next best thing to do is create a DNS entry pointing to your PDC Server. This way if you ever need to decommission your current PDC server, you can just change the DNS record and not have to go back to all your Linux systems to update the system they authenticate to.

From here, everything you’re going to do, aside from creating new AD users and security groups, will all be done at the Linux command line. There’s a couple of conf files that we need to configure after installing some software on each of the systems. In one of my future blog posts, I’m (hopefully) going to be going over using Chef to distribute configuration files <>.

This whole process isnt all that difficult as long as you have a decent understanding of the services and subsystems that you’re relying on. Here they are:

  • Pluggable Authentication Modules (PAM)
  • Server Message Block (SMB, Samba)
  • WinBIND (part of Samba)
  • Kerberos 5 (By MIT, with Microsoft compatibility hacks)

SO, lets get some software installed. Below is the EXACT command line that I used on my Ubuntu servers (10.04).

sudo apt-get install krb5-user libkrb53 krb5-config winbind samba ntp ntpdate nss-updatedb libnss-db libpam-ccreds libnss-ldap ldap-utils


After installing that software, you’ll want to stop all the services while you configure them:

sudo /etc/init.d/samba stop
sudo /etc/init.d/winbind stop
sudo /etc/init.d/ntp-server stop


Each server in a Kerberos authentication realm must be assigned a Fully Qualified Domain Name (FQDN) that is both forward- and reverse-resolvable.

Note: Active Directory depends heavily on DNS, so it is likely that the Active Directory Domain Controller is also running the Microsoft DNS server package. If this is the case, verify that each server has a FQDN assigned to it before performing the tests outlined in this section.

If the server already has an FQDN assigned to it, test forward and reverse look-up with the following commands:

nslookup  (ip address of server)

The output of the first command should contain the IP address of the server. The output of the second command should contain the FQDN of the server. If this is not the case, Kerberos authentication will not function properly. Next, we’ll be configuring the Kerberos Config file which is located here: /etc/krb5.conf Here’s what mine looks like (Make sure to read the comments I put in there):

default_realm = ERDMANOR.COM #Kerberos is CASE sensitive; this must be all UPPERCASE!
default = FILE:/var/log/krb5.log
kdc = FILE:/var/log/krb5kdc.log
kdc = #You really only need 1 kerberos domain controller
kdc = #but in my network there are three, so I listed
kdc = #all of them in here.
admin_server = #This should be set to the DC that holds the PDC Role
default_domain = #

krb4_convert = true
krb4_get_tickets = false



Active Directory, for as long as I can remember, is time sensitive to about +/- 5 minutes. You can adjust that window to anything you want by editing your Domain Policies (Group Policies (GPOs)), but there’s no need to really do that. Anything outside that window of time and your Domain Controllers will deny any kerberos ticket requests. This is why you need to make sure and setup your NTP daemon to point at your domain controller. I recommend setting it up with a DNS name, but you can get by with an IP address. Reason is, if the PDC ever changes, you dont need to go back to all your old machines and update conf files. Run this command: “sudo nano /etc/ntp.conf”

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Specify one or more NTP servers.

server #insert your PDC here
server #secondary DC
server #third DC
server #fall back to Ubuntu's NTP
server #
server #


So, we’re on our way here. Without saying, you’re probably getting a DHCP address from a Domain Controller if you’re already on a Windows network. If you’re setting up a server with a Static address, then make sure to setup your DNS nameservers in your /etc/resolv.conf file so that you’re getting DNS from your PDC and any other Domain Controllers which host DNS. I DONT recommend using your “/etc/hosts” file for this.


So lets get to testing! From the command line issue this command:

kinit -p username@MYDOMAIN.COM
#obviously changing to your username and domain name on your network.
#Notice the UPPERCASE spelling of MYDOMAIN.COM?

After that command is entered you should be getting prompted for your DOMAIN password. From here just make sure that you’re not getting any errors (which you shouldn’t). If you’re looking to verify that you have a valid ticket, then issue this command:

klist -e

Now that we have Kerberos and NTP working properly, we can move onto the next portion of authentication: PAM. If you dont know anything about PAM then you can safely move on to the configuration portion of this part. But for those of you wanting more of an understanding, here you go. I got this information from, and it’s VERY good info. Also, verify that your “/etc/skel/” directory is setup properly. You can get creative with this and have some pretty neat options rolled out to all your users if you prefer.

#I took out all the #comments for this blog, but I HIGHLY recommend that you leave them in!

so here are what my PAM modules look like in /etc/pam.d/:

# /etc/pam.d/common-account - authorization settings common to all services
session required skel=/etc/skel/ umask=0022 #VERY IMPORTANT!
account [success=3 new_authtok_reqd=done default=ignore]
account [success=2 new_authtok_reqd=done default=ignore]
account [success=1 default=ignore]
account requisite
account required
account required minimum_uid=1000


# /etc/pam.d/common-auth - authentication settings common to all services
# here are the per-package modules (the "Primary" block)
session required skel=/etc/skel/ umask=0022
auth [success=6 default=ignore] minimum_uid=1000
auth [success=5 default=ignore] nullok_secure try_first_pass
auth [success=4 default=ignore] krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth [success=3 default=ignore] use_first_pass
auth [success=2 default=ignore] minimum_uid=1000 action=validate use_first_pass
auth [default=ignore] minimum_uid=1000 action=update
auth requisite
auth required
auth optional minimum_uid=1000 action=store
auth optional
auth optional


# /etc/pam.d/common-password - password-related modules common to all services
password [success=4 default=ignore] minimum_uid=1000
password [success=3 default=ignore] obscure use_authtok try_first_pass sha512
password [success=2 default=ignore] use_authtok try_first_pass
password [success=1 user_unknown=ignore default=die] use_authtok try_first_pass
password requisite
password required
password optional


# /etc/pam.d/common-session - session-related modules common to all services
session [default=1]
session requisite
session required
session optional
session required skel=/etc/skel/ umask=0022
session optional minimum_uid=1000
session required
session optional
session optional
session optional
session optional nox11


# /etc/pam.d/common-session-noninteractive - session-related modules
# common to all non-interactive services
session [default=1]
session requisite
session required
session optional
session optional minimum_uid=1000
session required
session optional
session optional
session optional


This should be everything you need for PAM to work properly. Now we need to work on Samba. The Samba config is stored at “/etc/samba/smb.conf”. Again, I stripped my Samba config down and made a backup of the original. I dont want my end users sharing data between themselves, I want them using corporate file shares where I know that the data is backed up. Also, I want them using Print Servers, not hosting printers from their machines. So this smb.conf is pretty short compared to the original. If you visit the Samba website, you’ll even see that they want people to keep this file short and simple. According to the Samba Team, the longer this file is, the more it impacts performance of the system. Please heed the warnings in your smb.conf as well as the notes I post below:

# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic
# errors.
#======================= Global Settings =======================


security = ads
realm = MYDOMAIN.COM #Must be UPPER case
password server = #PDC that we mentioned earlier
workgroup = MYDOMAIN #This is the NetBIOS name of your Domain
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/MYDOMAIN/%U #Dont forget to update this directory!
template shell = /bin/bash #You can use whatever shell you'd like
client use spnego = yes
client ntlmv2 auth = yes
encrypt passwords = yes
winbind use default domain = yes
restrict anonymous = 2

server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog only = yes
syslog = 4
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
domain logons = no #Extremely important that this is NO.
usershare allow guests = yes



Next we’ll be setting up the “/etc/nsswitch.conf” file. This file does a few things to help communications with your LDAP server (AD in this case) as well as tell your local Linux system where to look for password information.

When fiddling with /etc/nsswitch.conf, it is best to turn the Name Services Caching Daemon off or you will be confused by cached results. Turn it on afterwards.

/etc/init.d/nscd stop

Now edit the nsswitch.conf file:

# /etc/nsswitch.conf
passwd: files winbind
group: files winbind
shadow: compat
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

And Turn back on your service:

/etc/init.d/nscd start


Assuming that all goes well and Kerberos, Winbind and Samba are setup properly, you should be able to join your linux system to the domain. Due to restrictions in the NetBIOS protocol, the hostname must contain no more than 15 characters. If you see a STATUS_BUFFER_OVERFLOW message in the winbind log, odds are the hostname is invalid. Now would also be a good time to clear whatever cache files, if any, Winbind had previously generated. The Winbind cache is located in /var/lib/samba/. Backup this directory to /var/lib/samba.bak/ and delete all the files in the original. Now you can issue this command:

sudo net ads join -S MYDOMAIN.COM -U {domain-admin-user}

Couple things here.
First, you may need to change MYDOMAIN.COM to KERBEROS.MYDOMAIN.COM. If it doesn’t work the first way, try the next. Second is, {domain-admin-user} MUST be a Domain Admin account in Active Directory. Otherwise you’ll fail.

Now, I’ve gotten mixed results here… My Mint 12 and 13 boxes joined and I actually got a “Domain Joined!” message in the shell.

My Debian 6 machine threw an error:

steve @ mintdebianvm ~ :) ᛤ>   sudo net ads join -S ERDMANOR.COM -U administrator
[sudo] password for steve:
Enter administrator's password:
kinit succeeded but ads_sasl_spnego_krb5_bind failed: Server not found in Kerberos database
Failed to join domain: failed to connect to AD: Server not found in Kerberos database

I haven’t had much time to look into why this is happening, but I can assure you the system joined the domain, the computer account was created in AD and I’m able to SSH to this machine with domain creds… If anyone knows why this is happening, PLEASE contact me! Thanks!


Look up Windows Ports needed for Active Directory. Need Microsoft Link!
After your join to the domain is successfull, you can startup your services:

sudo /etc/init.d/samba start
sudo /etc/init.d/winbind start



From this point, you should be able to test some querys against the domain:

getent passwd
getent shadow
getent group

At this point, you should be able to resolve users and groups from the Windows Active Directory domain using getent passwd and getent group. If these commands don’t display your Windows accounts, try to resolve them using wbinfo -u and wbinfo -g. These commands query the Winbind service directly, bypassing the name service switch. If you can resolve users and groups with wbinfo, go back and make sure you configured /etc/nsswitch.conf properly.


Now with EVERYTHING setup properly, you *should* be able to fire up an SSH session to your linux box and log in with AD Credentals. BUT! Your Domain Users are NOT going to be able to “sudo” any commands. For the sake of security, you dont want ALL your domain users to be able to sudo commands, so what I did is create a domain security group, mine is named “linux-sudo”. Then I added in only the users I want to be able to sudo commands to that group. Then I edited my “sudoers” file to include the domain security group “linux-sudo”. So make sure to edit your “/etc/sudoers” file, and add this line:

%linux-sudo     ALL=(ALL:ALL) ALL

Now, I’m able to log into my Debian, Mint and Ubuntu Linux systems with Domain Credentials! 🙂

EDIT: In looking for information regarding this entire process on a RED HAT system. (RHEL 5 or 6), please refer to this guide:

Here are all the sites that I used in the making of this blog:

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)