There is a good article on User Masquerading in Lion Server on techrecess.com. This feature has come and gone a few times in Mac OS X Server and through a few different books, I’ve discussed it here and there over the years. Some use it as a troubleshooting mechanism for permissions on servers. I have always had a couple of problems with this feature and so I’ll do a mini-rant on it. No offense to Randy whatsoever as the article is great in and of itself.
Problem #1: Logs
When a user logs into a file share via AFP and browses a directory, those events are logged. The user’s IP address is logged along with the username they entered for authentication. Subsequent activity, including directory browsing, file access and file deletion events are then logged into the AFP logs (provided you actually use logging). If the username is entered through a masqueraded account then you might be able to look into your DHCP logs (or router logs or whatever other logs help with this) and figure out which events have to do with a masqueraded account. But events are tracked by IP address from then on, meaning that if you have two IPs logging in with the same username, that you effectively have an issue with the logs not telling you a complete story. This isn’t that big a deal, except that it leads to Problem #2.
Problem #2: Forensics
Things can happen on servers. Data theft is one of those things that happens a lot, but that we don’t discuss much in the server admin side of things. You see, to us, users either have access to data or they don’t. And if they have access, then they have certain limitations put on what they can or cannot do with that data. But, when you’re doing any forensics work, you look for certain things in the logs. For example, if a user copied a lot of data from the server the day before they left their job then you can reasonably be assured that the user was stealing that data from the server. If the user deleted a lot of data 10 minutes before you fired them, then they probably got wind of what was about to happen. If their actions are bad enough then forensics invariably comes up.
Now beyond the shadow of a doubt and reasonable doubt are two different things. But, if you are looking to prove that a specific action was taken then using AFP logs is already hard enough as you only see entries for IP addresses, with the exception of when the user authenticated. The fact that you can masquerade as a user means that doubt can be placed on whether the user did something or whether ANY user with an administrative account did something because they knew the user could take the blame. For example, the systems administrator gets an email that the user is going to be let go. The systems administrator then uses a system in the office (not their own) to authenticate as the user and do something. The user gets blamed. Now, most systems administrators I know would never engage in nefarious activities; however, reasonable doubt that the user who performed an action can be cast if you are using masqueraded accounts.
Problem #3: Lock Picking
When picking locks, one thing you learn is that it’s easier to pick a lock that has different sets of keys that can open it. There’s just more combinations, making it quicker and easier to pick the lock of many an office building than it is to pick the locks for many houses. Another problem with masquerading is in brute force. Password policies in OS X Server do not get applied to administrative accounts. Let’s say you have 4 admin accounts. In a Mac OS X Server environment you can pretty safely assume that either admin or diradmin are accounts that exist on the domain. Any user can dscl from their client system to find administrative accounts, if they’re part of an OD environment. If a brute force attack is run, then there are 5 possible passwords (including the user password) that can authenticate, theoretically cutting down the amount of time to run such an attack by almost 80%. I know, I know, don’t forget about the adaptive firewall, and all… But it’s a best practices conversation, not specifics.
Problem #4: Non-repudiation
Similar to Problem #2, but not quite. You authenticate as a user and access data in a file that you as the systems administrator are not supposed to have access to. If you are sitting at the console of a computer, a sudo event would have been trapped in the security logs. However, since you’re coming in over AFP, you do so as a user who has access to that payroll file or something else you should not have access to. I really don’t like knowing any user passwords, ever. This way the finger never gets pointed at me. If I need access to a user’s data, I am going to change their password. That way, they know I accessed their data. The only way I can access their data is if I change their password, because I don’t otherwise have access to their stuff…
But I can just enable masquerading any old time? Having a layer of change/configuration management, where you snapshot server settings, such as sabackup helps to keep an audit trail clean and consise. Logs and the fact that afp would have had to be restarted twice between snapshots helps make possibility of wrongdoing more easily tracked and therefore (hopefully) less likely. There are a lot of ways to troubleshoot permissions. Masquerading as a user is rarely going to be necessary, and in any cases where it is necessary, you can change the user’s password. The security issues that arise, visibility in logs and how this option breaks some of the most basic tenets of security all make me stay away from using this feature.
It would seem there are those within Apple that would agree with me. Otherwise I can’t imagine why the option would come and go over the years… Having said this, one of the reasons I’ve spoken about security less and less over the years is that there are a lot of different views and points and layers that go into a security model. Another is that some Mac users can get violent at the most minor implication you may make that there is a modicum of a flaw in their platform of choice – even if it is meant to increase the overall security of the platform. Or at the least there is a general sense of apathy about security on the platform. Provided you’ve masquerading into account though, then by all means, use this option (there are definitely arguments that good Splunk (or other log analysis/aggregation tools) utilization can override such practice, albeit a lot of effort would need to go into such a practice). Either way, thanks to Randy for pointing out how to enable it!