Hi Mike,
thanks for your answer. You are right, it is no security issue.
I tried out your suggestion and configured no session for the user,
after that i kick of the active session and he could not connect again.
He's still logged in into the guac-client, but he can't do anything.
thank's for your help
best regards
Michael
Am 15.01.2018 um 09:00 schrieb Mike Jumper:
On Sun, Jan 14, 2018 at 11:46 PM, Michael Niehren <[email protected] <mailto:[email protected]>>
wrote:
Hi together,
i see an security issue in the following scenario:
First, if you think you've found a problem with security implications, *please do not post about
it in a public forum*. Follow responsible disclosure practices, as described at:
http://guacamole.apache.org/security/
That said, this is not a security issue. More on this below.
Let's say, we have an user for which are 2 sessions configured. Now the
user has been logged in into the guac-client and is connected to 1 session.
I see, that the user does bad things in his session and i want do kick it
off and disable his account. So i change his password and kick of the
session.
But he's still logged in in the guac-client and immediately he can reconnect
the session.
In the documentation i didn't find a possiblity to kick the login into the
guac-client. The only option i found to influence the guac-client login is
the "api-session-timeout", but this option only affects on inactivity.
I do agree that this would be a nice feature to have, but it is indeed a feature, and its absence
is not a security problem.
In the meantime, you can actually kick a user such that they cannot reconnect
by:
1) Revoking their access to the connection in question.
2) Killing their active session to that connection.
Though the user will still be logged in, access will now be denied if they
attempt to reconnect.
Maybe a new option "auto-session-logout" would be useful, which, if set,
will
automatically kick off the guac-login if the session is closed. So he can't
login again as the password has been changed.
What do you think about that ?
I think that if we're going to add a feature which allows administrators to forcibly log off
users, then we should add a feature which allows administrators to forcibly log off users. No need
to hack things together with additional configuration parameters which happen to cover the need in
a specific case. In fact, given recent support for tracking user login/logoff, I see the addition
of admin UI sections for displaying user login/logoff history as well as active user sessions as a
good fit.
- Mike
--
Michael Niehren __ _ powered by
/ / (_)__ __ ____ __
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\
