There are a few aspects that could be improved. Their API was a little spotty when I last used it, and some of those use cases were around removing systems from our environment. We have ephemeral environments, so systems will come up and down and up and down and auto-scale. For each of those systems, the JumpCloud agent gets installed in the system and it gets registered to groups. We found that the systems would not get auto-removed, and so the agent would try to check in or the UI would show that the agent was not responding. We had to create a script to remove these systems from our environment, and that became a bit of a pain for us. I do not know if integration with AWS CloudTrail or something like that can help to know when a system is terminated or the lifecycle of that system, that would be pretty helpful to improve this process. We had to write our own script and sometimes that would not work. There are two versions of the APIs. I have also seen some methods that were lacking in the API versus raw REST cURL requests. I have not double-checked this. I just went towards a path of not trusting the API at some point because it just was not consistent with what was in the raw cURL request. In that case, it was the user auditing and things like that which was getting the expected output back. Lastly, for systems, user IDs are created on Linux systems. I don't know if this has changed, but at one point, we were running into a collision. A Linux system will assign a value to a user ID. For example, if 1000 is the user ID, JumpCloud will also assign a user ID. You can fix that number and it will increment based on a certain value, but we found that we have internal systems as well that will create users. In some cases, we would have user ID conflicts on the system and in JumpCloud. We have received prompts from JumpCloud that says, "Hey, there's a conflict and this user's using this ID number." That was for some of the use cases where we had to run scripts on the system. I would have to reassign the user ID and run the script to have consistent user IDs for that user across the board. Otherwise, the user would get added as the next user on the system. There was a little bit of complexity there and a little bit of pain. These are the improvements I would like to see in the tool. I have heard that JumpCloud has made a lot of changes and I would like to see them. If it is not there now, it can generate an easy-to-use report for an audit and give me the relationships between user groups and systems. I am not sure if that exists. These were not there the last time I had run an audit on systems. From my understanding of the solution, OpenID Connect is not supported, but it would be cool to see that feature involved in the service. There has been a shift away from JumpCloud which is not because of technical reasons. The shift has been mainly because of the cost and compliance issues. I do not believe that they have FedRAMP compliance. It is a requirement for the organization to maintain FedRAMP compliance. The vendor's due diligence is an important aspect. Our vendors have to meet or we try to have them meet the same bar that we have for compliance. The shift is occurring not because of technical reasons but more on the basis of what services are offered. It would be nice to see JumpCloud as a FedRAMP or NIST 800-53 certified product.
