RE: Hebrew/English keyboard layout challenges
All Right-To-Left language implementations (Hebrew, Arabic, Farsi, Aramaic, etc.) work this way, with dynamic switching of keyboard layouts, and most use the same key combination for switching between the layouts (either Alt+Shift or LCtrl/RCtrl+Shift). You should take into account that RTL languages use totally different non-Latin character sets, so there’s no way getting around in a Latin OS without being able to switch back and forth between English characters and Hebrew ones. Also, due to unfortunate historic typewriter layout reasons, punctuation marks are located on different physical keys compared to Latin layouts. Uri From: Nick Couchman Sent: Monday, May 6, 2024 7:07 PM To: user@guacamole.apache.org Subject: Re: Hebrew/English keyboard layout challenges On Mon, May 6, 2024 at 10:31 AM mailto:u...@alyn.org>> wrote: Hi there, We are using Guacamole 1.5.4 for Windows RDP, and are faced with a challenging keyboard layout mapping problem. Our clients and servers all use the same Hebrew keyboard layout which is based on standard US-qwerty, and is switchable on the Windows OS level (using a combined Alt+Shift keypress) between English and Hebrew layouts. While connected through Guacamole, as long as the client’s Windows language is set to ENG everything works fine, since the JS key events are translated by the Guacamole client to standard keysyms, which in turn are translated back on the server to the appropriate Windows scancode values. In this scenario it doesn’t matter which language is currently set active within the RDP session (on the target Windows session), since it receives the standard scancodes from Guacamole server and interprets them according to the active session language layout. The mess begins when the client’s selected Windows language is set to HEB (which happens every time the user intuitively presses Alt+Shift during work in the RDP session). In this case, the Guacamole client intercepts unmapped Hebrew key presses, so by default it sends them as Unicode to the server. This is sort of half a problem when both client and remote RDP session languages are set to HEB, but when client machine is set to HEB and RDP session set to ENG, unwanted results occur (Hebrew characters are typed instead of English). Yes, this will be a problem if users are changing the keyboard layout on the remote side without updating the client-side (Guacamole) keyboard layout - you'll get a mis-match and odd character input. The behavior for Unicode characters being sent when the keys are not mapped is completely intentional - it's designed to give a "fail-safe" for Guacamole in situations where the keymap is undefined. I was able to get over most of this effect by adding the following lines to en_us_qwerty.keymap: map -caps -shift 0x12..0x19 ~ "קראטוןםפ" map -caps -shift 0x1E..0x27 ~ "שדגכעיחלךף" map -caps -shift 0x2C..0x34 ~ "זסבהנמצתץ" map +caps +shift 0x12..0x19 ~ "קראטוןםפ" map +caps +shift 0x1E..0x27 ~ "שדגכעיחלךף" map +caps +shift 0x2C..0x34 ~ "זסבהנמצתץ" This maps client Hebrew key presses to their proper physical scancodes, but it only partly reduces the frustration since there are still problematic leftovers: • In Hebrew layout, the Slash (/) sign is located on the KeyQ key, while in English layout it’s on the ordinary Slash key • The Quote (‘) sign is located on the KeyW in Hebrew, and on ordinary Quote key in English • The Comma (,) sign is located on the Quote key in Hebrew, and on ordinary Comma in English • The Period (.) sign is located on the Slash key in Hebrew, and on ordinary Period in English • The Semicolon (;) sign is located on the Backquote key in Hebrew, and on Semicolon in English So at the moment, as you can gather, if client language is set to HEB and server Guacamole RDP session language is set to ENG, pressing ‘q’ will lead to a slash (/) sign pressing ‘w’ will lead to Quote (‘), etc., which really is a problem that our users can’t live with. To sum the long story short, two questions: 1. Is there a way to make the Guacamole client be aware of the currently active Windows language, and define different layouts correlating to their relevant languages? I'll have to look at the FreeRDP source code, but I don't think there's a feedback loop or callback for when the remote side changes the keyboard layout - I think the expectation is that the client-side keyboard is a fixed (physical) keyboard, so it will not dynamically change, and that you'd want that to stay the same for the entire remote session. I can't foresee a lot of situations where you'd want the client-side keymap to change on-the-fly. 2. Alternatively, on Windows machine scenarios (client + servers) the whole back-and-forth conversion from client JS Key code (which is equivalent to scancode) through generic keysym and then back to scancode on server
Nesting SAML and Local Groups
Hello, I'm piloting Apache Guacamole in our organization and I have been trying to see if there is a way to nest SAML groups with Local Groups. I am able to get users authenticated and resources assigned via SAML groups using the group ID, but for the sake of ease of management what I was hoping to do would be to have a local group defined with the connections assigned to it, and then make the SAML group a member of that locally defined group. ex. Local Group - "ACME Contracting" has access to a Building Automation Server. Entra ID (Azure AD) group ID "7beb9ac3-6042-4fce-a5ff-430e212363ab" contains users defined in our tenant. This Group ID is also configured as a Member of "ACME Contracting" so that users within the Entra/Azure group inherit the connections assigned to "ACME Contracting". In my testing, this doesn't seem to work. Is this in any way possible with Guacamole? Thanks, Gino
Re: [GUAC] Using with AAD Joined RDP w/ NLA?
Yes, but my systems are exclusively Azure AD Joined which I believe add some unique restrictions. For example, you can only RDP from another machine that is also joined or registered. However, the web sign in option works without this requirement but requires using the hostname of the machine, IP address wont work. I doubt Guacamole can pass through the web sign in though. My best guess is that the only way is to disable NLA but will be happy to be told I am wrong. -mike On Monday, May 6, 2024 at 01:00:30 PM EDT, Daniel Carroll wrote: By Entra-joined, you mean where "AzureAdJoined" shows "YES" in the output of dsregcmd /status? Our systems are hybrid joined (both AzureADJoined and DominJoined) with NLA enabled and they have been working fine with Guacamole/RDP. We don't have any systems that are exclusively AzureADJoined (and not DomainJoined) though. Thanks, - Daniel -Original Message- From: Mike Sent: Mon May 06 2024 10:22:01 MDT Subject: [GUAC] Using with AAD Joined RDP w/ NLA? Hi, I am wondering if anyone is successfully using Guacamole with AAD-Joined (Entra-joined) windows desktops w/ RDP without having to disable NLA? - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: Hebrew/English keyboard layout challenges
On 5/6/24 9:06 AM, Nick Couchman wrote: On Mon, May 6, 2024 at 10:31 AM mailto:u...@alyn.org>> wrote: ... To sum the long story short, two questions: 1.Is there a way to make the Guacamole client be aware of the currently active Windows language, and define different layouts correlating to their relevant languages? I'll have to look at the FreeRDP source code, but I don't think there's a feedback loop or callback for when the remote side changes the keyboard layout - I think the expectation is that the client-side keyboard is a fixed (physical) keyboard, so it will not dynamically change, and that you'd want that to stay the same for the entire remote session. I can't foresee a lot of situations where you'd want the client-side keymap to change on-the-fly. Sadly, this is simply not reported over RDP by the RDP server. I remember implementing the Guacamole side of this and wishing that such a mechanism existed. An RDP client can request a particular layout during the RDP connection process, but receives no information from the server if that layout is changed later after the RDP session has started. 2.Alternatively, on Windows machine scenarios (client + servers) the whole back-and-forth conversion from client JS Key code (which is equivalent to scancode) through generic keysym and then back to scancode on server side, seems redundant when clients and servers share the same keyboard layouts. Is there a way to configure the client to avoid it, and hence implement direct mapping from client JS Key code to server scancode? Mike can probably comment more thoroughly on this, but my understanding is that, no, this is not possible. Even in situations where client and server keyboard layouts match, in order to properly interpret the keyboard input, particularly for characters that require modifiers, the key mapping needs to be done from JS to the Windows scancodes. No, the keycode cannot be used for this (more on this below). There is a more recently introduced value that is directly related to the scancode and might be usable for cases where it's not possible to ensure the remote keyboard layout is predictable/correct, but: * Moving in that direction would be a step away from Guacamole's idealistic, layout-independent posture. If we do this, I think we'd best put that behavior behind an option and clearly document why usage of that option is discouraged (users should be able to transparently use whatever keyboard they want locally and not have to worry about making corresponding settings changes inside the remote desktop - that's an admin concern). * There will always be cases where there is no scancode, such as characters typed using dead keys, the on-screen keyboards of mobile devices, and IMEs like those used for inputting Chinese characters. Doing this could mean that we'd have the opposite problem and would need to somehow produce usable scancodes for key events that do not have scancodes by their own nature. Fun fact: the JS keycode is actually not a very useful value. It's commonly misunderstood to be a scancode, but the value is only loosely related to the scancode of the key. It's actually defined as the scancode of the key that would be used to type the desired character on a US keyboard. This means: * The value is ambiguous for different keys on non-US keyboards that produce characters that happen to be located on the same key on US keyboards. * The value is not well defined for keys that don't exist on a US keyboard. See: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode - Mike - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: [GUAC] Using with AAD Joined RDP w/ NLA?
By Entra-joined, you mean where "AzureAdJoined" shows "YES" in the output of dsregcmd /status? Our systems are hybrid joined (both AzureADJoined and DominJoined) with NLA enabled and they have been working fine with Guacamole/RDP. We don't have any systems that are exclusively AzureADJoined (and not DomainJoined) though. Thanks, - Daniel -Original Message- From: Mike Sent: Mon May 06 2024 10:22:01 MDT Subject: [GUAC] Using with AAD Joined RDP w/ NLA? Hi, I am wondering if anyone is successfully using Guacamole with AAD-Joined (Entra-joined) windows desktops w/ RDP without having to disable NLA? - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Using with AAD Joined RDP w/ NLA?
Hi, I am wondering if anyone is successfully using Guacamole with AAD-Joined (Entra-joined) windows desktops w/ RDP without having to disable NLA? Thanks Mike
Re: Multiple Shared-drives showing in Guacamole
On Mon, May 6, 2024 at 7:38 AM Viji Shankar wrote: > Hi Team, > > The issue occurs when initiating a single connection. We are not utilizing > the multiple connection feature. > Thanks for confirming. > > ERROR in guacd container: > > > > > > *guacd[60]: ERROR: File open refused (-2): "\desktop.ini"guacd[60]: > ERROR: File open refused (-2): "\Download\desktop.ini"guacd[60]: > ERROR: File open refused (-2): "\desktop.ini"guacd[60]: ERROR: > File open refused (-2): "\Download\desktop.ini"guacd[60]: ERROR: File > open refused (-2): "\Download\desktop.ini"* > > Hmmm...those files may not exist, but, if they do exist, can you make sure that permissions are set correctly such that guacd (or the container) has access to those files? > We are currently utilizing Guacamole version 1.5.3, and we have opted for > the official stock version without any modifications to its codebase. > Despite dropping and recreating the database and restarting the Guacamole > pod, the issue persists. > > Is there anything we have to check in the Windows machine as well? > I don't think so - I believe that the Shared Folder you're seeing in the web menu is completely outside of the Windows connection. I don't know why it would be showing up multiple times, but maybe there's some bug that causes this when permissions are not correct? -Nick
Re: Hebrew/English keyboard layout challenges
On Mon, May 6, 2024 at 10:31 AM wrote: > Hi there, > > > > We are using Guacamole 1.5.4 for Windows RDP, and are faced with a > challenging keyboard layout mapping problem. > > > > Our clients and servers all use the same Hebrew keyboard layout which is > based on standard US-qwerty, and is switchable on the Windows OS level > (using a combined Alt+Shift keypress) between English and Hebrew layouts. > > > > While connected through Guacamole, as long as the client’s Windows > language is set to ENG everything works fine, since the JS key events are > translated by the Guacamole client to standard keysyms, which in turn are > translated back on the server to the appropriate Windows scancode values. > In this scenario it doesn’t matter which language is currently set active > within the RDP session (on the target Windows session), since it receives > the standard scancodes from Guacamole server and interprets them according > to the active session language layout. > > > > The mess begins when the client’s selected Windows language is set to HEB > (which happens every time the user intuitively presses Alt+Shift during > work in the RDP session). In this case, the Guacamole client intercepts > unmapped Hebrew key presses, so by default it sends them as Unicode to the > server. This is sort of half a problem when both client and remote RDP > session languages are set to HEB, but when client machine is set to HEB and > RDP session set to ENG, unwanted results occur (Hebrew characters are typed > instead of English). > > > Yes, this will be a problem if users are changing the keyboard layout on the remote side without updating the client-side (Guacamole) keyboard layout - you'll get a mis-match and odd character input. The behavior for Unicode characters being sent when the keys are not mapped is completely intentional - it's designed to give a "fail-safe" for Guacamole in situations where the keymap is undefined. > I was able to get over most of this effect by adding the following lines > to *en_us_qwerty.keymap*: > > > > map -caps -shift 0x12..0x19 ~ "קראטוןםפ" > > map -caps -shift 0x1E..0x27 ~ "שדגכעיחלךף" > > map -caps -shift 0x2C..0x34 ~ "זסבהנמצתץ" > > > > map +caps +shift 0x12..0x19 ~ "קראטוןםפ" > > map +caps +shift 0x1E..0x27 ~ "שדגכעיחלךף" > > map +caps +shift 0x2C..0x34 ~ "זסבהנמצתץ" > > > > This maps client Hebrew key presses to their proper physical scancodes, > but it only partly reduces the frustration since there are still > problematic leftovers: > > > > · In Hebrew layout, the Slash (/) sign is located on the KeyQ key, > while in English layout it’s on the ordinary Slash key > > · The Quote (‘) sign is located on the KeyW in Hebrew, and on > ordinary Quote key in English > > · The Comma (,) sign is located on the Quote key in Hebrew, and on > ordinary Comma in English > > · The Period (.) sign is located on the Slash key in Hebrew, and on > ordinary Period in English > > · The Semicolon (;) sign is located on the Backquote key in Hebrew, > and on Semicolon in English > > > > So at the moment, as you can gather, if client language is set to HEB and > server Guacamole RDP session language is set to ENG, pressing ‘q’ will lead > to a slash (/) sign pressing ‘w’ will lead to Quote (‘), etc., which really > is a problem that our users can’t live with. > > > > To sum the long story short, two questions: > > > > 1. Is there a way to make the Guacamole client be aware of the > currently active Windows language, and define different layouts correlating > to their relevant languages? > > > I'll have to look at the FreeRDP source code, but I don't think there's a feedback loop or callback for when the remote side changes the keyboard layout - I think the expectation is that the client-side keyboard is a fixed (physical) keyboard, so it will not dynamically change, and that you'd want that to stay the same for the entire remote session. I can't foresee a lot of situations where you'd want the client-side keymap to change on-the-fly. > 2. Alternatively, on Windows machine scenarios (client + servers) the > whole back-and-forth conversion from client JS Key code (which is > equivalent to scancode) through generic keysym and then back to scancode on > server side, seems redundant when clients and servers share the same > keyboard layouts. Is there a way to configure the client to avoid it, and > hence implement direct mapping from client JS Key code to server scancode? > > > Mike can probably comment more thoroughly on this, but my understanding is that, no, this is not possible. Even in situations where client and server keyboard layouts match, in order to properly interpret the keyboard input, particularly for characters that require modifiers, the key mapping needs to be done from JS to the Windows scancodes. Is there a reason that you would not want to just implement the Hebrew keyboard layout in
Hebrew/English keyboard layout challenges
Hi there, We are using Guacamole 1.5.4 for Windows RDP, and are faced with a challenging keyboard layout mapping problem. Our clients and servers all use the same Hebrew keyboard layout which is based on standard US-qwerty, and is switchable on the Windows OS level (using a combined Alt+Shift keypress) between English and Hebrew layouts. While connected through Guacamole, as long as the client’s Windows language is set to ENG everything works fine, since the JS key events are translated by the Guacamole client to standard keysyms, which in turn are translated back on the server to the appropriate Windows scancode values. In this scenario it doesn’t matter which language is currently set active within the RDP session (on the target Windows session), since it receives the standard scancodes from Guacamole server and interprets them according to the active session language layout. The mess begins when the client’s selected Windows language is set to HEB (which happens every time the user intuitively presses Alt+Shift during work in the RDP session). In this case, the Guacamole client intercepts unmapped Hebrew key presses, so by default it sends them as Unicode to the server. This is sort of half a problem when both client and remote RDP session languages are set to HEB, but when client machine is set to HEB and RDP session set to ENG, unwanted results occur (Hebrew characters are typed instead of English). I was able to get over most of this effect by adding the following lines to en_us_qwerty.keymap: map -caps -shift 0x12..0x19 ~ "קראטוןםפ" map -caps -shift 0x1E..0x27 ~ "שדגכעיחלךף" map -caps -shift 0x2C..0x34 ~ "זסבהנמצתץ" map +caps +shift 0x12..0x19 ~ "קראטוןםפ" map +caps +shift 0x1E..0x27 ~ "שדגכעיחלךף" map +caps +shift 0x2C..0x34 ~ "זסבהנמצתץ" This maps client Hebrew key presses to their proper physical scancodes, but it only partly reduces the frustration since there are still problematic leftovers: · In Hebrew layout, the Slash (/) sign is located on the KeyQ key, while in English layout it’s on the ordinary Slash key · The Quote (‘) sign is located on the KeyW in Hebrew, and on ordinary Quote key in English · The Comma (,) sign is located on the Quote key in Hebrew, and on ordinary Comma in English · The Period (.) sign is located on the Slash key in Hebrew, and on ordinary Period in English · The Semicolon (;) sign is located on the Backquote key in Hebrew, and on Semicolon in English So at the moment, as you can gather, if client language is set to HEB and server Guacamole RDP session language is set to ENG, pressing ‘q’ will lead to a slash (/) sign pressing ‘w’ will lead to Quote (‘), etc., which really is a problem that our users can’t live with. To sum the long story short, two questions: 1. Is there a way to make the Guacamole client be aware of the currently active Windows language, and define different layouts correlating to their relevant languages? 2. Alternatively, on Windows machine scenarios (client + servers) the whole back-and-forth conversion from client JS Key code (which is equivalent to scancode) through generic keysym and then back to scancode on server side, seems redundant when clients and servers share the same keyboard layouts. Is there a way to configure the client to avoid it, and hence implement direct mapping from client JS Key code to server scancode? Thanks, Uri הודעת דואר אלקטרוני זו נשלחה אליך מבית החולים אלי"ן. יתכן שבהודעה כלול מידע רפואי רגיש המוגן בחוק הגנת הפרטיות התשמ"ה 1981, מידע שנועד לשימושם הבלעדי של המכותבים הישירים אליהם נשלחה ההודעה במקור. אם ההודעה אינה מיועדת לך, ואף שיתכן שהגיעה אליך בטעות, הרי שחלה עליך חובת שמירת סודיות. במקרה כזה אנא עדכן באופן מיידי את השולח, ומחק/י את כל עותקיה של ההודעה הנמצאים ברשותך. The contents of this email was sent to you by ALYN Hospital. This email might contain confidential medical information, which is legally protected by the 1981 privacy law. This information is intended only for the use of the original addressee/s of the email from the original sender only. If you are not an intended recipient of the original sender, you are hereby notified that any disclosure, copying, and distribution of this information, is strictly prohibited. If you have received this email in error, please immediately notify the sender and delete any copies of this email in your possession.
Re: Multiple Shared-drives showing in Guacamole
Hi Team, The issue occurs when initiating a single connection. We are not utilizing the multiple connection feature. ERROR in guacd container: *guacd[60]: ERROR: File open refused (-2): "\desktop.ini"guacd[60]: ERROR: File open refused (-2): "\Download\desktop.ini"guacd[60]: ERROR: File open refused (-2): "\desktop.ini"guacd[60]: ERROR: File open refused (-2): "\Download\desktop.ini"guacd[60]: ERROR: File open refused (-2): "\Download\desktop.ini"* We are currently utilizing Guacamole version 1.5.3, and we have opted for the official stock version without any modifications to its codebase. Despite dropping and recreating the database and restarting the Guacamole pod, the issue persists. Is there anything we have to check in the Windows machine as well? Regards, Viji S On Fri, May 3, 2024 at 10:15 PM Nick Couchman wrote: > On Fri, May 3, 2024 at 10:55 AM Viji Shankar > wrote: > >> Hi Team, >> >> I am encountering an issue when attempting to connect to the Virtual >> Machine via Guacamole. Multiple shared drives are appearing in the >> Guacamole File System. I have attached a screenshot for reference. >> >> Could you please assist in resolving this matter? We are utilizing a >> MySQL server. I would like guidance on identifying any duplicate entries >> within the Guacamole database. >> >> > I have a few questions and things you could share that might help track > down the issue: > * Are you using the feature where you can open multiple connections in the > same window/tab, and do you have multiple connections open? Or does this > happen when you open a single connection? > * Could you share a (sanitized) version of the connection configuration? > * Can you enable debug logging in guacd and share the output when you > connect? > * Can you confirm 1) what version of Guacamole you're using, and 2) that > you're using the official/stock version of it - that you haven't modified > the code at all? > > -Nick > - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
