'Roaming profiles' and credentials caching

Hi all

I am trying to find the best/proven/preferred solution for a roaming profile equivalence on FreeBSD. The goal is to have a centralised authentication but still be able to log in when a network connection is unavailable.

In the Windows world there are roaming profiles. On FreeBSD one could now mimic the solution using Samba 4. And then, there is SSSD. I have however some difficulties with these solutions:
  1. Samba is a kind of alien in the Unix world, trying to teach Linux/FreeBSD to speak a "foreign language". I prefer to base the home directories on NFS rather than SMB and the authentication on OpenLDAP with Kerberos.
  2. The FreeBSD port of SSSD seems abandoned at version 1.6 where the current one is 1.10. Furthermore it introduces another layer of complexity and stuff to learn and care of.
So my question is: isn't there another way of solving this requirement under FreeBSD? Something like this approach here?

What I need is:
  • caching of login credentials (i.e. username and password hash)
  • home directory synchronisation (probably with rsync?)
  • VPN or other kind of end-to-end encryption to the server
so a user could log in to and work on her/his laptop in the Namibian desert but have VPN and home directory sync as soon as a network is available. Actually the functionality of SSSD for FreeBSD but based on already available and well maintained ports?

Thanks in advance for every input!
 
Update/clarification:
  • Samba could be used on the server only - there still isn't any counterpart (i.e. caching client) for a FreeBSD laptop.
  • My question addresses the client part as the server should run LDAP with Kerberos.

SSSD functionality under FreeBSD without SSSD?
 
Haven't done it myself, but I'd suggest reading up on LDAP (distributed configuration) and Kerberos (centralised SSO).


edit:
So my question is: isn't there another way of solving this requirement under FreeBSD? Something like this approach here?

Just had a quick glance - that page looks to be (basically) on the right track. I'd also suggest the O'Reilly books on Kerberos and LDAP. What you're doing is certainly on my list of projects, but unfortunately its a long way down - I'm in a mixed environment and Active Directory is based on Kerberos and LDAP - using those will give you a level of compatibility/integration with the Windows world as well, if that's important.

vanessa said:
What I need is:
  • caching of login credentials (i.e. username and password hash) - Kerberos
  • home directory synchronisation (probably with rsync?) - rsync sounds like a plan
  • VPN or other kind of end-to-end encryption to the server - IPsec

Use LDAP to distribute the configuration of the above to your machines.
 
Well, unfortunately it's not that easy :( Kerberos/PAM clients don't have a caching capability on their own. This is why the Linux solution uses nscd - a daemon not available for FreeBSD. Actually libpam-ccreds and libpam-mklocaluser have not been ported either.

SSSD seems to be the only viable solution for the credentials caching part, and I must correct myself regarding its 'freshness' - the last update has been 2 months ago. So the port is in fact being maintained, albeit 1.6 only.

I am however surprised that there are no efforts for providing a robust solution for FreeBSD. This is a key technology not only for laptops but for corporate use of the OS at all. Correct me if I am wrong, but I've got the impression that most people try to bind FreeBSD clients to Active Directory instead of providing an alternative based on UNIX.
 
O-ye :r I didn't think that nscd comes with the base system and looked for it in the ports db only.

Now I searched deeper with Google and found out that somebody has already used Linux binaries (Ubuntu/Debian packages) of the other two libraries under FreeBSD at some point of time:
http://www.mmnt.net/db/0/0/ftp.is.freebsd.org/ubuntu/pool/universe/libp/libpam-ccreds
http://www.mmnt.net/db/0/0/ftp.is.freebsd.org/ubuntu/pool/universe/libp/libpam-mklocaluser

So at least one could try using them this way or compiling them from source. Seems like a 'shaky' solution for a corporate use though.

I'll give SSSD a shot first and report if/how it worked.
 
I promised to give some feedback regarding SSSD on FreeBSD, so here it is:

After a couple of days trying to build version 1.10.1 I finally gave up. It turns out that SSSD uses some pieces of software developed for Linux (like popt) which on their own didn't compile under FreeBSD.

I tried to compile SSSD from source as there are no ports after version 1.6.1 and it has a bug when used with plain LDAP instead of FreeIPA. While building all the dependancies prior to SSSD I finally gave up on popt which drove me nuts. Despite compiling the last version, SSSD always complained about a missing function in popt.

Taking into consideration the high number of open bugs as well as the fact that even Ubuntu users have their difficulties with SSSD I can definitely say that it is something for people with lot of free time and no production-grade needs.

Fortunately there is an alternative. We will be using a local LDAP server, which will replicate the master server content and cache it locally for offline logins. I am marking this thread as solved (for me) but will appreciate any feedback from more experienced users.
 
Just a thought... Apple do similar stuff with Open Directory.

I know this might be a bit of a side-track to what you want to do and not entirely open source, but you could perhaps (?) run Open Directory on a Mac server or two and use FreeBSD machines to replicate it via LDAP, etc.

Supposedly, Open Directory is built on open source tools with a proprietary schema and GUI for management and I've not personally attempted to integrate it into a generic Unix environment, but it may be worth a look?

Open Directory can also act as a Windows PDC which could be handy if you also have some Windows boxes.
 
Yes, you are of course right, and we checked this option first, as the whole company works on Macs here. We have no one Windows box (well, a couple VMs for testing under VBox).

I started to answer you here but then moved the reply to a new thread because it became quite lengthy and off-topic for this thread. Please look at this post.
 
Back
Top