Accessing Remote Mac - Questions

[MTFIDjamf]

All -
Facing something new in our environment. We are almost 100% a Mac Air shop. Basically each device has one assigned AD user. A remote site in Europe is planning on purchasing and building out two Mac minis soon. Both will be headless and locked up in a server room after they are imaged. Multiple domain users will need to access them to run development tools.

Questions:

1. After these are imaged and locked up, how do I get AD users to login and create a profile? There is no way each user can login at build time as they are all over the globe.

2. Do users need to login to create the profile? Is it possible to create an AD based profile ahead of time?

3. What would be the best (free) method for the multiple users to connect to these devices? I understand that ARD exists, but it is doubtful each user will get the OK to purchase the App.

4. If all goes well and they can connect and create profiles, will encrypting with Filevault cause remote accessibility issues?

Any help here is greatly appreciated.

[Rosko]

Screen Sharing is built in to each mac, can you use that?

And if I remember right there is a way to add the user to a mac ahead of time from terminal, but I dont have the command handy...

[mm2270]

You can add AD based accounts ahead of an actual login using the createmobileaccount binary in a script.

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount

[MTFIDjamf]

@Rosko Does screensharing merely shadow a currently logged in user's session or would login the person attempting to control it as a fresh login/account? Any idea?

@mm2270 Very interesting. Would you happen to have any examples of an end product of the script or know of somewhere I could view one/some?

[mm2270]

@MTurnerFMRCO if you just plop the above line into your Terminal and run it, it will send back a help page showing the options for the binary, like this:

usage: createmobileaccount -n username [-h homepath] [-P | [-p password]] [-e] [-q] [[-x] | [-X]] [[-s] | [-S]] [-u syncURL] [-t urlPath] [-d] [-v] 
-n username : user record name.
-h homepath : user home path; Default is "/Users/<username>".
-p password : user password.
-P : prompt for user password. A user password is required to create a FileVault home.
-e encrypt : encrypt new home with FileVault.
-q quota : max size in bytes of FileVault home.
-x : create as external account on non-boot volumes. Default.
-X : create as mobile account account non-boot volumes.
-d : disable external account creation.
-s : set home sync on if home created.
-S : set home sync off if home created. Default.
-u syncURL : server target of home synchronization.
-t urlPath : additional path after syncURL.
-v : verbose output.

Examples:
    createmobileaccount -n jsmith
    createmobileaccount -v -P -n jsmith
    createmobileaccount -vsxn jsmith -h /Volumes/HD3/jhome
    createmobileaccount -vsxn jsmith -h /Volumes/HD3/jhome -u nfs:/server.apple.com/bigs/homes -t myusers/macos/jhome

Notes:
    - createmobileaccount must run as root.
    - If you do not specify a password, the account's cached password will be created during the account's first log in.

The basic idea is, the Mac must be already joined to your domain, then you can add a cached AD mobile account to the Mac using a line like:

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n username -p somepassword

Or you can use the uppercase p (-P) to get prompted for a password to type in. You can also just leave the password blank. It will create the user, but their account password will not get cached. However, as long as the Mac is hardwired to the network or connected in some way at the login screen, when the client logs in, they will be able to get in and their password will get cached. But I don't know if that process would work if they were trying to log into it remotely. I've never tried that honestly.

Lastly, I see no reason to consider using FileVault for these. Not only will it add a layer of complication to the process, if they are going to be locked away in a server room, I don't see the need to encrypt them. That's great for mobile devices. Sort of pointless for devices locked to a desk or a rack.

[Rosko]

@MTurnerFMRCO Yes, ScreenSharing can do some multi-user logins...but it is limited and isn't really aimed at that. If you are planning to have a large amount of users connecting to these Mac Mini's at the same time you may want to consider this product...Aqua Connect

[kstrick]

You can turn on directory based logins in AD... so if they try to login with ARD or Screen Sharing, it will create a profile if they haven't even logged in.