magervalp / createuserpkg Goto Github PK

I downloaded version 1.2 and created a package that creates an admin account with a three letter password as a test. Added an image to it, but didn't change UserID or the UUID and don't have Automatic login enabled. Deployed the package through DeployStudio but I couldn't log in to the machine. Tried it once again by recreating another package, different username and three letter password, same result. Installed the package on 10.7.4 machine, logged out and tried logging in with that new account, and it didn't work. Created another package with a 6-digit password and tried it again on a clean 10.7.4 and same result. The user doesn't appear in Users & Groups in System Preferences and it doesn't seem to be creating the home folder for that account, however when I run dscl . list /Users the account is there.

It would be very useful if there was a checkbox to 'require a password change on login' when creating a new user. This way we can deploy a generic admin account as part of our imaging process and ensure that the password gets changed to something unique after the first login.

Allow an option to hide the User from the Login Screen if the UID is less than 500. This would enable us to add a totally hidden user. If not feasible for "security" reasons maybe a custom postflight script section where we could add the custom script?

Would be really nice if the CreateUserPkg had an option to allow auto login. My current workflow (and I suspect others out there do the same) is for the newly imaged machine to boot and run first boot scripts and provide my helpdesk guys a GUI for running localisation. I have a custom PKG that autologs in the first time as my admin user. I have some sample code if you want it.

I'm trying to use createuserpkg as a tool to update the local admin password, and while it does work to change the login password, the FileVault password does not get updated. Reproduced the issue several times on different machines. Here are my steps:

Machine imaged
Account created (with old password) via munki with createuserpkg
Issue new pkg via munki (created with createuserpkg)
Old password still used for FileVault, but new password required to log in

Running this on 10.10.3 machines. If this isn't the intended usage of createuserpkg, I'm open to other ideas. I was able to change the password using

dscl . -passwd /Users/

but that puts both the passwords in plaintext.

Thanks!

Guys, after I've created a new UserCreatePkg hidden account, added it to casper then deployed my image (OS 10.9) to my test laptop, I can see that the account I've created after the machine reboots. However, when I try using the password to authenticate against the account I've created, from the UserCreatePkg utility --the password will not allow me to login. The account creation process is very straight forward, but I'm not sure what's preventing the account from recognizing the password that I built in the the UserCreatePkg utility.

I'm puzzled. Am I missing a step? Any thoughts or directions out there?

I have a user package that has automatic login enabled. It has stopped working in 10.9.5 and continues to not work in 10.10.0. The package is applied in my AutoDMG workflow.

Some image formats, such as PDF or EPS, can be dragged to the user picture but are not converted to JPEG and saved in the package. It fails silently and no error message is displayed.

I've noticed lately that my users are failing to be made as admin.

I'm creating the packages on El Cap, deploying with Casper Imaging.

I recently changed the UID's to be above 500 (file vault stuff), other than that I'm not sure what the issue is.

It may be possible that it's not as compatible with El Capitan as I thought?

Steps to reproduce:

1. Create a pkg and save it to the desktop.
2. Close the document.
3. Open the saved pkg.
4. Gatekeeper displays a dialog that prevents opening as the package isn't signed.

Possible workaround would be to xattr -r -d com.apple.quarantine after saving.

Add an option to store the password in salted SHA1 (10.5+) or PBKDF2 (10.7+) format. Salted SHA1 might not be secure enough for some environments.

With the addition of the "IsHidden" setting for accounts as of Yosemite, it would be very helpful to have a checkbox in the UI to toggle IsHidden = 1 (or 0, respectively)

I'd like to see a checkbox that grants the resulting user full admin rights via ARD. I don't think it's necessary to get as fine grained as specifying specific ARD permissions, just "ARD Admin" or nothing. If others agree, the bests solution might be to simply use kickstart to grant permissions after the user account has been created.

Caveats: It would make sense for CreateUserPkg to also make sure the ARD client is activated, again using kickstart, but I'm not sure how to handle the "allowAccessFor" option. I always prefer "specifiedUsers", but modifying that setting has the potential to break an existing setup. Worst case, I suppose an auxiliary checkbox or radio button could be added that allows the user to specify this setting as well.

Rewrite based on the document-based app template in xcode. This enables:

• Reading, editing, and writing of create_user.pkg files.
• Sandboxing, which is a requirement for App Store submission.

When entering a password that is mixed alphanumeric, the account's password is incorrect. I've tried this 5 times when different username and password combinations.

Steps to reproduce:

1. Create a new package from scratch.
2. Save pkg.
3. Close document.
4. Open saved pkg.
5. Save another copy.

The copy now has an empty shadow hash file.

You cannot enable automatic login when dragging a package to update.

Test and verify if the administrative users still works on yosemite 10.10.

This is a task to be carried out, not a bug.

It seems that administrative users created with a version 1.2(41) is installed as normal user in 10.10.

Will try to update createuserpkg to 1.2.4(58), reimage and reinstall the user to see if it works as expceted.

If it still does not work, Ill try to isolate based on which type of image is used (os version).

I'm using CreateUserPkg to create a second Admin account on computers that I have deployed to my schools. I added the pkg to be installed by DeployStudio at image time but it seems that the second admin account tries to use the home directory of the first admin account. So that when I log in as the first admin the computer thinks that I'm logged in as the second. I've tried troubleshooting this to the best of my ability. Any help is appreciated.

create_package.py line 192-194:

pkg_version = "1.0"
pkg_name = "create_%s-%s" % (utf8_username, pkg_version)
pkg_id = "se.gu.it.create_%s.pkg" % utf8_username

Even though in the build settings code signing is turned off, Xcode 4.3 barks at me with the error:
"Check dependencies
Code Sign error: The identity 'Mac Developer' doesn't match any valid, non-expired certificate/private key pair in the default keychain"
Not sure if this is on my end or yours, and haven't tried since 1.1. Thanks, Allister

Will there be any bug fixes for this or further development to make it work with the newer OSes? Please continue support and but fixes to continue to work with new OSes. Thanks Chris

Hi MagerValp.
The utility tool is really helpful for me. But have a tiny issue.
I want the application is working in recovery environment (I customized the OS recovery for my self) .
I also understand the tool dependency in Python (also add Python2.7 to my customized OSX recovery). But the app still didn't working.
The error return is kill 9.
I have know idea about the issue.
Will take time to take a look into the issue in Recovery Environment.
But I think I will need your advice.
Thanks and best regards,
Kevin

It would be useful if there were fields included for providing MCX flags and MCX settings for these account plists. Looking at an account.plist that's had user-specific MCX settings assigned to it via Workgroup Manager, there are two extra keys: mcx_flags and mcx_settings. These contain what you'd expect - XML data inside that can be copy/pasted from pre-existing account files. It'd be a nice timesaver if I could copy and paste this data directly into CreateUserPkg, thus saving me the effort of having to install the account, assign MCX settings, and then rebuild the package.

It would wonderful to be able to create a package with PBKDF2 encrypted password and drop the backward compatibility as an advanced option.

In order to perform certain tasks prior to installing the package and creating the user it would be nice to be able to run a preflight script. This would allow for certain preflight operations such as unifying the installed user's UUID, UID or username to let the package update an existing admin user vs. clashing over user name, UID or both.

Would it be possible to add GID as well as UID?

Regards

Christian

I know messing with root is a bad idea but we needed to for a particular reason. Anyway, if you use CreateUserPkg to "create" root (yes, it already exists, but I wanted to set the password and autologin), the password gets set but automatic login does not. I examined the output package and it contains /private/etc/kcpassword but it doesn't work. I got around the issue by capturing /private/etc/kcpassword from a system where I set root to autologin. This shows root can be set to autologin, but CreateUserPkg doesn't do it. I know this is a special case but I thought I'd let you know about it.

I see some upsides to the user created having group 80, and therefore all files created are group 'admin' as well, but I was wondering if that was intentional or could/should be altered so it can be staff instead, within the confines of how the package operates(since we're not running dscl from the postflight to append the user to the admin array, as in the past).

Not sure if there's an obvious downside(other than consistency with manually-added users,) just wanted to open the discussion.

It would be useful to be able to create the user's home directory and populate it with custom items such as ssh keys or preferences.

I would like to have the option to create a guest account using CreateUserPkg. In some environments might be useful to create a custom guest account so that the user data is deleted on logout.

Currently I am doing this using a postflight script . The script is very raw but I think it should be easy to include the feature in the app

Noel

Hi,

We have student account without password. With the old CreateLionUser, it was possible to put nothing in password. But it's no more possible with your application. Is it possible to correct this and allow to create an user without password (or blank password) ?

Many thanks for your grat work.

Christian :-))

With CreateUserPkg 1.2.3, the standard User created couldn't change the full name and their image and you correct this bug (issue 31).
We still use this version because for us, in public school, it's a good idea that children can't change the name and the image of the student session. Will it be possible to have this possibility as an option for standard users, or do you consider it as a bug ?

Using version 1.2.4, I created a package to create a user that is set to automatically login. My standard workflow has been to install this as part of a Casper policy that is called during the first boot after being reimaged with DeployStudio. I've not had any luck getting the automatic login to work, though the user account is created.

My attempts at troubleshooting have revolved around installing the package while the computer is sitting at the login window (a couple of attempts at installing while a user was logged in went without issue). At this point I've had intermittent results trying installation through Casper, SSH'ing in and installing locally, and other methods. When it doesn't work, I've noticed that the autoLoginUser key is written properly during install, but once the computer is rebooted, that key is mysteriously gone. Do you have any idea why this might be or any other troubleshooting I should undertake?

Thanks!
Eric

My create admin user script adds the local admin user to a number of groups. I am unable to modify the user created by the application in the Accounts pane under my user account that is also part of the admin group.

Enabling automatic login stores the password in a format that can be converted back to plain text. A security warning should be displayed.

If I create a Standard User with CreateUserPkg, the Full Name (aka RealName in Directory Utility) field can NOT be changed by that user after logging in.

A Standard User created with 'Users & Groups' in System Preferences can change this field as needed.

Tested on 10.7.5 and 10.8.5.

After creating the new user and booting to the user, system folders such as Downloads have a red minus on them and indicate that the "folder cannot be opened because you do not have permissions to see the contents."

Although this can be fixed manually, is there a way to fix this through the application?

Cheers!

I would like to be able to add either a custom picture or one from the defaults already on the system.

It would be useful if there were an advanced view for the CreateUserPkg tool which allowed you to tweak the user's shell and the other items that are hidden from view by default. This would allow 100% customization of the user package if desired.

At the very least, perhaps just add the shell to the default view so it can be tweaked as desired.

Hi,

In old CreateLionUser.pkg, we can put 1 in "KickstartARD" and 1 means that the Apple Remote Desktop agent should be kickstarted and access given to the newly created user. Is it possible to have this fonctionality in your application ?

Many thanks in advance

Christian :-))

Similar to how PackageMaker can keep a default organization ID: com.mycompany.

request to create all user types in OS X

administrator
standard
managed with parental controls
sharing only

This tool is very helpful, but here are some additional options I'd love to see:

• To have the package check if the account exists. If it exists, the choice to either do nothing or update the current user-- to match the packages password, account picture, display name, and account type, but keeping the current unique identifiers. Or if you update the identifiers, to also update the permissions and whatnot so it doesn't break the user account.
• The option to not specify a User ID, but to have the new user account just pick the next available ID
• The option to also enable the user in Filevault, if Filevault is already enabled on the boot drive.

Sorry if you'd prefer these each be in separate issues. I can break them out if you'd like, but I'm not sure which is better etiquette.

Could you add a checkbox to support the IsHidden feature available in 10.10+ ?

https://support.apple.com/en-us/HT203998

It turns out there are some subtle behavior differences when a user is an admin because they have a GID of 80 as compared to being added to GroupMembers/GroupMembership of the admin group:

Admin accounts created this way -- when viewed in System Preferences/Users & Groups, "Allow user to administer this computer" is disabled -- you can't uncheck this to remove admin rights.

These accounts can't delete other admin accounts in System Preferences/Users & Groups, or remove admin rights from other admin accounts in System Preferences/Users & Groups.

These are minor issues and have workarounds, but if we've seen these, are there other issues we have not yet discovered?

So it would be even better if the package could leave a GID of 20 (or whatever the admin chooses), but if the account is supposed to have admin rights, add the account to the local admin group. This is made more difficult by the small selection of available tools in the Lion/ML installer environment.

See https://github.com/pudquick/PathPlistsAddUserUid for some possible solutions.

Using the account created by the application any network account (AD) that is created on the machine is unable to be deleted by the Administrator account that the Create User application generated.

We've been using CreateUserPkg successfully for our custom OS X installs over the last year and a bit. Having odd issues in 10.9 however, such as the admin user not being available in the list of users to enable for Remote Login and Remote Management, yet the user exists within Users & Groups.

Am I right in thinking that something has changed in Mavericks?