Users can log into PCs using Active Directory credentials but not Macs

[burnettb]

Hey everyone! I don't think this is a Jamf issue but it may be so I thought I would post it here for all you experts out there.

Our environment uses Active Directory to allow users to log in to both PCs and Macs. Though we are mainly a Windows environment, we have several Macs and are getting more and more. We are now having users who will randomly be able to log into PCs but not Macs. Does anyone know how to fix this, or what may cause this issue?

We have tried resetting user passwords in Active Directory, and checked security permissions but nothing seems to work. The last time this happened, we worked on it for a week or so and though nothing fixed it right out, it suddenly started working again one day. We couldn't pin point anything that may have fixed it however.

We bind to Active Directory, and then set the preferred domain in Directory Utility to our domain. I haven't been checking the box however that allows users to log in from any domain in the forest. Could it be that we don't have this boxed checked and that's what's doing it? It has worked in the past without this option checked though. Any help I could get would be greatly appreciated. Thanks!

[perrycj]

I'm assuming you are attempting to bind through the imaging process and using a binding script from your JSS? What version of JSS are you on?

Have you tried manually binding the macs with directory credentials or just credentials that have access to bind machines? Do you get the green orb in Users & Groups that the mac is bound?

[burnettb]

We actually manually bind after the imaging process. We found that if we only bind during the imaging process something happens and users can't log in. I do get the green orb, and other users can log into the computer just fine. It sounds like an Active Directory issue but if the user can log into a Windows machine, and other users can log into that computer with no problems I don't really know what to think.

[burnettb]

We actually manually bind after the imaging process. We found that if we only bind during the imaging process something happens and users can't log in. I do get the green orb, and other users can log into the computer just fine. It sounds like an Active Directory issue but if the user can log into a Windows machine, and other users can log into that computer with no problems I don't really know what to think.

[perrycj]

Alright so what are the exact fields you have checked off in the user experience tab? And this may seem like a silly question but you're trying to log in while connected via ethernet and not wifi, right?

[Kaltsas]

We have several domains in the forest with users having accounts in at least two domains, I had to write a script that sets the search order after the bind. It's simple but it cleared up the issues in my case where users were authenticating against the wrong domain.

#!/bin/sh
dscl /Search -delete / CSPSearchPath "/Active Directory/xxxxxxxx/All Domains"
dscl /Search -append / CSPSearchPath "/Active Directory/xxxxxxxx/xxxxxxxx.uiowa.edu"
dscl /Search -append / CSPSearchPath "/Active Directory/xxxxxxxx/xxxx.uiowa.edu"
dscl /Search -append / CSPSearchPath "/Active Directory/xxxxxxxx/xxxx.edu"
killall opendirectoryd

[alexjdale]

Are you mapping the local UID and GID to attributes in Active Directory? If so, make sure those attributes are populated correctly in the AD user accounts.

We use the native AD plugin (bound via custom scripts) and have mapping to two AD attributes (uidNumber and gidNumber). If those attributes are blank, the user can't log into Macs but can log into Windows just fine.

Another thing to check is drive mapping on login. Sometimes if a user has a "Home folder" set up to Connect (like H: set to map to a file share path), that will fail to mount and the login will fail. I make sure user accounts have a home folder set to "Local path" instead (in the Profiles tab in ADUC).

[glutz]

Mappings could be the issue but less likely if it has worked on some and you haven't changed your methods. One thing that I have seen in the past is if you have multiple AD controllers located in other sites around the country or world. What happens is if site awareness is not configured in both DNS and in AD your Macs could be authenticating somewhere else far away. Another issue that could be compounding this and was exceptionally painful for Mt. Lion users where it would time out due to either latency or combo of latency and OU complexity. In Mavericks they have resolved the OU search issue which in some cases caused time outs. But for ML users and if they had never logged in to their machine they couldn't get in and if they already have cached profile the user would log in after that 10 minute time out. I have some additional logging methods I could post if you need it that helped track our issue around ML.

[jrusterucci]

We actually do a manual bind after the imaging process. As part of the imaging we select Users $ Groups from System Preferences and make sure that the "Network Account Server" is set to "MULTIPLE" with the green orb. To correct, select EDIT and ensure that Active Directory is in the number 2 position (listed second) with the Apple Server (Open Directory Server use ONLY the IP address) in the number 1 position (listed first), then save and close. All users in the AD should not have any issues logging into either device. Of course, barring all other aspects of the setup are completed appropriately. Good luck!

[thoule]

What about command line login? A couple command line things to look at: type: id username (subbing a valid user short name)
That should return info about the user. Basically, you can confirm directory services is talking to AD.

Also try logging in as the user command line. Type: login username
..and see if you get in. If so, we can track down what's missing from login info. Oh... Anything in logs?

Good luck Todd