ARD not active

[rpayne]

While this is not entirely Jamf related, I'm hoping for some help. Here is some info on the machines: I have 2 Mac mini machines in a rack mounted bank. One is a 2016 model, the other is a new 2018 model. The 2016 is on 10.14.3, the 2018 10.14.4.

...and the issue: I can remote into the 2016 remotely (via ARD 3.9.8) and can login at the login window (straight from a power on), reboot, then login fine. On the 2018, if I power on the machine, I cannot see the login window via ARD. I have to login locally THEN I can ARD. This obviously not ideal (it's cold in the server room and I'm not an eskimo). Both machines are set up identical (as far as I can see) EXCEPT the OS build AND the 2016 is not Jamf managed.

Sometimes, in ARD the 2018 will show ARD not active.

[sdagley]

@rpayne Any chance you enabled FileVault on the 2018 mini? If that's the case it's basically a brick until you enter your password on the boot login screen.

[rpayne]

@sdagley Actually yes. Disabling it makes it work again. The problem is though, this is a server and needs to be encrypted, but having to physically log in on every reboot is not an option. Thoughts?

[sdagley]

@rpayne If physically logging in after a reboot isn't an option then neither is FileVault. When you have FileVault enabled the Mac doesn't boot into your main partition, it boots into a recovery/security partition whose purpose is basically to present you a UI showing what accounts are enabled to unlock the main partition, and let you enter the password for one of them. The Mac is not on the network at that point, and no remote access is possible.

[adamcodega]

You can perform authenticated restarts, while logged into the Mac run

sudo fdesetup authrestart

in Terminal.

[sdagley]

@adamcodega While that's good for planned restarts, it isn't going to help with un-planned ones.

[mking529]

Yeah this is a tough one. That login screen you see after FV2 is enabled isn't really the login screen, but rather a nicely presented drive unlock screen. The OS isn't running, hence why you can't remote in. The fdesetup command can help but as others have stated, unplanned restarts are an issue. Also fdesetup is technically bypassing your encryption on a per reboot basis, reducing your security.

I'm not sure how much data you need to protect but you might be able to encrypt just what needs encrypting by storing it in an encrypted file container and mounting those at login, but that has its own limits and annoyances.

[sdagley]

It seems kind of pointless to encrypt a drive that you want to mount automatically after every restart with no user interaction. I'd be more concerned with physical security for that machine/drive(s) than with encrypting them.

[AVmcclint]

I work in a HIPAA security world and as long as servers are behind a locked door with limited physical access, unencrypted drives are allowed. All Mac, Windows, and Unix servers are all expected to be remotely managed at all hours of the night and that is physically impossible if someone has to drive in to the office, unlock a door, and login at a keyboard. You may want to have your security directives re-evaluated to allow unencrypted server drives.