ARD 3.9 admin guide?

AVmcclint
Honored Contributor

Does anyone know where I can find the Apple Remote Desktop 3.9.x admin guide? The latest one I can find on Apple's site is 3.3. I'm trying to enable AD directory services, but the info in the 3.3 guide isn't working, so I assume there's more to it in the newer version.

1 ACCEPTED SOLUTION

Scott_Watkins
New Contributor II

This should cover what you are asking for:

https://help.apple.com/remotedesktop/mac/3.9/#/apdFAB787DA-C7DF-4E2D-9ADA-6F1C22A0EC42

View solution in original post

6 REPLIES 6

Scott_Watkins
New Contributor II

This should cover what you are asking for:

https://help.apple.com/remotedesktop/mac/3.9/#/apdFAB787DA-C7DF-4E2D-9ADA-6F1C22A0EC42

AVmcclint
Honored Contributor

oh yeah, duh. I forgot about the Help menu. hmmm It looks like there's even less information in this guide than in previous guides. I'll keep digging.

spalmer
Contributor III

I was just looking at the Help menu version a few days ago as somebody else asked a similar question on the MacEnterprise mailing list. After a quick look through, it appears the online Help guide has been dumbed down as far as enabling the Directory Services goes. It no longer seems to discuss "Method #2" which allows you to add AD users to locally created groups to grant the appropriate ARD permissions.

I had to use this method since we have a specific group naming convention in AD that we have to adhere to meaning we can't use the special AD group names that Apple suggests in Method #1. I don't know why they removed Method #2 as I just tested and it still works with Catalina.

@rtrouton has a very good write up at https://derflounder.wordpress.com/2018/08/22/using-directory-membership-to-manage-apple-remote-deskt... that references the Method #2 that I can't find in the Help guide.

AVmcclint
Honored Contributor

That does look like it would have been helpful a couple years ago. I see a couple things wrong with it now though. 1a) it requires adding accounts that already exist on the Mac to the group?... which defeats the purpose of using Directory services. Maybe I'm misunderstanding how it works. Relevant lines of code:

/usr/bin/id "$arduser"
if [ $? != 0 ]; then
   echo "Unable to set specified Apple Remote Desktop permissions!"
   echo "$arduser account not found on this Mac."
   error=1
   exit "$error"
else
   echo "$arduser account verified as existing on this Mac. Proceeding..."
fi

1b) What I need is for all users in the ard_admin AD group (which will be tightly controlled) to be able to control all the Macs. If I understand this script, I'd have to manually add one account at a time to the LOCAL group... but then as we added and removed people from the group in AD, I'd still have to manually update it every time. 2) Even creating the groups manually in System Preferences doesn't work. I tried creating com.apple.local.ard_admin on a Catalina Mac and it told me that group name was not available. I used dscl to look in the Local groups and that name does not already exist, so I'm not sure why the name is unavailable. How did you get method 2 to work in your environment? I honestly believe Apple has ONE GUY working on ARD... part time. And this one guy doesn't know how to fully document this product. Documentation has always been sparse and confusing. The man page for the kickstart command is barely helpful.

spalmer
Contributor III

I should have clarified that I don't use Rich's exact setup. Basically, what I do is have a script that users run through Self Service. This script gets the current logged in user, verifies the proper group exists (and creates it if it doesn't) then adds the current user to that local group.

Here is my RemoteManagementARD-enableForCurrentADUser.sh script:

#!/bin/bash

# Grab the currently logged in user
ObjectName=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`

# Enable AD auth for Apple Remote Desktop
echo "Enabling AD authentication for Apple Remote Desktop…"
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setdirlogins -dirlogins yes

# Create the ARD Interact group which allows Control and Observe
dseditgroup -n /Local/Default com.apple.local.ard_interact
if [ $? != 0 ]
then
    echo "com.apple.local.ard_interact group does not exist.  Creating…"
    dseditgroup -n /Local/Default -o create com.apple.local.ard_interact
else
    echo "com.apple.loca.ard_interact group already exists"
fi

# Add the user's AD Account to the new group
echo "Adding user $ObjectName to com.apple.local.ard_interact…" 
dseditgroup -n /Local/Default -o edit -a $ObjectName -t user com.apple.local.ard_interact

# Verify the user's AD Account is a member of the group
echo "Verifying $ObjectName is a member of the com.apple.local.ard_interact…"
dseditgroup -n /Local/Default -o checkmember -m $ObjectName com.apple.local.ard_interact

As long as your Mac is still bound to AD, dseditgroup can work with AD users. This script does not validate whether your AD binding is still valid so if something is hosed with your binding it will fail.

I only scope this to specific Macs in Self Service for users that request it. This way we can vet what users actually need it for and verify there isn't better solution to do what think they need to do remotely. We don't really have as much of a need for it any more since a majority of our users have laptops now.

mhegge
Contributor III

ARD has become so unreliable for me. One second I can remote to a computer, the next I cannot (same computer). Frustrating as I rely on this product.