User can't unlock screensaver when login is LDAP authenticated

Alan Trewartha wrote:
i feel pretty foolish now.

i managed to overlook one crucial LDAP mapping - of PrimaryGroupID (to #20 in our setup). which has the effect of letting you login but messing up permissions enough to fail the screensaver authentication of "authenticate-session-owner-or-admin"

😟

anyway, posting in case this is ever useful to anyone else. (and in case anyone is paying attention - i found this out BEFORE i submitted a bug!)

I am currently having this problem with a couple of users I have upgraded to Leopard.

As far as I am aware, the default setting is for the default group to be 20 (Staff) which is the case for these users. So what is the issue? Should it be something else? Your post does not make it clear what your solution was.

I would be grateful if you could provide more details.

As I am using a standard Leopard client connected to a Leopard Open Directory Server, all I did was add the server's IP address in Directory Utility on the client and use 'LDAP mappings from server' which is the default.

I am not binding the client machine to the Open Directory server (so I have not entered any LDAP authentication details).

This works fine when in the office for creating mobile accounts and logging in as a mobile account, and for LDAP searches via Apple AddressBook or the Directory program. Kerberos logins also work fine when in the office, and Leopard (unlike Tiger) even automatically renews Kerberos tickets.

I was given this hint by some really awesome co-workers:

to allow the screensaver to work with a user's Kerberos password. Add the following mechanisms to the 'authenticate-session-owner-or-admin' key of the /etc/authorization file

<key>mechanisms</key>
<array>
<string>builtin:authenticate</string>
<string>builtin:krb5authnoverify,privileged</string>
</array>

That should allow either a local admin or the kerberos user to unlock the screensaver. Note, we use kbr5authnoverify since we don't use Kerberos keytab files. If you do use keytab files, I think you'd want to use 'krb5authenticate' in place of 'kbr5authnoverify'.

Here's what the entire 'authenticate-session-owner-or-admin' structure would look like in the /etc/authorization file:

<key>authenticate-session-owner-or-admin</key>
<dict>
<key>allow-root</key>
<false/>
<key>class</key>
<string>user</string>
<key>comment</key>
<string>Authenticate either as the owner or as an administrator.</string>
<key>group</key>
<string>admin</string>

<key>mechanisms</key>
<array>
<string>builtin:authenticate</string>
<string>builtin:krb5authnoverify,privileged</string>
</array>

<key>session-owner</key>
<true/>
<key>shared</key>
<false/>
</dict>

It's been triple tested and works in our situation.

Alas, the user suffering the problem the worst (and therefore my guinea pig) reports the krb5authnoverify option did not cure the problem but at least made it no worse. The krb5authenticate option however made it fail even when in the office.

Sorry to hear that John, but I don't think this is a fix for your situation. From your previous post it sounds like your using solely Open Directory accounts to log into your computers. Open directory accounts should be able to unlock without modification to the etc/auth file. Can you provide more detail to your specific setup and issues, perhaps we can figure it out.
Rusty

Russell Myers wrote:
Sorry to hear that John, but I don't think this is a fix for your situation. From your previous post it sounds like your using solely Open Directory accounts to log into your computers. Open directory accounts should be able to unlock without modification to the etc/auth file. Can you provide more detail to your specific setup and issues, perhaps we can figure it out.
Rusty

The user has a MacBook running Mac OS X 10.5.6. They are using a 'mobile' account, i.e. one that was created at first login to their Open Directory account. The account details are therefore synchronised to the Open Directory account. (I am not synchronising the contents of their home-directory.)

The server was a Xeon Xserve running Mac OS X 10.5.5 at the time the mobile account was created but has now been upgraded to 10.5.6.

When in the office the MacBook can (obviously) contact the server and the user has no problems waking the screensaver password. When at home they do not have a link to the Open Directory server and typically attempts to wake the screensaver fail (I believe if you keep trying it might eventually succeed).

A local administrator account on the same MacBook can wake the screensaver when this happens but I cannot give admin level passwords/accounts to ordinary users.

I have not tried creating the user with a local 'ordinary' user level account as that does not fit with our environment. This is a good point, I suspect it would work, not that that helps much. As a different aspect a local 'ordinary' account would not be able to unlock the screensaver of the mobile user account (unlike a local admin level account).

When in the office everything works fine including Kerberos logins. When the screensaver is not locked the user remotely has no problems. Rebooting (forcible in these cases) does let the user login to the MacBook using the same account even when remote from the office.

SInce I upgraded from tiger to Leopard [ a while ago] I have had an equivalent problem.
I need to unlock screen saver using a local admin account
this is weird because my account have admin privilege anyway, I am the sole user of my laptop..

This is a purely local problem for me
I went to genius bar on that issue they had no clue.
This is specific to my account created before upgrading to leopard for a new account created under leopard do not have this issue.I tried it.
It have to do with some local settings/privilege but I have no clue which one.
Not a big deal in the end but i would love to know how to fix that tough..

Message was edited by: jf.leon

We also have this issue. The computers are bound to the AD. when the screen saver kicks in, sometimes the AD user can not log in, but the local admin can. Where would one change the LDAP mapping to test and see if this is the problem.

When this problem happens, i.e. when a laptop is away from the office and a (Mobile) user account cannot unlock the screen saver (but a local admin account can), the problem will go away without a reboot or logging out once the machine is back in the office.

Obviously once back in the office the machine (laptop) can then contact the directory server (an Apple Mac OS X 10.5 Open Directory server in our case).

To some extent this is somewhat similar behaviour to what one sees with Kerberos. When out of the office Kerberos to the server even via VPN does not work because it is using an external DNS server and this breaks Kerberos because it cannot look up the office servers. When back in the office Mac OS X 10.5 client (Leopard) unlike Tiger now automatically will renew a Kerberos ticket (with Tiger you had to manually renew a Kerberos ticket).

I am hoping Mac OS X 10.5.7 which appears to be due 'real soon now' - perhaps Tuesday 28th April might include a fix for this.

John Lockwood wrote:
I am hoping Mac OS X 10.5.7 which appears to be due 'real soon now' - perhaps Tuesday 28th April might include a fix for this.

10.5.7 did not fix it. 😟

I will now wait for 10.6 and do a completely fresh install.