myrkridianrhapspody

Q: ARD Settings via Profile Manager

Hello all,

 

Trying to solve an issue here. At my current institution, all users are local admins. This means they can pretty much change anything on the machine, except that I have profile manager pushing settings to the machines which they cannot change. Thus, I was hoping to have all of the settings that I don't want them to be able to override coming from profile manager. This has worked pretty well, and I have found the "configure custom settings" option in Profile Manager to be super helpful here. On to my question: a small number of users turn off Remote Management in system preferences because they they don't like the idea that I can remote in to any machine. It isn't really up to them (as their admin it's kind of up to me) but at this point I haven't been able to stop them. I was really counting on the fact that I could configure a custom setting for the ARD agent that would prevent them from turning anything off. My searching however has caused me to conclude that the ONLY way to create settings for the ARDagent (other than from the GUI in System Preferences > Sharing) is to use the kickstart command via the command line. This just seems kind of impossible to me, as I would expect there to be a plist somewhere that contains this information that I can push out to all machines and lock in place. Wondering if anyone has any ideas on this. Thanks!

Posted on Oct 8, 2015 7:31 AM

Close

Q: ARD Settings via Profile Manager

  • All replies
  • Helpful answers

Page 1 Next
  • by keithfromvirginia beach,

    keithfromvirginia beach keithfromvirginia beach Oct 9, 2015 6:41 AM in response to myrkridianrhapspody
    Level 1 (20 points)
    Mac OS X
    Oct 9, 2015 6:41 AM in response to myrkridianrhapspody

    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.

  • by myrkridianrhapspody,

    myrkridianrhapspody myrkridianrhapspody Oct 9, 2015 6:57 AM in response to keithfromvirginia beach
    Level 1 (4 points)
    Oct 9, 2015 6:57 AM in response to keithfromvirginia beach

    The only viable option I can come up with is to 1) incorporate ARD settings into the base image (which I have already been doing) and 2) hide the Sharing preference pane from the user so they are not able to go in and make changes. I'm not sure what else can be done.

  • by keithfromvirginia beach,

    keithfromvirginia beach keithfromvirginia beach Oct 9, 2015 7:03 AM in response to myrkridianrhapspody
    Level 1 (20 points)
    Mac OS X
    Oct 9, 2015 7:03 AM in response to myrkridianrhapspody

    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.

  • by keithfromvirginia beach,

    keithfromvirginia beach keithfromvirginia beach Oct 9, 2015 7:07 AM in response to keithfromvirginia beach
    Level 1 (20 points)
    Mac OS X
    Oct 9, 2015 7:07 AM in response to keithfromvirginia beach

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

  • by myrkridianrhapspody,

    myrkridianrhapspody myrkridianrhapspody Oct 9, 2015 7:13 AM in response to keithfromvirginia beach
    Level 1 (4 points)
    Oct 9, 2015 7:13 AM in response to keithfromvirginia beach

    You can just use a .cmd file that asks for credentials and utilizes the kickstart command. For example, I run:

     

    sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/k ickstart -activate -configure -access -on -users USERNAME -privs -all -restart -agent -menu

     

    With USERNAME being your admin account. I have it all set up on the base image though, not as a post-install script.

  • by keithfromvirginia beach,

    keithfromvirginia beach keithfromvirginia beach Oct 9, 2015 7:15 AM in response to myrkridianrhapspody
    Level 1 (20 points)
    Mac OS X
    Oct 9, 2015 7:15 AM in response to myrkridianrhapspody

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

  • by myrkridianrhapspody,

    myrkridianrhapspody myrkridianrhapspody Oct 9, 2015 7:19 AM in response to keithfromvirginia beach
    Level 1 (4 points)
    Oct 9, 2015 7:19 AM in response to keithfromvirginia beach

    Check out this page:

     

    Apple Remote Desktop: Configuring remotely via command line (kickstart) - Apple Support

     

    In Teminal, type for help:

     

    sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/k ickstart -help

  • by keithfromvirginia beach,

    keithfromvirginia beach keithfromvirginia beach Oct 9, 2015 7:32 AM in response to myrkridianrhapspody
    Level 1 (20 points)
    Mac OS X
    Oct 9, 2015 7:32 AM in response to myrkridianrhapspody

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

  • by myrkridianrhapspody,

    myrkridianrhapspody myrkridianrhapspody Oct 9, 2015 7:42 AM in response to keithfromvirginia beach
    Level 1 (4 points)
    Oct 9, 2015 7:42 AM in response to keithfromvirginia beach

    Not being dense... you wouldn't actually do this via PM, and I'm not sure you can. If you could find a way, you would solve the thread! The only possible way would be to somehow use the login hook, but from what I hear that's deprecated and also a bit complicated. The way I do it is I run the command on my base image, capture the image and then use that image on all new machines. You could use something like deploystudio to do this. You could also run a script via deploystudio although I believe scripts in deploystudio do not allow user input (which sudo would invoke). Otherwise, just create your script and run it on each machine as part of the post setup, when you are installing your profiles. This way you don't have to going into system prefs > sharing and start clicking boxes and whatnot. If you don't want to (or know how to) create an executable then just copy/paste your particular kickstart commands into terminal. I do that from time to time.

  • by myrkridianrhapspody,

    myrkridianrhapspody myrkridianrhapspody Oct 9, 2015 7:47 AM in response to keithfromvirginia beach
    Level 1 (4 points)
    Oct 9, 2015 7:47 AM in response to keithfromvirginia beach

    I suppose if you also enable remote login, you could SSH in after the fact and run your scripts so you don't have to spend much time at the machine physically.

  • by keithfromvirginia beach,

    keithfromvirginia beach keithfromvirginia beach Oct 9, 2015 8:03 AM in response to myrkridianrhapspody
    Level 1 (20 points)
    Mac OS X
    Oct 9, 2015 8:03 AM in response to myrkridianrhapspody

    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!

  • by cdhw,

    cdhw cdhw Oct 10, 2015 5:39 PM in response to myrkridianrhapspody
    Level 4 (2,653 points)
    Servers Enterprise
    Oct 10, 2015 5:39 PM in response to myrkridianrhapspody

    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.

  • by Alan Ramos,

    Alan Ramos Alan Ramos Nov 16, 2015 7:23 AM in response to myrkridianrhapspody
    Level 1 (5 points)
    Nov 16, 2015 7:23 AM in response to myrkridianrhapspody

    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

     

    Script

    # set up SSH access in from your admin account

    sudo dseditgroup -o edit -d admin -t group com.apple.access_ssh

     

    sudo dscl . append /Groups/com.apple.access_ssh user <YOUR LOCAL ADMIN ACCOUNT>

     

    sudo dscl . append /Groups/com.apple.access_ssh GroupMembership <YOUR LOCAL ADMIN ACCOUNT>

     

    sudo dscl . append /Groups/com.apple.access_ssh groupmembers `dscl . read /Users/<YOUR LOCAL ADMIN ACCOUNT> GeneratedUID | cut -d " " -f 2`

     

    sudo systemsetup -setremotelogin on


    # set up ARD to allow access to your account

     

    sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/k ickstart -configure -allowAccessFor -specifiedUsers

     

    sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/k ickstart -configure -users nsadmin -access -on -privs -DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings

     

    sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/k ickstart -configure -activate -restart -console


     

    exit 0

     

    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.

  • by cdhw,

    cdhw cdhw Nov 16, 2015 10:43 AM in response to Alan Ramos
    Level 4 (2,653 points)
    Servers Enterprise
    Nov 16, 2015 10:43 AM in response to Alan Ramos

    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.

Page 1 Next