We are trying to get binding working through Big Sur. Our configuration profile for binding worked previously in Catalina, but now it doesn't work on Big Sur.
When looking at Active Directory, the machine says it's binded but we can't seem to log in with our domain accounts.
Does anyone have this issue in Big Sur? Any suggestions/tips would be appreciated.
While binding might work for non-mobile, shared devices (e.g. iMac in a lab), it can be a headache for mobile devices deployed in a 1:1.
I'd recommend looking at alternatives to binding, like the Kerberos Single Sign-on
Extension. Pair this with authenticated enrollment and pre-setting the local account full name and short name to match the directory, and you have most (if not all) of the benefits of binding without the headache.
Just my $0.02
What happens if you skip the config profile and bind with Directory Utility or
dsconfigad? In general, binding works and is supported in Big Sur. There is a known bug, however, where an AD user with a mobile account doesn't get a login keychain on their first login.
@cbrewer We were able to fix the plugin error by adding the computer to our Windows AD list. However, even though manual binding is a successful now, we still cannot log in with our domain accounts. We're pretty stumped at the issue. I will update this post once we figured whats with our binding method and Big Sur.
Do you have the same issue if you use a script? Sample below:
#Bind to AD computerid=`scutil --get ComputerName` dsconfigad -f -a $computerid -domain ad.yourcompany.com -u "adbindingaccount" -p "adbindingpassword" -ou "OU=OUWHERETHEYWILLLAND,DC=ad,DC=yourcompany,DC=com" sleep 1 #set advanced options dsconfigad -useuncpath disable sleep 1 dsconfigad -passinterval 0 sleep 1 # Enable encryption dsconfigad -packetsign require dsconfigad -packetencrypt require # Restart opendirectoryd killall opendirectoryd sleep 5
I have started experiencing this exact same problem on the new M1 Mac minis we have gotten. I have gathered the logs and submitted a report to Apple, and am now working with one of the techs on this issue. I have 31 Mac minis I need to get working, so it's a priority for me and will share whatever resolution Apple offers.
Similar issue, getting back to basics found ARM machines can no longer resolve our Active Directory Domain name... Intel machines are unaffected... believed we were having a DNS issue - all records check out...? Testing more. Get back to you if I find something.
Found Sophos Endpoint and Cisco AnyConnect System Extensions clashed and caused this issue. Am waiting for Sophos to update the client about this known issue of not working with some VPN clients.
Hello! Did you get an update from Sophos? We use Sophos and am looking at all possibilities that may be causing this to be an issue before looking at alternatives like Jamf Connect, Kerberos, etc.
Cisco and Sophos really weren't interested in getting both installed software working 'together'... Troubleshooting showed as soon as either the system extensions (manual or config profile) were installed at the same time (no order), our domain was no longer accessible. Appears to be a shared resource dependency issue from the system extension, they just don't like each other...
I did edit the Host file for testing which worked but didn't see this as a solution.
Am about to test Jamf Protect, hearing good things.
Can you advise how you discovered the clash between Sophos Endpoint and Cisco AnyConnect? We're using a whole suite of McAfee endpoint products, as well as Cisco AnyConnect. I can see there are socket errors in console after trying to establish Kerberos, but I'm not able to tie it back to Cisco or McAfee just yet. Cannot even bind now.
Any update on this? M1 Mac Mini's we are needing to bind for a shared lab setting. Having issues binding. 5200 error.
Console entry says 'KDC is unreachable - 'unable to reach KDC in realm '__our AD domain name__', tried 0 KDCs'
Was looking at this: https://www.blackvoid.club/how-to-join-a-mac-in-microsoft-active-directory/
That was published in 2019, these computers are 11.3 Big Sur and do not have a /etc/krb5.conf file, they have a krb5.keytab file though.
Has anyone received any updates? I am experiencing this issue with all M1 computers. I can connect to AD but no one but a specific group of users can sign in. Where as intel computer has no issue letting anyone sign in. (OS does not seem to be affected as some intel computers are on Big Sur 11.5 and bind and connect with no issue)
Apple is aware of the issue, as I have put in a support ticket. They don't plan on addressing it, until the release of Monterey. I had to find some intel Mac minis and not replace some iMacs while I wait for Apple to iron out the problem. Something about DNS not being updated correctly, when binding to AD and a multiple domain environment. The ticket is still open with Apple.
Long story, short, I have to wait for Monterey but still could not get a clear definitive answer if it would actually fix the problem.
I wish. It is still an issue and unfortunately (well, fortunately) for me, I am retiring at the end of this month and will be handing this issue off to my co-worker, who has been brought up to speed on the problem and I have given him the ticket number and I informed the Apple tech I am working with, that it is still an issue and to resume troubleshooting with my co-worker.
We are looking into Jamf Connect and Azure as a way to get around this.
I have found that recent versions of Big Sur and Monterey are working well when bound to AD - including many M1's.
Some things to check...
Is your AD forest and domain functional levels current?
Are your Macs set to use domain controllers for DNS?
What are your Macs set to for a time server? Is the client time aligned with your domain time?
Have you checked the service principal attribute on your Mac AD computer objects? What do those look like?
You say you can't login, but can you use dscl to query AD?
Example: dscl /Search read /Computers/"adComputerName" RecordName
I have tried all the above to no avail. We thought the keychain issue was related to AD binding and using mobile accounts, but the keychain issue is still there (not binded to AD, and we created a local account).
What we have noticed is if we don't enroll the device in JAMF, the keychain issues disappear. As soon as we enroll the device, the login keychain folder disappears and we start receiving keychain errors.
So we started from scratch. Wiped the hard drive, and reinstalled Monterrey. No application deployments, no policies, no configurations. After a reset, the only thing happening is the MDM profile installation, and the keychain issues start; if we remove the MDM profile, keychain issues go away.
Any new updates on this issue? Our Mac devices will not open the Self Service portal. No login keychain is being created. We also have domain users who can't sign into Apple devices, but it's inconsistent. Some people can sign in, some can't. Kerberos SSO package can fix the sign in issues, but not the keychain issue.
No updates and no fixes yet.
The self serve crashing I have experienced and found a thread on Jamf that stated if the category names were over 32 characters, it would crash. After shortening the names, I can consistently open Self Serve and I have had no other users report the issue.
Not sure if this is a fix for everyone, but it seems to be working for us in our environment.
Devices are binded to AD
Mobile profiles enabled
Have the user sign in, open finder, hit cmd+shift+g, type /user in the box, open the user's profile folder, hit shft+cmd+period to show hidden folders, open library, delete the keychains folder, restart. Have the user sign-in. If you have single sign on for apps it may prompt you to update the keychain (requires admin rights).
We've tested this on about ten Mac devices (Cataline and Big Sur). No issues.
I posted in this thread a while ago having issues. We had a large shipment of the M1 iMacs. None of them would bind to AD out of the box. They would only bind after re-imaging them. Very strange. But instead of binding, we're using NoMAD (https://nomad.menu/products/) (which the JAMF Connect product evolved from). But like I said, out of the box, we couldn't get any of these iMac's to bind, NoMAD wouldn't work either. Using the kinit command to test pulling kerberos tickets, no dice. Couldn't contact AD.
I'll admit NoMAD is sort of a 'ghost' product at this point that doesn't get much support, but it works great for us creating local accounts for people, no issues of people coming unbound anymore, etc. Working on latest versions of Big Sur and Monterey. Just FWIW.