[Imaging] Users Unable to Login after Imaging with 10.7.2 Image

[daworley]

I have seen something similar.

Mine is from a 10.7.2 NetInstaller (taken from the 10.7.2 version of the Install Mac OS X application). I needed a way to verify that the Restore Partition would be there to allow FileVault2 to work for my tests.

The grey login window loads, i type in credentials and it tries to load, and then it bounces back to loginwindow. It looks like it registers the authentication, but cannot load the user's launchd service (or something around that period)

Poking around the system, the plist for the user exists in /var/dslocal/nodes/Users, but they cannot be accessed. Reading online, it was recommended to use the Reset Password utility from the Apple Restore Partition and set up the root user. That did not work.

I am at a loss, and really not confident about being able to support a Lion deployment in the wild.

[#2]

Hi all,

We're having the exact same issue with our Lion image. After imaging we can login fine with local accounts and AD accounts. But if we restart the imaged Mac a few days later, all logins suddenly fail. The login window behaves as described in the posts below. If we enter ">console" and login from there it works fine, even with AD accounts.

I've checked the system log and it shows some failures at the time login is attempted:

Oct 27 11:43:12 MHD1009999 SecurityAgent[1231]: User info context values set for maclabtest
Oct 27 11:43:12 MHD1009999 SecurityAgent[1231]: Login Window login proceeding
Oct 27 11:43:13 MHD1009999 ManagedClient[1226]: MCXCCacheGraph(localhost, dsRecTypeStandard:Computers): The record "localhost" (dsRecTypeStandard:Computers) interferes with the computer cache. Delete this record to resume caching.
Oct 27 11:43:13 MHD1009999 com.apple.loginwindow[1220]: 2011-10-27 11:43:13.359 ManagedClient[1226:b003] MCXCCacheGraph(localhost, dsRecTypeStandard:Computers): The record "localhost" (dsRecTypeStandard:Computers) interferes with the computer cache. Delete this record to resume caching.
Oct 27 11:43:13 MHD1009999 ManagedClient[1226]: MCX.getComputerInfoFromStartup: MCXCCacheGraph() == -2 (MCXCCacheGraph(localhost, dsRecTypeStandard:Computers): The record "localhost" (dsRecTypeStandard:Computers) interferes with the computer cache. Delete this record to resume caching.)
Oct 27 11:43:13 MHD1009999 com.apple.loginwindow[1220]: 2011-10-27 11:43:13.360 ManagedClient[1226:b003] MCX.getComputerInfoFromStartup: MCXCCacheGraph() == -2 (MCXCCacheGraph(localhost, dsRecTypeStandard:Computers): The record "localhost" (dsRecTypeStandard:Computers) interferes with the computer cache. Delete this record to resume caching.)
Oct 27 11:43:14 MHD1009999 loginwindow[1220]: Login Window - Returned from Security Agent
Oct 27 11:43:14 MHD1009999 loginwindow[1220]: AuthorizationRef returned an error (100022), with username = maclabtest
Oct 27 11:43:14 MHD1009999 loginwindow[1220]: This indicates that a SecurityAgent plugin has returned something other than errAuthorizationDenied (usually cancelled) after the auth record is set up.
Oct 27 11:43:14 MHD1009999 com.apple.loginwindow[1220]: AuthorizationRef returned an error (100022), with username = maclabtest
Oct 27 11:43:14 MHD1009999 com.apple.loginwindow[1220]: This indicates that a SecurityAgent plugin has returned something other than errAuthorizationDenied (usually cancelled) after the auth record is set up.
Oct 27 11:43:14 MHD1009999 parentalcontrolsd[47777]: CGSLookupServerRootPort: Failed to look up the port for "com.apple.windowserver.active" (1102)
Oct 27 11:43:14 MHD1009999 loginwindow[47785]: Login Window Application Started

I've never seen such behaviour before and havn't a clue how to begin troubleshooting something like this. Hopefully someone here can offer us some advice because we're pretty stuck at this point.

Cheers, Ron.

[iamkmc]

I managed to quickly correct this via Archive Install from a triage drive
with 10.7.2 installer. At the moment I'm just going through all my packages
that are causing this to happen.

Going see if Apple maybe able to figure out exactly what is broken that is
causing this.

[golbiga]

This all sounds like an issue that I ran into under Snow Leopard. Under accounts in system prefs you can allow or disallow network users to login. You can run into an issue if you allow network users to login, but under options choose "Only these network users:" and leave the list blank. This created for me a dummy group that basically blocks any account from logging in via the login window (I was able to login via console.

While logged via console, use dscl and check for a local group called com.apple.access_loginwindow. This should be the dummy group that is created, you can check the membership of the group to be sure. dseditgroup -o delete -T group com.apple.access_loginwindow should then remove the group, when you log out you should be able to login via the login window. Hope this is still the case w/ 10.7

Thanks
Allen

[#5]

Hi all,

Just when I thought the issue had gone away, suddenly yesterday it surfaced again. After almost a whole week of running perfectly, I decided to shutdown our MBP 13" and started it up again half an hour later. Tried to login with our test account and it cycled back to the login screen again.

I've tried Allen's suggestion below and listed the groups using "dscl . list /groups". There was no group named "com.apple.access_loginwindow" in that list. Looks like under OSX Lion something else is now also causing this issue.

Cheers, Ron.

[davelb20]

daworley,

I'm having this issue on 10.7, were ever able to resolve it?

Dave

[sgarringer]

Yes I have found a solution.

For anyone else having this issue, I believe I have figured out a quick and easy fix. You need to gain access to the OS either through SSH from another box, by booting in Single User or through target disk mode. Check the /var/audit folder and look for a file named "current". This is supposed to be a symbolic link to the latest file in the folder, however on every machine I have seen with this infliction it is actually just a regular file. If you delete this file (Remember to remount / as RW if you are in single user mode) you can then reboot the system and log in normally. There is nothing else you need to do to resolve this.

In my case, the file was introduced by mistake through the use of JAMF Casper to deploy software to a workstation.

[ImAMacGuy]

we get this quite a bit, though I've noticed the Canon EOS v22.24 utilities cd causes this too, there's a couple updates that you can run after installing (before reboot) and it seems to take care of the /current file.

[kirk_magill]

I was having this same issue and jamf support helped me in finding a solution:
running this from the terminal on the offending machine - or through an ssh connecton:

sudo dscl . -delete /Computers/localhost
I was then able to do a sudo mcxrefresh -n username

As long as the machine was listed in my workgroup manager before I tried the mcxrefresh it grabbed the updated mcx settings.

[MrP]

FWIW, we had the same issue here. I tracked it down to an idiosyncrasy in the configuration profiles. Looking in /Library/Managed Preferences/com.apple.loginwindow.plist I saw that "LocalUserLoginEnabled" was set to 0. This made no sense because I had not set this option anywhere and by default a value of 1 is assumed. I disabled all the configuration profiles and removed the com.apple.loginwindow.plist. I enabled one at a time then ran "sudo jamf mcx", then re-examined the plist until I figured out which profile did it. I found that a profile with only the Computer payload "Restrictions" was causing that parameter + value to be added and set. Before adding that the parameter "LocalUserLoginEnabled" wasn't listed in the plist. What is odd is that the restrictions payload in the JSS interface doesn't say anything about login accounts of any sort. By adding the payload "loginwindow" and checking the box "Local-only users may log in" the parameter "LocalUserLoginEnabled" had it's value changed from 0 to 1, and users could then login.

This is on Mavericks.