Very interesting. Makes a lot of sense. I’m surprised this isn’t in the docs (or is it and I missed?). There should definitely be something there that mentions the consequences of whatever userid you are using with guacd.
> On Aug 20, 2022, at 8:54 AM, Nick Couchman <[email protected]> wrote: > > On Sat, Aug 20, 2022 at 8:40 AM Doug Baggett <[email protected]> wrote: >> >> ok. Running guacd under daemon was the problem, it has to run under guacd >> user. A good summary and quick instructions was here >> >> https://kifarunix.com/install-guacamole-on-debian-11/#fix-rdp-security-negotiation-failed >> >> Can anybody explain what is specific about connecting to Windows 10 pro that >> it requires guacd to run under the guacd user with a writable directory? >> > > Glad you got it figured out. It's not specific to Windows 10, but it > is specific to NLA. The FreeRDP libraries need a place to write known > NLA certificates out when you connect with NLA. It's similar to how > SSH has it's "known_hosts" file, but for NLA certificate fingerprints > instead of SSH fingerprints. Sometime in the last couple of years the > FreeRDP libraries changed to the point where, if the fingerprint > cannot be written out (because the account under which the libraries > are being used doesn't have a place to write them, or doesn't have > write access to the location), the connection will fail. This is what > you were hitting. The "daemon" user on many systems (EL7/8 in my > experience) uses /sbin as a home directory and doesn't have write > access to /sbin, so when guacd runs under that account, it can't write > the fingerprints out and the connections fail. For whatever reason > this is only for NLA and doesn't occur for TLS (xrdp) connections. > > -Nick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
