Thursday, March 29, 2018

JumpCloud and Samba 4

Having a Samba 4 AD around in my lab was nice for a time, but every now and then things would break after Ubutnu installed the latest Security update or some other unknown cause, and it always seemed to happen when I really wanted to use my Samba server too which made it even more annoying.

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.

No comments: