Last post May 27, 2020 11:48 AM by corriedotdev
May 27, 2020 11:00 AM|corriedotdev|LINK
The issue has been ongoing for a while now. Background of the application is its a self service ADLDS site, that it works as expected when ran through the IDE and I have managed to solve the issue on my development machine. We can use my development machine
and access the site from a domain name, and authenticate when the user has been added to a group. I can no longer recreate the client side changes made to solve the issue on other machines. If not i have recreated them but because the development machine is
hosting the site there is an underlying permission that i didn't set but am unaware of.
This post was great and client side tasks i have completed are listed there.
However as noted I have implemented a solution on my development machine hosting the site at a domain and on an IIS server and am struggling to identify what this change was otherwise its likely only working on my development machine as it is also hosting
An operations error occurred.
I am starting to think its something to do with permission/ trust issues as it only works on the machine the site is hosted on, however the domain we are using is using a DNS on another machine so find it hard to believe this as it would still have to go
through the DNS.
Ideas are appreciated, its starting to eat into a lot of my time.
May 27, 2020 11:25 AM|PatriceSc|LINK
"impersonating to make changes" and "The site is running under the context of a service account with relevant permissions" seems contradictory. With "Trusted for delegation" being mentioned do you mean that you are impersonating authenticated
users to make this change ?
Reading is fine? I would try step by step. For example I would use the https://docs.microsoft.com/en-us/dotnet/api/system.directoryservices.accountmanagement.principalcontext?view=dotnet-plat-ext-3.1#constructors that
allows to provide explicitely an account/password to see if it works (even maybe from a console app).
Edit: "it only works on the machine the site is hosted on" looks like a delegation issue. Maybe a simpler scheme could be enough such as using a dedicated account and having the application testing first the user is allowed to do this?
May 27, 2020 11:48 AM|corriedotdev|LINK
Apologises for confusion, we are authenticating the windows account and then
impersonating the authenticated users to make the edit changes in ADLDS. They have write permissions on the attributes in ADLDS.
Valid point, yes reading is working as expected across all instances of this site I have running.
Will review the link you posted thank you.
I think it is likely a delegation issue as well, its failing on the Cache() line of code.