Archive

I've now read several posts discussing the security of Alpine Linux versus other Linux distributions, with a lot of the arguments boiling down to whether it's better to have a less-used but smaller footprint (Alpine) or a very widely-used but larger footprint (e.g. Debian) distribution, such as that discussed here. Personally, I don't buy that there's no security advantage in having a smaller libc (musl) - it's well-documented, after all, that larger code bases lead to more bugs, although that's at least partially balanced out by the sheer number of users that are on glibc. The small footprint has definitely been attractive to me up until now, but the difficulty of trying to get software on it has definitely made things more frustrating. Things came to a head when I was looking at better domain integration after finding that I was having some more difficulty generating a keytab on Windows Server systems, at which point I figured I could do better (something I was unable to get working on Alpine Linux).

As such, I've decided to shift over to Debian, after finding that it gets me an okay footprint (1.5 GB with swap and a bit of usable free space), although it's (not surprisingly) still larger than Alpine Linux (1 GB with swap and some usable free space). But, it's considerably smaller than what CentOS or Ubuntu can offer, particularly if only picking the "SSH server" but not the "standard system utilities" and disabling recommend packages after installation:

I initially had a bunch of text cribbed from here about setting up libpam-krb5 for authentication/authorization, and it actually works reasonably well, although involves a number of a steps, a few of them more fiddly than I'd like. And it turns out that realmd does all this in a simpler way (at a cost of 100MB over the libpam-krb5 option). As a result, domain integration is a matter of installing a laundry list of packages:

In order to tweak a few settings, create a simple configuration file:

And then add the system to the domain:

Enable GSSAPI authentication for SSH:

And restart sshd:

We want to ensure that users have home directories on login, so tweak the PAM config, enabling "Create home directory on login":

But, the default permissions for creating a home directory are awful (umask 0022), so tweak the result to be more sane:

And finally, to limit the users who should have login access:

As a final note, ESXi integration is still available via open-vm-tools.

After putting in a fair amount of effort in order to move from Windows Server to Samba and from Exchange to Kopano, I've decided to roll all that back (kind of). Why, you might ask? Ultimately, it ends up with the mail server:

• For redundancy, especially since I'm not being paid to be a full-time system administrator. It's much harder to guarantee uptime when I'm not monitoring my systems constantly, so if I want a reliable mail server, I would need to set up something like a secondary MX... which, quite frankly, is a PITA, especially once you factor in needing another domain controller to feed information to the mail server, along with whatever that Kopano would want. Doing it properly? Not so simple.
• Kopano hasn't been as straightforward as I was expecting. I've already mentioned the ActiveSync issue, but Z-Push has also been remarkably flaky as well.

So I'm actually switching over to Microsoft 365 (formerly known as Office 365) Business, which addresses these issues (although, as with everything, comes with others).

Windows Server

Setting up a newer Windows Server with a new domain generally means setting up a domain controller with Server Core, which is a different beast than setting up a minimal interface installation. Fortunately, there are pages out there that explain the PowerShell commands needed to get everything up and running once the initial installation is complete:

After this is a matter of installing the certificate authority root certificate (assuming that you're not using Windows Server as your CA). This is handled via certutil -dsPublish (after you copy the root certificate to your server). Installing a matching server certificate with private key via certutil -importPFX, then restarting the server lets the LDAP service start the LDAPS variant (there isn't an explicit service that can be restarted to start up LDAPS).

Azure AD Connect

... Oh my god, dealing with this piece of software was horrible. Poorly documented, "security" fighting me the whole time, bugs all over the place... suffice it to say that it wasn't a pleasant experience.

• This is documented, but it needs to run on Server GUI and not Server Core for... Reasons.
• The documentation blithely assumes that you've already turned IE Enhanced Security off... which isn't the default.
• Reconfiguring Azure AD Connect often requires uninstall and reinstalling it.
• After several attempts, I found that that the Express mode was unable to detect my domain and would just fail mysteriously instead.
• Once I did get it installed, I found that it installed Azure AD Connect Health Sync. And would, under certain circumstances, fail that installation, but wouldn't be clear anyways that it was an optional part of the installation (especially since you need to pay for a higher level of Azure AD before that functionality even works).
• And, of course, if you don't have Azure AD Connect Health Sync working, if the sync ever gets into a weird state, it'll never tell you. Fun.

I did try to see whether it would be possible to run Azure AD Connect against Samba. My conclusion is that it was possible at some point in time, but with the current version of Azure AD Connect, it's not (it runs some queries that the current version of Samba doesn't support).

Microsoft 365

All in all, so far, the experience hasn't been all too bad, even though there is some functionality that iOS has never supported (and likely never will): shared mailboxes. Instead, I'm using the workaround of paying for another account and logging in with that account as well. On the bright side, I suppose, it gives me additional OneDrive space for backups. On top of that:

• It's possible to set up e-mail sub-addressing on Office 365 with a bit of work, with one major benefit over services like Gmail or consumer Outlook: the ability to use a symbol other than + for subaddressing, which is great since there are lots of services out there which don't handle + very well.
• It takes quite a bit of wrangling, but it's also possible to send e-mail using aliases on the same domain while treating everything as a single mailbox.

One of the useful things about having a directory service is the ability to authenticate users effectively, with the standard for this with networked computers being RADIUS. This can then be used by services like VPNs and wireless 802.1X. So how to set one up?

Joining the domain

First off, start off with a standard system. Then, install the packages we'll need for authenticating versus an Active Directory domain:

In order to hook up RADIUS to Active Directory, the system must be added to the domain. Similar to what a domain controller needs, the Kerberos configuration file must be set up:

Then, Samba must be set up:

Followed by the domain join command:

Then, since we need winbind, enable it in the daemon:

At this point, you can then start Samba:

To check that Samba is working correctly, you can run a quick command to verify that the system is communicating with the domain correctly:

FreeRADIUS

We need to install the FreeRADIUS packages first:

Since Alpine Linux doesn't have a lot of the more advanced protections other Linux distributions have, changing group permissions so that FreeRADIUS can access winbind's files is sufficient:

Next up, follow the standard FreeRADIUS documentation to add a client for authentication. Then is server identification. First off is generating the Diffie-Helman files:

To go with this file, we need an SSL server certificate for the RADIUS server to identify itself. The certificate and private key should be combined as /etc/raddb/certs/server.pem, and the CA root certificate as /etc/raddb/certs/ca.pem.

After this, the Active Directory integration. Edit the two files in /etc/raddb/sites-enabled (default and inner-tunnel), and replace every instance of -eap with eap (removing the hyphen). In addition, remove the additional hyphen in this section of the configuration:

The EAP and MSCHAP modules then need to be adjusted:

You can then enable FreeRADIUS:

And test it (although you should use a test account, or make sure to remove these lines from your shell history), being aware that your results may vary slightly:

If you need to debug FreeRADIUS, it often makes more sense just to run it from the command line after shutting down the daemon:

Samba

If you hadn't followed this blog post for setting up your Active Directory domain and you're running Samba, you might need to follow the hint on this page and add this section to your smb.conf on your directory controllers: