Managing Shared NTFS Folders with Local Accounts

For a more updated version of this article, please visit our knowledge base here.

Managing an NTFS file server using JumpCloud is very similar to managing permissions with Active Directory.  The main difference is that the JumpCloud agent is deployed on the file server to maintain local accounts, instead of granting permissions via domain accounts.  Access to a given folder is granted by defining local groups, then adding the local user to the appropriate local group.

For this example, we’ll take the following actions:

• Install the JumpCloud agent on the file server and a client system
• Provision a local account to both systems
• Create a local group and define folder permissions on the share
• Add the user to a local group on the file server, optionally using a script via Commands
• Access the share via UNC path, a persistent mapped drive, and the Finder is OS

We’ll also need:

• An NTFS file server.  This TechNet post explains the process of setting one up.
• A client machine.  We’ll use a Windows 7 and an OS X system in this example

Installing the JumpCloud agent

Installing the JumpCloud agent can be done via various methods.  Our knowledge base article will walk you through the basics of installation.  Depending on the scope and size of the environment, and if configuration management software like SCCM or psexec are being used, it would be worth checking into the command line methods to automate agent deployment.

Provision local accounts

There are various ways to bind users to systems.  In our case, we want to bind the same user to 3 different systems. Since this is a one-to-many relationship, it’s easiest to use Tags for this.

We’ll call this tag ‘File share users’.  The tag name is arbitrary, so you’re free to name it something that falls under a different naming convention or would be more meaningful for your organization.

Next, select the systems that the user will be bound to.  We’ll select the three systems we’re working with today, our file server and two client systems.

Finally, let’s tag the user that we want to have access to the file share and save the tag.  Once saved, within 60 seconds, the user will be provisioned as a local account to the systems that have been selected.

Create a local group and define permissions

Since the user we selected is not a Global Administrator in JumpCloud, that means the account will be provisioned as a member of the ‘Users’ group on the systems. We don’t want just any user to be granted access to the share, so let’s define a specific group that will have access to our share and the share itself. We’ll create a group and folder both called ‘Boulder Office’. If using the GUI is preferred, User and Group management is explained here.

The commands we will use:

net localgroup ‘Boulder Office’ /add
mkdir “e:\share\Boulder Office”

Now let’s set the sharing and permissions on our Boulder Office folder so members of both the Administrators and Boulder Office groups have full control. In Windows Explorer, right click Boulder Office > Properties > Advanced Sharing > Share this folder > Permissions > Add > Enter Boulder Office;Administrators > Check Names > OK > Check Allow Full Control for both groups > OK > OK > Close. Note the name of the network path to the share: \\windows2012r2\boulder office

Add the user to a local group

To add the user to the appropriate local group on the file server, we’ll be using the Commands function in the JumpCloud Administrator Console.  Select the ‘+’ to add a new command.  Then select Windows as the type.  This command is named “Boulder Office localgroup file share”.  In this case, running it under Powershell does not matter because it will execute under cmd.exe just as well.  For the command itself, we’ll add our user ‘gamberson’ to the localgroup ‘Boulder Office’:

net localgroup “Boulder Office” “gamberson” /add

Since we only need this to run on the file server, select the Systems Drop down and check the file server.  The command is now ready to execute, select “Save & Run Now”.

The command may take a minute to complete.  Once done, we can find the results in the Console and confirm the change has been made on the server.

Accessing the share

For our Windows 7 system, accessing the share should be very familiar, the user is logged into their system and they simply go to the proper network path in Windows Explorer. The NTLM service passes along our credentials that are synchronized between client and server and access is granted.

At this point, the user can opt to map this as a persistent network drive, or an admin may use the Commands function to do this on the user’s behalf.  In this case we would use the command:

net use g: /persistent:yes “\\windows2012r2\boulder office” /user:gamberson

A more robust example of mapping network drives dynamically can be found on our knowledge base here.

Further documentation on using the ‘net use’ command can be found on TechNet here.

OS X users can access this share using the Finder. Open the Finder and select Command+K to open the Connect to Server dialog.

Then authenticate

And access is granted.  The folder is managed just like any other folder in the Finder.

If it’s desired to configure this share for automatically connecting at login, be sure to enable ‘Remember this password in my keychain’, then add the volume to the Login Items list. Go to System Preferences > Users & Groups.  Select your user account and the Login Items on the right.  Click the ‘+’ and select the share.  It will be added to the list and mount upon login.

That’s all there is to it.  Depending on how often users are onboarded, the process can be mostly automated between leveraging Commands and provisioning users using the JumpCloud General Access API. Happy file sharing!