Open Radar

 
Summary:
We've been using an OpenLDAP server for a while to provide directory services to Mac and Linux clients, along with an MIT Kerberos KDC server for authentication. Both of these are running on an Ubuntu Linux 10.04 server. I was trying out setting up Lion as a client with these and found that alarmingly, the client seems to allow any network user to log on/authenticate with an incorrect password.

We had been using the same setup for a while with Snow Leopard, and found that by extending the OpenLDAP server schema with the apple.schema file from Open Directory, and adding the apple-user objectClass to our user records, we could add the required authAuthority attributes to the user records to tell OS X clients to authenticate the user via Kerberos. The only authAuthority attributes that we've added are the ;Kerberosv5; ones - there is no Apple Password Server involved.

Steps to Reproduce:
1. Start with an existing MIT Kerberos KDC, serving one realm "REALM.ORG" and an existing OpenLDAP server using the RFC2307 schema for users and groups (running on linux)
2. Extend its schema with the Apple schema, including the apple-user object class and the authAuthority attribute.
3. Create a user entry 'testuser' on the OpenLDAP server, with the apple-user objectClass, and create a principal for that user, 'testuser@REALM.ORG' on the KDC.
4. Add the required authAuthority attribute to testuser's entry on the OpenLDAP server, with a value of ";Kerberosv5;;testuser@REALM.ORG;REALM.ORG". Make sure the user entry for testuser on the OpenLDAP server has *no* userPassword attribute, the user's password should only be known by the KDC.
5. Add the OpenLDAP server as a Directory server to a client machine running OS X 10.7, using Directory Utility. Set it up to use RFC2307 mappings but customise the Users record type to map the AuthenticationAuthority attribute type to the 'authAuthority' attribute on the server.
6. Reboot the client, and log in as 'testuser' with the correct Kerberos password.
7. Open Terminal and enter 'klist', note that credentials have been obtained:
Credentials cache: API:1000:1
        Principal: testuser@REALM.ORG

  Issued           Expires          Principal
Jul 21 10:30:28  Jul 21 20:30:28  krbtgt/REALM.ORG@REALM.ORG
8. Allow 'testuser' to administer the client machine by logging in as a local admin on the client machine and ticking 'Allow user to administer this computer' for 'testuser's acount in System Preferences, reboot the client for changes to take effect.
9. Log in as 'testuser' again, and go to a pref. pane in System Preferences that requires authentication to make changes - click the 'Unlock' icon and enter an incorrect password
 
Expected Results:
The screen should shake to indicate an incorrect password and the padlock icon should stay locked

Actual Results:
The padlock icon unlocks, and everything else authorizes the user to perform changes, as if the user had entered their correct password.

Regression:
The same setup - OpenLDAP server with apple.schema, user records with authAuthority attribute added, Kerberos authentication only - all worked as expected on Snow Leopard. Every time users entered their password (e.g. to log in or authenticate in System Preferences) they would be authenticated against the KDC, and not permitted to proceed if Kerberos authentication failed.

Notes:
It seems to be every place that a password is requested to authenticate will accept incorrect passwords, for example login, sudo, etc. 

When the incorrect password is entered I can see an attempt being made on the KDC to obtain a ticket with the incorrect password: (from the KDC log)
Jul 21 11:17:24 homeserver krb5kdc[11599]: AS_REQ (4 etypes {18 17 16 23}) <client's IPv4 Address>: NEEDED_PREAUTH: testuser@REALM.ORG for krbtgt/REALM.ORG@REALM.ORG, Additional pre-authentication required
Jul 21 11:17:24 homeserver krb5kdc[11599]: DISPATCH: repeated (retransmitted?) request from <client's IPv6 Address>, resending previous response
Jul 21 11:17:24 homeserver krb5kdc[11599]: preauth (timestamp) verify failure: Decrypt integrity check failed
Jul 21 11:17:24 homeserver krb5kdc[11599]: AS_REQ (4 etypes {18 17 16 23}) <client's IPv4 Address>: PREAUTH_FAILED: testuser@REALM.ORG for krbtgt/REALM.ORG@REALM.ORG, Decrypt integrity check failed
Jul 21 11:17:24 homeserver krb5kdc[11599]: DISPATCH: repeated (retransmitted?) request from <client's IPv6 Address>, resending previous response

The failure to authenticate against the KDC doesn't seem to deter OS X, though. I also see the following lines in the secure.log file when 'unlocking' a preference pane:
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_authenticate(): Got user: testuser
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_authenticate(): Got ruser: (null)
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_authenticate(): Got service: authorization
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_authenticate(): Context initialised
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_authenticate(): Stashing kcm credentials in enviroment for kcminit: testuser@REALM.ORG
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_authenticate(): pam_sm_authenticate: ntlm
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_acct_mgmt(): OpenDirectory - Membership cache TTL set to 1800.
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in od_record_check_pwpolicy(): retval: 0
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Establishing credentials
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Got user: testuser
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Context initialised
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Got euid, egid: 0 0
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Done getpwnam()
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Done setegid() & seteuid()
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): pam_sm_setcred: init credential cache
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): pam_sm_setcred: storing credential for: testuser@REALM.ORG
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Got cache_name: API:1000:2
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Environment done: KRB5CCNAME=1000:2
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Cache closed
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Done cleanup2
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Done cleanup3
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Done seteuid() & setegid()
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): Done cleanup4
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): pam_sm_setcred: ntlm
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in ac_complete(): ac_complete returned: 0 for 1000
Jul 21 10:16:26 clienthostname authorizationhost[4384]: in pam_sm_setcred(): pam_sm_setcred: ntlm done
Jul 21 10:16:26 clienthostname com.apple.SecurityServer[44]: UID 1000 authenticated as user testuser (UID 1000) for right 'system.preferences.accounts'
Jul 21 10:16:26 clienthostname com.apple.SecurityServer[44]: Succeeded authorizing right 'system.preferences.accounts' by client '/Applications/System Preferences.app' [4378] for authorization created by '/Applications/System Preferences.app' [4378]
Jul 21 10:16:26 clienthostname com.apple.SecurityServer[44]: Succeeded authorizing right 'system.services.directory.configure' by client '/Applications/System Preferences.app' [4378] for authorization created by '/Applications/System Preferences.app' [4378]
Jul 21 10:16:26 clienthostname com.apple.SecurityServer[44]: Succeeded authorizing right 'system.services.directory.configure' by client '/usr/libexec/opendirectoryd' [2829] for authorization created by '/Applications/System Preferences.app' [4378]
Jul 21 10:16:26 clienthostname com.apple.SecurityServer[44]: Succeeded authorizing right 'system.preferences' by client '/System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/writeconfig' [4387] for authorization created by '/Applications/System Preferences.app' [4378]

After the incorrect password has been entered, I notice an extra Kerberos credential cache appears in the list of credentials returned by 'klist -l', but the cache contains no actual TGT - the output of klist for that cache is:
Credentials cache: API:1000:2
        Principal: testuser@REALM.ORG

  Issued    Expires    Principal

The same empty credentials cache shows up as a new 'identity' in Ticket Viewer, and with every incorrect password attempt it seems a new one is created.