Wandering Thoughts archives

2017-09-20

Wireless is now critical (network) infrastructure

When I moved over to here a decade or so ago, we (the department) had a wireless network that was more or less glued together out of spare parts. One reason for this, beyond simply money, is that wireless networking was seen as a nice extra for us to offer to our users and thus not something we could justify spending a lot on. If we had to prioritize (and we did), wired networking was much higher up the heap than wireless. Wired networking was essential; the wireless was merely nice to have and offer.

I knew that wireless usage had grown and grown since then, of course; anyone who vaguely pays attention knows that, and the campus wireless people periodically share eye-opening statistics on how many active devices there are. You see tablets and smartphones all over (and I even have one of my own these days, giving me a direct exposure), and people certainly like using their laptops with wifi (even in odd places, although our machine room no longer has wireless access). But I hadn't really thought about the modern state of wireless until I got a Dell XPS 13 laptop recently and then the campus wireless networking infrastructure had some issues.

You see, the Dell XPS 13 has no onboard Ethernet, and it's not at all alone in that; most modern ultrabooks don't, for example. Tablets are obviously Ethernet-free, and any number of people around here use one as a major part of their working environment. People are even actively working through their phones. If the wireless network stops working, all of these people are up a creek and their work grinds to a halt. All of this has quietly turned wireless networking into relatively critical infrastructure. Fortunately our departmental wireless network is in much better shape now than it used to be, partly because we outsourced almost all of it to the university IT people who run the campus wireless network.

(We got USB Ethernet dongles for our recent laptops, but we're sysadmins with unusual needs, including plugging into random networks in order to diagnose problems. Not everyone with a modern laptop is going to bother, and not everyone who gets one is going to carry it around or remember where they put it or so on.)

This isn't a novel observation but it's something that's snuck up on me and before now has only been kind of an intellectual awareness. It wasn't really visceral until I took the XPS 13 out of the box and got to see the absence of an Ethernet port in person.

(The USB Ethernet dongle works perfectly well but it doesn't feel the same, partly because it's not a permanently attached part of the machine that is always there, the way the onboard wifi is.)

WirelessCriticalInfrastructure written at 01:22:01; Add Comment

2017-09-15

Ignoring the domain when authenticating your Dovecot users

In this recent entry, I wrote about how some of our users periodically try to authenticate to our Dovecot IMAP server with the user name '<user>@<our domain>' instead of simply '<user>', and said that we were probably going to switch our Dovecot configuration to ignore the domain name. We've now done that so here is an early experience report.

Dovecot is somewhat underdocumented, at least online and in manual pages. Your best source of information for what specific configuration settings do appears to be the various pieces of the example configuration in the source code, which have comments. Quite possibly your OS's packaging of Dovecot reuses these as the standard configuration files, so you can just read the documentation comments there. The comments in the authentication configuration file explains things this way:

# Username formatting before it's looked up from
# databases. You can use the standard variables here,
# eg. %Lu would lowercase the username, %n would drop away
# the domain if it was given, or "%n-AT-%d" would change
# the '@' into "-AT-". This translation is done after
# auth_username_translation changes.
#auth_username_format = %Lu

If you're willing to ignore all domains, so that '<user>@<random garble>' is treated as '<user>', then you can simply set this to:

auth_username_format = %Ln

This is what we did and it works. In current versions of Dovecot this changes Dovecot's view of the username for everything, not just for authentication. And by this I mean that we have some Dovecot settings that use '%u', and after this auth_username_format change they see the username as '<user>', not '<user>@<domain>'. It also changes what Dovecot shows as the username in log messages, stripping out any domain that was originally there. For our purposes this is what we want with only the minor downside of the log message change.

(For a concrete example, we have set mail_location to something that specifies '...:INDEX=/var/local/dovecot/%u' in order to keep Dovecot indexes on the IMAP server instead of on NFS. If you log in as '<user>@<domain>', your index files continue to use just /var/local/dovecot/<user>'.)

Based on what I've read, the Dovecot people are aware of this but don't consider it a bug as such, although they've considered changing it someday. Personally I hope that they don't, or if they do they provide a username_format setting to do this global username change.

If you want to strip only a single domain but leave other domains untouched, so that '<user>@<your domain>' becomes '<user>' but '<user>@<random thing>' stays unchanged, I think that you can do it with a conditional variable expansion. The Dovecot documentation says that conditional expansions can be nested, so you could do this for multiple domains if you were sufficiently determined.

I can see points for either side of being selective here. On the one hand, being selective doesn't help your own users as far as I know, because I believe that regardless of whether they use the wrong domain or the wrong password (or the wrong login), the only error they'll ever get from Dovecot is 'authentication not accepted' (aka 'bad password'). On the other hand, not altering completely wrong domain names means that they will appear in Dovecot's logs intact, so that you can spot people that are trying to use them. If using certain domains are a sign of attackers, preserving these in logs may be valuable.

(My experience from looking at our Dovecot logs was that attackers always tried to use the same domain name that our users did, which is not really surprising. Attackers tried them much more than users did, but that's not much help here.)

DovecotIgnoreDomainOnAuth written at 23:52:11; Add Comment

2017-09-11

Giving users what they want and expect, IMAP edition

Like many places, we have an IMAP server (currently we're using Dovecot). This IMAP server is part of our overall Unix authentication environment, so users log in to their IMAP mailboxes using their Unix login and password (well, their general login name and password, since it's also used for Samba access, authentication with several web servers, and so on). More specifically, users log in to our IMAP server using just their Unix login; they do not use '<user>@<our domain>', as apparently is common at many places.

Well, that's the theory. In practice we get a trickle of users who try to use '<user>@<our domain>' with our IMAP server and then plaintively report problems, because from Dovecot's perspective (or more exactly PAM's), there's no such login 'whoever@us'. We had another one recently, and when I saw the email my first reaction was to think that our support site needed to have a clear 'don't do it this way' note about '<user>@<our domain>', since it keeps coming up. Then I took a step back and reminded myself that users are right, and specifically that if users are doing something naturally and on their own, user education almost never works very well. If some number of users were going to keep putting in our domain on their IMAP login credentials, the best and most friendly thing to do would be to quietly accept it anyway, even if it's not technically correct.

(In a sense refusing '<login>@<our domain>' is robot logic. We know (or can know) what was intended and it's completely unambiguous, it's just that our software doesn't recognize it.)

As far as I can see Dovecot doesn't give you any straightforward way to strip off a specific domain from the login name that users give you. However it does appear to be able to strip all domain names off the login name, so you'll accept '<valid login>@<any random thing>', not just '<login>@<your domain>' (this is allegedly done by auth_username_format to, eg %Ln). In our environment it's probably okay to be so broadly accepting, so I'm going to propose this to my co-workers and then perhaps we'll deal with the whole issue once and for all.

(We should still update our documentation to be explicit here, but once we accept everything that documentation is just a backup. It's not crucial that people actually read it and notice that bit; as long as they're close, their IMAP access will work.)

IMAPAuthAcceptingDomain written at 01:42:50; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.