Directory Bound Computers going offline in Jamf

anadeem
New Contributor II

Hello!

 

We are unable to log into any computer that is bound to Active Directory with the mobile account that is created.

 

We've noticed that:

- On Jamf, impacted computers will stop checking in.

- Computers will flap on the network, that is, they will intermittently lose connection and gain connection.

- When we log into a local administrator account, use sudo jamf policy and other commands and log out, the mobile account will be accessible for only a temporary period of time.

- AD connection is valid, and all iMacs are in the proper OU. There are no duplicate entries.

- All computers are on Sonoma.

- We use Crowdstrike, and no alerts have been triggered.

 

Any ideas as to why this may be happening?

1 ACCEPTED SOLUTION

anadeem
New Contributor II

Since FileVault was enabled on these shared computers, that is what caused the inability to login, nothing to relate to AD, in certain respects.

View solution in original post

7 REPLIES 7

AJPinto
Honored Contributor III

You mention the devices are intermittently losing network connectivity, honestly that is where I would start. 

 

This likely has nothing to do with domain binding which is a bad practice on macOS or Jamf. However, long uptimes are known to cause launch daemons like the Jamf binary to hang. Just like any program, Jamf's framework can hang, and the chances of this happening go up the longer it's been since a device rebooted.

 

What I would do, make sure devices are being rebooted weekly. If that fixes your issues move on. If reboots don't fix your issues, start looking at your network equipment for errored ports, DNS issues, 802.1x configurations, and so on. Any network connectivity issues need to be resolved before attempting to address any other issues.

anadeem
New Contributor II

Hello!

 

Apologies for not detailing a bit more with networking, but we did run some extensive testing with networking in the building. For one, we ran hardware testing on a couple tests to see if the network card was the issue, that came out to be clear.

Secondly, we connected a Windows laptop to the existing ethernet in one of the impacted spaces, and that laptop remained on, did not flap whatsoever. We brought an impacted iMac from one of the locations down to another area, it continued to flap (the same one we performed a hardware test on to verify it wasn't a network card issue). The weird thing is that even though these computers intermittently disconnect and connect, as long as we log into the admin account and then log into a mobile AD account, it will work again. Plus, as far as I know, mobile accounts do not require an active internet connection either. We have also restarted some machines we've done testing on, with no success. One machine we managed to get back online for around...3-4 days? Same issue started happening once more.

AJPinto
Honored Contributor III

You mention logging in to the device brings it online. Are you logging in to FileVault or the macOS Login Window? FileVault has no concept of network connectivity, if the devices are sitting at the FileVault screen that would explain your situation.

anadeem
New Contributor II

For a subset of machines, it looks like FileVault is already enabled, are you suggesting that for every user, it is 'attempting' to activate FileVault? We do not see prompts to enable FileVault when attempting to log in.

garybidwell
Contributor III

read this Apple article on checking DNS consistency for Active Directory to eliminate its a bind issue.

https://support.apple.com/en-us/101872

If any for the four dns-s queries don't come back with valid results for your domain you'll get all sorts of issues with AD bound Mac's

anadeem
New Contributor II

We ran those commands and the only one that did not come out with RDATA was the dns-sd -q _gc._tcp.example.com. The rest returned valid IP addresses. We were also able to ping the domain controllers and ldap server.

anadeem
New Contributor II

Since FileVault was enabled on these shared computers, that is what caused the inability to login, nothing to relate to AD, in certain respects.