I get a weird error when i try to log into the deployment server with a different user

Hi Stuart Masters ,

It is a known issue that is caused by the users in nested domain groups. The JWT token returned by PCS SMS may not contain the role claims required the deployment server even login is successful.

You could add required user group names to the UserGroupFilters section of C:\Program Files (x86)\AVEVA\Platform Common Services\Management Server\appsettings.json

For example,

Please refer to the workarounds suggested in https://softwaresupportsp.aveva.com/#/knowledgebase/details/000038376?lang=en_US.

Regards,

Jacky

Take a look at the tracelog.SE.Asb.Deployment.Server.WindowsService.dat file catches the failed authorization on to the Deployment Server, where you could see "AuthorizationProvider.CheckAccess failed for Identify ---".

Thanks Jacky, I don't see that text in the tracelog, but I went and added the required domain user groups in the json file to no effect.  No guarantees that I didn't do something wrong I guess!

Also, I would not have thought that my windows groupings were that complex in my test environment, but in the wild they will be so good to know.

I don't seem to be able to see that  kb so maybe I am not privileged enough for it.

These are the errors I am getting in tracelog.se.asb.deployment.server.windowsservice.dat

I feel so small now

Your trace log reported a different exception in https request. Do you see "Login Successful" messages in aaLogger on the SMS machine when you use a domain user of the domain user group added to the user group SCADA.DeploymentAdmins on the deployment server?  It is worth trying to add an individual domain user directly to this deployment group and see if it works. If it works, I cannot see why a simple domain group won't work. It could be something else causing this problem.

So, it turns out that I had a fundamental misunderstanding of where the groups needed to be configured.  I wasn't paying much attention to our actual deployment server, but that's where my original user was configured of course, and where this config needs to go.  Begs the question why these roles exist on the deployment client though?