Laptops, centralized authentication, and "roaming profiles"

Tony Shadwick tshadwick at
Wed Jun 8 15:14:01 GMT 2005

On Wed, 8 Jun 2005, Henry Miller wrote:

> On 6/7/2005 at 19:09 Tony Shadwick wrote:
>> I have a question of theory that has been bugging me that I thought I
>> would throw at the list.
>> Presume this configuration: a typical small to medium sized company,
> we'll
>> say 25 workstations, all running some version of *nix, for sanity
> we'll
>> presume all FreeBSD, but I see no reason some couldn't be linux or
> osx.
>> I could set up centralized authentication via NIS or LDAP without too
> much
>> difficulty.  I'm aware of the differences in password schema that must
> be
>> overcome, but I've learned to deal with this.  So now I can go
> workstation
>> to workstation and log in, no problem.
>> NFS can be set up equally well.  No issues.  In the scenario with
> desktop
>> machines, this quite simply isn't a problem so long as you are okay
> with
>> working on everything across the network.  Something about that bugs
> me
>> though...really.  You wind up eating up network resources constantly.
> :\
>> Anyway, that's a tangent to the real kicker.
>> Laptops.
>> They don't stay put!  (well duh)
>> Okay, so the user can log in to the "domain" if you will when in the
>> office, and sure, NFS will automount, but what happens when the user
>> leaves the office?  I've done some quick searching on "roaming
> profiles"
>> (I actually googled 'linux roaming profiles' with little success).
>> So how should one play this out?  I personally am on a Powerbook, and
> have
>> intentionally set up local user auth.  I open and close my laptop to
> sleep
>> it, leave a network, open it and next thing you know you're on a new
>> network.  Now, the fact that you generally only have 1 user per laptop
>> makes this "kind of" okay, but your home directory is no longer
>> centralized, you home directory doesn't get backed up, and now I'm
> dealing
>> with a user that really isn't auth'ing against the domain, and having
> to
>> alot permissions for such user, and having to manage local machine
> uid's
>> and gid's.  Ugh!
>> You see the cluttered path my mind is wandering down here?
>> Is there already a solution to this, or is it still someone one must
> hack
>> for themselves?
> This is a hard question.
> Coda and AFS (Andrew's file system) both attempt to solve the home dir
> problem.   They are both known to be a headache, and not always stable.
> (though some very large installations use AFS, so it must work once
> you sacrifice the right breed of goat or whatever it is you have to do)
>  They are worth investigating.
> Consider connecting laptops via VPN, even when in the office.   Only a
> fool would have a laptop these days without wireless networking, and
> wireless isn't secure by default.  A VPN is just one solution, but
> since it solves the out of office issue (so long as you have network
> connectivity somewhere, which isn't a given) so it might be the best
> way to go.   Or maybe not, like I said, consider it.
> I don't know how to solve the login problem.
> If your company has money (with only 25 workstations this is unlikely)
> you should hire a couple developers to work on a solution.   Perhaps
> you can find a project that is working on parts of this and donate
> money?   I don't know of any, but if you find them.

Oooh....good call on the vpn.  Set it up to where they have a local user, 
and local home directory, vpn in.  Okay, so now I'm on the network, 
presuming the pptp server was authing against OpenLDAP or NIS.  Add a 
script to that login that mounts any NFS shares, and quite possibly does a 
quick rsync against a server to back up the home directory.  Problem is, 
if they didn't "nicely" disconnect, then we don't know who's copy needs to 
be updated, the local copy or the remote copy. :\

I'll look into Andrew's File System.  That's a bit of a misnomer on the 
acronym though.  AFS seems to be more commonly known as "Apple File 
Sharing" protocol.  Yay...

More information about the freebsd-questions mailing list