Running from private studio will not accept AD userid or password

Question

I am a server admin and a gallery curator and have all the permissions set to yes.

We authenticate using active directory.

I saved a workflow to my private studio with option to require credentials when it runs.

I try to run it and my userid or password is not accepted

I am certain I typed my password correctly

I get the same response from trying to store gallery credentials with my AD userid and passwort

I also tried including my domain before userid and get same response

I recently noticed, the gallery id's in windowsidentities table are wrong and don't match the correct ones in the users table. i read later that windowsidentities was obsolete but thought it may be worth mentioning.

hroderick-thr · Answer

Thanks for the tip. You may well be right, but I'm not giving up yet.  I've found information about setting changing server policy settings for a run-as user that your answer seems to suggest. It isn't exactly clear if this is necessary before an app can be run with user entered credentials. The admin credentials and permissions may also be required. Either one or both would be an extreme administrative load where we have many users and require frequent password changes. I have a service ticket open and found some others suggesting a similar 2019.3 bug. I will post answer when the dust settles on all that.

tothd · Answer

Hello,

I think this is a different form of the same problem.  If the private gallery is on the server and you are using AD.

https://serverfault.com/questions/782680/logon-failure-the-user-has-not-been-granted-the-requested-logon-type-at-this-co

The initial error code was 'Logon failure: the user has not been granted the requested logon type at th"

It means what it says and says what it means. Standard users can not normally and should not normally log on to the desktop of an Active Directory Domain Controller.

You will need to create a group policy that allows users to 'log on locally' (IIRC, disables "Deny log on locally) for DCs and apply it to the user.

The better approach is to not use a DC as your desktop. If you need a DC for development, run it as a virtual guest on a standard workstation in hyperv and use the standard workstation (or another hyperv guest if you need a workstation to be a domain member) for your dev users."

is computer', but alternate attempts to by pass the initial fail resulted in 'invalid username and password' type of errors.

Hope this at least gives some insight.

Cheers,

rdt