Now if only there was a way to let admin users masquerade as others through the OD login window (you can mount AFP shares with an admin password, but can't actually log into another user's account as far as I know).

This would be soooooo useful for testing Workgroup Manager settings, when something is not working properly for a particular user. Right now, my only option is to change the user's password first, then have them change it back when I'm done. Anyone know of anything better?

if only there was a way to let admin users masquerade as others through the OD login...

There's actually a pretty slick way of doing this: In OD, the password is stored via one level of indirection; a "pointer" to a password entry.

So:

• save the value aside, for the account you need to log in as
• overwrite it with one of your choosing (say, what's used for an admin account)
• log in as that user to do what you need
• restore the password with what was saved in the first step

Wait, how do you actually do the saving of the original password, though? As far as I can tell, there's no way to extract the actual password data from an account, especially when using Kerberos... am I missing something?

Right; you can't read a password, but you CAN read/write the "pointer" to it, and that's all you need.

Care to explain how to do this?

It can be done via "Workgroup Manager" (GUI; does not require Mac OS X Server) or via command-line - look for the "AuthenticationAuthority" attributes.

It's "advanced" (you won't even see that attribute until you enable WorkGroup Manager's "Inspector") and all the standard warnings apply; you can make a mess of things at this level.

Right, with Kerberos, the password information is not even on your machine. Your password is checked against a key server which assigns a Kerberos ticket to your session on the machine and it is only good for that session. You would have to either catch the action of authentication against the key server or crack the key server, itself. Without Kerberos, a password can be cracked with a chosen text attack, which is more or less difficult depending on the strength of the one way hashing algorithm used to encrypt the password and on how strong the user's password is. See my reply to one of the other messages below for more about this.

Right, which makes me wonder what mvgfr (above) is talking about.

You simply replace the *reference* to the password (the text string in the AuthenticationAuthority attribute, if I recall), which tells OD where to find the password.

And then put the old *reference* back when you're done.

No actual passwords are read or changed.

I just upgraded to "Mavericks" and have 3 major issues with it:

First and foremost I lost my IMac admin. ID and password.

After trying everything I could, I still can't recover them, including using UNIX, as recommended on these sites:

http://www.hackmac.org/tutorials/decrypt-os-x-user-account-passwords/

http://www.hackmac.org/tutorials/how-to-create-a-new-administrator-account/

http://www.wikihow.com/Reset-a-Lost-Admin-Password-on-Mac-OS-X

http://osxdaily.com/2011/08/24/reset-mac-os-x-10-7-lion-password/

http://osxdaily.com/2010/08/10/forgot-mac-password-how-to-reset-mac-password/

http://support.apple.com/kb/HT4718[/B]

http://www.macworld.com/article/2056561/how-to-make-a-bootable-mavericks-install-drive.html

http://www.macworld.com/article/1167855/installing_mountain_lion_what_you_need_to_know.html

No matter how hard I try, it just doesn't work.

I thought I had when I used "resetpassword", but when I used it again it said: "Please use install disk which doesn't exist now".

Also, Safari 7.0 starts to come up, then quits. Only pace it worked was in "Recovery" mode.

Likewise when I want to print to a PDF file, "Preview" starts, then quits. It seems to run on it's own!

There may be "200" new and better features, but I haven't got to them yet!

I wanted to keep Mountain Lion, but wasn't given that choice on one of my two external drives, because they both were treated like backup drives!!

Any advice is deeply appreciated.

Thanks,

Glenn Welker

ghwelker3@comcast.net

Caveat: The "replace the password reference" trick did work in prior versions of OS X, however I haven't tested in 10.6.

However, after a brief check via Workgropup Manager, it looks like it may not work in 10.6.

Personally, I consider that a good thing, since it's more secure.

This is a great hint! I've been wondering about this since 10.6 was released.

If you're doing something which doesn't actually require being logged in as the user, then fast user switching is probably the best answer. If I remember correctly, there is a way to auto logout users after a period of inactivity so that rebooting isn't an issue with still having someone logged in.

I guess this hint is for something like troubleshooting an email account issue, where you really have to be logged in as the user. Our policy for that situation is that the user is supposed to be present when you're poking around in their account. It's true that a lot of users don't know this or don't care about the policy and, especially the big shots, want stuff done while they're gone. We always assume that there could be PHI (HIPAA regulated data) hidden by the locking screen saver (that's why we require locking screen savers in the first place.) The user needs to clear that stuff away so that the desktop tech doesn't see it by mistake. If you don't have such an issue, like HIPAA, payroll stuff, etc. where you need to hide one employee's data from another, then why enable the lock on the screensaver? My point is that there will often be policy reasons not to follow this hint.

Auto log-out is pretty unreliable, because any modal dialog will prevent it from happening. Also I'm pretty sure you can't fast-user-switch when the screen is locked; you'd have to unlock the screen before you can access the FUS menu.

Fast-user-switching is available from the screen unlock dialogue, my kids use it all the time to log into their account when I have not logged out and the screen has been locked.

Ahh, good to know! Hadn't noticed that before. Might come in handy too, thanks.

Still need to be able to see other users' accounts from within a lot of the time, especially in an MCX environment where you're trying to propagate prefs and restrictions -- just can't verify that an account is working properly until you see it for yourself.

when i go to the com.apple.ical.plist, the window opens then closes How do i change anything to do with the alarms if that won't stay open?

Help?

cat /etc/pam.d/screensaver | sed 's/account    required       pam_group.so no_warn group/account    sufficient     pam_group.so no_warn group'/ > /Users/Shared/screensaver.new.txt
sudo mv /etc/pam.d/screensaver /Users/Shared/screensaver.old.txt
sudo cp /Users/Shared/screensaver.new.txt /etc/pam.d/screensaver
open /Users/Shared/

sed -i '.bak' 's#account    required       pam_group.so no_warn group=admin,wheel fail_safe#account    sufficient       pam_group.so no_warn group=admin,wheel fail_safe#g' /etc/pam.d/screensaver

# screensaver: auth account
auth       optional       pam_krb5.so
auth       required       pam_opendirectory.so nullok
account    required       pam_opendirectory.so
account    sufficient     pam_self.so
account    required       pam_group.so no_warn group=admin,wheel fail_safe
account    sufficient     pam_group.so no_warn deny group=admin,wheel ruser fail_safe