automount purgatory

[orris]

I’ve read the helpful article on automounting…Perhaps I’m being a bit naive, but I would have thought that Kerberos, automount and afp would be a bit more straight forward and cooperative by 10.4.5…I’m trying to force people to get a kerberos ticket before they can automount a server volume. As I understand it the porblem is that on startup and login, the user does not yet have a ticket. The mounts are established in an unauthorized state, so that even when one subsequently obtains a ticket, the automounter doesn’t unmount them and remount them in a seamless fashion. I can certainly force the issue by killing the automount daemon and restarting it by hand on the client, but one seems to need to acquire an afpserver ticket. That is only issued by directly signing into the server, which really obviates the whole point of automount anyway. Is there a way out of this conundrum? Or am I stuck with abandoning Kerberos all toghther?

[orris]

Is there a way to use kerberos for a single signon to authenticate to a server that would allow clients to automount several shared network mounts from the same server on the fly? Everything I’ve read would seem to imply that this is the point of kerberized afp and automount, but I’ve yet to see it work as advertised.

[orris]

At the outset, thanks for the site. Lots of little pieces of information not easily learned from manuals.

What I’d like to have happen is after a user logs onto their own computer, that the disks on the server could be mounted by accessing the mount point via command line or finder the way old NIS/NFS automount/autofs used to work under our old UNIX system. However, I’d like the signon authentication of a kerberized afp, but not the tunnel of ssh, since I don’t want the server encrypting/decrypting all packets.

On the server:
AFP: Guest acces enabled, kerberos enabled, Bonjour enabled, secure connections enabled, authentication Kerberos

I’d like to share a volume giving read privileges to several groups, and ownership of folders/directories therein to users. This would be to allow a rudimentary collaboration/backup Volume.

Sharing settings at the top level volume:
Share enabled, ACL enabled, Volume ownership root:staff, Volume permissions 755, AFP share enabled, AFP guest access enabled, network mounting enabled via AFP, Use for “User Home Directories”

In this volume are several folders/directories owned by users with specific entries in the LDAPv3 domain.

On the Client Machine side the Directory Access is set to the correct binding LDAP server, (however, I should point out an annoying bug, that it never lets me unbind from that server).

Once the user logs in with their password they are asked to choose a workgroup (choice seems irrelevant). The login finishes a finder window is initiated and one clicks on Network then Server then on the server name and a list folders appears
Groups
Users
Volumes
Shared

Further attempts at accessing any of these folders is met with no response. No challenge for authentication (which is what I’d like to have happen). If one obtains a kerberos ticket from the server, manually kills and starts the automount daemon in debug mode, and migrates over to the server folder again, then there is a tremendous list of failed attempts at mounting resulting in either error 5 IO Error, 80, 45 Operation not permitted, or 2, depending on the specifics of the files one is attempting to access. Next if one gets a kerberos ticket and manually connects to the server a new afpserver ticket appears under /usr/bin/klist. Now if you kill the automounter again and restart it, anything mounted as static (I know this is not strictly what I’m after) can be mounted successfully. But, I really can’t have my users go to this much trouble to access their backup/file server.

Any suggestions or hints would be much appreciated!

[orris]

Your suggestion works very well….For network managed users. In this case the afpticket is issued at the time of the login. If however, the user is authenticated locally, but has a network account as well, then they seem to be out of luck.

There is a command line program called mnthome that seems to be just the thing to use, but it returns
Error: There is no home_loc for

[orris]

Thanks! I experimented with this some by creating a network user and modifying the local NetInfo database appropriately to match two different types of users. This essentially required the addition of several new fields
original_authentication_authority
authentication_authority
original_node_name
sharedDir
original_node_name
mcx_flags
preserved_attributes
mcx_settings
original_home_loc
original_home
original_passwd

Additionally the gnerateduid needed to be changed to match the network user generateduid.

This just seems like a heck of a complicated work around!
Anyway, Thanks for the help!

[Author]

Posts