Bug 1631005 - When User Group sync is enabled, customer wait long time to authenticate / login
Summary: When User Group sync is enabled, customer wait long time to authenticate / login
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Authentication
Version: 6.3.2
Hardware: All
OS: All
high
high
Target Milestone: 6.6.0
Assignee: Ondřej Ezr
QA Contact: Nikhil Kathole
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-19 17:03 UTC by Waldirio M Pinheiro
Modified: 2019-10-22 19:50 UTC (History)
7 users (show)

Fixed In Version: foreman-1.22.0-0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-22 19:50:21 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 25795 Normal Closed LDAP - When User Group sync is enabled, user wait long time to authenticate / login 2020-06-11 17:20:04 UTC

Description Waldirio M Pinheiro 2018-09-19 17:03:05 UTC
Description of problem:
Currently, there is a feature called User Group sync, so when enabled, Satellite will bind the external Auth Source and will try to match the user on User Group already defined on the Sat side. If match, the system will assign automatically the role related and on the fly / first login, the login page will be according to the roles.

This feature works fine when the account is member of few groups, but when we are talking about a huge number of groups *this happens all the time* the login process can spend a long time to conclude.

Version-Release number of selected component (if applicable):
6.3.x

How reproducible:
100%

Steps to Reproduce:
1. Configure the LDAP Auth
2. Create the user on AD
3. Create a bunch of groups on AD *like 100*
4. Add the user on all groups
5. Login on the Satellite via webUI with the User Group Sync enabled

Actual results:
Spend a long time to conclude the process/check and login.

Expected results:
Be faster then today.

Additional info:

Comment 9 Bryan Kearney 2019-04-08 14:01:49 UTC
Upstream bug assigned to oezr@redhat.com

Comment 10 Bryan Kearney 2019-04-08 14:01:50 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25795 has been resolved.

Comment 13 Sanket Jagtap 2019-08-09 15:06:06 UTC
Build: Satellite 6.6 snap15

AD usern and Time from raw ldapsearch for use in 900 groups

 root  /tmp/bug  time ldapsearch -LLL -x -D 'administrator@' -w 'Secret7' -b 'dc=satqe' -h 10-.-.-.- '(samaccountname=testuser)'
dn: CN=Test User.,OU=TEST
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Test User.
givenName: Test
initials: User
distinguishedName: CN=Test User.,
instanceType: 4
whenCreated: 20190809141016.0Z
whenChanged: 20190809141404.0Z
displayName: Test User.
uSNCreated: 193503
memberOf: CN=GRP900,OU=TEST,
<snip>
logonCount: 0
sAMAccountName: testuser
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,
dSCorePropagationData: 20190809141017.0Z
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 132098348838095771

real	0m0.044s
user	0m0.003s
sys	0m0.012s


New login from AD user to Satellite:

 time hammer -u admin -p changeme user list
---|-------|------------|------------------------------------|-------|---------------------|--------------
ID | LOGIN | NAME       | EMAIL                              | ADMIN | LAST LOGIN          | AUTHORIZED BY
---|-------|------------|------------------------------------|-------|---------------------|--------------
4  | admin | Admin User | root | yes   | 2019/08/09 14:54:26 | Internal     
---|-------|------------|------------------------------------|-------|---------------------|--------------

real	0m1.716s
user	0m1.405s
sys	0m0.221s
[root@qe-sat6-feature-rhel7 ~]# time hammer -u testuser -p apple@123 user list
Access denied
Missing one of the required permissions: view_users

real	0m6.054s
user	0m1.447s
sys	0m0.218s

Repeated this couple of times, the time taken is around 6 seconds


I think this is considerable improvement from 23 secs

Comment 14 Waldirio M Pinheiro 2019-08-12 13:26:51 UTC
Hello

For sure it's :)

Thank you.

Best Regards
-- 
Waldirio M Pinheiro | Senior Software Maintenance Engineer

Comment 15 Bryan Kearney 2019-10-22 19:50:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3172


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