"You are unable to log in to the user account "abcdefg" at this time"

Sean_M_Harper
Contributor

Hey everyone, getting some really strange errors the last few days on all my macs. To be clear, I am only running AD, and nothing has changed on the mac side of the house what so ever.

Currently if you UNCHECK the "create mobile user account at login" box, network users log in without error. However, once you check this box and try to log in a network user, a dialog box pops:

"You are unable to log in to the user account "abcdefg" at this time" Logging in to the account failed because an error occurred.

Any conversation or help would be great, as we are completely stuck on this side about what would be causing this issue. Note that last week our engineer rolled the DC's, and the problem was gone for the rest of the day Friday, but it has once again returned. I am simply looking for any and all info to try and resolve this issue.

15 REPLIES 15

ClassicII
Contributor III

What os are you running ?

Sean_M_Harper
Contributor

10.8.3 and/or 10.8.4 (happening in both)

vadanx
Contributor

Usually get this issue if the Mac OS doesn't recognise your login as the owner of the home folder in /Users. Mac OS uses a SSID unique identifier (some letters and numbers separated by hyphens) in AD to differentiate user accounts.

If you "ls -l /Users", what output do you get back? Copy paste back here?

Andrew

Sean_M_Harper
Contributor

On a random machine, having this issue:

PAR-MW-1421-06:~ admin$ ls -l /Users total 0 drwxrwxrwt 6 root wheel 204 May 13 08:42 Shared drwxr-xr-x+ 17 admin staff 578 Sep 9 10:31 admin drwxr-xr-x+ 14 bailey.r JANESVILLEDomain Users 476 Aug 23 15:57 bailey.r drwxr-xr-x+ 15 behne.e JANESVILLEDomain Users 510 Aug 23 15:57 behne.e drwxr-xr-x+ 14 deandainig.m JANESVILLEDomain Users 476 Aug 23 15:57 deandainig.m drwxr-xr-x+ 14 degeyter.j JANESVILLEDomain Users 476 Aug 23 15:57 degeyter.j drwxr-xr-x+ 15 denio.a JANESVILLEDomain Users 510 Aug 23 15:57 denio.a drwxr-xr-x+ 17 finster.s JANESVILLEDomain Users 578 Aug 23 15:57 finster.s drwxr-xr-x+ 14 gonzalez.d1 JANESVILLEDomain Users 476 Sep 6 14:23 gonzalez.d1 drwxr-xr-x+ 14 green.b JANESVILLEDomain Users 476 Aug 23 15:57 green.b drwxr-xr-x+ 16 holbrook.l JANESVILLEDomain Users 544 Aug 23 15:57 holbrook.l drwxr-xr-x+ 15 hussmann.d JANESVILLEDomain Users 510 Aug 23 15:57 hussmann.d drwxr-xr-x+ 14 kim.h JANESVILLEDomain Users 476 Aug 23 15:57 kim.h drwxr-xr-x+ 12 macadmin staff 408 Apr 24 12:17 macadmin drwxr-xr-x+ 15 mccollum.a JANESVILLEDomain Users 510 Aug 23 15:57 mccollum.a drwxr-xr-x+ 15 mchapin JANESVILLEDomain Users 510 Aug 23 15:57 mchapin drwxr-xr-x+ 14 mitchell.m2 JANESVILLEDomain Users 476 Aug 23 15:57 mitchell.m2 drwxr-xr-x+ 16 punzel.h JANESVILLEDomain Users 544 Aug 23 15:57 punzel.h drwxr-xr-x+ 16 quillman.b JANESVILLEDomain Users 544 Aug 23 15:57 quillman.b drwxr-xr-x+ 14 stordock.m JANESVILLEDomain Users 476 Aug 23 15:57 stordock.m drwxr-xr-x+ 15 wauchop.r1 JANESVILLEDomain Users 510 Aug 23 15:57 wauchop.r1

vadanx
Contributor

Nothing obviously wrong there.

Are you having this issue with every single AD user on this single machine? Is this only for AD users who already have cached accounts? Or new AD users as well?

Do you use UNC home shares? Are the permissions correct to mount it?

If 10.7 and below try ssh'ing in to the Mac and running "tail -f /var/log/secure.log", or else with 10.8 run "tail -f /var/log/system.log" (could try syslog -w as well), see if it comes up with a better reason as to why it doesn't let you login.

I often find it's due to either incorrect permissions on UNC mount (smb/afp mount errors), user has lost ownership or permissions to their home folder (usually different SSID) or one of the account aliases (email address etc) has changed and doesn't match the cached account on the Mac (last 2 would only affect returned users with already cached accounts on the Mac).

Andrew

Sean_M_Harper
Contributor

I fixed this issue... with a little insight from vadanx :)

A genius (sarcasm recommended) decided we should use DFS for AD Account home directories. Short story: A script from UMRA or some other program appears to have removed the correct permissions from the parent directory, which in turn did not allow mountain lion to see the child account folder (as 10.8 requires you to have visibility from the parent all the way to the child, instead of just the child itself.)

Thanks for all the help everyone!

vadanx
Contributor

I had this very same issue years ago with returning freelancer users lacking the very same permissions, congratulations on fixing it!

Just FYI this has been an issue at least since 10.6 from my experience.

Andrew

Sean_M_Harper
Contributor

Thanks for all the help!

BK
New Contributor III

@Sean_M_Harper I was having the very same issue. Turns out the UNC network home path was pointing to the wrong server on a bunch of students accounts (+200). It was pointing to the old AD ile Server that was just upgraded. We ending up have to correct the name and put the FQDN such as ABC-ADFS-S1.city.k12.xx.usSTUDENTS

I figured out it had to do with the UNC since when I unchecked "Use UNC Path...." in Directory Utility Binding it started logging in but had no permission and wanted to get an admin account to fix some library files but it did log in.

So moral of the story: Check the Path of the network home and make sure it has the proper permissions!

Rack'Em!

Leal
New Contributor III

I was having the same issue with a single user on a laptop. The UNC path was correct. I turned of the "Use UNC path from Active Directory.." from Directory Utility, had the user login, then enabled it again. That fixed the issue on my end.

Insert-C
New Contributor

This did the trick. Thank you!

jbutler
New Contributor

Post by Leal worked for me.

"I was having the same issue with a single user on a laptop. The UNC path was correct. I turned of the "Use UNC path from Active Directory.." from Directory Utility, had the user login, then enabled it again. That fixed the issue on my end."

J_Martinez
New Contributor III

@Leal @jbutler After a ton of testing I figured out that this was an issue with one of our DFS namespaces not using the FQDN. When it tried to map the drive it would fail every time.

famosoc
New Contributor

Hey team...I had this issue just recently and come to find out the simple answer was to grant the user full control to their home directory. Well anyway that fixed it for me. Hope this helps at some level...

Thanks,
Chuck

lcater
New Contributor II

I had this issue with a certain group of Macs. After some troubleshooting it turns out there was something corrupt in the policy that bound the Macs. After deleting that particular domain and policy and re creating it. It now works fine.