Monday, May 19, 2014

OS X Active Directory Users losing admin privileges when offline

For anyone using Directory Services in OS X to bind the Mac to a Windows domain, you've likely seen the option to allow administration by..., where you can define groups to administer the machine. I have a security group setup in Active Directory specifically for this, and whenever I bind the Mac to the domain I add that group and turn that option on. However, once in a while, when a machine is not able to directly authenticate with an Active Directory server, domain users do not have local admin rights. Typically admin rights come back the next time the machine is able to communicate with Active Directory, but in the meantime it is an annoyance while offline. Fortunately, it appears that I'm not the only one who has been dealing with this. I only wish I had spent some time researching it sooner.

Previously, my workaround to this problem has been to remove the Mac from the Active Directory domain, and then rejoin. While this has worked, it is just a workaround rather than a solution. It appears that someone with the same issue has found the actual problem, and also posted the solution. What is apparently happening is that even though those groups are supposed to be allowed to administer the computer according to the setting in Directory Services, the accounts are not added to the local admin group on the Mac. You can fix this by opening a Terminal session, and running the following command:

dseditgroup -n /Local/Default -o edit -u localUsername -p password -a accountToAdd -t user admin

*UPDATE*

Rather than use the above command, I found simply using sudo removes the need for the -u and -p switches so you can use the following.

sudo dseditgroup -n /Local/Default -o edit -a accountToAdd -t user admin

-n = node
-u = local username used to authenticate to make the change
-p = password for user defined with -u
-a = name of account to add to the admin group
-t = type of account you're adding
admin = group name

You'll want to use your own information for -u, -p, and -a. -t can take group as an option (instead of user). I haven't tried that yet, but it should allow you to add an entire security group to the local admin group in case you have multiple users for that one machine

Now, I believe this may do the same thing as well if you're not comfortable using Terminal to issue that command. You'll need to have login info for an actual local admin account, and the domain account you want to grant admin rights to must have logged in to the machine at least once already. Simulate being offline by turning off the wifi connection and disconnecting any LAN cable(s). Once you're offline, go into System Preferences->Accounts, click the user that should have local admin rights and check the box that says "Allow user to administer this computer". Then reconnect your network connection and reboot.

The two articles I found related to this that I used are:

https://discussions.apple.com/message/16026679#16026679

https://discussions.apple.com/message/22540531#22540531




Wednesday, May 14, 2014

ProcessExplorer "Unable to extract 64-bit image" error

The ProcessExplorer program is a very useful utility. I needed it today to track down a file lock, but upon trying to run it on my Windows 7 64-bit machine, I kept getting an error telling me "Unable to extract 64-bit image...". A few Google searches mentioned this being caused by a permissions error, but this didn't make sense since I'm an admin on the machine. After I ran across this on the SysInternals forum, then I realized that those saying that permissions were the problem weren't wrong, but that their answer wasn't specific enough.

Upon running the ProcessExplorer executable, it will extract the 64-bit version of the program to the AppData/Local/Temp folder and attempt to run from there. However, if you're like me and have restrictions on applications running from the Temp folder, this will cause the error. To get around it I simply navigated to my temp directory and move the procexp64.exe file to my Desktop and executed it from there. It opened right up and I was able to get back to what I needed ProcessExplorer for.

By default the AppData directory is hidden. The quickest way to get there is by clicking Start, then type %tmp% into the Search box and press Enter. Or type the path directly into the navigation bar, or choose to show hidden files.

Full path to the temp folder is C:\Users\"your username"\AppData\Local\Temp