Big Sur Active Directory Binding

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.

No issue binding Catalina 10.15.7 or Big Sur 11.2.3, using JAMF built in utiliy

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.

@JoySeeley I am also beginning to see issues, particularly on M1 devices. In particular, our root and intermediate certificates are not automatically getting trusted whereas they were in previous OS revisions.

I would be very interested in seeing any feedback from Apple!

I have gotten a response, but all they wanted were the logs. I keep updating and I have also told Apple that there is this thread with others having the same issue.

Stay tuned!

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.

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.

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.

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)

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.

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 also asked about Jamf Connect, but Apple was unwilling to state if it would resolve the issue or not.  Or at least work around it....

Any chance you can share the support ticket number or information? I'd like to add my info to that as I am having the same issue

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.

[101417087448] Newly deployed macOS devices are unable to authenticate users

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.

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.

Do you get an answer from Apple on that issue with M1 Macs where no login is possible? We still have this problem also with macOS Monterey 12.1 installed.

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