Posted on 03-26-2021 12:21 PM
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.
Posted on 03-26-2021 12:40 PM
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
Posted on 03-26-2021 12:43 PM
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.
Posted on 04-01-2021 04:03 PM
@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.
Posted on 04-02-2021 01:39 PM
No issue binding Catalina 10.15.7 or Big Sur 11.2.3, using JAMF built in utiliy
Posted on 04-05-2021 09:51 AM
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
Posted on 05-10-2021 05:06 AM
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.
Posted on 05-10-2021 10:58 AM
@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!
Posted on 05-18-2021 05:26 AM
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!
Posted on 05-24-2021 06:21 PM
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.
Posted on 07-20-2021 09:40 PM
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.
Posted on 09-13-2021 10:31 AM
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.
Posted on 09-14-2021 04:31 AM
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....
10-04-2021 08:53 PM - edited 10-04-2021 08:55 PM
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.
Posted on 09-30-2021 09:03 AM
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.
Posted on 07-19-2021 01:13 PM
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.
Posted on 09-13-2021 10:30 AM
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)
Posted on 09-14-2021 04:29 AM
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.
Posted on 09-23-2021 03:19 PM
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
Posted on 09-30-2021 09:27 AM
[101417087448] Newly deployed macOS devices are unable to authenticate users
Posted on 12-23-2021 02:40 AM
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.
Posted on 12-23-2021 10:45 AM
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.
Posted on 12-23-2021 11:51 AM
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
Posted on 01-06-2022 09:58 AM
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.
Posted on 01-06-2022 11:12 AM
It sounds like you have a different issue than what was being discussed in this thread. I would try working with Jamf Support.
Posted on 10-19-2021 06:18 AM
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.
Posted on 10-28-2021 04:50 AM
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.
Posted on 10-28-2021 06:42 AM
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.
Posted on 01-06-2022 01:04 PM
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.