04-06-2022 11:59 AM - edited 04-06-2022 02:53 PM
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.
04-06-2022 01:51 PM
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.
04-06-2022 01:59 PM - edited 04-06-2022 02:09 PM
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.
04-06-2022 03:06 PM
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.
New to the site? Take a look at these additional resources:
Ready to join us? You can register here.