Remotely Approving UAMDM

With the release of 10.13.2, Apple introduced a new “feature” called User Approved Mobile Device Management Enrollment (UAMDM), which withholds certain privileges from the managing MDM until manual action, by the device user, “Approves” the right to those privileges. Apple also made it quite difficult to perform this approval remotely, with the intent that the user of the machine would have to in fact agree to these extra capabilities. This poses an issue for MacAdmins who are managing fleets of Apple devices, especially those who may not have all of their devices in a centralized location, may not have an MDM setup, or may not have DEP for devices coming in, even if they do have an MDM setup.

As I’ve talked about previously, we’re in the middle of an MDM migration over to AirWatch. Because of this, we have (selfishly) been telling our customers to hold off on upgrading their machines to 10.13.x. In our defense, up until 10.13.2, it was primarily due to stability and security concerns. But at this point, we really are just trying to have them wait so that we can avoid UAMDM troubles once we are ready to enroll their machines into our new MDM.

We are also performing our migration in as much of an automated way as possible, which means installing the MDM profile directly on the machines via a package. This means that for any 10.13 machines that are already in our fleet, we will need to figure out a way to click that pesky “Approve…” button in order to reap all of the MDM goodness that we have at our finger tips.

Taking from what I learned about trying to automate the AirWatch location services in this post, I decided to see if we could do the same kind of thing here, by using AppleScript to send button clicks on our behalf in order to Approve UAMDM. From that post we can recall that fully automating this process is essentially impossible, since we can’t authorize Script Editor.app to have the “Accessibility” access it needs to send button clicks. But it might just allow us to at least approve UAMDM remotely, which is a heck of a lot easier and faster to do than sneaker-netting to all of our 10.13 machines, especially since we are a geographically distributed organization. Side note: Have an intern? This could be a great project if you have lots of non-UAMDM machines in your fleet!


If you just want to get the script and give it a shot, you can find it on my GitHub here along with the basic instructions: https://github.com/jbaker10/Remotely-Approving-UAMDM

Giving Ourselves over to Script Editor

As mentioned above, before we really do anything further, we might as well go ahead and grant Script Editor.app the necessary permissions it needs in order to help us. I also verified that this can be done remotely using Screen Sharing.

  1. Open System Preferences –> Security & Privacy
  2. Select the Accessibility option in the left column
    Screen Shot 2018-02-18 at 2.09.06 PM.png
  3. Click the plus (+) button to choose the app we want to allow, which in this case is under /Applications/Utilities/Script Editor.app
    Screen Shot 2018-02-18 at 2.09.18 PM.png
  4. Wonderful! We should now see that Script Editor has the necessary permissions to move forward!
    Screen Shot 2018-02-18 at 2.09.23 PM.png

Don’t Forget the “…”!

Now that Script Editor is authorized to have some additional rights to our machine, we need to start the process of finding out where the “Approve…” button is in the context of the UI. Upon enrolling a 10.13.2 (or higher) device into an MDM via something like a package or using the profiles command, if you open the “Profiles” preference pane, you will see the following screen advising you that not all MDM functionality is yet available for the device.
Screen Shot 2018-02-18 at 1.59.56 PM.png

This, ladies and gentlemen, is UAMDM. As most already know, trying to click that “Approve…” button via something like ARD or Screen Sharing results in the following alert: Profiles cannot be approved while using remote or automated input methods.
Screen Shot 2018-02-18 at 1.54.55 PM.png

Well, we’ll see about that.
well see.gif

Let’s load up the Accessibility Inspector.app, and take a look at the UI Hierarchy.
Side Note: There are instructions on finding and using this tool in the post about Automating Location Services, so I will not be covering them here.

Using Accessibility Inspector, if we choose the “Approve” button in the Profiles preference pane, we can get the hierarchy of visual attributes, which we will need to write our AppleScript.
Accessibility Inspector.png
We can quickly see a few things that will be important. 1. The “Approve” button is actually “Approve…”, with an ellipsis included at the end. 2. We can see that it is an nested attribute in a “scroll area” that does not have a name or description, which may make this just a little harder. Other than those important little details, we can see that as expected, the scroll area is nested within the “Profiles” window, which is nested in the “System Preferences” application. Great, now we have the necessary components to write our script!

Again, borrowing from what we learned previously, we know that we have to send the button click that we are trying to automate to the “System Events” process, and then from there to the actual application, in this case “System Preferences”. Therefore, we know the starting of the script should look something like this:
Screen Shot 2018-02-18 at 2.48.35 PM.png

From there, we just need to fill in the juicy bits, including the window (“Profiles”), the scroll area (no description), and the button (“Approve…”). However, sending the button click to the scroll area proved more difficult than I realized it would. I didn’t know what to call it when trying to “talk” to it, and went through several iterations. Turns out, it’s easier to just ask the application itself what to call it. We can do this by using a get command within AppleScript, and ask for the UI elements within a window. So our next iteration of the AppleScript was as so:
Screen Shot 2018-02-18 at 2.53.27 PM.png

This spit out a result like so:
Screen Shot 2018-02-18 at 2.54.52 PM.png

I’ve highlighted the two “scroll areas” that the command found. But we still don’t know which one is which. There are two scroll areas in the “Profiles” preference pane, the one on the left that lists all of the profiles installed, and the one on the right, which typically shows the description of the profile, as well as what settings the profile manages. You would think that “scroll area 1” would be the left column, based on how we read left to right, and therefore count as we go. Turns out, not so. If we do another get of the scroll areas to see what kind of UI elements they contain, we can try to figure out which scroll area corresponds to which column in the preference pane. Let’s first query scroll area 1 and see what it contains:
Screen Shot 2018-02-18 at 3.01.46 PM.png

And would you look at that, scroll area 1 is actually the right side scroll view, containing the attributes about the profile, including our “Approve…” button. So this is great news, we now know exactly where we need to click the button, with regards to what is nested in where. This leaves us with a script looking like so:
Screen Shot 2018-02-18 at 3.04.15 PM.png

And would you believe it, this worked! Apple tried to get in our way and add a second prompt to really make sure the user wanted to give their soul over to the MDM, but using the same techniques we did above, we were able to overcome that quite quickly:
Screen Shot 2018-02-18 at 3.06.06 PM.png

The final script ended up looking like this:
Screen Shot 2018-02-18 at 3.07.17 PM.png

Putting It All to the Test, Remotely!

I have reworked the script a few times now to try and handle a few different scenarios and still work. Below is a screenshot of the end result of the script at this time:
Screen Shot 2018-02-19 at 1.11.11 PM.png

So now that we’ve got ourselves a bona fide working AppleScript that will approve our UAMDM for us, does it work remotely? I opened up Screen Sharing and opened a remote session into the VM I was working on, held my breath, and clicked the Play button in Script Editor…

It worked! This may not be the cleanest, nicest, fanciest, or really even good way of doing this, but it is a way. You could theoretically take this method and remote into (remember that intern I recommended?) every non-UAMDM machine you have in your fleet, and get them “UAMDM’d”!

One of these days, I might actually try to learn the Objective-C ways of doing these kinds of things, but for now, Apple Script will have to do!


14 thoughts on “Remotely Approving UAMDM

  1. I’m getting an error when I try the same code “error “System Events got an error: Can’t get button \”Approve…\” of scroll area 1 of window \”Profiles\” of application process \”System Preferences\”.” number -1728 from button “Approve…” of scroll area 1 of window “Profiles” of application process “System Preferences””. Although it’s late so highly likely something I’ve done!

    But that aside, thanks for sharing the code. Apple remote desktop can push applescript code so I wonder whether you could run the whole process on a bunch of Macs at once?


    1. I wasn’t very clear, and the script currently isn’t very smart. You have to have already opened System Preferences, navigated into the Profiles prefPan, and selected the “Device Manager” profile. I’m going to work on seeing if I can get the AppleScript to do some of that, and I’ll update the post to make that more clear. Let me know if that helps though!


    2. I updated the AppleScript to now be a bit smarter. It will not open System Preferences for you, click the “Profiles” prefPane, and click the “Device Manager” profile before clicking the Approve button. Let me know if that helps at all!


    3. I have same issue… increased delays, and no luck :/
      And because of unknown reasons Accessibility Inspector does not allow me to inspect anything (despite being listed in Accessibility Security Settings).


      1. Are you using the latest version from the Github? Unless you’re clicking (stealing focus) while the script is running, it should be somewhat robust at handling opening SysPrefs, and/or getting to the proper PrefPane, etc.

        You also shouldn’t need Accessibility Inspector.app authorized in the Accessibility database, it just looks at attributes of objects (buttons, labels, etc.). You _do_ however need the Script Editor.app authorized in order to run the script successfully.


      2. I’m using part of it.

        tell application “System Preferences” to activate

        tell application “System Events”
        tell application process “System Preferences”
        set currentWindow to name of window 1
        if currentWindow does not contain “Profiles” then
        click button “Show All” of group 1 of group 2 of toolbar 1 of window 1
        delay 5
        click button “Profiles” of scroll area 1 of window “System Preferences”
        delay 5
        end if

        tell window “Profiles”
        tell scroll area 2
        repeat with aRow in row of table 1
        if value of static text of UI element 1 of aRow ends with “Enrollment” then
        select aRow
        delay 1
        end if
        end repeat
        end tell
        click button “Approve…” of scroll area 1
        click button “Approve” of sheet 1
        end tell
        end tell
        end tell

        tell application “System Preferences” to quit

        I “push” this file over ssh to client (VM) using echo -e “{scriptContent}” >> something.scpt and then run it using osascript.


      3. If I recall correctly, you can’t authorize osascript to have Accessibility authorization. Can you try running the script interactively on a machine and see what the error is? My guess is that you’re trying to run it and it’s failing because it needs the Accessibility authorization, which you can’t do without manually doing it via the GUI.


      4. I don’t need to authorize osascript, during first run I was prompted to add sshd-keygen-wrapper. I did that and no other prompts were displayed.
        Regardless how I run it (ssh or VNC) I always get:
        approveScript.scpt:825:867: execution error: System Events got an error: Can’t get button “Approve…” of scroll area 1 of window “Profiles” of application process “System Preferences”. (-1728)


      5. Well based on the error, it seems it’s getting all the way to trying to actually Approve the MDM, but not finding the button. Without seeing it it’s fairly impossible to know the state of the computer and the state of the profile, etc.


      6. I solved it… most likely library I was using to push script over ssh messed up non-printable characters…
        When I curl-ed it from github it worked like a charm!


    1. Hi Mike — No, the Accessibility database is SIP protected, so there is no way to fully automate this solution, there will always have to be some manual intervention to do it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s