Windows 10 now, by default, denies an SMB client from connecting to an SMB server with “guest access”. See:
The temporary fix is to change the registry to allow guest account access
To allow users in an AD group to access windows 10 desktops remotely …
1) Create the group as a global group in the AD
2) Create an OU for computers that will be in the “Remote Access Pool”
3) Create a GP object that is linked and enforced for that OU with the following settings:
In Computer Configuration – Preferences – Local Users and Groups – Group – Remote Desktop Users add the AD group setup above with Action = Update (see screen shot below)
The Update action is required to update this remote desktop users group every time GP update runs.
A reboot isn’t necessary but, since GP updates don’t happen all the time, you might want to run in an administrative cmd window the command:
gpupdate /force
Also note – you may want to carefully consider related remote desktop settings like allowing only one remote connection at setting a realistic time for disconnecting both idle and disconnected sessions.
Lastly, be sure that you understand remote desktop securely. Your systems should not be accessible from the internet. There are lots of RDP security threats so keep them behind a firewall that does not allow access unless running something like VPN.
Sometimes, (in my case when using DEP enrollment on a slow wifi connection) the Jamf agent doesn’t get installed properly during DEP enrollment. To fix that here is what I did:
I first ran the following commands to manually download and “install” the Jamf binary from the Jamf server – All commands must be run as root! (“#” indicates a comment in script fashion not a command to run. Also be sure to replace “<Your JAMF Server>” with the address of your Jamf server)
# Get the jamf agent binary to the right location
mkdir /usr/local/jamf
mkdir /usr/local/jamf/bin
mkdir /usr/local/bin
curl https://<Your JAMF Server>/bin/jamf -o /tmp/jamf
mv /tmp/jamf /usr/local/jamf/bin/
# Set the binary to be executable
chmod +x /usr/local/jamf/bin/jamf
# Create a symbolic link for the binary so the “jamf” command is in the default path
ln -s /usr/local/jamf/bin/jamf /usr/local/bin/jamf
# Create the configuration file the jamf binary uses to find the server
/usr/local/bin/jamf createConf -url https://<Your JAMF Server>
# Re-enroll computer to get the server certificate
/usr/local/bin/jamf -enroll -prompt
Once the Jamf agent is installed, the computer was checking into the Jamf server. However I wasn’t able to scope it to policies because it was listed as “unmanaged”. To change that, on the Jamf server I edited the computer’s “General” information tab by checking the box to set it to “Managed”and entering a local administrative username and password on the computer for Jamf to use to mange the computer. Also, since we use “Sites”, I manually set the site for the computer as well.
Now that the Jamf agent was installed and I set the computer record to “managed”, I was able to scope policies, etc to the computer as I normally do.
Here at Williams the concurrent usage of Comic Life 3 is controlled by the KeyServer. Therefore, we distribute a “keyed” version of the application. The application will only run if the individual is running the KeyAccess client and connected/logged into the Williams network.
In testing, we found that remote connections from windows clients to the built-in macOS VNC server were not encrypted in any way. To resolve this we decided to use RealVNC as the screen sharing server on Macs. Also, since we envision making these remote lab computers available to only a few individuals that have no other way to access critical academic software, I needed a way to restrict which users could authenticate to create the VNC screen sharing sessions.
The following steps are how I enabled this access on our AD joined lab macs where our users are NOT given administrative rights on the macs with the AD join: (This was tested on MacOS 10.14.5 Mojave.)
1) Create the group in your Active Domain using Users and Groups. If you do not have access to AD Users and Groups, talk to your AD domain administrator BEFORE continuing this! Someone needs to be able to add users to the AD group that is created. If that isn’t going to be you figure that out before proceeding! This AD group should be a “global” group. In the example below I have used “LabUsers” as the AD group name.
2) Log into the mac that will be the VNC server with an administrative account.
3) If on, disable the default MacOS screen sharing and remote login in System Preferences.
4) Install RealVNC Server.
5) Create the local mac group. In the example below the local mac group I created was “RemoteUsers”.
6) In the options for the RealVNC server for Users and Permissions, add the local mac group “RemoteUsers” as a group that is authorized to open a screen sharing session. Also, so that you know, in the Security tab of RealVNC server options I use”Mac Password” for the authentication method with encryption “Always on”.
6) Open a Terminal window on the mac and give the following command: (This should NOT be done as super user! I don’t know why but that doesn’t work)
dseditgroup -o edit -n /Local/Default -u localadminusername -p -a "AD_Domaim\LabUsers" -t group RemoteUsers
( In the above command /Local/Default refers to the local directly node for authentication information. Also, the ” ” are required around the AD_Domain\LabUsers so that the \ isn’t interpreted as an escape and with “-p” this will prompt you for the password for your localadminusername which is required )
Note that you may never be able to see this AD group listed as a member of the local mac group! All I ever got was the above command to run without any errors or feedback.
7) Once the command above completes without error, only those AD users that are listed in the AD group should be able to authenticate to the VNC server using the username format below. All other users of the mac that would generally be able to log into the mac but that are not in the AD group, will get an “Access Denied” message when attempting to open the screen sharing connection.
Other useful commands: (using “RemoteUsers” as the example local mac group name)
To list local mac group membership: (this will not list the AD group! If you know of another way, please let me know!)
dscl . read /Groups/RemoteUsers GroupMembership
To list local mac Group properties:
dscl . -read /Groups/RemoteUsers
When researching this I found this post particularly useful:
https://blog.travismclarke.com/post/osx-cli-group-management/
“Windows To Go” is a portable windows environment that Microsoft developed. While Microsoft says they are no longer developing this, it is still available for use on recent versions of windows 10. For the Microsoft overview see: https://docs.microsoft.com/en-us/windows/deployment/planning/windows-to-go-overview
I have used this to specifically create “portable” windows environments that boot most hardware from an external SSD drive. I say portable meaning that with “windows to go”, the windows OS installed on the external drive drops back into a setup mode when it detects that it is being booted on different hardware. This setup mode at boot time then tries to bring in the needed hardware drivers auto-magically for the new hardware this disk is being booted on. This is largely successful on most hardware as long as the network driver is sufficient to get a network connection. I have booted the very same Windows to Go disk without having to install anything new on Dell precisions, Dell optiplexes, Apple iMacs, Apple mac minis, Apple Mac Pros, etc.
While there is a built in process to create a “Windows to Go” disk in Windows 10 (type “Windows to Go” in the start menu search box), I have most recently been using the free utility Rufus to build these disks directly from our institutional windows ISO. Rufus can be found at: https://rufus.ie/ and below is a screen shot of the settings I have been using.
You will also need a copy of the Windows ISO for your institution, and, if applicable, your windows activation key. (We use KMS servers at Williams to serve our Windows and other MS software license activations so we don’t need to hand out the windows activation keys!)
Anyway, with Rufus, your Windows ISO, and a fast external SSD drive (Samsung T3) use these settings to create your portable windows environment on a bootable external disk:
We find that if people manually sleep a mac running Mojave (10.14.5) from the Finder menu that mac is then nearly impossible to wake up. So, at least on lecterns, I am using this command to disable the sleep menu item –
defaults write /Library/Preferences/com.apple.PowerManagement.plist SystemPowerSettings -dict SleepDisabled -bool YES
For more details see:
https://derflounder.wordpress.com/2013/01/27/disabling-the-sleep-command-in-the-apple-menu/
loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
For more details see:
https://scriptingosx.com/2019/09/get-current-user-in-shell-scripts-on-macos/
In 2018 we started using “Windows to Go” on externally boot-able disks to provide the “windows” half of a dual-boot mac. To make this work you need to do the following …
1) Purchase really fast external SSD drives of sufficient size. We choose 250 GBs Samsung T3 drives like:
https://www.samsung.com/us/computing/memory-storage/portable-solid-state-drives/portable-ssd-t3-250gb-mu-pt250b-am/
2) Create your windows environment on a computer that has a removable internal SSD drive. Check this carefully before you begin as most new hardware is coming with SSD system drives soldered to the motherboard! Also be sure that your image is “sysprepped”! See additional tips on preparing a system for imaging/cloning at: https://sites.williams.edu/lj1/labs/windows-10-imagining-tips/
3) Once sysprep has run and shutdown the system, remove the internal hard drive from the computer. Using a sata to usb hard drive docking station like: https://www.amazon.com/s?k=sata+to+usb+Hard+Drive+Docking+Station&i=electronics&ref=nb_sb_noss_2
Mount the sysprepped, internal drive on a different computer that has Microsoft WAIK installed. (Use the version of WAIK that matches the Windows version you are cloning!)
4) Attach another external SSD drive just regularly formatted for windows data. This will be a “Scratch” drive.
5) Run Windows update on your computer for any updates that could interrupt your process!
6) Set your Power and Sleep settings to NEVER sleep either computer or display. This process can take a long time!
7) Now determine all your drive letters. I will use C:\ for the current system where everything is attached, E:\ for the internal drive to take an image from in the drive dock, and S:\ for the scratch disk.
8) Create some directories. You will want to create:
C:\MyImageDir …. to receive the wim image you will be creating
S:\Scratch …. to hold the scratch files
9) With WAIK installed, the internal drive from your system to be cloned, and your scratch drive all attached ….
Find the Windows Kits in the Start Menu then open “Deployment and Imaging Tools Environment” with right-click and “Run as Administrator”. This opens a command window with elevated privileges.
10) To create the wim image in the opened command window you opened above, enter this command:
DISM /Capture-image /ImageFile:C:\MyImageDir\MyImage.wim /CaptureDir:E:\ /Name:"SomeNameForMyImage" /ScratchDir:S:\Scratch\
11) Wait a really, really long time ! Eventually you will see “Saving Image …” with a percentage in that command window.
12) Once that wim image is complete, you can use it as input to the Windows To Go disk creation process.
