Connecting to libvirtd as non-root user on openSUSE 13.1

As a revisit to my previous post on connecting to libvirtd as a non-root user on openSUSE 12.2, the way to do it on openSUSE 13.1 is the same that worked for Marek Goldmann on Fedora 18 (although he used the wheel group).

Create /etc/polkit-1/rules.d/80-libvirt-manage.rules with the following content:

polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("libvirt")) {
            return polkit.Result.YES;
    }
});

And add the user accounts that should be allowed access to the libvirt group.

Patching VirtualBox guest additions for SLES12/RHEL7 guests

This may not be relevant to most of you, yet, as the SLES12 and RHEL7 beta programs are not quite open to the public, but similar problems may happen to you with other distributions that do backports of patches as well.

If you see error messages such as the following when compiling VirtualBox guest additions for your Linux guest:

/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeMapUser’:
/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:1542:26: error: ‘struct mm_struct’ has no member named ‘numa_next_reset’
                 pTask->mm->numa_next_reset = jiffies + 0x7fffffffffffffffUL;
                          ^
make[2]: *** [/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o] Error 1
make[1]: *** [_module_/tmp/vbox.0] Error 2
make: *** [vboxguest] Error 2

You should take a look at VirtualBox ticket #12638 which deals with the removal of the numa_balancing_scan_period_reset sysctl and related data structures. I just submitted a patch there that tries to address the issue of distro vendor backports of patches in a less expensive way than grepping header files.

If you want to try it out, also have a look at How to recreate / build VirtualBox guest additions ISO image VBoxGuestAdditions.iso.

How to recreate / build VirtualBox guest additions ISO image VBoxGuestAdditions.iso

As Linux kernel development progresses, so do interfaces change from time to time and kernel modules outside of the Linux kernel such as VirtualBox’s guest additions need more or less updating. Having done some patching in the VirtualBox sources, you might want to rebuild the guest additions ISO image, VBoxGuestAdditions.iso, so you can try out the patched code in your VMs more easily.

Googling for “building VBoxGuestAdditions.iso” you might find this vbox-dev mailing list thread from 2011 which suggests that the ISO could not be easily rebuilt as a special build setup would be needed. However, it turns out this is not quite true:


pief@e6400:~/vbox/src/VBox/Additions> kmk additions-iso
kBuild: copydbg /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxControl - /home/pief/vbox/out/linux.amd64/release/obj/Additions/Installer/linux/debug/bin/VBoxControl
[...]
kBuild: Installing /home/pief/vbox/out/linux.amd64/release/obj/Additions/Installer/linux/lib/VBoxGuestAdditions/mount.vboxsf
kBuild: Packing /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxGuestAdditions-amd64.tar.bz2
Header is 404 lines long

About to compress 5440 KB of data...
Adding files to archive named "/home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxLinuxAdditions.run"...
./
./install.sh
./VBoxGuestAdditions-amd64.tar.bz2
./do_dkms
./vboxadd
./vboxadd-x11
./deffiles
./routines.sh
./vboxadd-service
CRC: 1167516186
MD5: eb794c6b2981e2042a81f475f060be18

Self-extractible archive "/home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxLinuxAdditions.run" successfully created.
kBuild: mkisofs - /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso
/usr/bin/genisoimage -rational-rock -joliet -iso-level 3 \
-volid "VBOXADDITIONS_4.3.53_50574" -l -graft-points -o /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso \
[...]
VBoxLinuxAdditions-amd64.run=/home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxLinuxAdditions.run \
[...]

I: -input-charset not specified, using utf-8 (detected in locale settings)
Total translation table size: 0
Total rockridge attributes bytes: 269
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
2906 extents written (5 MB)
kBuild: Zipping image /home/pief/vbox/out/linux.amd64/release/bin/additions/VBoxGuestAdditions.zip
adding: VBoxGuestAdditions.iso (deflated 8%)
pief@e6400:~/vbox/src/VBox/Additions> dir

In my case, I found the new ISO image in ~/vbox/src/out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso. Copying that file to /usr/share/virtualbox should make it available to your VMs.

Flashing the D-Link DBT-120 to become a HID proxy-capable USB bluetooth adapter

As pointed out in my previous post, I was looking into flashing the D-Link DBT-120 USB bluetooth adapter with Apple’s Bluetooth Firmware update so it becomes HID proxy-capable.

D-Link DBT-120 USB bluetooth adapter

D-Link DBT-120 USB bluetooth adapter

Now I do not have any machine running MacOS X, so I could not simply download and run Apple’s tool and was therefore looking into alternatives, aiming at extracting the firmware from Apple’s download somehow and using other means to flash the firmware. And obviously I wasn’t the only one.

Extracting the firmware

After downloading from Apple you’ll have a file BluetoothFWUpdate1.2.dmg. .dmg files are basically Apple Disk images, representing so-called volumes. In the simplest case running Linux’s file utility on such a .dmg would give you an output such as:


$ file example.dmg
example.dmg: Macintosh HFS Extended version 4 data last mounted by: ’10.0′, created: Fri Jan 30 11:12:33 2009, last modified: Fri Jan 23 12:09:55 2009, last checked: Fri Feb 07 04:22:58 2009, block size: 4096, number of blocks: 6400, free blocks: 218

In such a case you would be able to mount it with a command such as modprobe hfsplus; mount -t hfsplus -o loop example.dmg /mnt.

In our case, however, things are a bit more complicated:


$ file BluetoothFWUpdate1.2.dmg
BluetoothFWUpdate1.2.dmg: VAX COFF executable

file gets a bit confused here: in reality this is a compressed .dmg file that requires a conversion with the dmg2img utility. Download it, make sure you have zlib and bzip2 development headers installed and run make to compile it. Then, run it like this:


$ dmg2img-1.6.5/dmg2img BluetoothFWUpdate1.2.dmg
dmg2img v1.6.5 (c) vu1tur (to@vu1tur.eu.org)

BluetoothFWUpdate1.2.dmg --> BluetoothFWUpdate1.2.img

decompressing:
opening partition 0 ... 100.00% ok
opening partition 1 ... 100.00% ok
opening partition 2 ... 100.00% ok
opening partition 3 ... 100.00% ok
opening partition 4 ... 100.00% ok

Archive successfully decompressed as BluetoothFWUpdate1.2.img

Now we have a 1:1 image of a HFS+ filesystem (the filesystem Apple uses) and can mount it:


$ sudo mount -t hfsplus -o loop BluetoothFWUpdate1.2.img /mnt

If we now examine the mounted image’s contents, we’ll find a lot of MacOS X packaging-related files and a file Archive.pax.gz that we care about:


$ cp /mnt/BluetoothFirmwareUpdate1.2.pkg/Contents/Archive.pax.gz .
$ umount /mnt

This file is obviously gzip-compressed, so let’s uncompress and examine it:


$ gunzip Archive.pax.gz
$ file Archive.pax
Archive.pax: ASCII cpio archive (pre-SVR4 or odc)

cpio archives are something we know a bit about in the Unix world, so let’s create a subdirectory to extract its contents:


$ mkdir unpack
$ cd unpack
$ cpio -if < ../Archive.pax
5390 blocks

We'll now again have a quite verbose, MacOS-typical directory structure. Dive deeper and you'll find what we're looking for:


$ cd Applications/Utilities/Bluetooth\ Firmware\ Updater.app/Contents/Resources/
$ ls
total 2324
drwxrwxr-x 17 pief users 4096 Feb 21 21:12 .
drwxrwxr-x 4 pief users 4096 Feb 21 21:12 ..
-rwxrwxr-x 1 pief users 638672 Feb 21 21:12 DeskTop.dfu
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Dutch.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 English.lproj
-rw-rw-r-- 1 pief users 34690 Feb 21 21:12 FirmwareDownload.icns
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 French.lproj
-rwxrwxr-x 1 pief users 994866 Feb 21 21:12 GenericCSR.dfu
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 German.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Italian.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Japanese.lproj
-rwxrwxr-x 1 pief users 638672 Feb 21 21:12 Portable.dfu
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 Spanish.lproj
drwxrwxr-x 3 pief users 4096 Feb 21 21:12 da.lproj
[...]

Those .dfu files are what we were looking for, because of their file sizes and, in the case of GenericCSR.dfu, also because of its file name. Remember, we’re going to flash a CSR-based device.

Now it looks like we have three files to choose from: DeskTop.dfu, GenericCSR.dfu and Portable.dfu. “Generic” does suggest to be a good choice as “DeskTop” and “Portable” sound like firmware update files for special cases, but we wouldn’t take a bet on that. Running strings on each of them does not shed light into the darkness, however. But worry not, we’ll see more in a minute once we feed the files to the flash utility.

Flashing the firmware

In general there are two ways to backup and update the firmware of CSR-based USB bluetooth adapters:

  1. under Linux with the BlueZ project‘s dfutool.
  2. under Windows with a software suite from CSR themselves called “BlueSuite”.

I played around with Linux at first, examining the D-Link DBT-120’s properties before the flash upgrade with commands such as lsusb, hciconfig hci0 version and hciconfig hci0 revision. bccmd chiprev and bccmd buildname gave me an error message about an “Unsupported manufacturer”. But, more importantly, dfutool worked and I could get a backup of the existing firmware with dfutool archive dlink-dbt120.dfu.

However, I still wasn’t sure which of the three Apple .dfu files to flash. So I looked around on the Internet for CSR’s BlueSuite software for Windows. I checked their Website and found the CSR Developer Zone. To my surprise, they would let me get myself registered without any barriers, payments or anything. I ignored the warning about the “unknown mail domain” that would cause me “not to have full access” for the moment and was pleasantly surprised to find a BlueSuite 2.5.8 download (plus a user guide) on the “Last updated” page. Nice work, CSR, that’s how things should be! :)

BlueSuite is a collection of different development-related tools, some graphical, some command line-based:

CSR BlueSuite components

CSR BlueSuite components

It also comes with a special driver for accessing the Bluetooth adapter. Prior to installing that driver, if you look at Windows’ device manager and use Microsoft’s built-in Bluetooth stack (ie. not Widcomm, BlueSoleil, CSR Harmony etc.) you should see a “Generic Bluetooth Radio” device in the “Blutooth” category (screenshots from a German Windows version):

"Generic Bluetooth Radio" entry in Windows' Device manager

“Generic Bluetooth Radio” entry in Windows’ Device manager

You should also have a blue Bluetooth icon in the task bar’s notification area.

After installing the BlueSuite’s driver by running drivers\win64\DPInst.exe the Bluetooth icon will disappear and Windows’ device manager will now list an entry “CSR BlueCore Bluetooth” in the “USB controllers” category:

"CSR BlueCore Bluetooth" entry in Windows' device manager

“CSR BlueCore Bluetooth” entry in Windows’ device manager

This is a prerequisite in order to be able to use the BlueSuite utilities including our flashing tool DFUWizard.exe:

DFUWizard's Welcome screen

DFUWizard’s Welcome screen

Choose “USB” as connection method and select one of the three .dfu files we extracted earlier. You’ll notice that DFUWizard shows human-readable descriptions that are more useful than dfutool‘s:

DFUWizard with the DFU file tp flash selected

DFUWizard with the DFU file tp flash selected

GenericCSR.dfu looks to be the right candidate. So we’ll use it for flashing.

WARNING1: Flashing can render your device unusable, eg. if power outages occur or the wrong file is flashed. Do not perform the flashing process unless you know what you’re doing! I can not help you if something goes wrong!

WARNING2: Flashing Apple’s firmware will render your DBT-120 unless you’ve taken care of obtaining hid2hci.exe! Do not ask me for this tool.

DFUWizard flashing the DBT-120 adapter

DFUWizard flashing the DBT-120 adapter

This process should take just a minute and if things go right you should get a result such as this:

DFUWizard after a successful flashing process

DFUWizard after a successful flashing process

Congratulations, you now have a DBT-120 adapter that behaves as a HID proxy. You should now try running hid2hci.exe and pair your input devices again. After a reboot, they should work in the BIOS as well. Remember that returning to Windows you will need to run hid2hci.exe again to get them working. A followup post will deal with automation of this.

The crux of finding a HID proxy-capable USB bluetooth adapter

So, for some not very profound reasons (watching demos and putting my spare Ivy Bridge CPU to a use), I ended up having a living room PC again. And as it’s the living room, input devices must be wireless. Since I’m not a fan of running proprietary wireless technologies that jam my Wifi’s 2.4 GHz band and because of increased usability with other devices such as tablets, I wanted a keyboard and a mouse based on Bluetooth technology. Because of design, functionality and good experiences I bought Microsoft’s Wedge mobile keyboard and Sculpt Touch mouse:

Microsoft Wedge Mobile Keyboard (with German layout)

Microsoft Wedge Mobile Keyboard (with German layout)

Microsoft Sculpt Touch Mouse

Microsoft Sculpt Touch Mouse

All nice and sleek and working within an installed OS but it is only when you’re trying to reinstall your operating system or need to enter your BIOS that bluetooth-based input devices still have a large drawback: they do not work without a Bluetooth driver stack. And during both OS installation and BIOS configuration you do not have one yet. Even the modern UEFI world doesn’t change that.

At least in the PC world — Apple has been using Bluetooth-based input devices for over a decade now and admittedly often went a step forward for the sake of user experience. When the Apple Wireless keyboard was introduced in September 2003, a software update was published that allowed for the wireless keyboard to take control of the boot process.

However, this was strictly speaking not Apple’s merit alone: the software update worked with Cambridge Silicon Radio (CSR)-based adapters only because that very company introduced a technique called HID proxy for its adapters in August 2003 (see their press release “CSR saves stranded mice”).

The idea behind HID proxy is that the bluetooth adapter has additional intelligence that allows it to a.) take over responsibility from the host it’s connected to run and run certain software layers itself and b.) run in this special mode until the OS’s bluetooth stack is loaded and tells it to return to “normal” operation. In HID proxy mode, the adapter communicates on its own with previously paired Bluetooth input devices and emulates to its host a USB keyboard and USB mouse through a HID interface instead of exposing the ordinary HCI interface. As the PC industry has at least succeeded in getting broad USB support into BIOS and OS installation software, this means that the Bluetooth keyboard and mouse will magically work in spite of a missing Bluetooth stack.

You see, Apple did not magically invent an Apple-only, HID proxy-capable bluetooth adapter. In fact, in 2003 the internal Bluetooth modules in their Notebooks were software-compatible with certain revisions of the D-Link USB bluetooth adapter DBT-120. They also didn’t ground-breakingly integrate Bluetooth functionality into their EFI firmware. They just made their Bluetooth hardware default to HID proxy mode until Mac OS X tells it to switch to HCI mode, that’s the whole secret.

D-Link DBT-120 USB bluetooth adapter

D-Link DBT-120 USB bluetooth adapter

However, this means that if you use such a Bluetooth adapter in HID proxy mode, the OS must be aware of it and tell it to switch to HCI mode or you will have no Bluetooth functionality once it’s loaded. And to my knowledge no Windows Bluetooth stack does, not even Microsoft’s own stack in the latest Windows 8.1.

For this very reason, Apple, on its Bluetooth Firmware Update 1.2 Download page, warned that applying that update “[…] to a D-Link USB to Bluetooth adapter will make it incompatible with non-Macintosh systems”. Which, back then, yet seems to have been overseen by a number of users, considering this FAQ page by German computer magazine c’t. Yet, this does not mean a DBT-120 flashed with the Apple update is bricked, as Edd Dumbill pointed out among others.

The other problem is: the DBT-120 is an old Bluetooth 1.1 device that’s not produced anymore and by 2014 it is next to impossible to find a HID proxy-capable USB bluetooth adapter on the market. This tonymacx86.com forum post lists four, one of them being the Apple built-in BT module (which apparantly can be modded to be hooked up to an USB port) and one being the mentioned DBT-120 from 2003. The Belkin F8T016NG mentioned seems to be still available at Amazon UK and Amazon Germany despite being listed as being “made anymore”, whereas the fourth adapter, the Belkin F8T016CW, does not seem to be available in Germany at all.

From a hardware perspective, there is no reason for this situation. As this leaked CSR presentation on their BlueCore firmware points out, having HID proxy support is merely a question of enabling it in firmware builds. It doesn’t seem to be a question of firmware size either if only integrating RFCOMM support (which nobody seems to need) requires an 8 MBit flash chip and even the DBT-120 back then could be flashed to support both HID proxy and HCI.

The real reason is the lack of software support instead: as mentioned above, even with CSR-specific drivers Windows bluetooth stacks treat the adapter as an USB HID device and do not know that it can be told to reveal its real nature in form of the HCI interface.

CSR saw that problem and provided a sample Windows command-line application, hid2hci.exe, that does exactly the job (do not confuse it with the Linux executable hid2hci from the BlueZ project). It is a small executable of 44KB size and without any external dependencies. You can optionally tell it the USB vendor ID and product ID of the bluetooth adapter to be addressed, defaulting to a vendor ID of 0x0a12, which is CSR’s ID, and a product ID of 0x1000, which is the product ID a CSR USB bluetooth adapter uses when in HID proxy mode. After running this executable, the adapter will reappear on the USB bus with a different product ID and a HID interface, causing the normal Bluetooth driver stack to take over control. This change is not permanent, so the executable needs to be run after each OS boot and after each plugging out and in the USB bus, but, as a followup post will show, that can be nicely automated.

So to summarize, what it takes to get your Bluetooth input devices working in the BIOS as well is:

  1. a USB bluetooth adapter defaulting to HID proxy mode
  2. the hid2hci.exe tool
  3. some automation magic

As for the first problem, no matter what CSR-based bluetooth adapter you own, you’d need a HID proxy-enabled firmware. The way it looks like Apple’s update is the only one freely available on the Internet, but it’s for the old D-Link DBT-120 only. Maybe you can find one on eBay. As chance would have it, I still had one flying around and tried the update without having a Mac. This followup post has more on this topic.

As for the second problem, I do not know if and in what context CSR distributes hid2hci.exe if at all. This blog post by Stephan Joseph used to have an archive btinstall.zip with it that was even referenced inside a book called “Take control of Windows running on a Mac” but you’ll have to look for yourself. Do not ask me to provide you with a copy.

As for the third problem, look out for a second followup post — I’ve done some cool PowerShell scripting ;)

Integrating Samba’s DNS server with existing dnsmasq installations

As an Active Directory encompasses not only LDAP and Kerberos but also DNS and there are funny things Microsoft does with DNS (dynamic updates, special SRV records to locate hosts etc.), running Samba as an Active Directory domain controller means running either the built-in DNS server or bind9 with a special DLZ plugin.

dnsmasq integration has been discussed but seems to have been abandoned not so much for technical reasons than rather for lack of real interest on both sides. There is at least this HOWTO that works around the technical issues by teaching dnsmasq the necessary SRV records manually, but even then you won’t have dynamic DNS updates the way Samba needs them and it is more of a hack definitely unsupported by the Samba team than a viable solution.

Running dnsmasq is feasible not so much as an alternative running on the Samba host itself, but, at least in my idea of SOHO networking, it’s pre-destined for embedded devices such as access points and routers and accordingly the default DNS forwarder in OpenWrt. Having DNS resolution depend on a “higher-level” DNS service provided by Samba would contradict that concept. Apart from the fact that Samba’s DNS server would require support for every single feature existing DNS servers (such as dnsmasq) already have — or bind be used, a software I do not really miss particularly much (think zone files).

Obviously I can’t achieve the desired isolation of a basic network service such as DNS and a productive service such as Samba with a single DNS zone, as there is no such thing as zone sharing. So I’ll need two DNS zones: mysite.foo.bar and either ad.mysite.foo.bar or mysite.ad.foo.bar. The latter choice would be preferable if we were to seriously use Active Directory features such as forests and sites but also mean that there would be a “parallel forest” of “conventional” DNS zones and the need to have a foo.bar DNS server that supports delegations. As Samba 4 currently supports running a single Active Directory domain controller only anyway, I’ll go with the former:

DNS zone Managed by Running on
mysite.foo.bar dnsmasq OpenWrt-based access point/router
ad.mysite.foo.bar Samba “Real” server

Now I do, of course, have only one DHCP service at my “site”. Technically it could supply multiple DNS servers but you wouldn’t want that since you can’t control your clients’ resolvers’ behavior via DHCP (ie. when which DNS server is tried). And there’s no need to, because here comes the elegant part: all clients continue to receive the IP address of an OpenWrt device as DNS server which is authoritative for mysite.foo.bar. Requests for *.ad.foo.bar simply get delegated to the Samba host with a dnsmasq configuration such as the following:


# Local dnsmasq instance is responsible for
# mysite.foo.bar
domain=mysite.foo.bar
server=/mysite.foo.bar/

# DNS delegation for ad.mysite.foo.bar
server=/ad.mysite.foo.bar/192.168.0.1

# If rebind protection is on, this is
# required to avoid warnings on DNS
# rebinding attacks
rebind-domain-ok=ad.mysite.foo.bar

# Upstream DNS server, handles everything
# outside ad.mysite.foo.bar and mysite.foo.bar
server=192.168.0.254

Note that having two DNS zones does not imply that you need to have two IP subnets. It’s perfectly fine to have both baz.mysite.foo.bar and baz.ad.mysite.foo.bar point at 192.168.0.1 and have reverse lookup of the IP address resolve to baz.mysite.foo.bar, as long as you configure Kerberos client configuration accordingly (the rdns = false option described at the end of my sssd-ad configuration post).

This way, if the Samba server goes down, only the ad.mysite.foo.bar zone will be affected, not mysite.foo.bar as a whole. Neat :)

My SOHO network layer model

In my eyes, it makes sense to divide the elements that are part of a SOHO (small office/home office) network into one of two layers:

Basic network and productive services

Basic network and productive services

In this model, if I were to speak about “the network” I’d mean what I call the basic network: all components that in their togetherness constitute an independent, foundational layer cornered around connectivity and, by comparison, low complexity (ie. no full-blown operating system on each device). This includes the physical LAN cabling (if present), network switches, print servers (usually integrated into the printers), WLAN access points and routers.

Because nowadays it is often essential for system administrators to have Internet access, be it for googling on problems that pop up or for bootstrapping installations that download software directly from the ‘Net (eg. in disaster recovery scenarios when no local mirror is present any more), I consider DNS and DHCP services to be essential enough to be part of the basic network as well.

With the advent of flash-based embedded devices such as WLAN access points and routers, the availability of OpenWrt as a standardized Linux distribution for these and the low resource consumption of DNS/DHCP, migration of these services from hard disk-based servers onto access points/routers became feasible. After all, an access point running on flash memory is much less likely to fail than a full-blown server with hard disks as storage. The only part I’ve seen failing over years with these devices is the $0.05 power supply.

The basic network is foundational in two ways: for one thing, it is independent, ie. can stand on its own. And the productive services layer, that encompasses more value-creating (to the end user) services such as File, Print and E-Mail services, is stacked upon it. No basic network, no productive services. And at the same time: no productive services, no real value in the basic network.

Formulating such a model helps in making up your own mind and communicating with others, eg. about the question where a service such as NTP should be placed. What do you think?

Configuring sssd’s Active Directory provider

Following up on the previous post, here’s how we get sssd to actually provide access to our Samba-driven Active Directory.

I started with the instructions in the Samba wiki but these actually go beyond the minimum that is necessary. Let me also add some context to the individual components and settings involved.

How sssd’s components work together

sssd is quite modular: if you read the sssd.conf man page, you’ll learn about services and domains. You will also learn about different providers such as the already mentioned Active Directory provider that we are going to use. Do not be fooled however: providers are not mutually-exclusive. For example, our Active Directory provider works together with the LDAP and the Kerberos providers as shown here:

Individual sssd components working together

Individual sssd components working together

As a consequence, we’ll have to consider not only sssd-ad configuration directives but also some of those of sssd-ldap and sssd-krb5. And, because sssd-krb5 uses the Kerberos library we’ll also have to consider /etc/krb5.conf.

Configuration explained

Without further ado, here’s an example for a minimal /etc/sssd.conf that takes advantage of autodiscovery:


[sssd]
config_file_version=2
services=nss, pam
domains=ad.mydomain.foo.bar

[domain/ad.mydomain.foo.bar]
id_provider=ad
access_provider=ad
dyndns_update=false
enumerate=true
ldap_id_mapping=true
krb5_realm=AD.MYDOMAIN.FOO.BAR
krb5_keytab=/etc/sssd/ad.mydomain.foo.bar.keytab

Setting id_provider and access_provider activates sssd-ad as identity provider (ie. the source for user and group information) and access provider (eg. checks if a user is allowed access). However it also activates it as authentication provider (ie. checks passwords) and chpass provider (ie. changes passwords), because id_provider‘s value is a default for auth_provider, which in turn is the default for chpass_provider.

We do not specify ad_domain because the default is to use the configuration section’s name (minus the “domain/” part, of course). We do not specify ad_server either because Samba’s DNS server has automagically set up SRV records for us that sssd-ad/ can use for service discovery.

I disabled dyndns_update for now because it gave me problems. Setting enumerate to true is debatable and recommended for small setups only, but you might want it for playing around with nested groups and see how they work. The default is false.

There’s no need to specify any of ldap_uri, ldap_search_base, ldap_sasl_mech or ldap_sasl_authid, ldap_user_* and ldap_group_*sssd-ad will have taken care of these parameters for you.

ldap_id_mapping is set to true so that sssd itself takes care of mapping Windows SIDs to Unix UIDs. Otherwise the Active Directory must be able to provide POSIX extensions. If yours does, you can omit this option, of course.

It is obligatory to specify krb5_realm, which, by convention, is always upper-case and in most cases will the DNS name of the Active directory. krb5_keytab specifies the keytab file sssd will use to connected to Samba’s KDC (see also: What is a keytab file). The keytab file can be exported on the Samba server as per the Samba Wiki instructions.

Again, krb5_server, krb5_kpasswd will have already been provided by sssd-ad for you.

As you can see the net result is a much simpler configuration than with sssd-ldap and sssd-krb5 alone. Provided you’ve followed the other necessary steps, eg. PAM and NSS configuration (again, see eg. the Samba Wiki instructions), you can now try eg. getent passwd and should be able to see your Active Directory users.

Debugging hints

I had a hard time to get everything working, receiving “GSSAPI Error: Miscellaneous failure (Server not found in Kerberos database)” error messages all the time. Some hints:

  1. Start sssd manually and in debug mode with sssd -i -d 5, choosing the debug level as appropriate.
  2. One can not stress enough: get your DNS working properly. In my case, the DHCP service advertising the DNS servers to use ran on a separate machine, and of course I forgot to specify the IP address of the Samba server there…
  3. The Kerberos client library will do one thing you might not immediately be aware of: reverse DNS lookups. If, for example, you decided to use a separate DNS subdomain for Active Directory (which you definitely do want to do) but let your hostname sambahost.ad.foo.bar point at 1.2.3.4 and 1.2.3.4 in turn resolves to sambahost.foo.bar, things won’t work unless you specify rdns = false in your /etc/krb5.conf.

    By the way, the only way to really debug such issues is either to run Wireshark or to look at Samba’s logfiles — the client itself won’t even tell you it does such things (reverse lookups and their results) if you strangle it.

Update 08.02.2014: It seems that krb5_realm is not strictly necessary. The krb5_ad provider will take care of that for you:

(Sat Feb  8 23:55:13 2014) [sssd[be[ad.mydomain.foo.bar]]] [ad_set_ad_id_options] (0x0100): Option krb5_realm set to AD.MYDOMAIN.FOO.BAR

Making Samba users available locally to Linux systems

In the past, we used to integrate Samba and “native” Linux users by using a single password backend, often LDAP:

User authentication of Linux system and Samba users against LDAP

User authentication of Linux system and Samba users against LDAP

This lead to several moments of pain, from the deficiencies surrounding group membership, the NIS and the rfc2307bis schema (see eg. here and here), over the need to define scripts to execute administrative actions such as adding users, to the not really particularly intuitive LDAP server setup in newer OpenLDAP versions.

Samba has for quite some time offered an alternative solution, by allowing for two separate user databases, the Linux passwd/shadow one and its own, and providing the Linux system with access to its user database through the combination of the winbind daemon and suitable PAM and NSS modules:

User authentication of Linux system and Samba users against LDAP

User authentication of Linux system and Samba users against LDAP

However, as I pointed out before, the Samba4 version of winbind currently lacks some important functionality.

Luckily, this Samba wiki page points out two alternatives (don’t be fooled by this wiki page, which currently only one):

Note that nslcd/pam_ldap/nss_ldap is not PADL’s now-considered dead pam_ldap / nss_ldap but a fork/rewrite. Even this one, however, draws controversy.

Yet, I found it hard to make a decision in the light of rather opinionated information on the Web and rather sparse information on the Samba Wiki. So I tried to come up with a comparison table myself, focussing on integration with Samba 4 and Active Directory features. Note that the table comes with a level of uncertainty, feel free to send me corrections.

sssd / pam_sss / nss_sss (1.11.3) nslcd / pam_ldap / nss_ldap (0.9.2)
Supports unencrypted connections via plain LDAP? Yes Yes
Supports encrypted connections via Kerberos? Yes Yes
SASL required? No Yes
Requires explicit Kerberos ticket renewal eg. through background k5start process? No Yes
Retrieval of POSIX data (UID, GID, home directory, login shell) from a Active Directory provisioned with –rfc-2307 option Optional (if AD provider is used), Required (if pure LDAP provider is used) Required
Separate backends for user/group information and authentication Yes No (but different LDAP sources)
Host must be joined to the domain? No (but advantageous in certain scenarios) No
Supports Site-based discovery? Yes No
Supports Active Directory’s Global Catalog? Yes No
Can resolve Active Directory’s global and universal groups? Yes No
Can resolve group members from trusted domains? Yes No
Leverages Active Directory’s tokenGroups attribute? Yes (also in addition to POSIX attributes) No
Offline authentication possible? Yes Yes?
Latest release 2013 2013

The conclusion: nslcd is a choice for pure LDAP authentication, for Active Directory scenarios one should go with sssd.

Unfortunately, my $distro still shipped with sssd 1.9.5 and you really do want 1.10 or newer because of added features in its Active Directory identity provider. While is it possible to access AD via pure LDAP and with or without Kerberos, you really should use the Active Directory provider because of the reasons given above. See also Jakub Hrozek’s blog and his FreeIPA.org presentation for additional information on the new features.

So I built and packaged sssd (and Samba) myself — and it took me just a month…

Configuration of sssd for Active Directory will be continued in the next post.