Forcing 802.1X Active Directory Certificate Configuration Profile Payload to use Specific Certificate

[cainehorr]

Does anybody know if there is a way to have OS X automatically use a specific AD certificate after an 802.1X AD Certificate payload has been delivered?

Let me provide the example...

• I have a JSS Computer Configuration Profile
• It has a network payload with the following details...

GENERAL:
Name: 802.1X AD Certificate
Description:
Category: Active Directory
Distribution Method: Install Automatically
Level: Computer

NETWORK:
Network Interface: WiFi
Service Set Identifier (SSID): my-company
Hidden Network: Unchecked
Auto Join: Checked
Proxy Setup: None
Security Type: WPA2 Enterprise
Use as a Login Window configuration: Unchecked
Network Security Settings: Protocols | Trust

Protocols
Accepted EAP Types: TLS
Use Directory Authentication: Unchecked
Username: N/A
Password: N/A
Verify Password: N/A
Identity Certificate: AD Certificate
Outer Identity: N/A

Trust
Trusted Certs: Checked - my-company-root-ca
Trusted Server Certificate Names: N/A
Allow Trust Exceptions: Unchecked

CERTIFICATE:
Certificate Name: my-company-root-ca
Certificate: Uploaded
Passphrase: N/A
Verify Passphrase: N/A

AD CERTIFICATE:
Description: My Company Network Access CA
Certificate Server: my-company-server-name
Certificate Authority: my-company Intermediate CA
Certificate Template: my-company-machine
Certificate Expiration Notification Threshold: 30
Prompt for Credentials: Unchecked
Username: N/A
Password: N.A
Verify Password: N/A
Allow access to all applications: Unchecked
Allow export from keychain: Unchecked

SCOPE:
Target Computers: Specific Computers
Target Users: Specific Users
Target: Test-Machine-01, Test-Machine-02

When the Computer Configuration Profile is pushed, the certificate is downloaded from AD and installed in the user's keychain.
The user is then prompted for the correct certificate before a connection to the Wireless network is established.

Is there a way to force the Configuration Profile to automatically use the correct certificate instead of relying on the user to select from the list of available certificates?

BONUS ROUND:
At some point in time, the certificate is going to expire.

The user should be prompted that the certificate is going to expire.

Is there a way to flush the expired cert and/or delete old, deprecated certs via the JSS?

Thanks!

[perrycj]

Are you using the JSS to create the profile or are you creating the profile in profile manager, signing and then uploading to the JSS?

[daniel_behan]

If this is a computer profile and not a user profile, this should be going into the system keychain, not the user keychain.

In Network: try selecting the certs you need on the Trust tab

Also you may want to make this in Profile manager and install locally as a package. If you ever need to re-enroll to Casper the profiles may uninstall and kick you devices off WiFi.

[cainehorr]

@perrycj

I've pinged my colleague - hopefully he'll answer shortly.

@daniel.behan

You are correct - The cert does get installed in the System Keychain

Re-Enrollment is not an issue.

1. Devices are DEP enrolled.
2. Users can connect to guest wi-fi for self-provisioning.
3. Once JSS enrollment is complete, they have the Computer Configuration Profile installed.

[cainehorr]

@daniel.behan

I updated Configuration Profiles above to reflect the "Trust" tab details.

[perrycj]

If created in the JSS, the configuration profile will always be in user mode. This is a current product defect in the JSS as of the latest maintenance build of 9.92.

You will need to make it in profile manager, sign it (you have to sign it or the JSS will junk it up and convert it back to user mode) and then upload it to the JSS.

That will ensure it is in system mode and automatically connects, using the correct certificate.

[cainehorr]

@perrycj

Thanks for that! I've passed it along to my colleague. I believe he's gone to bed (he's in Riga, Latvia) and he doesn't have a JAMF Nation account (yet). LOL!

[IanCresswell]

Did you ever get this to work?
I have the same problem where I am using 802.1x for wired authentication, I can manually select the certificate to use but I cant expect our users to do that.
I can also set the client to "fetch" a certificate from our CA and the profile will then use that, however each time the profile runs it will "fetch" a new certificate and we will end up with hundreds of unused certs on our CA.
What I need to do is tell the profile to use the local certificate.
Sound simple enough but is proving to be anything but....

[perrycj]

@IanCresswell How are you making the profiles for ethernet?

[IanCresswell]

The MAC admins created the profile using JSS and then I have been manually editing and applying while testing various scenarios.
We have a script that tells the profile to run each time there is a network state change or only the first connected ethernet adapter works, unfortunately this means that each time the script runs it fetches a new certificate. Sanitized copy of the script we run:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> <key>PayloadContent</key> <array> <dict> <key>PayloadCertificateFileName</key> <string>XYZ Internal Root CA.cer</string> <key>PayloadContent</key> <data> BLA </data> <key>PayloadDescription</key> <string></string> <key>PayloadDisplayName</key> <string>X/YZ Internal Root CA</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>com.apple.security.root.4B989EBD-31A5-40C0-B1E8-77C62997CAF4</string> <key>PayloadOrganization</key> <string>X/YZ</string> <key>PayloadType</key> <string>com.apple.security.root</string> <key>PayloadUUID</key> <string>4B989EBD-31A5-40C0-B1E8-77C62997CAF4</string> <key>PayloadVersion</key> <integer>1</integer> </dict> <dict> <key>AllowAllAppsAccess</key> <true/> <key>CertServer</key> <string>certificates.XYZ.com</string> <key>CertTemplate</key> <string>ClientAuthentication-Computer</string> <key>CertificateAcquisitionMechanism</key> <string>RPC</string> <key>CertificateAuthority</key> <string>X/YZ Issuing CA 1</string> <key>CertificateRenewalTimeInterval</key> <integer>14</integer> <key>Description</key> <string>AD Certificate</string> <key>KeyIsExtractable</key> <false/> <key>PayloadDescription</key> <string>AD Certificate</string> <key>PayloadDisplayName</key> <string>AD Certificate</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>com.apple.ADCertificate.managed.1ABA6DA9-2170-40AB-B75F-9E2C0BF6F442</string> <key>PayloadOrganization</key> <string>X/YZ</string> <key>PayloadType</key> <string>com.apple.ADCertificate.managed</string> <key>PayloadUUID</key> <string>1ABA6DA9-2170-40AB-B75F-9E2C0BF6F442</string> <key>PayloadVersion</key> <integer>1</integer> <key>PromptForCredentials</key> <false/> </dict> <dict> <key>PayloadCertificateFileName</key> <string>XYZ Issuing CA 1.cer</string> <key>PayloadContent</key> <data> BLA </data> <key>PayloadDescription</key> <string></string> <key>PayloadDisplayName</key> <string>X/YZ Issuing CA 1</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>com.apple.security.pkcs1.23A8C1F9-4E05-46BF-AE8C-D3E4B18F04E2</string> <key>PayloadOrganization</key> <string>X/YZ</string> <key>PayloadType</key> <string>com.apple.security.pkcs1</string> <key>PayloadUUID</key> <string>23A8C1F9-4E05-46BF-AE8C-D3E4B18F04E2</string> <key>PayloadVersion</key> <integer>1</integer> </dict> <dict> <key>AuthenticationMethod</key> <string></string> <key>AutoJoin</key> <true/> <key>EAPClientConfiguration</key> <dict> <key>AcceptEAPTypes</key> <array> <integer>13</integer> </array> <key>PayloadCertificateAnchorUUID</key> <array> <string>23A8C1F9-4E05-46BF-AE8C-D3E4B18F04E2</string> <string>4B989EBD-31A5-40C0-B1E8-77C62997CAF4</string> </array> <key>TLSCertificateIsRequired</key> <true/> <key>TTLSInnerAuthentication</key> <string>MSCHAPv2</string> </dict> <key>EncryptionType</key> <string>Any</string> <key>HIDDEN_NETWORK</key> <false/> <key>Interface</key> <string>FirstActiveEthernet</string> <key>PayloadCertificateUUID</key> <string>1ABA6DA9-2170-40AB-B75F-9E2C0BF6F442</string> <key>PayloadDescription</key> <string></string> <key>PayloadDisplayName</key> <string>Network</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>com.apple.firstactiveethernet.managed.9E3BCA2D-B271-4CBD-A5DF-5C50F6264003</string> <key>PayloadOrganization</key> <string>X/YZ</string> <key>PayloadType</key> <string>com.apple.firstactiveethernet.managed</string> <key>PayloadUUID</key> <string>9E3BCA2D-B271-4CBD-A5DF-5C50F6264003</string> <key>PayloadVersion</key> <integer>1</integer> <key>ProxyType</key> <string>None</string> <key>SetupModes</key> <array> <string>System</string> </array> </dict> </array> <key>PayloadDescription</key> <string>Root and Issuing certificate, Computer certificate Wired payload settings</string> <key>PayloadDisplayName</key> <string>XYZ Wired Authentication - JSS Setup</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>D8301D6F-D0F0-4D82-B342-9C09FFCCDA12</string> <key>PayloadOrganization</key> <string>X/YZ</string> <key>PayloadRemovalDisallowed</key> <true/> <key>PayloadScope</key> <string>System</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>01D960EF-2A6F-4291-892B-B53A4231CE9E</string> <key>PayloadVersion</key> <integer>1</integer>
</dict>
</plist>

[perrycj]

Try making the profile in profile manager, signing it and then uploading it to the JSS. That will make it read-only and the JSS won't be able to affect any of the xml keys.

[m6jamf]

Hiya all,

Has the user mode profiles issue been fixed in Jamf Pro 10.x versions? In other words, does Jamf Pro 10.x correctly create system mode profiles?