We're authenticating our users via AD using a combination of clients.conf and then a perl script in post-auth. This works fine with the exception that the device has to be defined in both clients.conf and the perl script. To avoid the possibility of mistakes I'm trying to remove this duplication if at all possible. After scouring the official documentation all afternoon as well as looking at external sources I'm nowhere closer to knowing how to do this than before. Ideally I'd like to do something like this: client router-a { ipaddr = 1.2.3.4 secret = topsecret deviceclass = NOC_only } client IPMI-a { ipaddr = 2.3.4.5 secret = moresecret deviceclass = OPS_only } client VPM-a { ipaddr = 3.4.5.6 secret = mostsecret deviceclass = NOC_OPS } I'm not attached to "deviceclass" in any literal sense, just using it as an example of what I'm trying to accomplish. Ideally then the perl script could do what it normally does, which is to examine the authenticated request and authorize if the authenticated user is a member of the requisite group, only it's looking up the device's type from the original request rather than having to maintain a separate array of IP addresses which can get out of sync from clients.conf. One thing I had considered was adding the bogus deviceclass attribute in clients.conf and just having the perl script read that out of the file, but then I ran into a stopper: among the many unforgivable bugs the Supermicro IPMI has in its radius stack is that it _always_ passes 127.0.0.1 as its NAS-IP-Address in the radius request: (0) perl: &request:NAS-IP-Address = $RAD_REQUEST{'NAS-IP-Address'} -> '127.0.0.1' Thus the perl script assumes that any request coming in with that attribute pair is an IPMI: my @ipmi = '127.0.0.1'; Please forgive this digression, but I felt it useful to explain the sort of Catch-22 situation that I'm in with these IPMI devices. Any help figuring out how to get a device type set from clients.conf would be very welcome.