Fix for Connecting to OS X SMB Shares from Windows 10 – Updated

Please scroll to the bottom for the latest update on 18/3/2016.

Some people have run into difficulties connecting to SMB shares served by OS X servers running Open Directory.  I saw this phenomenon myself with a clients’ machine that was able to connect to the SMB share using a Local User account on the server, but when attempting the same connection with an OD Local Network User account the logs returned errors akin to not logging in to the correct domain.

After searching various online communities I found that a small group of people had run into this problem but no-one had sussed out a solution yet.  I banged my head against the wall for a while with this on the machine that was causing the problem without making any headway and then set up a new fresh VM of Windows 10 to test in my home lab setup.  To my surprise, the machine logged in to the SMB shares on my OS X Server machine without issue.

Comparing the fresh VM to the machine that failed to authenticate, I noticed some differences in Security Policy settings.  Many OS X admins who had Windows 7/8 machines that exhibited issues authenticating on earlier versions of OS X Server (10.7 mainly) used a set of “tweaks” to the Windows security policy to overcome these problems, and the client machine I was working with I suspect had these adjustments at an earlier point in it’s life.

The main “tweaks” were setting:

Network Security: LAN Manager Authentication Level to Send LM & NTLM -use NTLMv2 session if negotiated.

Network Security: Minimum session security for NTLM SSP Based (including secure RPC) Clients to unchecked (No Minimum).

I was re-pointed back to these settings via this site.

When examining the Local Security Policy on the fresh VM, I noticed that the first item, Network Security: LAN Manager Authentication Level, was set to Not Defined.

Secpol_Fresh_VM

Returning to the problem machine, setting this item to Not Defined was not an available option but changing it to Send NTMLv2 response only did the trick.  The machine now authenticates to the SMB Share with OD Local Network User accounts without issue.

Step-by-Step Instructions

Press the Windows key and “R” together on the keyboard and enter secpol.msc in the run dialogue.

Run_Secpol

Navigate to Security Settings / Local Policies / Security Options.

Secpol_Fresh_VM

Find Network Security: LAN Manager Authentication Level, and set it to Send NTLMv2 response only.
LAN_Manager

Finally, ensure that Network Security: Minimum session security for NTLM SSP Based (including secure RPC) Clients is set to Require 128-bit encryption.
Min_Security

These settings got my problem machine singing the right tune, hopefully it will help yours as well!

UPDATE – 18/3/2016

A few people have contacted me to say that this process is no longer working, and I have seen myself on the Home version of Win10 that you cannot access the secpol.msc applet to edit security policies.  Obviously, there have been many patches to both Windows 10 and OSX Server since this post was written back when 10 was first released.  Having just worked with an end user on this issue I thought I’d post an update with what worked for us on this Win10 Home machine.

Watching the log from the server I saw this on failed authentication:

Mar 18 11:39:10 server.company.com digest-service[61066]: digest-request: user=MicrosoftAccount\\username
Mar 18 11:39:10 server.company.com digest-service[61066]: digest-request: kdc failed with 36150275 proto=unknown
Mar 18 11:39:10 server.company.com digest-service[61066]: digest-request: guest failed with -1561745590 proto=ntlmv2

So the Windows 10 client was forcing the OSX server to find the user’s account in an unknown domain called MicrosoftAccount.  Let’s say that the OSX server’s Open Directory domain is “OD-DOMAIN”.  I was able to get the user to authenticate correctly after clicking Use Another Account and entering “OD-DOMAIN\username” in the username field and then supplying the user’s password.

Mar 18 11:51:34 server.company.com digest-service[61678]: digest-request od: ok user=OD-DOMAIN\\username proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_SIGN, NEG_TARGET, NEG_UNICODE

I hope this helps somebody!

 

Advertisements

Review of Backupify Migrator for Google Apps

Migrator Screen Shot

This is a review of the Migrator for Google Apps tool from Backupify.  This is a very useful tool for admins to transfer all the data from a Google Apps user in one domain to another.  The tool allows you one free migration with which you can test functionality and any further migrations are $15 per user account.

I work with a client that has been using Google Apps for Business for a few years now.  When they created their Google Apps accounts, Google didn’t yet support the creation of multiple domains and this client had always historically used different email domains for different geographic regions.  Recently, the decision was taken to incorporate all the regions under a single universal email domain.  For the home office’s account it was a simple procedure of adding the new domain name and making it the primary domain.  For regions that had been set up as separate Google Apps accounts, this was a much more challenging task that would require creation of new user accounts on the new primary domain and transfer of all the users’ existing Mail, Contacts, Calendar, and Drive data into the new accounts.  You would encounter a similar situation if a company with existing Google Apps service is absorbed or merged into another company that uses Google Apps.

We first ran a test migration using a dummy account that was populated with emails and shared calendars and data in Drive and this all transferred as hoped with shared calendars and Drive data being automatically re-shared with members of the same organisation at the new domain.  After being happy with this initial transfer we proceeded with the batch migration of the entire domain.  The Migrator has great documentation about all the processes and a template .CSV file for you to download to populate with all your user data to transfer.  The Migrator can handle batch migrations of up to 50 users at a time, which meant we only needed one pass to do all of our 28 users.

The process was as simple as checking through settings on the source and destination Google Apps Domains (specifically to ensure Federated Login using OpenID was turned on), choosing a batch migration on the Migrator App, authenticating to both source and destination domains as a Super User, and uploading the .CSV batch file.  Many of our users had close to 30 GB of data in their Google accounts and 25 of the 28 users were completed within 12 hours, with the last few completing within 16.  The whole way through the migration you can monitor progress of both the entire domain and individual users’ accounts both statistically and graphically, which is always reassuring to see constant progress when some larger accounts transfer very slowly.

After migration was completed we were very happy with the results.  There were a couple of small bits to tidy up but nothing had failed and all the data was intact.  The first thing to note is that because our Google Apps domains are set with the option, in Drive settings, of “For files owned by users in example.com warn when sharing outside of example.com”, when the Drive files were re-shared on the new domain they were automatically re-shared with all the associated personnel within the domain but were not automatically re-shared with 3rd party collaborators outside the company.  This didn’t cause much disruption but is worth noting to anyone who will be migrating groups that collaborate with external users much more widely.  The second minor thing is a result of a long-known occurrence in Apple’s Mail.app where the software repeatedly saves drafts of an email in the process of being written.  Mail and Google seem to have hidden all the multitude of drafts this creates pretty well in normal practice, but after migration my users that use Mail.app found that they had thousands of draft messages in the new account.  These iterations must have been hidden in the old Google account but when all the data copied to the new account it wasn’t clever enough to be able to re-hide or discard this information.  Luckily, any “meant” drafts were placed at the very beginning of the list and it wasn’t a difficult task to delete all the unnecessary detritus.

Overall I have to say that I’d highly recommend this app.  It did the job extremely well and without it the manual migration of all of this data would have been an extremely long and arduous task.  The minor issues I encountered I really only bring up as caution so Admins can steer their way around them in advance and they didn’t present any major inconvenience.  At $15 per account the Migrator for Google Apps tool from Backupify is an absolute bargain.

How to Create an Encrypted Disk Image on a Mac

Sometimes you share your Mac with other people without using separate user accounts, or sometimes you just need an extra secure place to keep some valuable information.  This guide will show you how to create a password-protected disk image file to keep your data in that is protected with encryption.

1. In your Applications folder find the Utilities folder and open Disk Utility

2. On the top of the Disk Utility window, click New Image.

Disk Utility

3. Name the image and choose the location you would like to save it, then set the image size (there are predefined sizes and you set any size at the bottom of the drop menu under Custom…).  Make sure you make your disk a size that is large enough to hold all the files you want to keep plus any anticipated expansion.

Create Image

4. Select the level of encryption you’d like to use.  128bit is generally a good compromise for security and quick access.  If you require the highest grade security, select 256bit.  256bit encryption will slow down read/write access to the files within your image.

5. For an image that will contain files you wish to edit you want to partition the disk formatted as a Hard Drive and keep the Format as read/write disk image.

6. Click Create and enter the password for the disk image in the following screen.

Password Dialogue

7. Now you will see the new image listed in the left pane of Disk Utility and also a removable disk icon on your desktop.  Double click on the disk and move any files you want to secure inside of it.

Icon

When finished, simply eject the disk to close and secure it.  When you want to access it again find the file where you saved it, double click it and enter your password.  The removable disk will now be loaded in your finder and you can access all your protected files again.