-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comments
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. |
As a work around im currently blocking any logins with DOMAIN\USERNAME using this pam code.
Only downside is that some rdp client are sending the domain by default. At least mstsc on windows server 2012. |
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
samid -- SAMAccountName in active directory 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. |
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)
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)
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)
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)
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
The text was updated successfully, but these errors were encountered: