On Sun, Jan 7, 2018 at 9:48 AM Amarjeet Singh <amarjee...@gmail.com> wrote:

>  If I don't pass username and password then ${GUAC_USERNAME} fails to
> resolve [ *Scenario : I want users to enter username and password on
> Windows screen* ]. It create directory with it's own name i.e.
> ${GUAC_USERNAME}
>
>
> So, Creating filesystem solved this issue and It created directories of
> users at runtime using "*enable-create-drive*" parameter.
>
> Now, I need to look into the following to achieve quotas per sub-volumes
> or each user's directory. :-
>
> ZFS or btrfs, for example, allow for sub-volumes and quotas per-volume,
>> per-user, and/or per-group
>>
>
>  Using SFTP  is a good idea though but in case I want the user to enter 
> *username
> and password* on the Windows screen then It would fail.
>
> *Can't save username and password on the user-mapping.xml file for
> security purposes.*
>

I would not use the user-mapping.xml file for the size of production
environment that you're using.  First, I'm not certain that the tokens
(${GUAC_USERNAME} and ${GUAC_PASSWORD}) actually work with the simple/basic
file authentication mechanism.  Mike can verify this.  Second, storing
usernames/passwords in user-mapping.xml for 500 users seems like a bad idea.

If you're considering scaling to this level, I suggest using one or more of
the extension modules for authentication - at least the JDBC module, and
perhaps that in combination with something, like LDAP.  If you're using
active directory for the Windows servers you're connecting to this makes a
lot of sense, because the username/password used to log in to Guacamole
will match to the servers you're logging into.  If you're not, it still
might make sense to track users in some sort of database - either JDBC or
LDAP - as this will provide continuity across the environment.

-Nick

Reply via email to