Mailing-List: contact user-help@guacamole.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@guacamole.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGqQFsMhS-4p6G_88Ft=CuxzZPKS7nEd=-86Dm2EFQziO8CmLQ@mail.gmail.com>
References: <CAGqQFsMhS-4p6G_88Ft=CuxzZPKS7nEd=-86Dm2EFQziO8CmLQ@mail.gmail.com>
From: Mike Jumper <mike.jumper@guac-dev.org>
Date: Fri, 4 Nov 2016 23:34:18 -0700
Message-ID: <CALKeL-NS42aJSUE3skZXt+SibgfLKoV3SFmtdCz=984jZiFLRA@mail.gmail.com>
Subject: Re: Apache front end with HTTP Basic authentication Windows AD LDAP -
 username and password tokens
To: user@guacamole.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a113f0326f728c3054087fa3d
archived-at: Sat, 05 Nov 2016 06:34:25 -0000

--001a113f0326f728c3054087fa3d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 31, 2016 at 6:51 AM, Patrick L Archibald (PLA) =E2=98=AE <
patrick.archibald@gmail.com> wrote:

> Hi,
>
> Our Intranet is an Apache front end configured with HTTP Basic
> authentication via LDAP to a Windows AD. Apache uses ProxyPass
> websocket-tunnel to the Guac Tomcat application server.
>
> I would like to pass the HTTP Basic authentication user name and
> password to Windows 2008 R2 RDS VMs and Windows 7 VMs.


Guacamole will do this automatically, at least in part. If the
"Authorization" header is present from HTTP Basic authentication,
Guacamole's authentication system will automatically pull the username and
password and pass them to installed authentication extensions.


> I had noauth-config.xml configured like so:
>

If you want usernames or passwords to have any meaning, using NoAuth (the
extension which effectively neuters the authentication system) is
definitely not the way to go. More on this below.


> Before I roll my own authentication, is there a BASIC_USERNAME and
> BASIC_PASSWORD token?
>
>
There are no such tokens, but if there is no true separation of identity
between the user authenticating via HTTP Basic and the user authenticating
with the RDP server, I think it would be a mistake to try to force such a
separation within Guacamole. It would be better to embrace Guacamole's
concept of a user and credentials, and allow the layers to communicate
properly.

For an arbitrary user X, you currently have the following layers, connected
in order:

1) Proxy (configured to verify and recognize user X)
2) Guacamole (configured to not recognize anyone thanks to NoAuth)
3) RDP (configured to verify and recognize user X)

The system here breaks down because the middle layer (Guacamole) has been
explicitly configured to not care about identity. What you should be doing
instead is:

1) Proxy (configured to verify and recognize user X)
2) Guacamole (configured to verify and recognize user X)
3) RDP (configured to verify and recognize user X)

If each layer is configured to verify and recognize the user in the same
way, then each layer will function as expected, including the behavior of
things like the ${GUAC_USERNAME} and ${GUAC_PASSWORD} tokens.

Any other suggestions?
>
>
I'd recommend using the LDAP authentication included with Guacamole, either
on its own or together with a database. As long as you configure the LDAP
authentication to use the same Windows AD server as your proxy, the
username/password within the HTTP Basic authentication will just magically
work, and users will not need to manually log in.

You would end up with a system which re-verifies the credentials provided,
and then pulls connection data from elsewhere. If eventually someone
manages to access your Guacamole server without going through your
authenticating proxy, Guacamole would itself enforce authentication, and
things remain secure.

Thanks,

- Mike

--001a113f0326f728c3054087fa3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 31, 2016 at 6:51 AM, Patrick L Archibald (PLA) =E2=98=AE <span dir=
=3D"ltr">&lt;<a href=3D"mailto:patrick.archibald@gmail.com" target=3D"_blan=
k">patrick.archibald@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Hi,<br>
<br>
Our Intranet is an Apache front end configured with HTTP Basic<br>
authentication via LDAP to a Windows AD. Apache uses ProxyPass<br>
websocket-tunnel to the Guac Tomcat application server.<br>
<br>
I would like to pass the HTTP Basic authentication user name and<br>
password to Windows 2008 R2 RDS VMs and Windows 7 VMs.</blockquote><div><br=
></div><div>Guacamole will do this automatically, at least in part. If the =
&quot;Authorization&quot; header is present from HTTP Basic authentication,=
 Guacamole&#39;s authentication system will automatically pull the username=
 and password and pass them to installed authentication extensions.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I had=C2=
=A0noauth-config.xml configured like so:<br></blockquote><div><br></div><di=
v>If you want usernames or passwords to have any meaning, using NoAuth (the=
 extension which effectively neuters the authentication system) is definite=
ly not the way to go. More on this below.</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
<br>
Before I roll my own authentication, is there a BASIC_USERNAME and<br>
BASIC_PASSWORD token?<br>
<br></blockquote><div><br></div><div>There are no such tokens, but if there=
 is no true separation of identity between the user authenticating via HTTP=
 Basic and the user authenticating with the RDP server, I think it would be=
 a mistake to try to force such a separation within Guacamole. It would be =
better to embrace Guacamole&#39;s concept of a user and credentials, and al=
low the layers to communicate properly.</div><div><br></div><div>For an arb=
itrary user X, you currently have the following layers, connected in order:=
</div><div><br></div><div>1) Proxy (configured to verify and recognize user=
 X)</div><div>2) Guacamole (configured to not recognize anyone thanks to No=
Auth)</div><div>3) RDP=C2=A0(configured to verify and recognize user X)</di=
v><div><br></div><div>The system here breaks down because the middle layer =
(Guacamole) has been explicitly configured to not care about identity. What=
 you should be doing instead is:</div><div><br></div><div><div>1) Proxy (co=
nfigured to verify and recognize user X)</div><div>2) Guacamole=C2=A0(confi=
gured to verify and recognize user X)</div><div>3) RDP=C2=A0(configured to =
verify and recognize user X)</div></div><div><br></div><div>If each layer i=
s configured to verify and recognize the user in the same way, then each la=
yer will function as expected, including the behavior of things like the ${=
GUAC_USERNAME} and ${GUAC_PASSWORD} tokens.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
Any other suggestions?<br>
<br></blockquote><div><br></div><div>I&#39;d recommend using the LDAP authe=
ntication included with Guacamole, either on its own or together with a dat=
abase. As long as you configure the LDAP authentication to use the same Win=
dows AD server as your proxy, the username/password within the HTTP Basic a=
uthentication will just magically work, and users will not need to manually=
 log in.</div><div><br></div><div>You would end up with a system which re-v=
erifies the credentials provided, and then pulls connection data from elsew=
here. If eventually someone manages to access your Guacamole server without=
 going through your authenticating proxy, Guacamole would itself enforce au=
thentication, and things remain secure.<br></div><div><br></div><div>Thanks=
,</div><div><br></div><div>- Mike</div><div><br></div></div></div></div>

--001a113f0326f728c3054087fa3d--