Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Session for winbind users is not always reconnect #1823

Closed
swer21 opened this issue Mar 4, 2021 · 3 comments · Fixed by #2472 or #2731
Closed

Session for winbind users is not always reconnect #1823

swer21 opened this issue Mar 4, 2021 · 3 comments · Fixed by #2472 or #2731

Comments

@swer21
Copy link

swer21 commented Mar 4, 2021

When a winbind user has started a xrdp session using DOMAIN\username. Then he disconnect the session and later try’s to reconnect. But he uses only the username, the session is then not reconnected but a new session is created.

OS: Ubuntu 20.04.2 LTS
Version: 0.9.12

@matt335672
Copy link
Member

hi @swer21

Thanks for raising this.

I think I can see what's happening here - at the moment we look for a matching session by checking the username string, which is normally unique. In the winbind case (and possibly with sssd), the same user can have different forms. hence the new sessions.

One way to work around this might be for the code to match on UID rather than username when looking for an existing session.

@swer21
Copy link
Author

swer21 commented Mar 12, 2021

As a work around im currently blocking any logins with DOMAIN\USERNAME using this pam code.

auth [success=1 default=ignore] pam_succeed_if.so user !~ DOMAIN*
auth requisite pam_deny.so

Only downside is that some rdp client are sending the domain by default. At least mstsc on windows server 2012.

@evanlinde
Copy link

One way to work around this might be for the code to match on UID rather than username when looking for an existing session.

This would be very good. On my domain, there are at least 6 or 7 "valid" username forms that will be accepted by both winbind and sssd (tested via getent passwd _______):

samid -- SAMAccountName in active directory
upn -- userPrincipalName in active directory
mail -- email address

In my case, the upn is in the form of [email protected] where the name part could be the same as samid, but mostly isn't. I'm not absolutely certain that mail gets used in an AD environment (mail and upn are always the same in ours) but it does get used in a non-AD LDAP with sssd.

matt335672 added a commit to matt335672/xrdp that referenced this issue Dec 14, 2022
Update sesman to cope with separate authentication/authorization (AA) and
command processing.

Also, internally users are now tracked by UID rather thn username.
This addresses a problem found by some users using federated naming
services (e.g. Active Directory) where the same user can be referred to
in more than one way. See neutrinolabs#1823

The separation of AA in this way allows for multiple attempts to be made
on one connection to get a password right. This addresses MaxLoginRetry
not working (neutrinolabs#1739)
matt335672 added a commit to matt335672/xrdp that referenced this issue Dec 14, 2022
Update sesman to cope with separate authentication/authorization (AA) and
command processing.

Also, internally users are now tracked by UID rather thn username.
This addresses a problem found by some users using federated naming
services (e.g. Active Directory) where the same user can be referred to
in more than one way. See neutrinolabs#1823

The separation of AA in this way allows for multiple attempts to be made
on one connection to get a password right. This addresses MaxLoginRetry
not working (neutrinolabs#1739)
matt335672 added a commit to matt335672/xrdp that referenced this issue Dec 15, 2022
Update sesman to cope with separate authentication/authorization (AA) and
command processing.

Also, internally users are now tracked by UID rather thn username.
This addresses a problem found by some users using federated naming
services (e.g. Active Directory) where the same user can be referred to
in more than one way. See neutrinolabs#1823

The separation of AA in this way allows for multiple attempts to be made
on one connection to get a password right. This addresses MaxLoginRetry
not working (neutrinolabs#1739)
matt335672 added a commit to matt335672/xrdp that referenced this issue Dec 22, 2022
Update sesman to cope with separate authentication/authorization (AA) and
command processing.

Also, internally users are now tracked by UID rather thn username.
This addresses a problem found by some users using federated naming
services (e.g. Active Directory) where the same user can be referred to
in more than one way. See neutrinolabs#1823

The separation of AA in this way allows for multiple attempts to be made
on one connection to get a password right. This addresses MaxLoginRetry
not working (neutrinolabs#1739)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants