Slow Logins, Unable to Login at this time error, and Local Mobile Accounts Issues

[apizz]

OK. Here goes ... We really need help on this one. I'm looking for anyone who uses Active Directory and Local mobile accounts in their environment and how you make it work.

We are experiencing three related, but different issues with our Macs in our environment and have been troubleshooting with JAMF for two weeks now with not much narrowing of what the actual root problem(s) is/are. The issues are as follows:

1. Slow logins, primarily on Mid-2012 Macbook Pros with 5400RPM drives.
2. "User is unable to login at this time" error
3. Local mobile accounts not being created properly

I will explain the relation and details of these issues in a moment ...

We use Active Directory and have mobile accounts created locally on machines our users login to, however we do not enable home sync. All we want to do is to make it easy for our users to login to machines they've used previously and also auto mount their network folder. We were achieving the automounting previously via the Directory Services "Mount home as sharepoint" setting. We used DeployStudio last year with 10.9.5 Mavericks and did not experience any of the above issues in our environment. Our configuration then as it was until recently when we started down this road to resolve these issues was the following:

Advanced Options - User Experience
  Create mobile account at login = Enabled
     Require confirmation        = Disabled
  Force home to startup disk     = Enabled
     Mount home as sharepoint    = Enabled
  Use Windows UNC path for home  = Enabled
     Network protocol to be used = smb
  Default user Shell             = /bin/bash

Advanced Options - Mappings
  Mapping UID to attribute       = not set
  Mapping user GID to attribute  = not set
  Mapping group GID to attribute = not set
  Generate Kerberos authority    = Enabled

Advanced Options - Administrative
  Preferred Domain controller    = not set
  Allowed admin groups           = MASTERSdomain admins,MASTERSHelpDesk_Restrict
  Authentication from any domain = Disabled
  Packet signing                 = allow
  Packet encryption              = allow
  Password change interval       = 0
  Restrict Dynamic DNS updates   = not set
  Namespace mode                 = domain

We recently disabled the mount home as sharepoint setting due to this thread's (https://jamfnation.jamfsoftware.com/discussion.html?id=11004) recommendation to disable the UNC path setting and create an Applescript application to mount users network folders. But this did not resolve our issues.

Issue #1: Slow logins

What initially started us down this troubleshooting path. It was taking new AND returning users roughly 2 minutes to login to Mid-2012 Macbook Pros in our laptop carts.

After much testing, we were able to determine that Sophos Anti-Virus, which we only added to our image this past year, noticeably added to the overall login time of machines. However, the longest login times were when a user was logging in to a machine for the first time after the computer had been restarted. This leads into issue #2 ...

Issue #2: "User is unable to login at this time"

Since we started using Yosemite, we've been getting this error when users attempt to login to a machine for the first time. Initially we only saw this periodically, but once the school year started we saw this on all our Macs regardless of user.

We're able to get around this error by restarting the computer once and having the user login again. However, as previously mentioned it takes several minutes for this user to login. Once the user has been logged in and their local mobile account is created the user does not see this error again. But even when the user is logging into a machine they've already logged into it still takes at least a minute - minute and half to fully login and actually use the computer to any extent.

In our testing, we do not get this error on any of our imaged machines immediately after it's been imaged. But when we come back to the machine the following morning we start seeing this error. No policies are run or settings changed in the interim. We confirmed we get this error on a computer with just 10.10.4 Yosemite and bound to Active Directory manually as well as one imaged via our JSS, so it doesn't appear to be JSS issue.

Various threads point to this error as having to do with the Use UNC path setting used to derive the network location, but disabling this breaks the creation of the local mobile account. So in trying to fix one thing, we break another ...

Issue #3: Local Mobile Account Issues:

So disabling the UNC path setting does not create a local mobile account for the logged in user. But now with the UNC setting re-enabled in our testing we're seeing something else that we are not seeing in our production environment where the user is able to login, but does not create a local user account. It acts like it logs in, but instead actually mounts their network folder and puts the Mac home folder in their network folder.

At this point I really just don't know what to try or do differently to resolve these issues and improve our users experience. Thanks in advance for your help.

[brandonpeek]

Have you tried your luck with 10.10.5? The mDNSResponder service was put back in place with this update after having been replaced with the new DiscoveryD service. This seemed to resolve our login delay issues for our AD-bound Macs.

[apizz]

@brandonpeek, that's the direction I was starting to head ... I'll see what we happens.

[brandonpeek]

It made a big difference for us over here. We were seeing Macs take anywhere from a few minutes to never completing the login. We tried a number of things, but in the end it was 10.10.5 and the reinstatement of the mDNSResponder service that did the trick. It even resolved a SQL connectivity issue for a group of folks that were just absolutely convinced that we pushed some change that broke them.

Some nice details on the whole discoveryD debacle here: MacRumors on mDSNResponder and discoveryD

[mm2270]

FYI, 10.10.4 introduced the change from discoveryd to mDNSResponder, not 10.10.5, http://www.macrumors.com/2015/06/30/apple-releases-os-x-10-10-4/ so I don't think your issues are related to the OS version specifically if you have been testing on 10.10.4.

@aporlebeke, for clarification, are you saying that first login is the slowest once on each Mac, or did you mean its slow at first login after every reboot? If you meant the former, that can partially be explained by the fact that you're allowing the Apple AD plug-in create the accounts and home directories on first login. A lot goes on at that initial AD login attempt. The Mac first checks to see if a local cached account for the AD user exists on the Mac. Once it sees that isn't there, it needs to get information from AD about the user account. Then it creates the local directory services record (what you see when you run dscl . list /Users for example), then it creates the home directory, by copying contents from /System/Library/User Template/ into place, sets the account as the owner of that home directory, and finally, logs you in. While that should all be happening fairly quickly, my experience has shown due to issues with Apple's AD plug-in, or just issues with AD in general, this process can take a while. But, it should be a little faster after that first login.
Is there any possibility you'd be able to pre-create the user accounts prior to first login with a script that uses the createmobileaccount binary? That's kind of how we have things set up, within a custom application post imaging, so when the user logs in, it doesn't take so long.
If you're saying its always slow even when the account is already cached, then something else is going on.

So, that probably doesn't explain the whole story. I wouldn't be surprised if your Sophos set up is creating some issues here as you mentioned. AV software tends to be set up in a way that it will scan all reads and writes, not just writes. If you think about how much data is being read by the OS during login, its no wonder AV software slows the whole thing down so terribly. Our McAfee software has been known to do the same thing. We went through a hellish process about a year ago of trying to track down why our Macs were literally almost hanging at login, and it boiled down to McAfee scanning being misconfigured, or configured to scan too much. Do you have any exclusions set up for Sophos, or is it just looking at everything going on on the drive?

[apizz]

@mm2270, thanks for all the details on the AD plugin steps.

I've seen other threads refering to the createmobileaccount binary, but don't know much about it or how to go about utilizing it. I'll look into it.

How do you have this configured in your environment with the custom app & how does this shorten the process for when a user logs in for the first time? Does it still apply the local user template for new users?

[ShadowGT]

Hi All,

First time responding on the nation :). I was running into the same issue. But I discovered this thread that helped me out.

https://jamfnation.jamfsoftware.com/discussion.html?id=7799#responseChild41415

Double check that your clients are directly talking to the domain controller rather than the "All Domains" Don't know if this will help, but it so far this has corrected our issue that just started plaguing our macs. In my environment my login times reported were from 30 to 2mins in some cases. After correcting the issue, we have gained back our original login speeds. I hope this helps.

[lionelgruenberg]

@aporlebeke Total shot in the dark... but read up on the @rtrouton post Bypassing the Mavericks managed preferences login check and deploy this workaround to a test machine for kicks?

[davidacland]

On the "Unable to login at this time" issue, I've often had this related to having the SMBHome enabled in the plugin. Specifically these two options:

Mount home as sharepoint    = Enabled
Use Windows UNC path for home  = Enabled

Try switch these off to see if that helps.

If it does, you can get the home mounted with our script here: https://github.com/amsysuk/psu/blob/master/mountHome.sh

and here's a video of my PSU talk on the topic of stabilising AD integration: https://www.youtube.com/watch?v=X8e2gyS8n_Q&index=21&list=PLRUboZUQxbyVydhdMcxGGfEaZc2sFdQk8

Hope this helps.

[apizz]

@davidacland, initially in trying to solve Issue #2, I created an Applescript application to mount the user's network folder thanks to @bentoms so we could disable the mount home as sharepoint setting - https://macmule.com/2011/09/08/how-to-map-drives-printers-based-on-ad-group-membership-on-osx/.

However, after disabling the Windows UNC path setting when a user logs in it doesn't successfully create a local mobile account for the user. It presents a dialog box that the library needs to be repaired and if you look in the /Users folder, the logged in user doesn't have a folder.

It sounds like @mm2270 may have an application in his/her environment that runs at login that would still allow us to use local mobile accounts for our users so we could disable the UNC path setting.

[apizz]

@mm2270, I see your comments on this thread that there was an issue in 10.10.3 that broke the createmobileaccount binary. Given your suggestion here, can I assume that this now been fixed?

[mm2270]

@aporlebeke Hey, sorry for the delay. Yes, 10.10.4 and up fixed the bug introduced in 10.10.3 that broke the createmobileaccount functionality, so there should be no issue using it going forward.

To answer your question from yesterday, our custom application is not something that runs at each login. Its something that was kind of designed to replace the Apple setup assistant process.
Essentially, our Macs are imaged with DeployStudio and sent to customers to set up. Because AD joining and using an AD account are necessary in our environment and I don't foresee it going anywhere soon, a custom process needed to be developed to help with this. Since the Mac could be shipping to someone in a home office far away from a physical wired connection to the office, we needed a way that when a user received the Mac, they could effectively log in with their AD account. But since we don't know users passwords of course, simply pre-creating their account ahead of time is impossible, and they can't log in while off the network unless the account is created with a cached password.
So what happens is, the Mac is set up to auto log in to a temporary account set up during imaging. This account is pretty locked down, so only the custom app launches at login. It checks to see if it can communicate with AD, and if not, prompts the user to either connect to a network, or launch our VPN software and connect that way. It won't continue until it can "see" the network. It then lets them fill in a few details about location and language preference, asks them for the user ID and their password, and verifies these against AD. Once all good, it uses the createmobileaccount binary behind the scenes to pre-create their AD account. Finally, it makes sure the Mac is enrolled in Casper and such, and finally, logs out. The user can now login at the regular OS X login screen to their Mac, even if completely off the network, since their AD account is now a cached mobile account. Finally, it runs a cleanup script that removes the temp account from the machine, enables FileVault for next user (deferred enablement) and initiates a restart so they can turn on FileVault.

Because the app is so custom and because its not something I created, the above is the most I can really talk about it. Its not something I'd be able to give you. Even if I could, its heavily customized for our environment, so its not something you'd be able to just drop into your setup. The app was designed by my colleague and was written in Applesctipt ObjC.

[bentoms]

However, after disabling the Windows UNC path setting when a user logs in it doesn't successfully create a local mobile account for the user. It presents a dialog box that the library needs to be repaired and if you look in the /Users folder, the logged in user doesn't have a folder.

@aporlebeke Sounds like there's an item with bad permissions being deployed to the user library, perhaps via FEU or FUT.

Can you verify that?

[apizz]

@bentoms, it's funny because I just tried disabling the Windows UNC path setting and for some reason now each AD account I try logging in with for the first time does not get the "user cannot be logged in at this time" error AND successfully creates and logs into the local mobile account ... This was not happening originally, so I'm not sure what's different.

I'm doing some more testing to confirm.

[apizz]

After additional testing, after only disabling the "Use UNC Path" setting on machines where before attempting to login as a new user produced a "user cannot login at this time error," the user was able to login without producing the error AND successfully created a local mobile account.

I'm really not sure at this point why we were getting weird issues during our testing where disabling the UNC setting somehow prevented a local mobile account from being created when a user logged in for the first time.

Unfortunately, we are still getting painfully slow login times on these machines. Not installing Sophos shaves off 20-30 seconds of login time, but still over a minute.

A a recent thread mentioned getting faster login times for AD users with the "Perform login hook actions in the background" enabled, but we already had it enabled to begin with.

Any other ideas for improving AD user login times? Does anyone have login time / performance issues in their environment on Macs with HDDs?

[bentoms]

@aporlebeke maybe the post linked in: this?

[davidacland]

@aporlebeke I think the other thread mentioning "perform login hooks in the background" was a specific issue with their setup as they had a few things running (not AD related) at login. Although its usually worth enabling anyway.

[apizz]

Thanks, @davidacland.

@bentoms, I saw that thread but was confused as to what those two settings actually do, especially the bypasslogincheck

[bentoms]

@aporlebeke Sorry, I meant: https://macmule.com/2011/03/11/slow-login-for-ad-mobile-accounts-when-off-the-office-lan/