A small truth about Open Directory passwords...

We had a problem today, which gave me some insight in the way OD handles its passwords.

I created a new user in OD and, being based in Munich, made an Oktoberfest induced error.
(At least that's my excuse...)

I deleted the value of "Authenticaton Authority" in the Inspector window in the user account. I tried to fix that by copying over that attribute from another user. Seems to work, everything fine.

After a while, the user from which I copied the attribute showed up and complained that his password suddenly seemed to be invalid.  Hmm.
Maybe just a coincidence? I changed his password, seems to work, everything fine. Back the the headache.

Shortly after, the new user showed up, her password was broken now!
Ok, time for some research...

The open directory does not save the passwords in the ldap tree (as hash, hidden field, etc...) . Instead is utilises a secondary password service (kerberos) which holds and manages the password. The link to this password is established by the "Authentification Authority" field in the OD. It contains an ID that references the password in the service.

Copying the hash from one user to the next gave both users the same entry, and thus the same, linked password. The problem was solved as I deleted the complete entry "Authentification Authority" of the new user, and changed the password. The OD created a new entry in the ldap and the password service, and it really worked, finally everything fine.

...don't drink and root. ^_^


<edit>
A college found this on the web:
http://flylib.com/books/en/4.395.1.68/1/

It explains the relation beween LDAP, Kerberos and the Apple password service in detail. Interesting stuff.

It's from 2005 but seems to be correct in most regards. One thing that seems to be deprecated is the note that the change of a users password with kpasswd does not change the password in the Apple password service. Tried it, it does. (SL Server, ML Client)

________
Appendix:

Get the Last modification stamp of the users password (on the OD host):
sudo kadmin.local -q 'getprinc user@DOMAIN.COM'

New shell commands in Mountain Lion

Just a quick link to a useful post from patrix:

http://apple.blogoverflow.com/2012/07/interesting-new-unix-commandsbinaries-in-os-x-mountain-lion/

There is some cool new stuff under the hood. =)

Recovering a locked down system with broken mobile user

Yesterday I set up a brand new MBA13''. Nice, but I prefer the MBPwRD for the same money. 
As usual I created an local admin account to access the system if anything goes wrong. The user account was an mobile user for obvious reasons. Both users had access to the filevault2. 

I gave the system to the user for data migration, task done.

Today I got it back with the trademark words "It Just Broke, I Did Nothing". First thing I noticed as I switched the thing on, no local admin account. And guest access was activated. Huh?

Logging in with the users password started the system, but dumped me to the normal login screen where only the guest user was visible and the "more..." button for other (normally network) accounts.

Trying to sign in with the "more..." button yielded nothing, so off to start from the recovery partition.

First bump: filevault2 encrypts the whole disk, how do I start the Recovery?
Quick Google: holding cmd-R works, even if the Recovery partition is not listed on the alt boot menue.
I still could enable the filevault2 partition with the old user password.

I tried to reset the password of the user with resetpassword (See blog post in Febuary) but it did not work. Well duh, it's a mobile user, of cause it does not work. The local admin stayed gone.

Well then, of to single user mode! (cmd-s at startup)
First, I fixed the file permissions like this:

> /sbin/fsck/ -fy

A look into the /Users directory showed the local admin account as deleted. Well, someone did something...

Ok, the user account was somehow borked, the local user was gone... what to do?

Easy:

(in single user mode) 

> mount -uw /
> rm /var/db/.AppleSetupDone
> reboot

After the reboot, the fresh installation assistent greets you, wants to register your device, show you how to natural scroll and creates a user with admin rights!

I took a gamble and gave it the same name and credentials als the deleted local admin account, and it worked like a charm.

Ok, after the system was accessible, the thing that caused all this was obvious:

The "Allow network users to log in at login window" login option was deactivated. Well durr, good lock signing in Mr Mobile User. Together with the deleted local admin account this was, well, stupid. 


At least I can now be sure that the local admin stayes on the system, that my colleges got a good laugh and I a blog post out of it. =) 

Kerberos Auth works again!

After trying again to analyse the problem, I've found that only the MCX prefs I've applied to the main group of the users would not get pulled down to the clients. 


Looking for this specific problem, I've found this:
http://lists.apple.com/archives/client-management/2012/Jun/msg00005.html

Durr, now everything is clear.
Just as the post stated, I've created a new group with the AuthWhiteList preference set and ... voila!

Chrome Kerberos auth breaks with MacOS 10.7.4 patch?

I have installed the new 10.7.4 update on my MacBook and promptly the Kerberos Auth of our Trac and FreePBX broke down in Chrome. I have not a clue why this is so, but it seems to affect only Mobile (account) users...

Puh... work, work.

- update -

It's still possible to give Chrome the Whitelist parameter manually:
open /Applications/Google\ Chrome.app --args --auth-server-whitelist="*.example.com"


- update 2 -

I've found the source file with all cmdline switches for chrome/chromium. Took me long enough to find, so I'm documenting it here:

http://src.chromium.org/svn/trunk/src/chrome/common/chrome_switches.cc

Get Chrome to work with Kerberos

A lot of stuff regarding Kerberos is broken on Lion. Some say everything. 

One thing that hit us soon after trying out Lion was that Chrome was not working with Kerberos anymore. We found the problem was with the "AuthServerWhitelist" parameter. 

We could fix it for network users with a change in the OD: 

• Access the opendirectory in the workgroup manager
• choose your main user group
• switching to "manage preferences" in the button bar 
• going to the "Details" tab
• Press +
• choose Google Chrome
• Select "Always"
• click on "New Key"
• Enter "AuthServerWhilelist" and give it the string value "*.<yourdomain.com>".
• Apply, and your done. 

It's more difficult for local users. There you need to access the local directory on the client. 

You can do this in Lion with the building "Open Directory Utility" but it cumbersome. 

I streamlined this by learning a bit of dscl: 

sudo dscl . mcxset /Users/<USER> com.google.Chrome AuthServerWhitelist always '*.<yourdomain.com>'

Replace USER and YOURDOMAIN, enter into terminal. Done.  

Kerberos client config with OD on SL and Lion

I've dived into the murky, two-colored waters of Kerberos on MacOS SL and Lion. Our installation works, but the tickets are issued without the Renewable and Forwardable flags, which complicate usage with Linux. I needed to find a way to config the Kerberos Client on the Macs….

After a lot of searching, I've found that Snow Leopard clients with network users read an Open Directory config entry and uses it as its krb5.conf

This entry is (seen from the OD host (SL Server)): 

/LDAPv3/127.0.0.1/Config/KerberosClient/XMLPlist

You can edit this list with the Inspector tab in your Workgroup Manager (again SL). The entry is formatted as an XML file, but you'll see the similarities to a normal krb5.conf right away. 

Don't forget to increment the GenerationID at the end of the XML to apply changes on your clients. The entries should be applied on the next login but you can enforce the sync by using the tool "kerberosautoconfig".  Add the parameter "-v 4" to it to get some feedback: 

$> sudo kerberosautoconfig -v 4 

Alternatively, you can copy a regular krb5.conf file to the file /Library/Preferences/edu.mit.Kerberos.

Lion Clients ignore the entry in the OD. They hilariously still accept the edu.mit.Kerberos file, even though Lion uses Heimdal Kerberos instead of the MIT flavor. Lion is missing the "kerberosautoconfig" tool as well, but the SL version still runs on Lion. Get the file from somewhere and copy it to "/sbin/".

You can generate a local "/Library/Preferences/edu.mit.Kerberos" file by running: 

$> sudo kerberosautoconfig -f /LDAPv3/<yourODhost>  -v 4

The configuration does not refresh by itself, so you need to run this again if something changed. 

I still have a lot to learn about Kerberos on Mac, I'll keep you posted.