[jira] [Comment Edited] (GUACAMOLE-1212) Support 2FA Directly in LDAP Extension

["Mirek Malinowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291280#comment-17291280 ] 

Mirek Malinowski edited comment on GUACAMOLE-1212 at 2/25/21, 11:02 PM:
------------------------------------------------------------------------

Thanks, I've enabled debug, and it looks like our error is related to ENTRY_ALRADY exists, as the 2nd call to bind is to get UserContex if the user has one in LDAP and because we are only using LDAP for authentication and everything else is in MySQL it's been safe to instead throw an error at failed during data retrieval to just return null which is a correct action anyway if no data for a user is stored in LDAP. I've also tried to update ldap.api to version 2.0.1, hoping maybe they did something but still the same issue.

{color:#000000}22:38:46.329 [http-nio-8080-exec-3] DEBUG o.a.g.a.ldap.LDAPConnectionService - Bind attempt with LDAP server as user "uid=c111111,cn=users,cn=accounts,dc=mydomain,dc=lab" failed. {color}
 org.apache.directory.api.ldap.model.exception.LdapAuthenticationException:  
        at org.apache.directory.api.ldap.model.message.ResultCodeEnum.processResponse(ResultCodeEnum.java:1995) 
        at org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1308) 
        at org.apache.guacamole.auth.ldap.LDAPConnectionService.bindAs(LDAPConnectionService.java:251)

Don't know enough about LDAP injected connections and why it's used but I'm happy to test any code changes in our FreeIPA enviorment.


was (Author: mirek186):
Thanks, I've enabled debug, and it looks like our error is related to ENTRY_ALRADY exists, as the 2nd call to bind is to get UserContex if the user has one in LDAP and because we are only using LDAP for authentication and everything else is in MySQL it's been safe to instead throw an error at failed during data retrieval to just return null which is a correct action anyway if no data for a user is stored in LDAP. I've also tried to update ldap.api to version 2.0.1, hoping maybe they did something but still the same issue.

{color:#000000}22:38:46.329 [http-nio-8080-exec-3] DEBUG o.a.g.a.ldap.LDAPConnectionService - Bind attempt with LDAP server as user "uid=c111111,cn=users,cn=accounts,dc=stuxnet,dc=lab" failed. {color}
 org.apache.directory.api.ldap.model.exception.LdapAuthenticationException:  
        at org.apache.directory.api.ldap.model.message.ResultCodeEnum.processResponse(ResultCodeEnum.java:1995) 
        at org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1308) 
        at org.apache.guacamole.auth.ldap.LDAPConnectionService.bindAs(LDAPConnectionService.java:251)


Don't know enough about LDAP injected connections and why it's used but I'm happy to test any code changes in our FreeIPA enviorment.

> Support 2FA Directly in LDAP Extension
> --------------------------------------
>
>                 Key: GUACAMOLE-1212
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1212
>             Project: Guacamole
>          Issue Type: Improvement
>          Components: guacamole-auth-ldap
>            Reporter: Brett Smith
>            Priority: Minor
>
> I'm using FreeIPA in my environment. I have guacamole-auth-ldap enabled and configured and it works fine for users who do not have 2FA enabled. For our users with 2FA enabled, we are using TOTP tokens provided by FreeIPA.
> When investigating a tcpdump between guacamole and the LDAP server, I can see that guacamole passes the username and password to the LDAP server twice. This works fine for a traditional username and password, but for a 2FA-enabled user, the second authentication attempt returns failure since the TOTP is one-time use. 2FA login attempts result in the guacamole logs outputting "successfully authenticated" while the web UI shows "Invalid Login" in a red banner.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)