According to Case PAE695407 I would really appreciate if the RADIUS sensor can be complemented with a certificate lifetime check. RADIUS is often used in conjunction with wired or wireless authentication and Protected EAP (PEAP), and therefore a valid certificate is needed.
Thank you for your input. It is noted.
Please allow me to communicate honestly that we ask you to not expect this kind of sensor in the foreseeable future though. The reason is that we are currently working on other features and sensors which we expect to offer more utility. We still collect all user feedback and evaluate it on a regular basis.
Any further update or timeline on this feature? Currently, we manually check expiration dates on our PEAP certs, but it would be handy to have a warning alert us of a cert expiring in 30 days or so. As a managed service provider, it'd be helpful for us to avoid one of our clients coming in to the office one day not able to authenticate any wireless devices; helps us keep an eye on things more easily.
While we constantly add new sensors and improve existing sensors, checking certificates for PEAP is not planned. That might change in the future, but realistically I don't expect that any time soon, I am sorry.
We would like PRTG to support validation of PEAP certificates as well.
thank you for the input.
As of now, the Radius sensor is still not scheduled for an overhaul, because we currently work on sensors for which we see higher demand.
Thank you for answering. I'm just courious: is there a list we can see which new sensors or improvements are planned? We all really appreciate your work and you and your team mates are doing a great job with PRTG. But sometimes I'm very confused (with a tendence to be a little upset) when I see which sensors are on higher priority than a simple cert-check (which you already have) on a existing sensor.
Best regards Ivo
regarding communicating roadmaps, we want to be careful, because it can happen that another feature gets higher priority which delays others.
Adding a feature into an existing sensor might look like a quick task. It still has to be defined, accepted, implemented, reviewed, merged, tested, documented, and the language file needs new strings for all supported languages in the interface. Those languages have to be reviewed by native speaking colleagues.
We want to use the developer time in order to serve the most users in most ways. We get too many useful ideas and requests to implement them all. But a lot of the improvement of PRTG is based on user feedback.
Hi, that sensor would be really appreciated. thank you.