ARD Settings via Profile Manager

I have somewhat the same issue except I would like to configure for new systems that I add to MDM. When I add machines I have the enrollment profile add systems to groups that control everything from binding to AD to setting finder pref's and network mounts. I have been unable to find a way to set remote management set to the settings needed to be able to control the machine form as soon as it is added to the groups.

We are a small shop so I have not gone the image route with new machines as it just takes a minute or two to setup new systems (rarely setting up more than 2-3 at a time) with the mobileconfig files on a thumb drive. I just have the temp network, trust and new device enrollment configs and execute those. Then PM handles the rest. I may go that route if no other option though.

One other idea I had was to create a custom ARD installer and set things there just to start...

Ahhh good idea... I'll try that.

OK so being dense on my end how do I make and distribute the .cmd file for PM?

😁 definitely a conundrum for a smaller deployment but I also understand from a security perspective why you would not allow some of the things I want to do out of the box... I guess it is a balance. Maybe I will venture into deploying images etc. to get it to do what I want 🙂

Thanks!

There are technical solutions (read the man page for 'security') but they are complicated. It seems to me that your issue is a personnel one. You need to thrash out a proper policy about who has admin privileges and what they may be used for.

The most basic protection is to make sure that every machine has at least two accounts, one 'admin' and the other 'user' that is configured to allow the user to do their day to day work.

C.

There isn't a way to do this from profile manager, you still need to distribute to systems that are not allowing access in via ARD or SSH as they're at default settings. What I did is use TextWrangler (don't use textedit) and paste the following string I put together. Change <YOUR LOCAL ADMIN ACCOUNT> to your admin account name

Now the problem with admin users can be that they may try to remove anything they see as being limiting or allowing administration by you- so my next step was to name the script something that isn't obvious and hide it in the private folder somewhere, try something Unix-ish sounding.. Then download Lingon (its in the App store)- you're going to create a launch agent that will automatically apply these settings with each reboot using elevated privileges. I did it as root on the computer and I tested with before rolling it out. This is handy as you will revert any changes the user makes to your settings here.

You'll have the option to set when these are applied using the in the app- those are just application features you'll need to learn about to get the most out of it. (I can't help with it)

Now it isn't good to have to set up each computer this way (manually) so make another copy of that script. Download something like Iceberg and use this as preflight script. The Exit 0 I place in the script above gives the success signal the package installer is waiting for to continue. Running the package installer will run the script then install the settings.. They'll then run again at restart or login, whatever you selected.

Now test. Did the package run the script and place the launch agent and script into your chosen location? Did your share settings get switched to what you wanted? Adjust as needed. Remove the settings in the Sharing pref pane with each test to be sure its working.

It is far easier to create a one-stop-drop like this and visit people's computers for the small install of around 39k. Once this is done you have your way in, users won't easily find and disable your script and when working, it will self-heal any changes made by local admins in the GUI every time they start up the Mac.

I don't think that the 'security via obscurity' approach is wise here - what you are proposing could easily be mistaken (?) for malware. My recommendation would be to leave the file in plain sight and put a comment at the top of it saying something along these lines:

# This file has been installed by XXX with the authority of the CTO (memo ref/date). Its purpose is to allow

# remote management and maintenance of this machine and removing it or interfering with its functioning

# without the written authority of a C-level executive is a serious disciplinary offence.

Some countries have privacy laws that even extend some protections to individuals using their employer's machines, so you need to make sure that whatever you do complies with these as well. It's also good practice to ensure that the login screen of all machines with this sort of spyware setup on them makes it clear that the use it being monitored.

C.

I'm not budging on hiding scripts. There is a clear need to manage the system by the department responsible for doing so here. Stating or quoting policy is secondary to the goal of getting these computers managed. The script should be out of reach and preferably out of view of end users or they'll sudo rm -rf it off the hard drive. If they're savvy enough to know what to look for an find it they'll remove it.

I don't think I would waste my own time warning people not to push the big red button. Put the button out of reach and behind lock and key- on your own authority to do so as IT.