Mostly off-topic:
This isn't helpful for grinder but there is actually a parameter of sorts on Windows only called ClientTimeOut. I say "of sorts" because it isn't implemented as a client or broker startup parameter but rather as a registry setting. I just became aware of it recently and I've never used it.
More details:
Progress KB - How to use the ClientTimeOut Startup Parameter.
Back on topic:
I understand the motivation to do this; one of our applications has an optional feature to disconnect a subset of users before the nightly batch run. But please heed Tom's advice.
My own view is that features like this are a response to problem symptoms rather than the underlying cause.
Example:
A user goes into an "update" screen in the UI; maybe to update something, maybe just as a shortcut for querying something they don't intend to update. (It might even be a particularly badly-written query screen!) Unbeknownst to them, they are in a transaction and hold exclusive locks on one or more records. Then they go for a coffee, go to a meeting, leave work early, etc. Now you have a bad situation brewing. First, they have started a transaction that isn't going to end anytime soon and that, combined with other users' activity will cause BI growth, given sufficient time. Second, they might be holding a record lock that some other client will later try to acquire, causing it to block (depending on how it's written).
Ultimately this causes database problems and business disruption and after a post-mortem, someone decides that the thing we need to do to eliminate these unwanted locks is to kick out "idle users", either at the end of the business day or after some period of idleness. It sounds simple and straightforward at first blush but as Tom points out there are a lot of subtleties to the problem. And you'll probably also boot some users who are causing no harm.
The root cause is technical debt; the way the application is designed and the fact that seemingly ordinary user behaviours (at least from the user's perspective) can cause big problems. The best long-term solution is to pay the debt: refactor those programs with optimistic locking, tighter transaction scope, transactions that don't span UI interactions, and code that won't block for half an hour when it encounters an unexpected lock.
I understand that that isn't a quick or trivial undertaking, particularly with a large code base. In the interim, it's important to monitor the application databases to understand which clients are causing the problems and which programs they are running at the time, as they need to be fixed, and which programs are the victims as they may need to be refactored too. Start with the most frequent offenders and fix as you discover them.