ARD intermittently not allowing AD authentication

[gmce87]

Hi, I've got users who are intermittently unable to access computers via ARD. We've set up an AD security group e.g. MYDOMAINAllowRemoteDesktop and then created a local ard_admin group on each machine and linked this security group to it using dseditgroup. Users then connect via ARD and authenticate with their domain accounts.

This has worked without issue for several months, however recently I've been having more and more users reporting issues with this no longer allowing them to connect to random machines, getting an "Access Denied" error.

Below is the script that we've been using to create the local group and bind it with the AD group.

#!/bin/bash
# Script to enable Active Directory logins for Apple Remote Desktop

# Enable directory logins on Apple Remote Deskop
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setdirlogins -dirlogins yes

# Grant access to Apple Remote Desktop by creating a local “ard_admin” group, and linking an AD security group to it
dseditgroup -o create ard_admin
dseditgroup -o edit -a 'MYDOMAINAllowRemoteDesktop' -t group ard_admin

exit 0

I've tried re-running this script on several machines which have the issue, however the issue persists. I've also tried the command below which I've found from searching blogs etc about this issue, but it doesn't seem to make any difference.

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -privs -all -users ard_admin -restart -agent

I've tried creating a second local group called ard_allowed on a test machine and bound the same security group to it, but this fails also.

My understanding is that none of the members of this security group are able to connect to the affected machines, however there are other machines which ARD is continuing to work on without issue.

If I use dseditgroup to read the ard_admin group, I see the below which indicates that the group has definitely been nested correctly, (I've used mm2270's script shared in this post to confirm the nested group name is correct) however users are still experiencing issues.

iMac:~ root# dseditgroup -o read ard_admin
dsAttrTypeStandard:GeneratedUID -
                2634ED0F-6D39-4C19-8A79-0E8E27942CF7
dsAttrTypeStandard:PrimaryGroupID -
                501
dsAttrTypeStandard:RecordName -
                ard_admin
dsAttrTypeStandard:RecordType -
                dsRecTypeStandard:Groups
dsAttrTypeStandard:NestedGroups -
                F0FA67BC-9246-4DB3-A412-8771F05CB3A4
dsAttrTypeStandard:AppleMetaNodeLocation -
                /Local/Default

I can't find much else about this online when I'm searching Google, has anyone got any advice on what else I could try to resolve this?

Thanks

[hkabik]

Does the AD user you are attempting to ARD in as have a mobile account on the machine you are attempting to ARD into? I've found that stops ARD access in my environment.

[gmce87]

No, we're not using mobile accounts in our environment currently. Just to be sure though I've checked the local users list on the machine using dscl and there's no sign of their username, so I believe it's only a domain account they're logging in with, unless I'm mistaken? My understanding is that if mobile accounts are in use, a local user account gets created when they log in with a domain account, is that right?

[hkabik]

That is correct, they would have a home folder in /Users.

[esummers]

On Mohave, make sure ARD was manually turned on in System Preferences > Sharing > Remote Management or it will not be fully enabled. Alternatively use an ARD config profile: https://support.apple.com/en-us/HT209161. The config profile requires the machine is DEP enrolled or user approved for UAMDM.

Login issues from only some users are sometimes related to messed up or missing password hashes in their user record. Try telling a user with issues change their password to update all the hashes to see if it helps.

Here is the script I use. Change MYDOMAINMyARDGroup to the proper AD group. Don't call the AD group ard_admin so it is distinct from the local group. This script was tested on macOS 10.14.4

#!/bin/bash

# Create a local group
dscl . -create /Groups/ard_admin
dscl . -create /Groups/ard_admin PrimaryGroupID "530" 
dscl . -create /Groups/ard_admin Password "*" 
dscl . -create /Groups/ard_admin RealName "ard_admin" 
dscl . -create /Groups/ard_admin GroupMembers "" 
dscl . -create /Groups/ard_admin GroupMembership ""

# Nest the AD group you want to have ARD access to the ard_admin group.
dseditgroup -o edit -a "MYDOMAINMyARDGroup" -t group ard_admin

# Give the group the necessary privileges via the ARD Kickstart command.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -privs -all -users ard_admin -restart -agent

# Make sure access is only allowed for ard_admin group.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers

# Set the ARD client options to allow directory services (including Active Directory) logins.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setdirlogins -dirlogins yes