[jira] [Commented] (GUACAMOLE-538) Add the ability to specify separate permissions for "History" and "Active sessions" tabs
[ https://issues.apache.org/jira/browse/GUACAMOLE-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428447#comment-16428447 ] Fabian Rodriguez commented on GUACAMOLE-538: The current ADMINISTER permission is all inclusive as I understand it. This issue is about having the choice to assign more granular permissions to the "History" and "Acrives sessions" tabs. Another use case is giving a junior tech the ability to manage connections while not having access to active sessions and/or history. > Add the ability to specify separate permissions for "History" and "Active > sessions" tabs > > > Key: GUACAMOLE-538 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-538 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Fabian Rodriguez >Priority: Minor > > In Settings > Users > $USER > Permissions, I'd like to be able to set two > extra permissions: > * access sessions History tab > * access Active Sessions tab. > This would help when it's required to provide a manager access to history and > active sessions, while avoiding giving them full admin rights (change/add > users/connections). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-538) Add the ability to specify separate permissions for "History" and "Active sessions" tabs
[ https://issues.apache.org/jira/browse/GUACAMOLE-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428254#comment-16428254 ] Nick Couchman commented on GUACAMOLE-538: - This is at least related to, if not a duplicate of GUACAMOLE-460. > Add the ability to specify separate permissions for "History" and "Active > sessions" tabs > > > Key: GUACAMOLE-538 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-538 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Fabian Rodriguez >Priority: Minor > > In Settings > Users > $USER > Permissions, I'd like to be able to set two > extra permissions: > * access sessions History tab > * access Active Sessions tab. > This would help when it's required to provide a manager access to history and > active sessions, while avoiding giving them full admin rights (change/add > users/connections). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-527) Add parameter for specifying known SSH/SFTP server fingerprint
[ https://issues.apache.org/jira/browse/GUACAMOLE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428216#comment-16428216 ] Nick Couchman commented on GUACAMOLE-527: - Server and client PRs submitted and waiting for review. > Add parameter for specifying known SSH/SFTP server fingerprint > -- > > Key: GUACAMOLE-527 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-527 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, RDP, SSH, VNC >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Major > > Guacamole's SSH support (used for both SSH terminal connections and SFTP) > currently does not provide a mechanism for verifying the identity of the SSH > server. In case Guacamole is used to access computers across untrusted > networks (or using hostnames queried from untrusted DNS), additional > parameters should be provided allowing the administrator to explicitly > specify the known key fingerprint of the SSH server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-527) Add parameter for specifying known SSH/SFTP server fingerprint
[ https://issues.apache.org/jira/browse/GUACAMOLE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-527: Component/s: Documentation > Add parameter for specifying known SSH/SFTP server fingerprint > -- > > Key: GUACAMOLE-527 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-527 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, RDP, SSH, VNC >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Major > > Guacamole's SSH support (used for both SSH terminal connections and SFTP) > currently does not provide a mechanism for verifying the identity of the SSH > server. In case Guacamole is used to access computers across untrusted > networks (or using hostnames queried from untrusted DNS), additional > parameters should be provided allowing the administrator to explicitly > specify the known key fingerprint of the SSH server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-537) Implement a "connection event tracker" note or comment
[ https://issues.apache.org/jira/browse/GUACAMOLE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-537: Priority: Minor (was: Major) > Implement a "connection event tracker" note or comment > -- > > Key: GUACAMOLE-537 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-537 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Reporter: Fabian Rodriguez >Priority: Minor > > I'd like to suggest implementing an optional "connection event tracker" to > log a reference, note, comment or reason to connect when doing so. > This would be a question asked before each connection, where the user would > have to indicate why the connection is being established,for logging > purposes. This information would then be visible in the history report. > Windows servers implement this, I can't seem to be able to attach an image > here, lots of example can be found doing an image search for "windows > shutdown event tracker". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-537) Implement a "connection event tracker" note or comment
[ https://issues.apache.org/jira/browse/GUACAMOLE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-537: Component/s: (was: guacamole) guacamole-client > Implement a "connection event tracker" note or comment > -- > > Key: GUACAMOLE-537 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-537 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Reporter: Fabian Rodriguez >Priority: Minor > > I'd like to suggest implementing an optional "connection event tracker" to > log a reference, note, comment or reason to connect when doing so. > This would be a question asked before each connection, where the user would > have to indicate why the connection is being established,for logging > purposes. This information would then be visible in the history report. > Windows servers implement this, I can't seem to be able to attach an image > here, lots of example can be found doing an image search for "windows > shutdown event tracker". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-536) Enhance restrictive LDAP authentication configuration requirements
[
https://issues.apache.org/jira/browse/GUACAMOLE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-536:
Priority: Minor (was: Blocker)
> Enhance restrictive LDAP authentication configuration requirements
> --
>
> Key: GUACAMOLE-536
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-536
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
>Reporter: Joseph L. Casale
>Priority: Minor
>
> The current LDAP authentication scheme can recursively search the base DN
> only when a bind DN is used. When biding with the user attempting to log on,
> the bind DN format pattern is not exposed through configuration which imposes
> unnatural restrictions forcing the user to exist in a single container.
> If the format pattern was exposed for configuration, for DSA's which allow
> flexible bind patterns such as Active Directory, configuration could allow
> "DOMAIN
> %s" or "%s...@domain.com" and for those DSA's which do not, you would simply
> configure the restrictive full DN as the pattern.
> The use case is that we use Active Directory anddo not allow bind accounts so
> the restriction prevents all users from accessing the application as our
> topology is not flat (we need to pick a single container therefor excluding
> everyone else).
> A working Java implementation of an LDAP auth scheme that facilitates this is
> [Gitblit|http://gitblit.com/properties.html], see the realm.ldap.*
> configuration properties. Setting the bind pattern to the UPN such as:
> {code:java}
> realm.ldap.bindpattern = ${username}@domain.com
> {code}
> allows the flexible configuration in our Active Directory environment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
