OMI Web Client - inconsistency with different users / servers

What messages are we seeing in the logger for the machine that is running the OMI app? 

Was the user removed from all the other groups, and only now in the one? 

Any time allowed for the change to the user/groups to propagate before testing? 

What version of System Platform is this?

Hi David,

Thanks for responding. 

On the GR(SMS server) we get this message when the client logs in:

There is no entry in the log on machine that is running the OMI client.

The user is still in all his corporate groups.

I have applied the filter, but it doesn't make a difference. I assume this must be done on the SMS server.

xxxxxxx

In some cases, logging in to the OMI Web Client fails if the user belongs to many groups in Active Directory (AD). This situation may lead to "token bloat," which occurs when the user access token has a large number of group memberships, thus causing the token to exceed the maximum size limit.

The OMI web client attaches the access token from Identity Manager for every web request after each successful user login. The access token includes all the roles, or Windows AD groups, to which the user belongs.

Workaround:

To reduce the network traffic and avoid login issues if the user has a large number of groups, filter the groups to which the user belongs and only include groups that are required by AVEVA software in the token. To filter the group, modify the appsettings.json file for the Identity Manager to include UserGroupFilters. The appsettings.json path is:
C:\Program Files (x86)\AVEVA\Platform Common Services\Management Server\appsettings.json

• Add required user group names to the UserGroupFilters section of the appsettings.json file. The UserGroupFilters option supports the use of the wildcard "*" at the end for the group name. In the example, RequiredUserGroup* allows RequiredUserGroupA, RequiredUserGroupB, etc.:

"AppSetting": {

"UserGroupFilters": [

"RequiredUserGroup*"

],

• If you are using Entra ID (formerly called Azure Active Directory) and have a large number of user groups, you can use AzureAdGroupQueryOptions in addition to UserGroupFilters to improve performance. Like the UserGroupFilters option, the "*" wildcard can be used to match partial group names as shown in the following example.

{

"AzureAdGroupQueryOptions": {

"Filters": [

"GroupNamePrefix*",

"GroupName"

]

}

}

xxxxxx

The group was created om Monday and the logs were done this morning. I think the Domain should have propagated by now.

ASP 2023 R2 SP1 P01

We have tested with my credentials on the client's machine and it works just to check that his pc can actually get to the OMI website.

There are a few cases like this.  Check the time on the nodes.  Everything the same/correct there?  Did you add aaAdministrators or the needed group in the filter?  There is also a registry setting i see from some cases.  Not sure which machine this goes on...

created two new DWORD type register entry.

MaxFieldLength 0x00008000

MaxRequestBytes 0x00008000

Under Directory Below

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

Maximum values:

MaxFieldLength with a decimal (NOT Hexadecimal) value of 65534. MaxFieldLength sets the maximum size of the header, which contains the token. This sets the value to 64KB. 

MaxRequestBytes with a decimal (NOT Hexadecimal) value of 1048576. This sets the maximum request size to 1 MB.

If it is neither of these, likely time to create a support ticket with your local support provider.

Glad I'm not the first.

aaAdministrators' must come preinstall. I just added the entry under  UserGroupFilters:

Must all the potential users of web be in aaAdministrators?

I'll escalate the ticket to Aveva. 

Thanks.

Glad I'm not the first.

aaAdministrators' must come preinstall. I just added the entry under  UserGroupFilters:

Must all the potential users of web be in aaAdministrators?

I'll escalate the ticket to Aveva. 

Thanks.