www.cendio.com
Bug 6209 - Cannot login when user has multiple usernames (e.g. domain specifier or case insensitive)
: Cannot login when user has multiple usernames (e.g. domain specifier or case ...
Status: CLOSED FIXED
: ThinLinc
Web Access
: trunk
: PC Unknown
: P2 Normal
: 4.10.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2017-03-29 09:29 by
Modified: 2018-06-25 12:59 (History)
Acceptance Criteria:
* Should be able to log in using any username alias (e.g. sssd user@domain, case insensitive usernames)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2017-03-29 09:29:06
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.
------- Comment #1 From cendio 2017-03-29 12:00:25 -------
Seems like tlwebaccess uses the provided username from the html form instead of
a looked up named which in this authentication setup can differ.
------- Comment #2 From cendio 2018-04-11 17:46:22 -------
> 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'.
------- Comment #3 From cendio 2018-04-12 10:07:42 -------
(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'.
------- Comment #6 From cendio 2018-06-25 12:59:19 -------
Works fine. Tested:

astrand
Astrand
astrand@default