One of the most popular posts on this blog is the how to: Active Directory With nss_ldap And pam_ldap On FreeBSD. That was almost a year and half ago and things have changed a bit since then. One of the reasons that I’d recommended using LDAP at the time was because Winbind (part of Samba) was troublesome (at least on FreeBSD) and that there wasn’t an easy way to provide a consistent UID to SID mapping across systems. Since then Winbind seems to be quite stable on FreeBSD and with the idmap_rid option you can easily keep the UID to SID mapping consistent across multiple systems. With the release of FreeBSD 6.0 this month I’m ready to update the steps needed to make FreeBSD use Active Directory (AD) users and groups, this time via Samba (Winbind) instead of LDAP.
I wrote these steps using FreeBSD 6.0 and Samba 3.0.20b (from the ports collection). The Active Directory system is running Windows 2003, thought I don’t think that will make a difference, AD on Windows 2000 should also work just fine. All host names use the domain example.com, so be sure to change them to reflect your network setup.
- Step 0: Your Windows AD server and your FreeBSD system should all be running normally, if not stop now and go fix them up first.
- Install Samba: We will be installing Samba 3.0.20b from /usr/ports/net/samba3. Add the following lines to your /etc/make.conf before installing the port:
This assumes that you aren’t interested in using CUPS for printing on this system. We also aren’t going to be using Kerberos for this, hence the
WITHOUT_ADS=yesline. The option to enable syslog is optional, I tend to prefer it. We must have Winbind and the experimental modules enables the use of imap_rid, which we also need. Although we will be using the Winbind PAM module, I like having the option using smbpass also. ACL support is not required, but I recommend including it.
make installfrom /usr/ports/net/samba3 and only enable the following options: WINBIND, ACL_SUPPORT, SYSLOG, UTMP, PAM_SMBPASS, EXP_MODULES, POPT. This might take a little while to build, in the mean time add the following lines to your /etc/rc.conf file:
This will enable the three major components of Samba on your FreeBSD system.
- SMB.CONF: The configuration file for Samba is /usr/local/etc/smb.conf. Here’s a basic one to make this work:
workgroup = EXAMPLE
server string = Samba Server
security = DOMAIN
allow trusted domains = No
log file = /var/log/samba/log.%m
max log size = 50
dns proxy = No
wins server = domainserver.example.com
ldap ssl = no
idmap backend = idmap_rid:EXAMPLE=10000-20000
idmap uid = 10000-20000
idmap gid = 10000-20000
template shell = /bin/tcsh
winbind use default domain = Yes
Most of this should be pretty straight forward, if you aren’t sure what an option means the Samba documentation does a good job of covering them. Change the workgroup to the name of the Windows domain and the wins server to the name of your wins server. Change the EXAMPLE domain in idmap backend to the name of your Windows domain. To make sure that I didn’t run into any UID conflicts I have Winbind use 10,000 through 20,000. This can be changed to meet your systems needs, if you aren’t sure then leave them unchanged, they should be a safe bet. Same goes for the template shell option.
- Join The Domain: The process for joining a domain in Samba has changed a bit over the years, mostly due to the new net program. The process is still simple though, run:
/usr/local/bin/net rpc join -S windomainserver.example.com -U administrator
Replace windomainserver.example.com with the name of one of your Windows domain controllers. You’ll be prompted for the administrator password. This should just work. If it doesn’t make sure that your FreeBSD system can resolve the IP address of your domain controller and try again.
- Start Samba and Winbind: At this point you can startup Samba and Winbind on your system with:
- Name Switch Service: To instruct FreeBSD to make use of Active Directory (via Winbind) as a source of user and group information we’ll need to make changed to the /etc/nsswitch.conf file:
group: files winbind
hosts: files dns
passwd: files winbind
In case it isn’t obvious, the two lines that need to be changed in the stock /etc/nsswitch.conf is group and passwd.
- Home Directories: You may or may not need to have support for user home directories on your FreeBSD system, depending on what services you want to make available. In my case I want users to be able to ssh into the system, so they’ll need home directories. Rather than running adduser for every AD user we’ll use the mkhomedir PAM library to take care of this automatically. Run
make installin /usr/ports/security/pam_mkhomedir to install it.
- Pluggable Authentication Modules: In other to authenticate users you’ll have to modify the corresponding PAM configuration file for that service. Sticking with the ssh example, we’ll be editing /etc/pam.d/sshd. In the auth section add the following as the second line:
auth sufficient /usr/local/lib/pam_winbind.so
That will instruct sshd to attempt user authentication via Winbind. In order to create home directories for users on demand add the following line to the session section of /etc/pam.d/sshd:
session required /usr/local/lib/pam_mkhomedir.so
The first time that an AD user attempts to login their home directory will be created. Be sure to make these changes for each service that your system will be making available (IMAP, POP3, FTP, etc).
- Optional Reboot: Although not required for everything to work, I’d recommend a reboot. This will give all of the FreeBSD subsystems a chance to become aware of the Name Switch Service and PAM changes. Let me repeat, you do not need to reboot in order for ssh and friends to work after following these steps.
That’s it. At this point you should have FreeBSD system that uses Active Directory users and groups and can authenticate those users via ssh. I prefer this method over the previous one that used LDAP. There are less components to install and configure and you don’t have to make any changes to your Active Directory layout. In my case this was a completely drop in solution, only requiring the ability to add a computer to the Windows domain.
If you have any thoughts or pointers on how to refine this process please leave a comment or send me a note via my contact form.