802.1x Wi-Fi on Non Domain Mac's

[ZJones1994]

We are trying to push out a profile to have our Mac's (in a primarily Microsoft environment) to auto join our 802.1x network. I have setup the Jamf ADCS and am able to push a device cert to the Mac's that I would like to use. I created a policy in NPS to use that cert for authentication that I would like to use but am getting auth failures. Any guidance for how to remediate this? 

[sdagley]

@ZJones1994 Are you including a Network payload for the SSID requiring 802.1x in your Configuration Profile that's deploying the certificate from ADCS? Both payloads have to be in the same profile for the certificate to be properly associated with the 802.1x settings for a Wi-Fi configuration. You'll also want to make sure that your 802.1x auth system is going to accept the certificate you're deploying from ADCS instead of an AD machine certificate.

[ZJones1994]

Good morning! It is in the same config profile, the issue seems to lie within our Windows Server NPS. We have the cert uploaded there and our policy is checking against that cert for authentication. The error that show up in Radius/NPS logs is that there is no AD object found.

[AJPinto]

Ya, JAMFs AD CS Connector is just making a CSR and passing it along, and the AD CS is just making a PEM or whatever format based on that CSR and returning it to JAMF for deployment. This workflow does not create an AD Object which Radius is looking for.

We are actually sorting this out ourselves. At my environment our Radius certificate authentication requires there to be an AD object. We are working our Macs away from domain binding and this topic is actually next on my list of things to figure out. Domain Bound Macs work fine, nothing changes but the domain part. All the issues are in Radius, and that is where the changes need to happen. You can even unbind a Mac (dont wipe) and it will work as the SID still matches AD.

[ZJones1994]

I figured that was the case, I have yet to find a way to make NPS stop looking at AD for an object unfortunately. I have seen some old posts on various forums where people have figured out a solution but I have yet to be able to figure something out in our environment unfortunately. We are by no means Mac experts here, we have 30 or so and I recently became our "Mac Guy" so this has been a learning process for sure. 

[AJPinto]

I am much in the same boat. We are a financial institution that is really obsessed with security (a good thing, but a pain some times). About 1% of our environment are Macs, and I am the one that manages them. They want Macs fully integrated, but none of the teams that manage things have any clue how macOS function or how to make macOS work with things and here I am.

Breaking up from AD is a 3 year endeavor that was only approved 1st quarter this year when MS did the packenforcement changes that broke AD binding. That hauled deployments for 3 months until our CISO said uninstall the KB update that did this. They dont want domain and mac to break again so I got the green light. 

[sdagley]

We don't bind our Macs to AD for auth, but we do use Kerberos SSO to sync local Mac accounts with our AD system. If you have an internal CA to issue a user cert with their domain ID you install on the machine and can verify the trust chain you should be able to match the cert name with their AD record to validate access.

[ZJones1994]

Kind of where we're at. Previously we had on-prem Jamf and that was setup years ago and only touched when we enrolled a new Mac. Once stuff started breaking after I started at the company began the process of looking into Jamf Cloud and Connect, deciding not to bind to AD etc. 

[Anonymous]

@ZJones1994 I think, you're using a configuration profile to do this.
We do the  same and it is working well.  What kind of message will come up while there  are authentication errors?
Did you configured the certificate at the part "Trust" in your configuration profile?

In some cases, the certificate is delivered to the client, but the system settings are set to "standard", instead of "always trust", this could be the reason of the authentication errors. In this case, the certificate has to be configured to "always trust".

Its only a guess, because I don't know the error message.

[ZJones1994]

Hello,

On the mac side everything seems to be pushing properly. The only error received is the standard couldn't authenticate. The errors we are seeing are on our radius server. We see the Mac trying to connect and it being rejected due to invalid credentials. We are trying to use device based auth with a cert. The policy on NPS Radius is set to look for a cert which is present on both the Mac's and the server, and generated/issued via Jamf ADCS. 

[AJPinto]

What are your networks authentication requirements? My bet is when you get to the Radius part of your network authentication, AD is being checked and Radius is not seeing an object for the device and rejecting authentication. 

For the sake of sanity. Cut the configuration profile out of this for testing. Drop the AD CS cert on the device and manually connect to the network. Once you have that working then try to do it with JAMF and a configuration profile.

[ZJones1994]

Good morning! That is currently where I am at, I have cut out the config profile and have the ADCS cert on the machine and am not able to connect. Looking in Radius logs (we use NPS on Windows Server 2022) I do see audit failures in event viewer stating reason for reject was user account doesn't exist. Trying to solve that has been where my issues lie for the time being. I have the policy configured to look for the cert that is present on both the Radius server as well as issued through ADCS and still a no go. 

[Mithrandir]

This is what finally worked for me in my shop:

1) Added both dNSHostName & service PrincipalName to unbound (dummy) computer objects in AD.

2) Exported machine cert delivered via ADCS to my Mac and used name mapping in ADUC to set it as an alt-id.

3) Modified cert request syntax to include: host/$COMPUTERNAME.FQDN.

4) Added UPN to cert request (in addition adding DNSName as SAN): $userPrincipalName.FQDN.

5) In ADUC, reset computer password; using root terminal in macOS, I used the security command to: set both an identity preference and a generic password (matching the password input in ADUC).

6) Added additional SAN setting to cert request: UserPrincipalName: $userPrincipalName.FQDN

7) Exported entire cert chain from relevant issuing servers, and put them in the profile... and it works!