dscl and InstaDMG

[akinspe]

So after an interesting perusal of the dscl man page, combined with some poking around in the SIU bundle, it turns out that you CAN use dscl on a non booted volume. In fact it’s really slick. Simply add a -f “path/to/dslocal/nodes/Default” and a “localonly” option and you can use standard dscl APIs to talk to “/Local/Target”

behold:

dscl /usr/bin/dscl -f “/Volumes/InstaDMG/var/db/dslocal/nodes/Default” localonly -create /Local/Target/Users/admin
dscl /usr/bin/dscl -f “/Volumes/InstaDMG/var/db/dslocal/nodes/Default” localonly -append /Local/Target/Users/admin RealName “Administrator”
dscl /usr/bin/dscl -f “/Volumes/InstaDMG/var/db/dslocal/nodes/Default” localonly -append /Local/Target/Users/admin UserShell “/bin/bash”

etc..

reading the man page you’ll see that dscl creates another instance of the DirectoryServices daemon and then goes to work on that folder structure. You of course could push the files all the same, but this way you get future resistant supported behavior. Combined with creating the right shadow hash and you’re on the way. With this method, the system generates the GUID for you.

In fact. If you want an interesting look at how the imaging process works, you may be surprised to find that in 10.5, it’s mostly done by shell scripts hidden in the automator actions!

If you have the server admin tools installed, check out

/Applications/Server/System Image Utility.app/Contents/Library/Automator/Create Image.action/Contents/Resources/

In particular, the createAdmin.sh outlines creating an account on a non-booted dslocal folder.

Also createNetRestore.sh basically makes a NetInstall image from a booted volume. I’m sure an astute user could adjust it to work with an already ASR’d image.

-Pete-

[Patrick Fergus]

Setting the GUID for a local admin would be a really good idea–that way you can easily change the password of your local admin by distributing a single file (the password hash). But otherwise this would remove one of the packages we’re currently installing on first boot of a freshly imaged machine. Very slick.

You could future-proof yourself further by using the installation shell variables:

dscl /usr/bin/dscl -f $3/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin

– Patrick

[Patrick Fergus]

I’ve retooled our Instauser package using your tip. I was resisting the Leopard (Instauser 10.5) method since whacking admin.plist didn’t seem like a good idea. Now I use dscl -f and just add our local administrator.

Thanks!

– Patrick

[akinspe]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]Setting the GUID for a local admin would be a really good idea–that way you can easily change the password of your local admin by distributing a single file (the password hash). But otherwise this would remove one of the packages we’re currently installing on first boot of a freshly imaged machine. Very slick.

You could future-proof yourself further by using the installation shell variables:

dscl /usr/bin/dscl -f $3/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin

– Patrick[/p][/QUOTE]

Yeah I wrote that real quick, I didn’t even notice that I had two “dscl”s in front. Using the $3 var is the way to go in scripts. If you want the same GUID, then you can just replace it with a known one. That does make pushing out the shadow hash change much easier, but I suppose one could write a package the grep’s out the GUID based on the shortname and writes the file as necessary.

FWIW: I did some testing and simply replacing the shadow hash seems to instantly change the password. Tested via su in terminal at least.

Long live dslocal. It really makes this type of stuff much more flexible.

[Patrick Fergus]

Nuts. I just noticed the command won’t run as we’ve typed it, and it appears I can’t edit a forum post after some amount of time. Anyways, the commands should be formatted as follows:

[code]/usr/bin/dscl -f $3/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin[/code]

– Patrick

[knowmad]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]I’ve retooled our Instauser package using your tip. I was resisting the Leopard (Instauser 10.5) method since whacking admin.plist didn’t seem like a good idea. Now I use dscl -f and just add our local administrator.

Thanks!

– Patrick[/p][/QUOTE]

Out of curiosity, where does this retooled instauser script reside? Do we have to wait for the next instadmg point release to see your work?

[dano]

The tip for using dscl on a non booted volume is good. The only problem I’m having is setting a password on an account I’m generating on a non booted volume using this method.

Using the appropriate command for setting password on account on a booted volume works:
/usr/bin/dscl . -passwd Users/instadmg “password”

whereas using the command for setting a password on account on non booted volumes doesn’t work:
/usr/bin/dscl -f “/Volumes/InstaDMG/var/db/dslocal/nodes/Default” localonly -passwd /Local/Target/Users/instadmg “password”

Any suggestions would be greatly appreciated.
Thanks

[knowmad]

Same Issue Here.

This is what mine looks like:
[code]#adds admin acct
Adminacct() {
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin home /private/var/admin
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin shell /bin/bash
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin uid 11
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin gid 11
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin realname “Administrator”
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Groups/admin
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Groups/admin gid 11
/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -passwd /Local/Target/Users/admin “Password”
}[/code]

And then I call it between apple updates and custom packages.
Account gets created, but cannot login….. suggestions?
(UID and GID are fine… 11 is unused and I tested 501 and other random numbers just in case)

[dano]

The issue is the command to generate a password doesn’t work. All the other commands to generate the various account keys work. If one boots from the install DVD and uses the password reset utility to change the password, it is possible to successfully login to the account.

[Patrick Fergus]

Although I can’t speak to setting the password via dscl -f, you can sidestep the issue by installing the appropriate hashed password and setting the “admin” user’s generateduid to match. Install the file here (substituting the appropriate UUID):

[code]/var/db/shadow/hash/BE532A71-08EA-4D68-8C02-91046BD32B90[/code]

and tack something like the following onto your script:

[code]/usr/bin/dscl -f /Volumes/InstaDMG/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin generateduid BE532A71-08EA-4D68-8C02-91046BD32B90[/code]

That will let you set the password at InstaDMG time.

– Patrick

[knowmad]

What if, instead of putting in a UUID, you let DSCL (in -f mode) generate a UUID and THEN set the password?
I am not 100% clear on the series of events required to properly set a password via DSCL, but I get the feeling that in order to properly create a hash, it needs a UUID, theoretically if it were running locally it would just do that, but since it is running on a non booted machine, it does not create one (UUID) unless strictly told to do so, even when told to create a password, thus setting the password does not fully work….. of course that is conjecture as I am not even certain where to check my guess against reality except to try it…..

and while looking that up (or trying to) I came across this in the DSCL man pages:

[code] passwd
Usage: passwd user_path [new_pasword | old_password new_pasword]

Changes a password for a user. The user must be specified by full path, not just a username. If
you are authenticated to the node (either by specifying the -u and -P flags or by using the auth
command when in interactive node) then you can simply specify a new password. If you are not
authenticated then the user’s old password must be specified. If passwords are not specified
while in interactive mode, you will be prompted for them.
[/code]
Which, while not completely applicable, makes me feel that maybe I should be using an authenticated instance of dscl to work on a local node?

Anyway, I was specifically looking for a list of keys, to see if you could generate the UUID by simply telling dscl to create a UUID without telling it what to set it to….
I am off tot he apple KB for more info.
(edited for typos)

[Patrick Fergus]

Having the your local admin’s UUID the same on all deployed machines is going to make your life easier. Want to change the admin password? Distribute a new password hash.

You can test to see if the UUID matters in the password hashing–create two accounts on a Leopard Mac and set the password to the same thing. Compare the hash files–obviously the password hash isn’t English-readable but the password hash either will or won’t match. Regarding setting the password with passwd, I feel that’s probably plumbed directly into the startup disk’s dslocal/NetInfo. I doubt you could change the password on another disk.

I’d strongly suggest just putting the password hash in the right place and being done with it.

– Patrick

[dano]

After a little more experimenting I’ve determined that the contents of the password hash file is strictly password information. There is no UUID link to the contents of the hash file. The name of hash file, however, must be the account’s UUID. It would appear that he following sequence of events happens when an account is generated:

1. After inputting user name and password information, an account is generated with appropriate keys including the randomly generated UUID.
2. A file is created using the account UUID as th file name and saved to /var/db/shadow/hash
3. The password is “hashed” and the resulted is saved to the file created in the previous step

I’ve also determined that one can take any hash file and attach it to any user account as long as the name is changed to the UUID of the account it is being attached to. I haven’t figured out how to generate a password hash but do check out the sample script specified by the initial post of this thread (posted by akinspe )

[akinspe]

[QUOTE][u]Quote by: dano[/u][p]I’ve also determined that one can take any hash file and attach it to any user account as long as the name is changed to the UUID of the account it is being attached to. I haven’t figured out how to generate a password hash but do check out the sample script specified by the initial post of this thread (posted by akinspe )[/p][/QUOTE]

This is precisely what this script is for. It simply generates the bits and you pipe the output to the appropriate file which is the UUID of the user you need.

In fact I am thisclose to finishing a package that will assist in automating the creating of a user and their password in package format for both 10.4 and 10.5. and is flexible to adjust to any particular policy you might have (same UUIDS, different, auto UIDs, specific, etc. Plus it won’t use clear text passwords if you pre-gen a hash so it’s slightly more “secure”

Anyway, I hope to have it cleaned up and up next week.

[jwestlake]

Hey all,

Resurrecting a thread of yore… I’m trying to figure out a way to change the Search path on a non-boot volume using some of the commands in this thread, but I can’t seem to access that info any way from the volume I am booted into. Tried:

dscl -f /path/to/my/dslocal/nodes/Default localonly -read /Local/Target/Search /

but I just get a blank prompt back. I want to make sure Active Directory comes before LDAPv3 in my search order. I’m imaging machines using DeployStudio, binding them to AD and OD and I want to make 100% sure that AD is 1st for authentication (after local).

Any ideas?

Thanks in advance!

Jason

[Author]

Posts