You Don't Need AD to have a File Server

[JCDavid]

You can't understate the importance of file servers for many SMEs. My own company (several years back) worked off of a few shared drives (for years) and that workflow was embedded in the company. We invested considerable time to get the permissions right, so that there was transparency, but security was in place and some areas were limited to specific groups. That was a major undertaking, given the original file share was "wide open" and primed primed for a ransomeware attack. I doubt we were alone.

Any proposal to change it would have been met by a flinch reaction. Sure, there's better technology out there, but it's what people understood. Changing how users work is among the most challenging jobs of IT. Change is hard, and we all learn differently. File servers are important, and aren't going anywhere within mature organizations. That's a legitimate concern that comes up when prospects are considering making the "jump" away from Active Directory, but it's no excuse to keep legacy on-prem servers.

The solution is a trick veteran Windows admins are familiar with: using a command to map network drives. A missing drive icon on the desktop was a common support call for us, especially among remote VPN users. We created a BAT to deal with it. Windows admins who are in the process of transitioning to JumpCloud, in the domainless enterprise, can do essentially the same thing.

I'm working on a formal blog write-up, but this is it at a high level:

1. Setup AD import and synch agents with JC
2. Verify which sec. groups in AD are given rights/privs to each file share on the windows fs.
3. Add those sec. groups as member of "JumpCloud" group in AD.
4. Create proper command to run drive mapping batch file upon each login to user windows computer.
5. Use ADMU to detach user/computer from AD.
6. After binding user to windows device in JC run command on windows computer.
7. Voila - Drives mapped to local on-prem Windows file shares (Or I suppose VPN connected file shares)

Here's a JumpCloud KB article about that BAT file.

This solution will help organizations to make migrate to JumpCloud on their owns terms. We also have a new professional services team for customers who have more complex requirements. There are many paths to a better directory.

[RyanBailey]

Hey David - looking forward to the full article! We do this currently and its being working well in production for the last few years. We were never an AD shop so it wasn't a full migration but had to solve a lot of the same problems.

Curious how you solve for keeping the local groups updated as the corresponding User Groups are updated in JumpCloud. We had to roll a script to run via Task Scheduler on the file server to sync local User Groups (and their members) with the corresponding groups in JumpCloud (which we consider the master record), but curious if there is a better way.

[JCDavid]

Good question. Allow me to give this some thought and discuss with our team before circling back here re: groups.

In general, it's possible to keep identifies in sync. 

• AD Sync is used for user provisioning and SSO. It enables you to maintain your directory within AD DS and to sync with JumpCloud. JumpCloud will be your IdP (SAML SSO). It provides a one-way synchronization of passwords and attributes from JumpCloud to Active Directory. In this case, you will no longer be managing your users from AD. For example, if you make a password change to a user in JumpCloud it will sync to AD. This method of integration between Active Directory and your domain controller can be used to establish SSO for device logins as well as external web app access control. The KB article has information about groups and this may be the rub: "For full bidirectional synchronization, we recommend that all Users and Groups be synchronized with JumpCloud, live under a single OU (Root User Container) in Active Directory. This can be the default CN=Users container in AD or an alternate custom OU within the directory."

• AD Import works in the opposite direction from AD to JumpCloud, maintaining AD as your default directory. 
• Use both utilities if you want full bidirectional synchronization

[BenGarrison]

Only option outside of this would be somehow mapping groups to LDAP groups. That would require some sort of LDAP integration that I am not familiar with personally.

  But I think since you're managing local groups the way you are doing (and how the support document illustrates) it is actually the best way in my opinion. It's seems expensive and definitely a single point of failure.