Just to probably embarass myself, on a fresh test setup using 10.4.8
clients it finally works, though I cannot check the difference in
configuration at the moment.
caleridas
@caleridas
Best posts made by caleridas
Latest posts made by caleridas
-
RE: Apple Networking Technology
-
RE: Apple Networking Technology
[quote user="The Vicar"]You're missing my point.
You
know that the clients are capable of connecting via Kerberized AFP, so
the problem is not support for Kerberized AFP. There is also nothing
preventing the clients from connecting to the server for home
directories in a generalized way (as, for example, there is with NFS:
nfs_mount has the -K flag disabled).[/quote]I
think you don't understand the difference between AFP and NFS: With NFS
you setup a static mount (or, at least a mount independent from any
user login) to the server and that's it. So nothing has to be done at
login time., just point to the right directory, and the user has all
his data ready waiting for him. For this reason NFS also works well
with ssh logins, because multiple users can have directories
accessible to them mounted simultaneously and in the same place. With
AFP you have to perform the mount operation at login time. So there is
a very very big difference in using the two.
[quote user="The Vicar"] Apple's documentation actually says you can use Kerberized AFP for network home directories, so what you are trying to do should be possible.[/quote]Actually I fail to find a website that explicitly states that. The documentation states that you can use AFP with Kerberos; and it states that you can use AFP for home directories. The combination of both seems implied, but maybe it is wrong.[quote user="The Vicar"]The solution must be some difference between what your systems are doing and what systems using Apple's built-in system do. So, what could that be?[/quote]Errm... maybe they just silently use plaintext authentication with no one noticing? You see, one OS X administrator I know of was quite surprised when I showed him the network protocols dumps...
[quote user="The Vicar"]There is nothing special about a "home directory" connection in AFP (as opposed to other connections). So if your clients can get a Kerberized AFP connection at all from netatalk, the problem does not lie with netatalk.[/quote]There are several things special about home directory mounts (not from the server or protocol point of view, but by how it is facilitated on the client). Since the home directory can be mounted anywhere, and users are normally not permitted to mount arbirtrary shares anywhere beside the Network folder, the operation is performed with a different privilege set. I *think* mnthome reroutes the mount request through the automounter; this implies that mnthome has to pass any authentication tokens through to the automounter which then performs the operation "on behalf of" the user (but not in the user's privilege context).
Things are completely different if you "manually" create a mount to a share; in that case mount_afp is *not* invoked by the automounter, but by the user instead. Since it is executed immediately by the user, it trivially has all of the user's authentication tokens available.I hope you understand that some extra work has to be performed for home directories and that there *is* in fact a difference. Maybe the automounter cannot deal with a Kerberos credentials cache, maybe the passing of the user credentials cache to the automounter through mnthome has not been implemented. Maybe both would be supported, but mnthome does not pass the credentials for some other reason, but at the moment I cannot tell. Of course no error message is logged...[quote user="The Vicar"]
There are only three real possibilities:1) In order to use Kerberized AFP for network home directories, the clients require some special non-obvious static configuration by the administrator, which either comes with Mac OS X Server or is documented in the instructions there[/quote]But how is the mere presence of an OS X server on the network going to change the client configuration?[quote user="The Vicar"]
2) In order to connect AFP network home directories, the clients require some special key from the LDAP (or other authentication) server; Mac OS X Server probably automatically sets this special key up for you when you use the integrated services[/quote]Ouch... LDAP is *not* an authentication service (though it can be (ab)used as one, it is a terribly bad idea). It is a directory service. As for the fields in the LDAP directory... they are documented reasonably well on the Apple website. Besides the fact that I *know* what OS X server puts in there, and it is not much different. Im am pretty certain that there is nothing to configure on the server side.
[quote user="The Vicar"]3) BothIn all three cases, whatever is necessary would be something that someone with Mac OS X Server would be able to detect for you if you asked them. That's why I'm suggesting you contact this guy at Indiana University, since he obviously has studied Mac OS X Server with respect to Kerberos; he probably already knows what you need to do.[/quote]
Maybe he knows something about the client configuration that I don't, I will ask him before I revisit the setup in January. But just believe me two things: There *are* no knobs about the server-side Kerberos configuration to turn. There *are* no knobs about the server-side LDAP configuration to turn. I know these things damn well since I partially implemented the protocols.
I admit that there may be something missing. But what really annoyed me was the sorry state of error reporting and logging. Basically when anything goes wrong you never get to see a message *that* something went wrong, *where* it went wrong (not even to mention *why* it went wrong); getting the whole system into at least the state it is currently in required a tremendous amount of server-side diagnosing of client-side problems. I am not used to this hackish working-style.
And I am also not used to the kind of documentation I could find... lots of extremely detailed step-by-step instruction for simple things (which I could have figured out myself, thank you), but no concise explanation of concepts that would let me logically deduce more complicated things.
-
RE: Apple Networking Technology
[quote user="The Vicar"]
[quote user="caleridas"]
Sorry, but the handling of network home directories on Apple systems is simply FUBAR.
[/quote]Not really, they just expect you to be running Mac OS X Server as the home directory server to do this particular trick. Similar situations exist (or at least did last time I had to do anything along those lines) with Windows and SAMBA, but you aren't running into them. There's a lot of documentation on Apple's site about how to set up Kerberized access to AFP home directories, and all of it involves using their configuration tools. You're using an someone else's server and, in effect, trying to mimic Apple's product without having a copy around to compare. There's nothing wrong with that, it just means you need to understand Apple's software a lot more thoroughly than it sounds like you do. (Which, incidentally, means that if you ever get it working, you could do a huge favor to netatalk by publicly describing what has to be done.)[/quote]Well since this is all about client-side configuration and not server-side configuration I fail to see the point. The "use Mac OS X server" argument does not cut it because it does not change client-side behaviour in any way. As for the myth that OS X server could be doing something different magically -- no, not the case; after all OS X server comprises of MIT Kerberos (guess what we used) and OpenLDAP (guess what we used); the only difference would be netatalk, but a simple network protocol dump shows that it is not behaving any differently (and why do you assume I did not have a copy of OS X server to toy around with?)Well, I received a private response that what I am trying to do is simply not (yet) possible; the "mnthome" command internally used to mount the home directory can accept a password, but not a kerberos ticket; at the moment I cannot verify the veracity of this statement.However even assuming Kerberos authentication worked as it should, AFP is a joke compared to NFS and SMB, security-wise. It is trivial to "hijack" an AFP connection from another computer on the net after authentication is completed, which is *not* possible with NFS or SMB (with Kerberos security and signing activated, respectively). The handling of the Kerberos service principal name in AFP is an invitation for a man-in-the-middle attack (the client tells the server "Who are you?"; and after that, if the server responds "I am host/evilmachine@REALM" the client obediently authenticates to this principal; if you understand how Kerberized services "normally" work you can appreciate the full WTFness). The impression I get is that all of this was written to satisfy a "bullet-point list" of features without anyone understanding the real issues.Just in case it is not obvious... I have strong security background (which is why I am doing this after all) and thus a very different perspective from most other people: I care only very little about anything else than sound security policies and their correct implementation. And if a given piece of software prevents implementation of a sound policy, it has to be scrapped :)
[quote user="The Vicar"]From what you've said, it sounds like Kerberos isn't being used because it can't be used at that point, which suggests that the afp mounting software is somehow unaware that it has a Kerberos key. That suggests, in turn, that there is an LDAP (or whatever) key missing, or possibly a missing/incorrect configuration file on the clients. (I found a PDF via Google of a presentation from Apple about authentication that mentions something about all the clients having "the right plist for Kerberos" at login time, but unfortunately that's all it says.) Have you tried finding an institution that actually uses Mac OS X Server and Kerberos and asking them what keys are returned by the authentication server?[/quote]No in fact not; the vast majority is using unauthenticated NFS (because it is so easy to setup, I presume); all others use local home directories with authenticated network shares mounted after login (which works without trouble); one site is using AFS, but not as primary home directory (they say it cannot be made working); one site is using AFS home directories and a Mac OS X server, but with plaintext authentication (they didn't know it was plaintext until I showed them network dumps).
[quote user="The Vicar"]I did a little searching, and it appears that there's a guy at Indiana University who probably can help -- he figured out how to get Mac OS X Server to substitute a third-party KDC for the built-in one, which suggests that he understands all the pieces of the problem well enough to tell you what needs to be present at login to make things work. I bet he can help you:http://www.afp548.com/filemgmt_data/files/Customizing%20Open%20Directory.pdf[/quote]
Well I know most of what is written there, though it is not relevant. My problem is about client configuration, and if you read the PDF, it deals with using the Apple management tools with a preexisting LDAP and Kerberos server. It has nothing to do with authenticated home directories. Actually, if you read carefully: "... so each user's homeDirectory attribute is set to /Users/username. This forces the creation of home folders on the local hard drive." :)
-
RE: Apple Networking Technology
[quote user="The Vicar"]
My latest guess is that your users' "home_loc" values look something like:afp://server_address/more_stuff[/quote]correct[quote user="The Vicar"]afp://user@server_address/more_stuffIf
this guess is right, then either your server isn't properly reporting
its supported UAMs (it's either leaving Kerberos out altogether or
giving it an incorrect value in the reply to FPGetServerInfo), or else
the AFP mounter doesn't try Kerberos unless you tell it do so. (In
which case, it's another WTF, because the documentation says that AFP
will try to use the most secure UAM it can, and Kerberos certainly
beats cleartext.)[/quote]The server *does* report Kerberos as an option. In fact if I connect to the share manually (and enter the exact same afp URL) I am explicitly prompted for my "Kerberos password", there is no warning about using plaintext (which is shown otherwise), and I can see in the server log that uams_gss is used
[quote user="The Vicar"]The solution, once again conditional on this guess being right, would be to alter the "home_loc" url toafp://;AUTH=Client%20Krb%20v2@server_address/more_stufforafp://user;AUTH=Client%20Krb%20v2@server_address/more_stuffdepending on which one you were using before.[/quote]this does *not* make any difference; plaintext authentication is used neverthelessIf i remove uams_clrtxt from the list of authenticators on the server, then it uses anonymous access instead (and hence I cannot write anything and not read any of my private files)If i remove uams_guest, then login is refused completelyI guess I could list this as WTF#8 (not honouring the authentication policy set by the administrator, and silently falling back to insecure plaintext without warning whatsoever)
[quote user="The Vicar"]Another possibility to try would be to disable all the UAMs in netatalk except Kerberos. (That may, however, not be possible in your setup. It's definitely something netatalk can do, though, so keep it in mind.)[/quote]
Does not work, see above.
Sorry, but the handling of network home directories on Apple systems is simply FUBAR.
-
RE: Apple Networking Technology
[quote user="The Vicar"]
First option: try AFS instead of AFP --
OpenAFS is free, available for both the server (Linux) and the clients
(Mac OS X), and supports Kerberos. (Of course, netatalk also supports
Kerberos, and still ended up with cleartext passwords, so that may not
help. Still, it can't hurt to at least try, right? It looks like AFS,
unlike AFP, has no fallback to cleartext passwords, so maybe it is a
bit safer... at least it would just plain fail instead of creating a
security hole.) In a sense, doing this would be overkill, since you
wouldn't be using the features that AFS was designed for, but if it
works, then who cares?[/quote]Yes I did consider AFS (OpenAFS) a few years back; maybe things have improved but what I learned back then:
- the OpenAFS server stores all files in their own container, not a regular filesystem; this means that you cannot get at the files via any means other than AFS, so *everyone* would have to use AFS- this means you need an AFS client on the AFS server to access the files it is serving- OpenAFS was dog slow; something like 5-6MByte/s read/write speed; NFS,SMB,AFP easily saturate Fast Ethernet at ~11MB per second, and I can get ~50MB/s on GigE- the OpenAFS client was buggy and crash-prone; especially on mulit-CPU systems the client would lock-up within hours; did I mention that you need an AFS client on the AFS server?
- the AFS permission model sucks- specifically using AFS for the Mac home directories was *not* possible -- every solution that I had found for Macs accessing AFS involved running some custom login scripts programs from their home directory, catch-22So based on past experience I did not even consider AFS.
[quote user="The Vicar"]Second option: if you know a low-level Mac geek who is willing to help, or are willing to become one yourself, compile the Darwin NFS code (which apparently has the -K option working), make an installer package, and have your users install it, then connect with Kerberized NFS. Although there may be a reason why Kerberos support in NFS didn't make it into the commercial distribution. (It's in ftp and AFP, so maybe the NFS code is shaky?)[/quote]It's in FTP and in AFP is not a good reason -- both FTP and AFP authenticate only "connecting to a share"; this means that after authentication is done, you can forget about it. NFS is very very very different in that the "connection to the share" is not authenticated, but every individual file access.I hope that Apple understandes their own NFS implementation, if it is deactivated I trust it is for a reason. As much as I want security I cannot treat the users as guinea pigs and have to provide a solution that does not leave their workstations crashing all the time.
[quote user="The Vicar"]Fourth option: go with SMB and buy copies of ADmitMac for everyone. (This would cost more than getting a copy of Mac OS X Server, unless you have no more than 4 Mac users, but it would let you use signed SMB.)[/quote]Maybe a realistic option, but for this year there is no budget anymore. Maybe next year. Actually I hope that Apple simply fixes the Kerberos AFP authentication (I am writing a problem report).
[quote user="The Vicar"]As for ssh login to the Macs not being useable: what, exactly, do you mean? Are you saying "I can't log in with ssh from another machine TO the Mac"? I've never had that problem.[/quote]No. I could log in to the machine using ssh. But I did not get my network home directory. Okay, I can the manually mount all shares that I want, including the share containing my home-directory, but it is kind of inconvenient -- it is not recognized as my home directory because it was not present at login time. This means that applications do not find their preferences etc. which makes working remotely quite awkward. Of course there is also the matter of what happens if two users want the same share at the same filesystem location, but with different permissions -- in short, the AFP model does not support that (NFS could, though).
-
RE: Apple Networking Technology
[quote user="The Vicar"]I'm guessing that you're using Windows as the AFP server, since there's a section in the netatalk documentation about this problem, right? AFP does indeed allow encrypted passwords and passwords longer than 8 characters, but the plaintext passwords problem (which also limits things to 8 characters) is a known issue with Services For Macintosh -- in short: in order to use the default encrypted password scheme, the server has to know the cleartext password; Windows uses one-way encryption by default, so this is not allowed; the fallback cleartext scheme (which is primarily meant for backwords compatability with old systems) only allows 8 characters. Voila![/quote]
No, the netatalk server(s) are running on Linux, though running them on Windows would not make a difference in this case. To use the hashed (or "encrypted" though this is a misnomer) authentication schemes in AFP, I would have to expose a complete list of plaintext passwords to the file server... errr, to *every* file server to be precise... Thinking for a moment about this I cannot seriously consider this as a good idea.
Not to mention that up until now the clear text password is not available *anywhere*, not even on the authentication servers, neither the Windows DC nor the Kerberos server store plaintext passwords; at the very least everyone would have to reenter their password. However since the ultimate goal is to lessen the burden on the network administratos, the idea is to unify the authentication into a single AD or Samba4+Kerberos database at one point in time; adding a third (and plain-text) password database is contra-productive.
Also I am not sure that installing additional UAMs would help at all -- mind you there is already a Keberos UAM *installed* that has also been verified working, but it is simply not *used* for the home directories (heck, I think that even uams_dhx is available...). The sheer idiocy of this still drives me mad.
There are other annoying minor WTFs to the story I didn't mention -- for example ssh login to the Macintoshes is unuseable -- the (sort of) authenticated AFP automount mechanism for the home directories only works for local graphical login. So you can have only one of the following: remote access ability via ssh; or a file server with (sort of) authentication. But never both.
-
Apple Networking Technology
I recently learned more about Apple networking technology than I ever wanted to know... This is probably too intricate to be front-page material, but there are really big WTFs in here, so I thought I'd share it
The environment: mixed set of Windows, Linux and Mac OS X clients; all clients authenticate against either an NT domain controller (Windows) or Kerberos KDC (Linux/Mac);users have a shared home directory for all clients off a central fileserver, served via SMB (Windows) or NFS (Linux/Mac)
The task: "tighten up" the less-than-secure file serving: anyone able to connect to the network could hijack an SMB connection, or simply pretend to be another user to fool the NFS service. In effect a malicious attacker could read and modify arbitrary files.
Okay, what I did... Step 1: enable SMB signing. This thwarts connection hijacking attacks and makes Windows file serving secure. An eavesdropper can still read what is written to the fileserver, but he cannot interfere. NT authentication is already secure, so I am done with that.
Step 2: Enable Kerberos NFS mounts on the Linux clients; since everything else is already in place this is as easy as adding the mount option "sec=krb5i" which provides the same security as SMB signing; I *could* use krb5p to encrypt the data over the network, but since the Windows clients are already communicating unencrypted it buys nothing (except slowing things down a lot).
Step 3: Now we take care of the Macintoshes.
Attempt 1: Use Kerberized NFS; the Apple man-page states that the switch "-k" activates Kerberos security for NFS mounts. However it does not work. A little web search later it turns out that it is *konwn* not to work. Actually, the feature is intentionally deactivated because it does not work, despite being prominently documented. (WTF #1)
Attempt 2: Well, Macintoshes are great and can communicate using any existing protocol on the planet (or so Apple tells me), consequently the next logical thing to try is SMB, as the Windows clients already use it. At first it looks promising, since I am able to access a test SMB share from the Macintoshes without hassle if I access it manually *after* I have logged in and have my home directory mounted already. However using SMB to access the home directories fails spectacularly - for starters, it does not work if SMB signing is activated (WTF #2), and even if deactivated, some apps cease to work at all (sorry, don't remember which, but nevertheless WTF #3). Reading the Apple documentation tells me that using SMB for the home directories is discouraged, and I begin to understand why. So this is a complete no-go.
Attempt 3: The protocol recommended by Apple is AFP. At first I am a little bit concerned that performance may suck (because AFP is a little bit aged), but after setting up netatalk and successfully connecting to a test share, I am pleasantly surprised that it is on par with NFS and SMB. Now I go setting it up for real; netatalk has a Kerberos module, which is neat because we are using Kerberos already, so I activate it. Configuring the Macintoshes to automount the AFP share at user login requires a bit documentation browsing but is straightforward otherwise.
Logging in with my password works and yields my home directory. Yeah, it appears I am done!
Just to finish up everything I start poking around in the log files to verify that everything is working. Hm, very odd: netatalk tells me that the Macintosh clients are using clear-text passwords to connect to the AFP share (send the clear-text password over to the AFP server, which in turn verifies it with the Kerberos server), even though Kerberos is configured and available. Confused, I (manually) connect to an AFP share, and sure enough the Mac uses secure Kerberos authentication against the AFP server, instead of insecure plaintext.
After a little bit of further experimentation, I am convinced that this is the rule: Manually connect to an AFP-share: can use secure Kerberos authentication. Auto-connect to an AFP-share (which *has* to be done for the home directory): can only use insecure plain-text authentication. So what happens when I log in to one of the Macintoshes: The Computer verifies my password using the cryptographically secured Kerberos mechanism; it obtains tickets for me to access further services; it then sends my password in plain-text over the wire to the file server to access my home directory (OMGWTF #4).
At this point I am already at a loss of words, but the security of this setup is as good as it gets given the constraints I had, so it was deemed acceptable. However the story is not finished yet... After the setup is deployed, a small number of users complain that they cannot login to the Macintoshes anymore (Windows and Linux clients work just fine). The error message they got when trying to login was that the AFP server could not verify the password (despite the password being evidently correct), and in fact the log files of the AFP server clearly said "wrong password".
As it turns out, the AFP protocol does not allow more than 8 characters per password... So the login procedure goes as follows: verify the (full-length) password against the Kerberos server, truncate it to 8 characters, send it to the AFP server, which in turn notices that the truncated password does not match the full-length password, d'oh. I think there are two distinct WTFs here: Allowing only 8 character passwords in a protocol in the year 2006 (WTF #5), and then giving a misleading error message instead of warning about the likely problem (WTF #6).
The story ends here, with everyone busily changing their passwords to a shorter one.