When setting up a ThinLinc server with sss authentication against an AD domain using realmd, one cannot login using the HTML5 client as expected. The problem beeing that a user is identified with a principle name user@domain: [root@tl01 sessions]# id cendio uid=1253001106(cendio@lab.lkpg.cendio.se) gid=1253000513(domain users@lab.lkpg.cendio.se) groups=1253000513(domain users@lab.lkpg.cendio.se) creating session directories like: /var/opt/thinlinc/sessions [root@tl01 sessions]# ls -al total 0 drwxr-xr-x. 3 root root 39 Mar 28 16:41 . drwxr-xr-x. 5 root root 53 Mar 28 14:58 .. drwxr-xr-x. 4 root root 53 Mar 29 01:43 cendio@lab.lkpg.cendio.se [root@tl01 sessions]# Now, lab.lkpg.cendio.se is set as default domain, so if username cendio is given it means that cendio@default-domain will be resolved. So when log in with HTML5 client using short form username cendio, auth goes thru but connect to agent fails with: 2017-03-29 09:24:36 ERROR tlwebaccess[13960]: [::ffff:10.47.4.21] Could not read session key for user 'cendio': [Errno 2] No such file or directory: u'/var/opt/thinlinc/sessions/cendio/1/sessionkey' Fails as you can see that there is no such session directory, if you use full form cendio@lab.lkpg.cendio.se, everything works as expected.
Seems like tlwebaccess uses the provided username from the html form instead of a looked up named which in this authentication setup can differ.
> Fails as you can see that there is no such session directory, if you use full form cendio@lab.lkpg.cendio.se, everything works as expected. Not always, I encountered a case with our ubuntu1604 machine in the lab where `$ id samuel@lab.lkpg.cendio.se` returned 'samuel'. Thus using 'samuel' was the only thing that worked in Web Access. Not 'samuel@lab.lkpg.cendio.se'.
(In reply to comment #2) > > Fails as you can see that there is no such session directory, if you use full form cendio@lab.lkpg.cendio.se, everything works as expected. > > Not always, I encountered a case with our ubuntu1604 machine in the lab where > `$ id samuel@lab.lkpg.cendio.se` returned 'samuel'. Thus using 'samuel' was the > only thing that worked in Web Access. Not 'samuel@lab.lkpg.cendio.se'. The problem is that you must use the "normalized" username when authentication is done using Web Access. If a nss backend supports aliases for the same user there is only one correct result eg. the "normalized" username. Different configurations of the NSS backend would give you different results, such as 'user@domain' or just 'user'.
Works fine. Tested: astrand Astrand astrand@default