Big Sur Active Directory Binding

kpeng09
New Contributor

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.

28 REPLIES 28

jcarr
Release Candidate Programs Tester

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

cbrewer
Valued Contributor II

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.

kpeng09
New Contributor

@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.

efil4xiN
Contributor II

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

fgonzale
Contributor

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

JoySeeley
New Contributor III

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.

mark_mahabir
Valued Contributor

@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!

JoySeeley
New Contributor III

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!

EREAFSNJAMF
New Contributor III

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.

RamosC
New Contributor II

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.

JoySeeley
New Contributor III

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....

 

EREAFSNJAMF
New Contributor III

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.

whiteb
Contributor II

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.

RamosC
New Contributor II

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)

JoySeeley
New Contributor III

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. 

KB81
New Contributor

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

JoySeeley
New Contributor III

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

ChrisD1
New Contributor II

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.

JoySeeley
New Contributor III

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.

cbrewer
Valued Contributor II

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

braillle
New Contributor III

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.

cbrewer
Valued Contributor II

It sounds like you have a different issue than what was being discussed in this thread. I would try working with Jamf Support.

braillle
New Contributor III

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.

JoySeeley
New Contributor III

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.

braillle
New Contributor III

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.

whiteb
Contributor II

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.