Bug 6209 - Cannot login when user has multiple usernames (e.g. domain specifier or case insensitive)
Summary: Cannot login when user has multiple usernames (e.g. domain specifier or case ...
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.10.0
Assignee: Pierre Ossman
URL:
Keywords: relnotes
Depends on:
Blocks:
 
Reported: 2017-03-29 09:29 CEST by Henrik Andersson
Modified: 2018-06-25 12:59 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
* Should be able to log in using any username alias (e.g. sssd user@domain, case insensitive usernames)


Attachments

Description Henrik Andersson cendio 2017-03-29 09:29:06 CEST
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 Henrik Andersson cendio 2017-03-29 12:00:25 CEST
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 Samuel Mannehed cendio 2018-04-11 17:46:22 CEST
> 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 Henrik Andersson cendio 2018-04-12 10:07:42 CEST
(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 Peter Åstrand cendio 2018-06-25 12:59:19 CEST
Works fine. Tested:

astrand
Astrand
astrand@default

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