So I’m on a bit of a Firefox kick today Here is another Firefox extension that is defintely worth your time: foXpose. It is kind of like Expose for Firefox tabs. It provides your with a button and a keyboard shortcut to display thumbnails of all the open tabs in Firefox. Clicking on one of the thumbnails will return you to normal browsing with corresponding tab brought to the forefront. This extension requires Firefox 1.5 or higher.

I tried this first on my PowerBook G4 1.25GHz system with Mac OS X 10.4.3. The extension works fine, but there is a noticable delay from the time that you push the foXpose button until the thumbnail view comes up. The delay is huge, perhaps 2 seconds (plus or minus a bit), but it is noticable. Clicking on a thumbnail responds quickly though. Even with the brief delay this is still a great plugin.

Just to see if the delay was specific to Mac OS X I tried this out on a Windows XP system running on a P4 1.8GHz. The results were pretty much the same as on the PowerBook. There is still a slight delay, with clicking on a thumbnail returning quickly. I’ve got a newer (read: faster) system and home that I’ll try this out and and see if I get the same results.

Thanks to Gadgetopia for pointing out foXpose.

Like many others I’ve been waiting for the release of Firefox 1.5 with some excitement. While I really, really like using Safari on Mac OS X (built in spell check is awesome), Firefox still performs much better in many cases. Not having the middle mouse click working in Firefox on Mac OS X was too painful though, so with the release of Firefox 1.5 I’m pleased that is no longer an issue.

The new automatic update process is nice to see. Having to uninstall and reinstall Firefox on each new release is rather a pain. In the Mac OS X version I don’t see an obvious way manually check for updates, which is disappointing. Hopefully the Windows version doesn’t have the same limitation.

Along with this release is a push point to www.mozilla.com. Other than the fact that the .com site belongs to the Mozilla Corporation, it isn’t completely clear what the differences are from www.mozilla.org.

Have you ever looked at a map of the United States of America and wondered what the deal was with the northern border of Minnesota? That little part there that sticks out above the rest of the state, completely out of place. Still not sure what I’m talking about? Check out it out on a slightly zoomed in Google Map of northern Minnesota. See that part there, southeast of Winnipeg, Canada? Today I finally stopped wondering and did a little research.

It turns that this little chunk of the U.S. has a name, The Northwest Angle. As you can see when looking at it closely there is a no land access to this portion of Minnesota, you can only get their via Canada or crossing the Lake of the Woods. This hasn’t stopped a small town from forming there; Angle Township, Minnesota. The population? 152 people.

So how did the U.S. end up with this odd little bit of land? The short answer: inaccurate maps. When negotiating treaties and land purchases early in U.S. history some of the maps of the day were simply wrong. They weren’t aware of some geographic features of the area and assumed certain things. They turned out to be incorrect and so we have this additional bit of land above Minnesota.

Now you know.

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.

1. 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.
2. 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:
   
WITHOUT_CUPS=yes
WITHOUT_ADS=yes
WITH_SYSLOG=yes
WITH_WINBIND=yes
WITH_EXP_MODULES=yes
WITH_PAM_SMBPASS=yes
WITH_ACL_SUPPORT=yes


   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=yes line. 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.

   Run make install from /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:
   
nmbd_enable="YES"
smbd_enable="YES"
winbindd_enable="YES"


   This will enable the three major components of Samba on your FreeBSD system.

3. SMB.CONF: The configuration file for Samba is /usr/local/etc/smb.conf. Here’s a basic one to make this work:
   
[global]
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.

4. 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.

5. Start Samba and Winbind: At this point you can startup Samba and Winbind on your system with:
   
/usr/local/etc/rc.d/samba.sh start

6. 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
group_compat: nis
hosts: files dns
networks: files
passwd: files winbind
passwd_compat: nis
shells: files


   In case it isn’t obvious, the two lines that need to be changed in the stock /etc/nsswitch.conf is group and passwd.

7. 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 install in /usr/ports/security/pam_mkhomedir to install it.
8. 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).

9. 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.