Enabling Root User

[thegooch49]

Hi gang, I’ve been working hard on instaDMG for the past week. I’m happy to say, it’s working great so far (in my limited testing). One last piece that I need to do, is to enable the root user, and set a password for it. I have a highly modified script that creates a local admin account, forces GUID, sets the hash, etc, but I need the root account configured. From what I have read, dscl is NOT used for configuring root. This needs to be done from Directory Utility.

Anyone have any ideas how to script this? Ideally, I do not want the password in plain text anywhere, and I want it changeable via ARD. I have accomplished both of these with my local administrator account, but I’m in the dark with root. Thanks for any help!

PS: I am aware of the ‘dangers’ in enabling the root user, and I don’t need a lecture on why it’s ‘bad’ 🙂

Thanks again!

[thegooch49]

Hi, I actually found the answer to part of my question. This is set using the command: dsenableroot

I can obviously enter it in a script that will set this at first bootup, but I’m not sure how to set the password. I can’t have it shown in a script that is plain text. My user create script forces a specific GUID, and I then place a pre-configured password hash in /var/db/shadow/hash. This should work the same way, since root’s hash password is in there as well. It looks like in 10.5 root’s GUID is not random, so it should automatically be the same (without me having to set it).

Anyway, I’ll post results when this is done, and let you know if it’s successful.

[pteeter]

Anyone care to comment on a strategy for enabling root in Tiger?

It appears that an entry for root exists in /NetInfo/Users from first boot, but the entry has no GeneratedUID.

If dsenableroot is run, the GeneratedUID is *not* standard as in Leopard, thus making it challenging to create the hash file with the correct name.

Is there a way to pre-determine what the GenUID will be?

I suppose one could run dsenableroot with a dummy password, then copy in the ‘real’ hash file. Problem there is that the local admin user password would have to be hardcoded into the script. Kind of bad.

[thegooch49]

Hi, I actually got this figured out in my image. I modified my instaDMG script to enable root. There are a couple mechanisms here. First, instaDMG installs the password hashes in a temporary spot on the HD. I put them here:

/var/db/shadow/hash/RootHash
/var/db/shadow/hash/TempHash

When the instaDMG script runs at bootup, it creates a user called locadmin. It then adds locadmin to be an admin. It then enables root with the dsenableroot command (see below). It uses the locadmin password that is in the script in plain text. Once that is done, I overwrite the hash for both locadmin AND root with my custom hash form the temporary locations (see above).

Although the locadmin password is in plain text in this script, it’s immediately overwritten with the hash containing my real password. So my actual password is never hanging around as plain text. This has worked wonderfully for me.

[code]#Make the account
/usr/bin/dscl . -create Users/locadmin
/usr/bin/dscl . -create Users/locadmin home /Users/locadmin
/usr/bin/dscl . -create Users/locadmin shell /bin/bash
/usr/bin/dscl . -create Users/locadmin uid 501
/usr/bin/dscl . -create Users/locadmin gid 501
/usr/bin/dscl . -create Users/locadmin realname “Local Admin”
/usr/bin/dscl . -create Groups/locadmin
/usr/bin/dscl . -create Groups/locadmin gid 501
/usr/bin/dscl . -passwd Users/locadmin “temppass”

#Make this useful! Add locadmin to the admin group
/usr/bin/dscl . -append /Groups/admin GroupMembership locadmin

#Enable root, using the bogus password before it’s changed
/usr/sbin/dsenableroot -u locadmin -p temppass -r bork

#Force GUID upon locadmin account
#This allows a hash file to be put in /var/db/shadow/hash
/usr/bin/dscl . -create Users/locadmin generateduid 000F740-88B5-4F3D-9AFC-86S61CBD1495

#Move the hash to set the password for the locadmin
cp /var/db/shadow/hash/TempHash /var/db/shadow/hash/000F740-88B5-4F3D-9AFC-86S61CBD1495

#Move the hash to set the password for the root account
cp /var/db/shadow/hash/RootHash /var/db/shadow/hash/FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000[/code]

[thegooch49]

Oops, I just read that you are looking for info in Tiger (not leopard). Sorry.

[pteeter]

No worries, thanks for the suggestions.

I think I have identified that I can set the GeneratedUID to a value of my choosing…perhaps the same value Leopard uses?

Then add the AuthenticationAuthority entry.

Then copy in the hash file to /var/db/shadow/hash.

I think it works…will test more.

[pteeter]

Packaged and ready to go.

Tested on Tiger.

Will test on Leopard shortly.

I think the method I’m using is somewhat more in-line with what Joel suggested earlier in the thread.

[Patrick Fergus]

Pulling up an old thread, but this is where it best makes sense.

I got a question regarding exactly how I enabled root in one of our InstaDMG builds. IIRC, enabling root really only does three things:

1. Edits the user record at
/var/db/dslocal/nodes/Default/users/root.plist

2. Places a password hash at
/var/db/shadow/hash/FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000

3. Adds root to the admin group at
/var/db/dslocal/nodes/Default/groups/admin.plist

#1 and #2 can be done by putting preconfigured files in the right spots on the destination disk (you should be able to scoop up usable versions of files from a machine after enabling root).

#3 can be done from a postflight script in an installer package as follows:[code]/usr/bin/dscl -f $3/var/db/dslocal/nodes/Default \
localonly -append /Local/Target/Groups/admin \
GroupMembership root[/code]Code inspired by this post:

[url]https://www.afp548.com/forum/viewtopic.php?forum=45&showtopic=19941[/url]

– Patrick

[Greg Neagle]

Why exactly are people enabling root?

I have never done so, and have never found a need to do so.

What are your reasons for doing it?

[Patrick Fergus]

Ours is enabled in our NetBoot Utility build. The original reason was that NetRestore (3.2 at the time, now 3.3.6) has a bug/quirk under Tiger which is as follows:

– NetBoot
– Log in as an admin
– Launch NetRestore
– The padlock next to the “Restore” button was dimmed [i]and[/i] unlocked. You couldn’t authenticate to perform an ASR restore via NetRestore. Logging in as root meant you already had that right without authenticating.

It also allows user backups to occur unimpeded, without the occasional “You do not have rights to copy this file” errors.

I’m aware that there are other ways to work around this (using asr from the command line, elevating rights to allow you access to copy/read a file), however I have to make this image usable by technicians who prefer to not descend into the same level of geekiness with OS X that I do.

– Patrick

[Author]

Posts