Poor performance when login on Windows client

Hey all,

does anyone else also has a poor performance when login on a Windows client?

After entering the Windows username, the AA Windows client loads the user's available chains. This process takes between 4 and 12 seconds. After this delay, users can select the chain and proceed. However, each step within the chain also has a delay, so it can be said that the login is significantly longer than without aa service (10-30 sec). This is not really acceptable and does not improve the acceptance of the tool...


In Webserver Logs i can see the delay too:

2024-02-23 15:32:53 (UTC+0100) INFO [uwsgi-end-req] GET /api/v1/custom_messages?category=messages&encrypt_secrets=true&endpoint_session_id=**ID** **NLB-IP** 81ms
2024-02-23 15:32:53 (UTC+0100) INFO [uwsgi-end-req] GET /api/v1/repositories?encrypt_secrets=true&endpoint_session_id=**ID** **NLB-IP** 14ms
2024-02-23 15:32:53 (UTC+0100) INFO [uwsgi-end-req] GET /api/v1/endpoints/**ID**/effective_policy?endpoint_session_id=**ID** **NLB-IP** 112ms
2024-02-23 15:32:56 (UTC+0100) INFO [uwsgi-end-req] GET /smartphone **NLB-IP** 1ms
2024-02-23 15:32:57 (UTC+0100) INFO [aucore.au.ldap.ldap_repo] Cached group was found
2024-02-23 15:32:58 (UTC+0100) INFO [aucore.au.ldap.ldap_repo] Cached group was found
2024-02-23 15:32:59 (UTC+0100) INFO [aucore.au.ldap.ldap_repo] Cached group was found
2024-02-23 15:33:01 (UTC+0100) INFO [aucore.au.ldap.ldap_repo] Cached group was found
2024-02-23 15:33:01 (UTC+0100) INFO [aucore.au.ldap.ldap_repo] Cached group was found
2024-02-23 15:33:01 (UTC+0100) INFO [aucore.au.ldap.ldap_repo] Cached group was found
2024-02-23 15:32:53 (UTC+0100) INFO [uwsgi-end-req] GET
2024-02-23 15:32:53 (UTC+0100) INFO [uwsgi-end-req] GET /api/v1/logon/chains?encrypt_secrets=true&endpoint_session_id=**ID**&event=Windows%20logon&include_all_chains=true&user_name=**DomainAndUser** **NLB-IP** 7542ms

Does anyone else have this problem?

Kind regards.

Jens

Parents
  • 0  

    Hello Jens,

    We have an open ticket for you about this with Development. I just reached out to Development again to see if they can provide any feedback.

    It would be interesting to see if any other customer here can share if they have the same issue.

    I'll keep you informed.

    Thanks.

    Regards,

    Luciano Testa

  • 0 in reply to   

    Hey Luciano Testa,

    Yes, I know. Our ticket has been open since September 18, 2023, and a second ticket since Friday (February 23, 2024). But I'd like to check if anyone from the community is experiencing the same issues and might have a solution. We're severely restricted in our usage.

    Regards,
    Jens

  • 0   in reply to 

    Hello Jens,

    I have increased the urgency of the existing ticket and sent a comment to Development.

    Thanks.

    Regards,

    Luciano Testa

  • 0 in reply to   

    There have been no updates, only information indicating that the ticket is in development. We've been waiting for months without any results. Logon processes are taking excessively long, as evident from the logs....

    Additionally, there appears to be an issue with Nginx. However, we're unable to modify any settings within the Nginx container. We're hesitant to open a new ticket because there has been no progress made on the existing one....:

    2024-03-19 15:35:55 (UTC+0100) [warn] 32#32: *60742 an upstream response is buffered to a temporary file /usr/local/nginx/uwsgi_temp/7/47/0000000477 while reading upstream



  • 0   in reply to 

    Hello Jens, 

    There is no point in opening a new ticket. I have replied about the existing one this morning through the ticket itself. 

    I have contacted Development as well and escalated the issue. That's all I can do from my side.

    I will also inform my manager.

    Thanks.

    Regards,

    Luciano Testa

Reply Children