FileVault 2 uses the GeneratedUID user attribute to save who is permitted to unlock an encrypted volume. If the GeneratedUID of a user differs from what was generated (or pulled from LDAP) when FileVault 2 was enabled, the user will not be permitted to unlock the machine, as their account will appear to be unavailable at the EFI menu. Also, this causes the crash of System Preferences on their Mac whenever they try to access the Security & Privacy prefpane.
This problem arises when /usr/bin/mcxrefresh runs and pulls a null value or a value different than what is stored locally from LDAP (if the attribute isn't defined for the user in question or is defined incorrectly, respectively), overwriting the GeneratedUID stored locally (which is generated and only stored locally when FileVault 2 is enabled without a matching LDAP attribute).
In other words, if an apple-generateduid value exists in LDAP for a user and is mapped properly on the users Mac to the GeneratedUID attribute, FileVault 2 will not generate a new value, but will instead use the value stored in LDAP.
I was able to resolve this issue by adding an attribute called apple-generateduid to the LDAP entry of any user experiencing this issue. I could generate a random value for this attribute in Python by running the following one-liner from my terminal:
python -c 'import uuid; print str(uuid.uuid4()).upper();'
This isn't the only step, however. You must also add a mapping for this attribute on the client side. This is easily done using the following steps:
- Open System Preferences.
- Click Users & Groups.
- Click Login Options.
- Click on the Unlock Icon.
- Under Network Account Server, click Edit.
- Click to highlight your directory server.
- Under Services, double-click on your directory service (in my case, it was LDAPv3)
- In the window that slides open, highlight your configuration name, and then click the Edit... button.
- Under Search & Mappings scroll down and single-click on Users to highlight it.
- Click the Add button (the left one).
- Choose GeneratedUID from the list of available Attribute Types.
- In the right column, click the Add button, and type
apple-generateduid. Click OK to save the changes until you're back at the main System Preferences dialog.
- At this point a mapping from GeneratedUID to
apple-generateduid has been created. Now when OS X looks up the GeneratedUID value it will get the value of apple-generateduid from the user in questions LDAP entry.
Finally, it's important that the locally stored value of GeneratedUID and value stored on LDAP match. Run the following command and make sure the two GeneratedUID values match:
dscl /Search search /Users GeneratedUID $(dscl . read /Users/$(echo $USER) GeneratedUID | cut -d " " -f2)
This problem has been bugging me for months. I've kept a weather eye on the Google results, poked around trying to find my own solution, upgraded to Yosemite to see if the issue was resolved there, but nothing turned up. So, during the Thanksgiving break I decided to sit down and fix this once and for all.
Looooong story short, every time you add a new tag (and possibly when you add a tag to a file) it gets popped into the Finder sidebar for easy access. Handy. Thing is, if you get crazy and add a metric ton of tags, none of them are ever removed from the Finder sidebar. They roll off the edge where you can't see them, and are flagged as "visible if newer items are removed" but they are all retained in the sidebar items plist. This plist gets massive, and takes a long time to parse any time it must be modified.
To make things worse, when you have "documents and data" turned on under System Preferences > iCloud the tag list is synced. This means the hang follows you to every machine where you are signed into iCloud, even on a fresh reload of OS X. Funfunfun.
Thankfully, there is an easy fix. I'll keep the explanation simple for Joe Internet who may be having this problem stumble across this post.
When the Finder is running properly (not beach-balled), right-click on the icon in the Dock and select "Go to Folder". In the dialog that appears type "~/Library/Preferences/". That funny little squiggle at the front is just a nice little shortcut that tells the dialog to start in your home folder for the path, rather than the root of the internal drive.
You will be presented with a cornucopia of scary looking plists. The one we are after is titled "com.apple.sidebarlists.plist". Copy that plist somewhere you can find it later (just in case something goes awry and you have to put it back.) Now, delete the the original plist in the Library folder and reboot your machine. After the reboot Finder will have an empty tag sidebar and you can create, delete, and rearrange tags to your hearts content. No hangs. As long as you have iCloud "Documents and Data" enabled, this new clean sidebar will also be uploaded to iCloud and clear out the old gigantic one on all your machines.
It should be noted that this DOES NOT delete the tags from your files. That information is actually appended to an extended attribute (xattr) of the file itself, rather than being stored in a single plist or database somewhere. Thankfully the tags on the files themselves aren't what's causing the hang issue, so we can leave them untouched.
Of course, what you will lose are the list of tags and custom folders you want in the Finder sidebar. Add the folders back the normal way (drag them into the sidebar) and you can select which tags you want by going to the Finder menu > Preferences > Tags and checking the boxes. I've got about a dozen and things are snappy.
One other unfortunate loss are the tags' assigned colors. That's strictly stored in the Finder's plist. The tags may appear to retain their color until you add them back to the sidebar, or try to apply a tag to an item, at which point the color vanishes.
After you've added a tag or two back to the sidebar the "all tags" item will reappear at the bottom of the list. Click on that and scroll through the list of tags to re-assign their colors. Make sure to re-apply color even to the tags that appear to have retained it, because when that tag is next added to a file or otherwise modified there's a good chance the color will disappear.
Something to note if you have a lot of colors applied: adding them all back may cause the hang issue to re-manifest. All those color assignments are stored in the plist, and too many may drag things down. I've only got a few color assignments so I haven't been able to verify this theory.
That's it! Congratulations! Tags are now usable on your machine(s) again. Just remember to go into Finder > Preferences > Tags every now and again and clear the checkbox or minus sign from the tags you don't want displayed in the sidebar and things should remain snappy.
Best Answer
Refer to this article for more information about the Firewall and how to enable it: https://support.apple.com/kb/PH18646?locale=en_US
It is fine if the main computer user is an admin. You will still need to enter your password to authorize changes to the computer, the only thing that is different from being a standard user (in this scenario) is that your username will be automatically entered. As an administrator, you also cannot delete important system files (built-in apps, operating system files, etc.).