[
https://issues.apache.org/jira/browse/GUACAMOLE-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Connor Norris updated GUACAMOLE-1691:
-------------------------------------
Description:
Hello avocado enthusiasts,
I believe i've discovered a bug - i've spent the past 5 days inadvertently
finding every environment its reproduceable in while trying to avoid it. This
was not an issue around ~6 months ago when I last used guacamole, but it is
now... maybe
It would seem that TOTP is very specifically incompatible with the "expire
password" checkbox in the Guac GUI.
I have reached pretty much the full extent of my ability to debug this, and
have tried... a lot... of different fixes and installation methods. Some
pointers to a relevant log file with more verbosity would be incredibly useful!
I'll try to format both what i've tried, the relevant logs, and how guac is
currently installed below.
Behavior:
- On a clean install, the expire password checkbox functions normally. user1
inputs password1, then they are prompted to change their expired password, and
they input password2. Password 2 becomes their new password
- After installing TOTP, then expiring a password, after the user changes
password1 to password2 and inputstheir valid 2FA code, the user is sent back to
the login screen with 'invalid login' at the top.
- If user1 enters password1, (or any random password) they get 'invalid login'
(expected)
- if user1 now enters password2, they get 'Verification failed. Please try
again.' ... this sorta implies that it KNOWS this is the correct newly updated
password, given the error message is only different when entering that one
password
- user1 can no longer login without admin account intervention.
Other pertinent details:
- TOTP functions as expected in all other use cases. Clear TOTP and Confirm
TOTP both function as expected.
- The password for user1 can still be set manually by admin accounts
- The self-serve 'change own password' bit still functions as expected
- Clearing the TOTP secret while expiring the password in tandem does not
solve the issue.
- granting the user anything from change password, to all permissions and
admin has no impact
- Only the specific combination 'totp' + 'expire-password' seem to be
incompatible
Current environment:
- Ubuntu 20.04.5 LTS Server
- Guacamole server 1.4.0
- guacamole-auth-jdbc-1.4.0
- mysql-connector-java-8.0.30
- guacamole-server-1.4.0
- 10.3.34-MariaDB-0ubuntu0.20.04.1
(i've tried many more as well, see 'things i've tried' below)
{code:java}
// /etc/guacamole/guacamole.properties
## MySQL properties
mysql-hostname: 127.0.0.1
mysql-port: 3306
mysql-database: guacamole_db
mysql-username: guacamole_user
mysql-password: censored
## TOTP properties
totp-issuer: guacamole
## (i've tried not changing the issuer as well{code}
{code:java}
// catalina.out
log/var/lib/tomcat9/logs/catalina.out:727:[2022-09-30 20:10:01] [info]
20:10:01.371 [http-nio-8080-exec-8] INFO o.a.g.r.auth.AuthenticationService -
User "user1" successfully authenticated from IPaddrX.
/var/lib/tomcat9/logs/catalina.out:728:[2022-09-30 20:10:01] [info]
20:10:01.373 [http-nio-8080-exec-8] INFO o.a.g.auth.jdbc.user.UserService -
Expired password of user "user1" has been reset.
/var/lib/tomcat9/logs/catalina.out:729:[2022-09-30 20:10:20] [info]
20:10:20.475 [http-nio-8080-exec-7] WARN o.a.g.r.auth.AuthenticationService -
Authentication attempt from IPaddrX for user "user1" failed
{code}
{code:java}
// from the guacamole_db
// the most interesting/notable thing here, is that the 'change own password'
system permission seems to be missing from the user? it is visibly set in the
gui. Not sure if that would be a row in system_permission or not.
[guacamole_db]> select * from guacamole_entity where name=user1\G
entity_id: 4
name: user1
type: USER
[guacamole_db]> select * from guacamole_system_permission WHERE entity_id=4\G
1. row
entity_id: 4
permission: CREATE_CONNECTION
2. row
entity_id: 4
permission: CREATE_CONNECTION_GROUP
3. row
entity_id: 4
permission: CREATE_SHARING_PROFILE
4. row
entity_id: 4
permission: CREATE_USER
5. row
entity_id: 4
permission: CREATE_USER_GROUP
6. row
entity_id: 4
permission: ADMINISTER
6 rows in set (0.000 sec)
[guacamole_db]> select * from guacamole_user_password_history\G
Empty set (0.000 sec)
?? note: password history definitely exists... entering an old password
generates and error the old and the new cannot be the same
[guacamole_db]> select * from guacamole_user_permission WHERE entity_id=4\G
1. row
entity_id: 4
affected_user_id: 4
permission: READ
2. row
entity_id: 4
affected_user_id: 4
permission: UPDATE
2 rows in set (0.000 sec){code}
Things i've tried so far:
- full wipe, installing guacamole from source as per the apache site
instructions
- installing using docker instead
- ubuntu 22.04, ubuntu 20.04
- using mySQL instead of MariaDB
- adding TOTP before first login
- adding TOTP after accounts are made
TLDR:
TOTP and 'expire password' seem to conflict. The most notable thing here is
that in the guacamole_system_permission table i was expecting to see a 'change
own password' value just like there is in the gui.
I've tried just about every different database and install method thats
supported, all with the same result.
Please let me know if there is any other data I should share, or if anyone has
any ideas.
Thanks!
Connor
was:
Hello avocado enthusiasts,
I believe i've discovered a bug - i've spent the past 5 days inadvertently
finding every environment its reproduceable in while trying to avoid it. This
was not an issue around ~6 months ago when I last used guacamole, but it is
now... maybe
It would seem that TOTP is very specifically incompatible with the "expire
password" checkbox in the Guac GUI.
I have reached pretty much the full extent of my ability to debug this, and
have tried... a lot... of different fixes and installation methods. Some
pointers to a relevant log file with more verbosity would be incredibly useful!
I'll try to format both what i've tried, the relevant logs, and how guac is
currently installed below.
Behavior:
- On a clean install, the expire password checkbox functions normally. user1
inputs password1, then they are prompted to change their expired password, and
they input password2. Password 2 becomes their new password
- After installing TOTP, then expiring a password, after the user changes
password1 to password2 and inputstheir valid 2FA code, the user is sent back to
the login screen with 'invalid login' at the top.
- If user1 enters password1, (or any random password) they get 'invalid login'
(expected)
- if user1 now enters password2, they get 'Verification failed. Please try
again.' ... this sorta implies that it KNOWS this is the correct newly updated
password, given the error message is only different when entering that one
password
- user1 can no longer login without admin account intervention.
Other pertinent details:
- TOTP functions as expected in all other use cases. Clear TOTP and Confirm
TOTP both function as expected.
- The password for user1 can still be set manually by admin accounts
- The self-serve 'change own password' bit still functions as expected
- Clearing the TOTP secret while expiring the password in tandem does not
solve the issue.
- granting the user anything from change password, to all permissions and
admin has no impact
- Only the specific combination 'totp' + 'expire-password' seem to be
incompatible
Current environment:
- Ubuntu 20.04.5 LTS Server
- Guacamole server 1.4.0
- guacamole-auth-jdbc-1.4.0
- mysql-connector-java-8.0.30
- guacamole-server-1.4.0
- 10.3.34-MariaDB-0ubuntu0.20.04.1
## (i've tried many more as well, see 'things i've tried' below)
## from /etc/guacamole/guacamole.properties
## MySQL properties
mysql-hostname: 127.0.0.1
mysql-port: 3306
mysql-database: guacamole_db
mysql-username: guacamole_user
mysql-password: censored
## TOTP properties
totp-issuer: guacamole
## (i've tried not changing the issuer as well)
### catalina.out log/var/lib/tomcat9/logs/catalina.out:727:[2022-09-30
20:10:01] [info] 20:10:01.371 [http-nio-8080-exec-8] INFO
o.a.g.r.auth.AuthenticationService - User "user1" successfully authenticated
from IPaddrX.
/var/lib/tomcat9/logs/catalina.out:728:[2022-09-30 20:10:01] [info]
20:10:01.373 [http-nio-8080-exec-8] INFO o.a.g.auth.jdbc.user.UserService -
Expired password of user "user1" has been reset.
/var/lib/tomcat9/logs/catalina.out:729:[2022-09-30 20:10:20] [info]
20:10:20.475 [http-nio-8080-exec-7] WARN o.a.g.r.auth.AuthenticationService -
Authentication attempt from IPaddrX for user "user1" failed
### from the guacamole_db
## the most interesting/notable thing here, is that the 'change own password'
system permission seems to be missing from the user? it is visibly set in the
gui. Not sure if that would be a row in system_permission or not.
[guacamole_db]> select * from guacamole_entity where name=user1\G
entity_id: 4
name: user1
type: USER
[guacamole_db]> select * from guacamole_system_permission WHERE entity_id=4\G
1. row
entity_id: 4
permission: CREATE_CONNECTION
2. row
entity_id: 4
permission: CREATE_CONNECTION_GROUP
3. row
entity_id: 4
permission: CREATE_SHARING_PROFILE
4. row
entity_id: 4
permission: CREATE_USER
5. row
entity_id: 4
permission: CREATE_USER_GROUP
6. row
entity_id: 4
permission: ADMINISTER
6 rows in set (0.000 sec)
[guacamole_db]> select * from guacamole_user_password_history\G
Empty set (0.000 sec)
## ?? note: password history definitely exists... entering an old password
generates and error the old and the new cannot be the same
[guacamole_db]> select * from guacamole_user_permission WHERE entity_id=4\G
1. row
entity_id: 4
affected_user_id: 4
permission: READ
2. row
entity_id: 4
affected_user_id: 4
permission: UPDATE
2 rows in set (0.000 sec)
Things i've tried so far:
- full wipe, installing guacamole from source as per the apache site
instructions
- installing using docker instead
- ubuntu 22.04, ubuntu 20.04
- using mySQL instead of MariaDB
- adding TOTP before first login
- adding TOTP after accounts are made
TLDR:
TOTP and 'expire password' seem to conflict. The most notable thing here is
that in the guacamole_system_permission table i was expecting to see a 'change
own password' value just like there is in the gui.
I've tried just about every different database and install method thats
supported, all with the same result.
Please let me know if there is any other data I should share, or if anyone has
any ideas.
Thanks!
Connor
> Reproduceable bug: TOTP incompatible with 'expire password' checkbox
> --------------------------------------------------------------------
>
> Key: GUACAMOLE-1691
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1691
> Project: Guacamole
> Issue Type: Bug
> Environment: Current envrionment:
> - Ubuntu 20.04.5 LTS Server
> - Guacamole server 1.4.0
> - guacamole-auth-jdbc-1.4.0
> - mysql-connector-java-8.0.30
> - guacamole-server-1.4.0
> - 10.3.34-MariaDB-0ubuntu0.20.04.1
> ## (i've tried many more as well, see 'things i've tried' below)
> Reporter: Connor Norris
> Priority: Major
>
> Hello avocado enthusiasts,
> I believe i've discovered a bug - i've spent the past 5 days inadvertently
> finding every environment its reproduceable in while trying to avoid it. This
> was not an issue around ~6 months ago when I last used guacamole, but it is
> now... maybe
> It would seem that TOTP is very specifically incompatible with the "expire
> password" checkbox in the Guac GUI.
> I have reached pretty much the full extent of my ability to debug this, and
> have tried... a lot... of different fixes and installation methods. Some
> pointers to a relevant log file with more verbosity would be incredibly
> useful! I'll try to format both what i've tried, the relevant logs, and how
> guac is currently installed below.
> Behavior:
> - On a clean install, the expire password checkbox functions normally. user1
> inputs password1, then they are prompted to change their expired password,
> and they input password2. Password 2 becomes their new password
> - After installing TOTP, then expiring a password, after the user changes
> password1 to password2 and inputstheir valid 2FA code, the user is sent back
> to the login screen with 'invalid login' at the top.
> - If user1 enters password1, (or any random password) they get 'invalid
> login' (expected)
> - if user1 now enters password2, they get 'Verification failed. Please try
> again.' ... this sorta implies that it KNOWS this is the correct newly
> updated password, given the error message is only different when entering
> that one password
> - user1 can no longer login without admin account intervention.
> Other pertinent details:
> - TOTP functions as expected in all other use cases. Clear TOTP and Confirm
> TOTP both function as expected.
> - The password for user1 can still be set manually by admin accounts
> - The self-serve 'change own password' bit still functions as expected
> - Clearing the TOTP secret while expiring the password in tandem does not
> solve the issue.
> - granting the user anything from change password, to all permissions and
> admin has no impact
> - Only the specific combination 'totp' + 'expire-password' seem to be
> incompatible
> Current environment:
> - Ubuntu 20.04.5 LTS Server
> - Guacamole server 1.4.0
> - guacamole-auth-jdbc-1.4.0
> - mysql-connector-java-8.0.30
> - guacamole-server-1.4.0
> - 10.3.34-MariaDB-0ubuntu0.20.04.1
> (i've tried many more as well, see 'things i've tried' below)
>
> {code:java}
> // /etc/guacamole/guacamole.properties
> ## MySQL properties
> mysql-hostname: 127.0.0.1
> mysql-port: 3306
> mysql-database: guacamole_db
> mysql-username: guacamole_user
> mysql-password: censored
> ## TOTP properties
> totp-issuer: guacamole
> ## (i've tried not changing the issuer as well{code}
>
> {code:java}
> // catalina.out
> log/var/lib/tomcat9/logs/catalina.out:727:[2022-09-30 20:10:01] [info]
> 20:10:01.371 [http-nio-8080-exec-8] INFO o.a.g.r.auth.AuthenticationService
> - User "user1" successfully authenticated from IPaddrX.
> /var/lib/tomcat9/logs/catalina.out:728:[2022-09-30 20:10:01] [info]
> 20:10:01.373 [http-nio-8080-exec-8] INFO o.a.g.auth.jdbc.user.UserService -
> Expired password of user "user1" has been reset.
> /var/lib/tomcat9/logs/catalina.out:729:[2022-09-30 20:10:20] [info]
> 20:10:20.475 [http-nio-8080-exec-7] WARN o.a.g.r.auth.AuthenticationService
> - Authentication attempt from IPaddrX for user "user1" failed
> {code}
>
> {code:java}
> // from the guacamole_db
> // the most interesting/notable thing here, is that the 'change own password'
> system permission seems to be missing from the user? it is visibly set in the
> gui. Not sure if that would be a row in system_permission or not.
> [guacamole_db]> select * from guacamole_entity where name=user1\G
> entity_id: 4
> name: user1
> type: USER
> [guacamole_db]> select * from guacamole_system_permission WHERE entity_id=4\G
> 1. row
> entity_id: 4
> permission: CREATE_CONNECTION
> 2. row
> entity_id: 4
> permission: CREATE_CONNECTION_GROUP
> 3. row
> entity_id: 4
> permission: CREATE_SHARING_PROFILE
> 4. row
> entity_id: 4
> permission: CREATE_USER
> 5. row
> entity_id: 4
> permission: CREATE_USER_GROUP
> 6. row
> entity_id: 4
> permission: ADMINISTER
> 6 rows in set (0.000 sec)
>
> [guacamole_db]> select * from guacamole_user_password_history\G
> Empty set (0.000 sec)
> ?? note: password history definitely exists... entering an old password
> generates and error the old and the new cannot be the same
> [guacamole_db]> select * from guacamole_user_permission WHERE entity_id=4\G
> 1. row
> entity_id: 4
> affected_user_id: 4
> permission: READ
> 2. row
> entity_id: 4
> affected_user_id: 4
> permission: UPDATE
> 2 rows in set (0.000 sec){code}
>
> Things i've tried so far:
> - full wipe, installing guacamole from source as per the apache site
> instructions
> - installing using docker instead
> - ubuntu 22.04, ubuntu 20.04
> - using mySQL instead of MariaDB
> - adding TOTP before first login
> - adding TOTP after accounts are made
>
> TLDR:
> TOTP and 'expire password' seem to conflict. The most notable thing here is
> that in the guacamole_system_permission table i was expecting to see a
> 'change own password' value just like there is in the gui.
> I've tried just about every different database and install method thats
> supported, all with the same result.
> Please let me know if there is any other data I should share, or if anyone
> has any ideas.
> Thanks!
> Connor
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
