QuickAdd 8.4 now "enrolls" computers

[donmontalvo]

We upgraded to JSS 8.4 (from 7.31) and noticed on new QuickAdds the postflight script has fewer commands, including an "enroll" command:

#!/bin/sh

####################################################
## Create the configuration file at:
## /Library/Preferences/com.jamfsoftware.jamf.plist
####################################################
/usr/sbin/jamf createConf -url 'https://XXXXXXXXXX:8443/' -k

####################################################
## Turn on SSH
####################################################
/usr/sbin/jamf startSSH

####################################################
## Run enroll
####################################################
/usr/sbin/jamf enroll -invitation XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

exit $?

Our old QuickAdds have a number of understandable and editable entries:

#!/bin/sh

####################################################
## Create the configuration file at /private/etc/jamf.conf
####################################################
/usr/sbin/jamf createConf -url 'https://XXXXXXXXXX:8443/' -k

####################################################
## Turn on SSH
####################################################
/usr/sbin/jamf startSSH

####################################################
## Create a new account
####################################################
/usr/sbin/jamf createAccount -username 'jdoe' -realname 'jdoe' -passhash 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' -admin -hiddenUser

####################################################
## Run Recon
####################################################
/usr/sbin/jamf recon -username 'recon' -passhash 'XXXXXXXXXXXXXXXX' -sshUsername 'jdoe' -sshPasshash 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
exitCode=$?

####################################################
## Enforce the Management Framework
####################################################
/usr/sbin/jamf manage

exit $exitCode

Is the "enroll" command mandatory? Or can we edit the QuickAdd postflight script to use the old commands?

Our concern is we have several hands-off QuickAdd installers designed for special groups of users, which have customized postflight script entries.

Don

[bill_bartig · Accepted solution]

"What do we do when we have Macs that stop checking in to JSS?"

It really depends, so I'd recommend contacting Support if you have any issues so that we can troubleshoot based on the scenario.

"How does the enrollment process impact our ability to use Casper Remote?"

It shouldn't have any impact that I can think of. Once a computer is enrolled and submits inventory, everything else should act normally.

"Does enrollment cause certificate issues?"

I'm not quite sure what you're asking, so please smack me on the head if this doesn't answer what you're looking for. Enrollment doesn't necessarily cause certificate issues, though certificate issues, especially certificate authority issues, can cause enrollment issues. Since the certificate stored on each managed computer is tied to the CA that the JSS uses, any changes to the CA will cause that certificate to be invalid and break communication. Also noteworthy is that re-enrolling a computer will generate a new certificate on that computer, which is why re-enrolling a computer is one way to troubleshoot issues with machines that stop checking in. (Note: Re-enrolling a machine will clear that machine's policy history by default. Support can help you disable that behavior if necessary.)

Please let me know if I can clarify anything else. I don't think I'd be much use with troubleshooting, but I at least have an idea of how the new enrollment process is supposed to work.

[karthikeyan_mac]

Hi,

Do we have any documentation on enroll in quickadd package post flight?

/usr/sbin/jamf enroll -invitation XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

When we run "sudo jamf enroll" on a 8.4 client, it causes the certificate issues. After the machine stops contacting server.

sudo jamf enroll Downloading JSS Certificate Authority Certificate...
Error Enrolling Machine: peer certificate cannot be authenticated with known CA certificates

Just looking for documentation on enrollment so can understand better?

Thanks & Regards,
Karthikeyan

[bill_bartig]

The "enroll" command is new in 8.4 and is used to add machines to the inventory of your JSS. When you invoke the "enroll" command with the -invitation flag like the QuickAdd packages do (or with -prompt flag for manual enrollment), the computer sets up certificate-based communication with the JSS (if enabled) and adds the computer to the JSS's inventory. After that, the "manage" command is executed to set up the scheduled tasks, login/out hooks, etc. Finally, the "recon" command is executed to send the full inventory report to the JSS. Ultimately, this is just a bit different ordering from how computers used to be added to inventory, and it adds more security by keeping the management account information and other settings out of the QuickAdd scripts. Those items are now sent to the computer during the enrollment process.

One last note about the "enroll" command is that it is designed to be executed once on the computer to initially acquire the machine, and after that it would not be used unless the machine needed to be re-acquired for any reason.

So, Don, hopefully that helps explain how the old three commands were condensed into one. You could still modify the QuickAdd scripts as needed, though the invitation codes expire as part of the enhanced security process.

Karthikeyan, to fix the issue you are seeing, I'd suggest running sudo jamf enroll -prompt and filling in the requested information (JSS user/pass and SSH user/pass) to re-enroll any troublesome machines.

Hopefully this helps and doesn't confuse anyone further. :)

[hunty]

HI Bill,
Can you please provide some more information about this new enroll command.
Specifically around the invitation. How does this work is the invitation stored in the JSS by the Recon app at the time the package is created?
Do these invitations expire? If so when? Can these invitations be modified or do they have to be recreated with Recon? How many machines can use a single invitation or single quick add package?

[bill_bartig]

Hi! Sorry for the late response. I'm just catching up after a little vacation. :)

The invitation code is generated when you create the QuickAdd package. I don't believe there are restrictions on how many computers can be used per invitation.

As it turns out, I was mistaken in my previous post. Invitation codes for QuickAdd packages do not expire, so once you generate one you can modify the QuickAdd scripts as you see fit and it should work just fine.

Does that help at all?

[donmontalvo]

Hi! Sorry for the late response. I'm just catching up after a little vacation. :) The invitation code is generated when you create the QuickAdd package. I don't believe there are restrictions on how many computers can be used per invitation. As it turns out, I was mistaken in my previous post. Invitation codes for QuickAdd packages do not expire, so once you generate one you can modify the QuickAdd scripts as you see fit and it should work just fine. Does that help at all?

What do we do when we have Macs that stop checking in to JSS? How does the enrollment process impact our ability to use Casper Remote? Does enrollment cause certificate issues?

Many thanks,
Don

[bill_bartig · Accepted solution]

"What do we do when we have Macs that stop checking in to JSS?"

It really depends, so I'd recommend contacting Support if you have any issues so that we can troubleshoot based on the scenario.

"How does the enrollment process impact our ability to use Casper Remote?"

It shouldn't have any impact that I can think of. Once a computer is enrolled and submits inventory, everything else should act normally.

"Does enrollment cause certificate issues?"

I'm not quite sure what you're asking, so please smack me on the head if this doesn't answer what you're looking for. Enrollment doesn't necessarily cause certificate issues, though certificate issues, especially certificate authority issues, can cause enrollment issues. Since the certificate stored on each managed computer is tied to the CA that the JSS uses, any changes to the CA will cause that certificate to be invalid and break communication. Also noteworthy is that re-enrolling a computer will generate a new certificate on that computer, which is why re-enrolling a computer is one way to troubleshoot issues with machines that stop checking in. (Note: Re-enrolling a machine will clear that machine's policy history by default. Support can help you disable that behavior if necessary.)

Please let me know if I can clarify anything else. I don't think I'd be much use with troubleshooting, but I at least have an idea of how the new enrollment process is supposed to work.

[donmontalvo]

Also noteworthy is that re-enrolling a computer will generate a new certificate on that computer, which is why re-enrolling a computer is one way to troubleshoot issues with machines that stop checking in.

Hi Bill,

Actually the above answers one of our questions. I remember we were trying to "fix" some of the Macs that stopped checking in and for some reason running "sudo jamf enroll" caused a certificate issue.

We'll put together a summary of the issues and remediation steps we've ben using we'll and open a ticket with JAMF.

You guys rock...vendors who monitor thier forums deserve to be fed beer and grapes (I hope JAMF managers are listening...hehehe).

Don

[karthikeyan_mac]

Hi Bill,

Enroll command works differently in 10.5 and 10.6.

Let me explain you what we noticed when running "sudo jamf enroll" on a 10.5(leopard) machines thats is reporting properly. It causes some certificate problems as below:-

leopard:~ user$ sudo jamf version
Password:
version=8.4
leopard:~ user$ sudo /usr/sbin/jamf checkJSSConnection
Checking availability of https://myjssserver:8443//...
The JSS is available. ##### Shows JSS available####
leopard:~ user$ sudo jamf enroll 
    Downloading JSS Certificate Authority Certificate...
    Successfully download certificate "my company JSS Built-in Certificate Authority"
    Adding certificate to JAMF Keychain...
    Successfully added to JAMF Keychain
    Device successfully enrolled to the JSS with device certificate "xxxxxxxxxxxxx"
Retrieving Inventory Preferences from https://myjssserver:8443//...
Locating Hard Drive Information...
Locating Hardware Information (Mac OS X 10.5.8)...
Locating Applications...
Executing Unix Applications...
Locating Receipts...
Gathering Application Usage Information...
Finding Extension Attributes...
Submitting data to https://myjssserver:8443//...
<computer_id>641</computer_id>
Getting Management Framework from JSS...
Enforcing Management Framework...
Enforcing Login/Logout Hooks...
Checking availability of https://myjssserver:8443/...
The JSS is available.
Enforcing Scheduled Tasks...
    Creating Usage Monitoring Task...
    Creating Restricted Software Task...  #### Enroll completed
leopard:~ user$ sudo /usr/sbin/jamf checkJSSConnection ### Checking connection gain, it shows Certificate error####
Checking availability of https://myjssserver:8443//...
Error signing communication - peer certificate cannot be authenticated with known CA certificates
The jamf binary could not connect to the JSS because the certificate is not trusted.
Waiting 5 seconds to try again...

The solution we are following for this issue is to run casper remote for this 10.5 mac by selecting the option "Allow Invalid certificate" in Casper Remote Preferences. The Macs starts reporting JSS

leopard:~ user$ sudo /usr/sbin/jamf checkJSSConnection
Password:
Checking availability of https://myjssserver:8443//...
The JSS is available.

Mac OS X 10.6.8 machines does not have any issues if you run "sudo jamf enroll" any number of time. my observation is while running "sudo jamf enroll" in 10.6 macs, enrollment removes any previous jamf device identities found on this machine. 10.5 enrollment does not remove the previous identities found on the machines.

"sudo jamf enroll" on 10.6 machine:- (see my comment)

snowleopard:~ user$ sudo jamf enroll
    Downloading JSS Certificate Authority Certificate...
    Successfully download certificate "my company JSS Built-in Certificate Authority"
    Adding certificate to JAMF Keychain...
    Successfully added to JAMF Keychain
###### Note the line below in 10.6 enrollment. This does not happen in 10.5###
    Previous (1) JAMF Device Identities found on this machine. Removing...
    Device successfully enrolled to the JSS with device certificate "xxxxxxxxxx"
Retrieving Inventory Preferences from https://myjssserver:8443//...
Locating Hard Drive Information...
Locating Hardware Information (Mac OS X 10.6.8)...
Locating Applications...
2012-02-01 04:18:09.016 jamf[12613:e07] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary.
Executing Unix Applications...
Locating Receipts...
Gathering Application Usage Information...
Finding Extension Attributes...
Submitting data to https://myjssserver:8443//...
<computer_id>2045</computer_id>
Getting Management Framework from JSS...
Enforcing Management Framework...
Enforcing Login/Logout Hooks...
Checking availability of https://myjssserver:8443/...
The JSS is available.
Enforcing Scheduled Tasks...
    Creating Usage Monitoring Task...
    Creating Restricted Software Task...

This was my observation on enrollment. Correct me if I am wrong.......

Regards,
Karthikeyan

[ryan_yohnk]

Karthikeyan,

It sounds like you have the "This JSS has a valid certificate installed" option enabled. It also sounds like if you turn that off (manually at this point) the 10.5 machines start communicating correctly. Is this correct?

We've seen issues in the past with 10.5 machines and enabling the "This JSS has a valid certificate installed" option. The problem there often lied in the fact that we use cURL to communicate with the JSS. In 10.5 cURL did not use the System trust to verify if the website you are connecting to was trusted. It used its own trust store which may not have the CA certificate for your web server certificate.

A good check for this is to run the following command on a 10.5 machine...

curl https://you.jss.com:8443

If you get HTML back it means that your web server certificate is trusted on that machine. But if you get a response that looks like this it means that it is not trusted:

curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.

If that is the case then we would need to look at the process to add the trust to those 10.5 machines.

[karthikeyan_mac]

Hi,

When I run following command on the 10.5.8, I am getting error.
Kindly provide us a process to add the trust to those 10.5 machines.

curl https://myjssserver:8443

curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). The default bundle is named curl-ca-bundle.crt; you can specify an alternate file using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.

Thanks & Regards,

Karthikeyan

[donmontalvo]

There is a similar issue on another thread, unfortunately no responses:

https://jamfnation.jamfsoftware.com/discussion.html?id=3700

Don

[ryan_yohnk · Accepted solution]

Hey Guys,

In response to Karthikeyan's post, it looks like those 10.5 machines don't trust your web server certificate. So we have two options here. Either uncheck the "This JSS has a valid certificate installed" checkbox or add the CA root that issued your web server certificate to the list of CAs that curl trusts on your 10.5 machines. If you'd like to do the second option then I would try getting the updated list of CAs from http://curl.haxx.se/docs/caextract.html. Try downloading the cacert.pem file and moving it to /usr/share/curl/curl-ca-bundle.crt on a test 10.5 machine. Then run that curl command ```
curl https://you.jss.com:8443
``` and see if the command succeeds in getting HTML back. If that's the case, try enrolling the machine and see if you get any better results.

Ryan

[donmontalvo]

Ryan,

Worked like a charm. We created a PKG containing the new file and a backup of the old, pushed to some 10.5 Macs, now they "trust" the cert again. Thanks for the fix!

Don

[donmontalvo]

Since 10.6 or 10.7 do not have /usr/share/curl directory, would it be OK for us to add this to our QuickAdd installer?

PS, I'll add a Feature Request to have Recon allow us to add stuff to QuickAdd when creating.

Don