ARD kickstart, uid lower than 500?

[pteeter]

So this is a fun revelation.

Using the createUser.pkg that akinspe created (thanks man, works quite well with a few minor tweaks), I spun some InstaDMG images last night to test this morning. Leopard and PPC-Tiger. Both deployed fine and each test workstation boots as expected.

I selected a uid of 499 for my local admin / hidden user account.

Then ran the defaults command on /Library/Preferences/com.apple.loginwindow in a launch daemon to actually hide the ‘less than uid 500’ users.

What I’m finding is…the account is now hidden from ARD too.

Ironic.

So, what to do – resolve to not use a hidden account for ARD purposes? Or unhide this local admin account?

Seems a little surprising that ARD won’t recognize this sub-500 uid account. Anyone think of way to make kickstart/ARD work with a uid lower than 500?

Feel free to correct the error of my ways.

[Patrick Fergus]

Without trying it, kickstart refuses to see the existence of a user whose uid is below 500? Strange.

You [i]might[/i] be able to work around it by assinging the privileges by hand. You’re looking for the “naprivs” key in the user’s account plist (in dslocal). It’s some crazy integer that represents the specific collection of rights–you probably want to set up a user with the correct rights to find out what the integer is.

– Patrick

[pteeter]

Compulsively, a while back I mapped out the integers for the -mask option in kickstart…which correspond directly to the naprivs values of course.

Of course this value is already set in dsattrTypeNative:naprivs for this user, as my kickstart script intended.

Shoot, looks like I’m un-hiding this user with a higher UID.

[Patrick Fergus]

Not sure what the problem is–I did the following:

– Reimaged with my InstaDMG build. Admin is uid 501 and ARD rights are presetup using kickstart at build time (via -targetdisk)
– Edited /var/db/dslocal/nodes/Default/users/admin.plist and changed the uid key to “301”
– Changed ownership on the admin’s home
– Hid users below 500 via the following command:

[code]sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool YES[/code]

– Rebooted, admin user was now hidden
– Was able to connect with via ARD with admin’s login and password, including using kickstart to edit the admin’s rights via an ARD “UNIX Command”

What are you doing?

– Patrick

[pteeter]

I was doing this:

1. create image with InstaDMG, admin uid as 499, user added with akinspe’s createUser.pkg
2. ARD kickstarting and privileges being set by 1st boot LaunchDaemon shell script
3. sub 500 uid’s hid with launchdaemon that runs the same defaults command you mention
4. after image is delivered to machine, on first boot am unable to ARD in…get permission denied

If I login to the freshly imaged machine with kbrd/mouse, am able to login with local admin/uid 499.

Both in Leo & Tiger, ARD/Remote Management is enabled *but* no user has privileges configured.

I am doing this now:

1. create image with InstaDMG, admin uid as 501, user added with akinspe’s createUser.pkg
2. ARD kickstarting and privileges being set by 1st boot LaunchDaemon shell script
3. specific user, the local admin, is hidden with launchdaemon that runs the a similar defaults command – HiddenUsersList -arry “shortname of account to hide”
4. after image is delivered to machine, on first boot am able to ARD in

I think the 2nd process works for me just fine.

Not sure if pros/cons exist between former and latter method.

[Patrick Fergus]

I ran into an issue/error where I was assigning ARD privileges before I actually created the user I was giving rights to. That didn’t work, and resulted in the same setup you describe (ARD on, but no privileges set).

– Patrick

[Patrick Gallagher]

Hiding a user in loginwindow will also hide it from the Accounts System Prefs and ARD config in the GUI. You can still add access for that user using kickstart or by created a client installer. This should be preferred. A big reason to hid an admin user to to prevent end-users (who are also admins) from making any changes to the support admin user, this would include ARD access.

[Dean_Shavit]

[QUOTE][u]Quote by: patgmac[/u][p]Hiding a user in loginwindow will also hide it from the Accounts System Prefs and ARD config in the GUI. You can still add access for that user using kickstart or by created a client installer. This should be preferred. A big reason to hid an admin user to to prevent end-users (who are also admins) from making any changes to the support admin user, this would include ARD access. [/p][/QUOTE]

How about creating a custom installer with Directory-Based administration and putting that into the build train. Then there’s no need to have any local accounts so long as the you (or any other admin) is in the group “ard_admin” on the od master or ad domain controller. Of course, hidden admin accounts are cool for other reasons, but if it’s just ARD access, this will work as well as anything.

[Theilgaard]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]Not sure what the problem is–I did the following:

– Was able to connect with via ARD with admin’s login and password, including using kickstart to edit the admin’s rights via an ARD “UNIX Command”

What are you doing?

– Patrick[/p][/QUOTE]

I’m creating a Custom Client Installer using the ARD administration application. Here I can set up privileges to the various (if more than one) user accounts, I can enable other settings, such as ability for any user to control the screen, IF the current user accepts the call, and also enable network based accounts to control ARD. Much easier, and with more options.

This package is installed as a CustomPKG, no need for me to figure out kickstart commands.

[Patrick Fergus]

Theilgaard,

All of the steps you’re describing are set up via kickstart. However, extracting the kickstart commands and running them by hand allows you to not be tied to an ARD client installer.

For example, the kickstart commands generated by the “Create Client Installer…” in ARD 3.0 are usable in 3.1 and 3.2.1. I’m not sure what the results would be if an ARD 3.0-generated Client Installer would be installed on a machine with ARD 3.1+ already on the computer. The client installer would hopefully skip the client portion and only install the configuration portion.

If the ARD Admin generated Client Installer does what you need it to, great.

– Patrick

[Author]

Posts