|setregproptool||Thomas Larkin||7/28/11 7:55 AM|
I just wanted to share something I figured out recently when mass imaging our Macbook Airs we are getting ready to deploy this next school year. Long story short, Apple changed something in firmware that doesn't allow my third party tools to set the firmware mode and password on all late 2010 and newer Macs. However, Apple did implement (sometime in 10.6) a command line binary called setregproptool which is located either on the OS X Installer DVD or on the newer USB OS X Installer drives that the Macbook Air comes with. Either copy the actual MacOSX.dmg to the desktop (it is hidden you must chflag -nohidden it) or use the hdutil to mount the image. Once it is mounted you can navigate here:
(note this is from one of the USB flash drive installers which are flashed as read only, DVDs are different)
then you simply run the tool
sudo ./setregproptool -h
This allows me to mass deploy firmware mode and password to our 5,500 Macbook Airs we are currently imaging for next school year in our 1:1 program. I hope this helps someone.
I also don't know if all third party tools are not able to set the firmware password on late 2010 or newer Macs. I know Casper as of right now cannot, but they do have the ability to run the tool if you add it in manually. They will most likely fix this very soon. Also, older versions of this tool DO NOT work on newer Macs either. I originally tried to pull the tool off a 10.6.4 installer DVD and no dice. So I grabbed the newest version off the 10.6.7 installer USB Flash Drive instead. So far in my testing it works on the current and older Macs at work.
hope this helps someone,
Subscription Options and Archives
|Re: setregproptool||Bruce Carter||7/28/11 8:04 AM|
Does the nvram command no longer work?
nvram security-password="<encoded password>"
|Re: setregproptool||Thomas Larkin||7/28/11 8:28 AM|
I thought the nvram command just obfuscates the password and you must input it in the obfuscated format? I haven't tried it, this tool works as advertised though. I can grab the next imaged client and see if it works. I am still on 10.6.8 though, we aren't going to early adopt Lion. The nvram command seems to work in a different manner, at least that is what I have read. I actually don't use it because I have had third party tools since day 1 here.
>>> Bruce Carter <bca...@ND.EDU> 7/28/2011 10:04 AM >>>
This message has been sent from the Kansas City, Kansas Public Schools. The information contained in this email and any attachments may be privileged and confidential, and are intended only for the individual or entity identified as the addressee. If you are not the addressee, or if the message has been addressed to you in error, you are not authorized to read, retain, copy, or distribute the message or any attachments. If you have received the message in error, please delete it and any attachments and notify the sender by return e-mail or by telephone. Thank you.
|Re: setregproptool||Zajkowski, James||7/28/11 8:39 AM|
As of the last round of Mac Pros and the just previous Airs (the current design but the Core 2's) the NVRAM password thing is now different, and that's being rolled through all new models. Recovering them is also more complicated now.
|Managing the dock in Lion||Sean Gaynor||7/28/11 9:00 AM|
I'm in a golden triangle setup. I can manage the dock fine using MCX from my OD master and I'd like to be able to use the 'merge with user's dock' setting and have some dock preferences handled by computer group, some by user group and some level of customisation by the user themselves.
This works fine except that the App Store, Mission Control, Face Time etc icons keep populating the dock as well from a template somewhere.
I've looked at /System/Library/User Template and the settings don't seem to be coming from there (i've also tried adding my own dock plist to this and nothing happens. I think this is for locally created accounts only?
As they are Active Directory accounts, I looked at the plist files in System/Library/Open Directory/
I've tinkered with the /Library/Preferences/com.apple.dockfixup.plist and removed everything under in add-app.
Clutching at straws really. Does anybody know where I can alter the setting to stop these apps populating the dock?
If I uncheck 'merge with user's dock' I get only what I'm setting in OD but the user cannot add their own app choices to the dock.
|Re: Managing the dock in Lion||Riti, Tyler||7/28/11 10:12 AM|
You might want to try writing a LaunchAgent to run a script that uses dockutil to remove the unwanted app icons after a user logs on. I haven't started tackling Lion but I know that in Snow Leopard, I was unable to remove the App Store from the Dock using any method provided by MCX.
|Re: Managing the dock in Lion||Patrick Fergus||7/28/11 11:19 AM|
They're possibly coming from a few places:
1. For new and existing (10.6 and before) users, com.apple.dockfixup adds Mission Control, App Store, Server (if applicable) and
2. For new and existing users, the Dock checks com.apple.dock.plist for a boolean key "checked-for-launchpad" and likely adds
3. For new users, the Dock reads preferences from here:
Which includes Launchpad, Mission Control, App Store, Mail, Safari, FaceTime, Address Book, iCal, iTunes, Photo Booth, iPhoto, System
The total of the above makes the "default" Dock that's getting merged with your settings. You should be able to prevent #1 by:
sudo defaults delete /Library/Preferences/com.apple.dockfixup add-app
I handle preventing #2 and #3 by dropping a correctly-formatted "blank" com.apple.dock.plist (with ownership/permissions of root:wheel 600) here:
Since the XML probably won't make it through the mailing list, the "blank" com.apple.dock.plist is the product of the following
On Thu, 28 Jul 2011 17:00:23 +0100, Sean Gaynor <seang...@MAC.COM> wrote:
> Hi all,...
|Re: Managing the dock in Lion||Sean Gaynor||7/29/11 12:24 AM|
Thanks Tyler, I'd not come across dockutil before, looks useful.
I had the wrong permissions on the dock plist in my template file. I found that I had to delete the persistent apps in the core services dock app as well though. Everything as it should be now!
|Re: setregproptool||Justin Elliott||8/18/11 8:12 AM|
Looks like setting the EFI password via nvram alone isn't working on the newest iMacs11,2, we have to use the 'setregproptool' that is only included with the Firmware Security Utility and somewhere on Lion's hidden Recovery HD volume.
Anyone know which Mac models require the setregproptool to really configure the EFI firmware security?
Apple really, really needs to include setregproptool in the base install of 10.6 and 10.7 now, or otherwise mass deployment of Macs for labs is going to be a PITA for us.
Yes, my next step is to file a bug/feature request ...
|Re: setregproptool||Thomas Larkin||8/18/11 8:21 AM|
I am under NDA from enterprise apple support but I am sure I can share this bit of info. Apparently all Macs with hardware from late 2010 and newer require this tool to set the password is the answer I got from Apple. I have successfully pulled the binary out of the installer disk (or USB installer for the MB Airs) and spliced it in my image via instaDMG and use scripts to set the Firmware password at image and have policy in place to mass change firmware password if any get leaked, or due to our security policy of changing passwords every so often.
I can also confirm you need the newest version of the tool from the newest installer disk to work on current OS builds. I first tried using a 10.6.4 disk and a 10.6.0 retail disk to grab the tool on a 10.6.8 image and no dice. I had to pull the version from the 10.6.7 installer USB disk drive from the Macbook Air to get it to work.
So far, for me it has worked out just fine.
>>> Justin Elliott <jd...@PSU.EDU> 8/18/2011 10:12 AM >>>
|Re: setregproptool||Ben Harper||8/18/11 8:23 AM|
setregproptool should work with any Intel Mac, and is required by the late 2010 MacBook Airs and Macs released since then. You should still be able to use the same version that came with the late 2010 Air installer on any Macs released since then to set the firmware password.
Note that on the late 2010 Airs onward, to change a firmware password that was already set, you have to successfully enter in the previously-set password, so don't forget it.
If you do forget it, you'll have to follow:
|Re: setregproptool||Thomas Larkin||8/18/11 8:31 AM|
If you look at my original email I covered the previous password. In fact in my post image script I included the previous password (even though there is no password set out of the box) switch on the command because I ran into snags where I would have to reimage a machine for whatever reason and it would halt my post image script because if you don't input the previous password it prompts for it. There is no force option, so I included it in my script and so far everything has worked perfectly.
We just got done mass imaging 5,500 Macbook Airs and I used this tool to mass deploy the firmware settings and password.
>>> Ben Harper <har...@MAC.COM> 8/18/2011 10:23 AM >>>
|Re: setregproptool||Ben Harper||8/18/11 8:38 AM|
Oh, one other thing...there is also a new option/feature that will work on the late 2010 Airs onwards to require the firmware password every time the machine boots, not just when the user tries to select another startup volume, etc. See the setregproptool command help for details. That combined with Full Disk Encryption can be nice for those so inclined.
Note that the tool does not provide feedback (e.g., in the form of an exit 1) when a firmware password has been successfully set or changed (likely for security reasons), so be sure to double check that it's working before you wrap up imaging, etc. and put the machines into production.
|Re: setregproptool||Thomas Larkin||8/18/11 8:50 AM|
I even noticed that when using the tool there is a switch that checks to see if a firmware password is enabled ( I think it is the -c switch don't have a macbook air near me at the moment), and it is suppose to return 0 if it is enabled and 1 if it is not. I cleared the firmware password via the tool, rebooted to verify no firmware was on there and then used the command to check if it was enabled, since it wasn't it should have returned 1. However, it still returned 0 for me. I opened up a bug ticket with Apple support but haven't heard back yet.
Otherwise it works, and I can change it and it sets the machines into command mode. We are a public school system with a 1 to 1 laptop initiative so I don't have to bother with encrypted home folders or file systems. The firmware password is merely a level of protection preventing the students from rooting the machine, booting into SUM, removing the /var/db/.AppleSetupDone file and then creating their own admin account.
With the new Macbook Airs, this will be near impossible since according to the documentation only AASP can reset the firmware password and the Airs use the security bit driver to take the back plate off. I assume if you crack the case open you will have to find a reset switch since the RAM is soldered to the main logic board.
>>> Ben Harper <har...@MAC.COM> 8/18/2011 10:38 AM >>>
|Re: setregproptool||Darren Severino||8/18/11 8:59 AM|
You have to sign in to GSX first then that article will load with the actual info in it.
|AD & Lion - Nested AD groups not recognised||Sean Gaynor||8/19/11 7:34 AM|
I have a standard golden triangle setup. 10.7.1 server, 10.7.1 clients.
I'm finding that AD groups inside OD groups are not being recognised. If I put individual AD users into the OD groups they are recognised and preferences are applied.
Even when I do have AD users individually inside OD groups some preferences don't seem to apply such as network preferences. The user's preferences ARE being pulled by the client but it's like it's just not reading them. The proxy I set for a user is just ignored and it uses the local system settings.
I've tried with both Centrify's free AD plugin and the standard AD plugin on the clients.
Both Lion clients and server both get the following AD paths when binding to AD:
/Active Directory/My_Domain/All Domains
Under Snow Leopard it was always just the single path:
/Active Directory/All Domains/
I don't know if that's part of the problem but it can't be helping.
Does anyone have any ideas what might be causing this? I remember the same thing happening years ago, I think it might have been on Leopard or even Tiger.
I have switched back to 10.6.8 server and the same thing is happening. Lion clients are not reading nested AD groups, Snow Leopard clients are.
|Re: AD & Lion - Nested AD groups not recognised||Hester, J. David (NIH/NIDCD) [C]||8/19/11 7:46 AM|
It's a bug (or three) with the OS.
Submit to radar.
Why Apple had to throw everything out and start from scratch still puzzles me. I thought things were more or less getting stable in 10.6. Then they start all over and re-introduce issues we saw clear back in the bad old days of 10.5.
|Re: AD & Lion - Nested AD groups not recognised||Benjamin LeRoy||8/19/11 8:45 AM|
I can't comment out of a NDA for my enterprise support agreement other than to say: I can confirm that AD group memberships are not being read by 10.7-10.7.1 at all in any of my binding and deployment testing. I would file bug reports if you do not have an enterprise support agreement or open a ticket with Apple if you do.
|Re: AD & Lion - Nested AD groups not recognised||Matthew Natividad||8/19/11 8:39 AM|
How many macs are in your environment?
Matthew Natividad | IS Apple Support
|Re: AD & Lion - Nested AD groups not recognised||Ben Toms||8/19/11 9:37 AM|
It's my suspicion that apple development the old os to the new.
So 10.7 came from 10.5 & not 10.6.
10.6 from 10.4.
10.5 from 10.3
I've just had to many issues that have affected say 10.6 & 10.4 but not 10.7.
Pure coincidence I'm sure.
|Re: AD & Lion - Nested AD groups not recognised||Sean Gaynor||8/19/11 10:53 AM|
Thanks all, I'll file a bug report.
Matthew, Approximately 230 Macs, quite a small amount relatively speaking.
|Re: AD & Lion - Nested AD groups not recognised||Matthew Natividad||8/19/11 10:56 AM|
Thanks Sean. I am thinking of implementing golden triangle in our
environment. We have about 170 Macs in 4 different locations in one city.