At work I've been buried into SSO, SAML, and identity management. So in that research I happened across JumpCloud. It didn't fit as a solution for work, but 10 users free forever and a LDAP server in the cloud, plus SAML (should I ever find a service I use that supports it...). This sounds promising.
I dove in, removed my Windows workstations from my Samba 4 AD, installed the JumpCloud agent, and used ForensiT Profile Wizard to migrate my Windows user profile from a domain profile to a local user profile. Other than a few easy to solve permission issues it worked perfectly, and it's free for personal use.
After installing the JumpCloud agent, my local Windows accounts were synced up with my JumpCloud accounts. This is looking good. I added the JumpCloud agent to my Mac and a Linux workstation with similar results. Each computer running the JumpCloud agent only has local user accounts, but the password for those accounts are synced with the JumpCloud agent.
The trickiest part was using the JumpCloud LDAP service as the Samba backend. JumpCloud advertises this as a main selling point, but the documentation for what to put in your smb.conf is non-existent. At this point I can't even cite all the different resources, forum posts, and mailing list emails I referenced to get a working configuration. For anyone else trying to figure it out, you're welcome.
smb.conf with JumpCloud LDAP
[global] netbios name = bumblebee workgroup = CYBERTRON security = user # Domain logons seems to be required to make look for the Workgroup and not NetBIOS name in LDAP. domain logons = yes domain master = no # Increasing the log level is helpful. log level = 3 # This doesn't seem to be needed. # idmap_ldb:use rfc2307 = yes ### JumpCloud LDAP Configuration passdb backend = ldapsam:ldaps://ldap.jumpcloud.com:636 ldap ssl = off ldap admin dn = uid=sambasvc,ou=Users,o=ReplaceWithYourOrgID,dc=jumpcloud,dc=com ldap user suffix = ou=Users #ldap group suffix = ou=Groups ldap group suffix = ou=Users #ldap idmap suffix = ou=Idmap #ldap machine suffix = ou=Computers ldap passwd sync = Yes ldap suffix = o=ReplaceWithYourOrgID,dc=jumpcloud,dc=com # Disable SMB1, just a good idea. min protocol = SMB2
After editing smb.conf you'll need to save the password for your Samba LDAP Service Account (uid=sambasvc in my configuration).
sudo smbpasswd -w
Now restart Samba and watch your log.smbd:
[2018/03/29 23:49:46.704615, 2] ../source3/passdb/pdb_ldap_util.c:280(smbldap_search_domain_info) smbldap_search_domain_info: Searching for:[(&(objectClass=sambaDomain)(sambaDomainName=CYBERTRON))] [2018/03/29 23:49:46.705466, 2] ../source3/lib/smbldap.c:794(smbldap_open_connection) smbldap_open_connection: connection opened [2018/03/29 23:49:48.252596, 3] ../source3/lib/smbldap.c:1013(smbldap_connect_system) ldap_connect_system: successful connection to the LDAP server [2018/03/29 23:49:50.939653, 0] ../lib/util/become_daemon.c:124(daemon_ready) STATUS=daemon 'smbd' finished starting up and ready to serve connections
At this point I'm still using local groups on my Linux server and adding my local Linux user (created by the Linux JumpCloud agent) to the local Linux groups. Not ideal for most small business, but for my very specific needs it's fine. Maybe someday I'll put in the effort to figure out if using LDAP auth on the Linux machines so I can tie into JumpCloud users and groups is worth it, for now it's not worth it to me.
Downsides
JumpCloud offers 10 users free forever. That's great, but when you setup Samba they recommend a service account dedicated to Samba due to the permissions and lowering of security required for LDAP/Samba integration. So you're down to 9 free users that you can use. I also created a more generic LDAP bind account that I'm using for other LDAP services such as my local Atlassian Confluence install. So that's two of my ten free users tied up with Service Accounts. Again, not a big deal for me but definitely something to be aware of.
