Hello,

My advice is to open a ticket with Technical Support so they can help you investigate this.

I do not think performance losses have been introduced, could be related to network, hardware or settings, but has to be investigated.

Just to check, is the option of Enable Nested Groups on? It's by default. 

Thanks.

Regards,

Luciano Testa

Nested groups is disabled - I guess this is preferable in terms of performance?

Yes, it is. But if it is already disabled then please contact TS.

Thanks.

Regards,

Luciano Testa

Hi mguldner,

we have the same problem, that the client is quite slow and therefore had a support ticket open. This was then open for 6 months and was closed with the comment that development is taking care of it and it may be solved in a future version.

Regards,
Oliver

Hey. We're [ Oliver Kannenberg and me ] facing the same issue.

We already have a post open about it and nothing has happened since then:

 Poor performance when login on Windows client 

We've removed the nested groups, done everything as Support requested. Doesn't seem like I'll be changing anything in the near future. Could you please check if you have the same logs in your web server logs on the aa servers as those I posted in the linked post above?

Best reguards,
Jens

I have opened a Support Case today and got the recommendation to use Repo Agent (https://www.netiq.com/documentation/advanced-authentication-64/repo-agent-installation-guide/data/bookinfo.html). I fear that this means all users would have to register their authenticators again...

Do you use Repo Agent?

I have also disabled nested groups - no difference.

I guess our logs should be quite different because we don't use client authentication but web authentication. I see the delay like this:

Preamble: [OIDP TOP]
Txn: Q1C0RoxSYdzBV-4b6XA
Priority Level: FINER
Java: internal.osp.oidp.aa.rest.NaafRestRequest.issueRequestWithRetry() [536] thread=http-nio-0.0.0.0-1009-exec-1
Elapsed time: 20.20 seconds
Time: 2024-06-11T10:33:46.098+0000
Log Data: Issue GET to http://127.0.0.1:6001/api/v1/users?user_name=CIT%5Cmguldner&attributes[..]

Up to 20 Seconds while AA searches the repo for the username - and sometimes it gives up, probably 20+ seconds is a timeout:

Preamble: [OIDP TOP]
Txn: Q1C0RoCxpSsdYdzBV-4b6XA
Priority Level: FINE
Java: internal.osp.oidp.aa.NaafSource.searchImpl() [1479] thread=http-nio-0.0.0.0-1009-exec-18
Time: 2024-06-11T10:58:22.399+0000
Log Data: Error contacting Advanced Authentication server while searching: internal.atlaslite.jcce.exception.CoreCommunicationException: Error communicating with AA server during user lookup.
         =>java.net.SocketTimeoutException: Read timed out
      internal.osp.oidp.aa.NaafSource: NaafSource.java: findUserEx: 2,592
      internal.osp.oidp.aa.NaafSource: NaafSource.java: searchImpl: 1,451
      internal.osp.oidp.service.source.data.DataSourceHasSearchImpl: DataSourceHasSearchImpl.java: search: 133

We dont use a Repo Agent. This answer was never provided by support in response to our tickets....

But what the hell??
They know that the AAF server has a delay and they want to fix it with "middleware" software? That should really be a function of the AAF server that is installed directly. What else does the AAF REPO Sync do.... Sorry but i fear about this solution ..

However, I think we will take a deeper look at it tomorrow..

Did you see that performance issue from the beginning, or starting with a certain version? I am not sure about this in our case. We tested AA for about one year with 20 users and did not see any issues. Then December 2023 we started productive with several 1000 users - and coincidentally this was exactly when 6.4.2 came. I think the problem might be introduced with 6.4.2 - but I am not sure.

Another thought: I think the problem has to do with the number of groups the user is a member of - even if AA does not use or pass on these groups. For users with only a few groups there is also a delay, but only a few seconds, not between 10 and 20 seconds.

Hey all. I am not support by any means but I am aware of a few performance fixes in 6.4.3 like the removal of the "otherMailbox" attribute.  There were some other issues with non-indexed attributes.  https://www.netiq.com/documentation/advanced-authentication-64/advanced-authentication-releasenotes-643/data/advanced-authentication-releasenotes-643.html#t4h90ut5kxto

We run extensive performance and scale tests with Advanced Authentication. As performance can be environmentally specific, I am interested what support finds as you work with them on the tickets.