Active Directory not allowing new users on Macs.

[RRTXmacAdmin]

Last Friday I noticed that our Mac systems started not allowing new users to log in (not creating mobile accounts, etc) when authenticating via Active Directory. Existing users can log into their mobile account on the system, but network resources do not appear to be available.This feature has been functional, and nothing has changed in the JSS or on the image. I have asked my team if anything has changed on the back end, and I have been reassured nothing has. This has seemingly come out of nowhere. With that, I am no expert in Active Directory so I am hoping that someone has seen this or something similar. Any help is much appreciated.

[grecopj]

Have you tried to unbind the machine and bind again to the AD server? I had a lab of 24 machines and about 12 of them could not authenticate. I had to unbind and rebind to correct the issue.

[emily]

I'm pretty sure this is a Mavericks issue; my users see that too. From what I've found, it takes an AD-bound Mac on Mavericks about a minute to check into the AD service, so when a machine first boots up, it doesn't show that network accounts are available right away. In our environment in particular, a Mac needs to sit on the login screen on the LAN (not Wifi) for a good 45-60 seconds before it sees network accounts.

[hodgesji]

Take a look at this discussion thread and see if it helps:

https://jamfnation.jamfsoftware.com/discussion.html?id=8775

[easyedc]

Apple has indicated to us that this is a known issue in OS X 10.9.x. They did say that if you can run either a

$ dseditgroup -o checkmember -m <username> <groupname>

or a

$ id <username>

and if you get a complete response to the Users membership/account information, that means it should have replicated out enough for logins. During testing, that does not appear to be the case. Apple followed up with additional information saying to try to remove that user from the group upon whose membership his authentication success is predicated. This should disallow access entitlements which are based on membership in the group. At that point do a temporary permissions change that would allow this user to access the share through some other entitlement. Options being:

• Make this affected user the POSIX owner of the share (recursively) and test his login that way. • You could temporarily change the permissions on the share so they were read-write-execute for “Everybody” (which includes this user) and test his login capability in that situation.
• Apple suggested to disable the profile that constrains access to the share. I brought up the fact that I am pushing configuration profile through JAMF with the setting to "allow access to: AD Group" and to try to just simply disable that and see if that worked.

I'm part of the way through these (we have a not-so-fast process to manipulate AD user accounts.

[Olivier]

Run "odutil set log debug" just before user tried to login, then disable it immediately afterwards with "odutil set log default", and look into logs generated in /var/log/opendirectory* (do it through SSH for example).

Logs are extreme verbose, but the reason why logon is rejected will be there.

Got one case like yours long time ago, the user inadvertently disabled the checkbox "Allow network users to log in at login window" in Users&Groups, which enables an access-list, that prevents all network logging attempts, but those who are already cached. Managed to see this ACL as it was logged with help of "odutil set log debug"...

[mrshultz]

I had this problem, there was an old Novell drive being mapped by AD, took that out and the user was able to login.