Wednesday, February 15, 2017

So, if you got here, you are looking for a solution to find out how you can prevent you users from being able to start applications from any location while still being able to print.

The big problems are:

macOS using restriction profiles seems unable to handle relative paths. In earlier versions of OS X you could use these paths such as '~/' for the home folder to for example deny execution of applications from within the home folder

In order to print, macOS needs to create these 'PrinterProxy' apps in the users home directory under 'Library/Printers'.

Why these PrinterProxys habe to be located within the home directory is out of my reach.
Also I don't think this is logic. Even if the printer is assigned to the machine, the folder containing those PrinterProxys is still located in the home directory of the user.

But anyway.

I tried al sorts of redirections, creating a PrinterProxy folder in /Library or /tmp and then creating a symlink that would point at these folder.
Forget it. It won't work.

So, in the end I ended up doing this:

For every file share that contains user home directories, I created an entry in the 'Allow Folder' section of the profile.

These entries look like this:

/Network/Servers//Volumes//%short_name%/Library/Printers

By using the payload variable '%short_name%" inside the path allows you to use the users short name as is most often done for the name of his home directory.

The rest of the path has to correspond to the path that you get when entering the command

pwd

in the terminal when logged in as an example user.

I hope this helps others to save some time and prevents them from going all the way again.

Monday, November 14, 2016

After having struggled for quite some time, here's what I found out when deploying VPP apps to clients running OS X or macOS using device bases assignment.

In this case we were using OS X 10.11.6 El Capitan.

This means that the apps are assigned to the device and not to the user.

One thing that was especially irritating was that we often had a dialog popping up:

«storedownloadd is trying to install new software.Type an administrator's name and password to allow this.»

The problem is: we are deploying the software to client whose users are not administrators.

So, what's the solution?

Well, thing is, there are several players to the game.

In order to have VPP apps being installed to your computer, you need:

A working VPP deployment system

Correct settings in Restriction Profiles applied to the clients

Correct settings in the App Store PrefPane being used by the clients software update mechanism.

1. Working VPP

Actually I found this to be the easiest of all.

We use FileWave to deploy our apps, but the problems we were having were independent of any special software.

2. Restriction Profiles

In order to really understand what's going on if you deploy VPP apps to the device, you need to know this: The apps being installed from VPP are actually being installed by the user currently logged in.

This means this:

The local user has to be able to install apps.

The user has to be able to use the app store

A non admin user has to be able to install apps

If no-one is logged in, apps are not being installed

If we look at a restriction profile, this is what we see:

In here there are two points:

One is: «Require admin password to install or update apps».

This has to be turned of because otherwise only admins are able to install apps.

Remember VPP is using the current user to install the apps which might not be an admin user.

This would make this dialog mentioned above to pop up and the app would not be installed correctly.

3. App Store Settings

In the App Store Pref Pane there are two things that need to be set correctly.

It should look something like this:

Two of these points seem to be affecting the deployment of VPP apps:

First we need to enable 'Automatically check for updates' in order to get the mechanism to work.

Second, the item 'Install app updates' has to be enabled.

The reason for this seems to be that the software deploying an app to a device seems to actually be assigning a license to the device, the installation all updates of the app itself are being done via App Store. So if we close down the app store for a client, it won't be able to download and install any apps.

I used a script to remove any previously configured settings to the app store and configure them as required. The script looks like this:

#!/bin/bash

# Configure app store to only download critical system updates and vpp apps

Unfortunately this script no longer worked when we upgraded to OS X version 10.11 'El Capitan'.

We tried everything, but always ended up with keychain errors.

When logging in, the guest user obviously tried to access keychains which at that moment weren't there or not accessible.

We the tried to revert back to the system guest.
That seemed to work. Until we removed the parental controls from that user at which point the system created a new user named 'Guest1' which had some other problems….

So, after trying around quite a lot, I found a solution.
The changes are actually quite simple. There are tow things that have to be changed:

Add a password for the guest user. The script won't work with empty passwords

The entry in the keychain added has to be accessible to all processes. To allow that the parameter '-A' is added to this step

OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. It can be re-enabled using the HostkeyAlgorithms configuration option:

ssh -oHostKeyAlgorithms=+ssh-dss user@127.0.0.1

or in the ~/.ssh/config file:

Host somehost.example.org
HostkeyAlgorithms ssh-dss

So OK, but how do I enable it?

Lets see. Clearly we need to edit the file '/etc/ssh/sshd_config'.
So after having created a backup of this file (and having me ending up locked out several times), I added two and tow together and tried this:

vi /etc/ssh/sshd_config

Here I added the line

HostkeyAlgorithms ssh-dss

Then restart the SSH daemon

/etc/init.d/SSH restart

But. It still doesn't work.

OK, but I still think this is the right way to go.

Restore the backuped file.
So we add two and three together which looks like this:

vi /etc/ssh/sshd_config

Now I add the line

PubkeyAcceptedKeyTypes ssh-dss

Then again:

/etc/init.d/SSH restart

Et voilà. It works.

So all you have to do is add the line

PubkeyAcceptedKeyTypes ssh-dss

to the file ' /etc/ssh/sshd_config' and then restart the SSH daemon using