We Keep Coding

PrincipalContext has exception when using Impersonation in ASP.NET Web API

I am building an ASP.NET Web API to retrieve Active Directory information using .NET Framework 4.8. The IIS is set to Windows authentication only.
The code works ok on my local machine, but does not work when accessing the API on a client computer.
The issue is from this code:
WindowsIdentity.RunImpersonated(((WindowsIdentity)User.Identity).AccessToken, () => {
var principleContext = new PrincipalContext(ContextType.Domain, null, ConfigHelper.AdRoot);
});
After getting the principalContext, principalContext.ConnectedServer throws an exception
000004DC: LdapErr: DSID-0C090A71, comment: In order to perform this operation a successful bind must be completed on the connection.
If I remove the RunImpersonated part, the code works fine. When I visit the Web API from the server, the impersonation also works.
Please help, thank you!
I guess it might be a double hop issue, but I cannot confirm.

Azure - System Assigned Managed Identities for Function App

I have a function app and need to give it permission to write to blob/table storage. I turned on "System Assigned Managed Identity", and I set the following permissions for it with the scope being the Storage Account I need to access.
Storage Account Contributor
Storage Blob Data Owner
Storage Table Data Contributor
Storage Queue Data Contributor
UPDATE
I remove AZURE_CLIENT_ID, AZURE_CLIENT_SECRET and AZURE_TENANT_ID and then I receive an environment configuration error. I am not running this locally or debugging, I'm triggering it through API Management.
Executed 'Create' (Failed, Duration=1406ms)EnvironmentCredential authentication unavailable. Environment variables are not fully configured. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/environmentcredential/troubleshoot
^ The above link tells me I should add those environment variables back, but it seems like I shouldn't need them according to Peter Bon's answer below
One piece that I find very confusing (because I can't find good documentation on this anywhere) is that I am required by Azure to include three variables
AZURE_CLIENT_ID
AZURE_CLIENT_SECRET
AZURE_TENANT_ID
I am inferring that they are needed to actually allow my function app to access the storage account, which confused me at first because if I just gave it permission explicitly with assigned roles, why do I also need to create something completely outside of my function app to give it permission to do the thing I already gave it permission to do?
My question about this though is "HOW DO I MAKE THIS?" If I need to make an App Registration, what should the callback URL be? What should the API Permissions be? I gave it my best guess and did not get a satisfactory result.
App Registration:
API permissions -> Microsoft.Graph User.Read
Authentication -> https://<mydomain>.onmicrosoft.com/.auth/login/aad/callback
-> ID Tokens
-> Accounts in this organization
Secrets -> Generated new secret to use for AZURE_CLIENT_SECRET
Roles & Admissions -> Cloud application administrator
I then set AZURE_CLIENT_ID to be the app id of this App Registration, AZURE_CLIENT_SECRET to the app registration's secret and AZURE_TENANT_ID to my tenant ID.
Then in my code, I attempt to do the following
var tableUri = new Uri(string.Format("https://{0}.table.core.windows.net/", storageAccountName));
var credential = new DefaultAzureCredential(options);
services.AddScoped(x => new TableServiceClient(tableUri, credential));
And it fails when accessing my table storage with the following error:
Executed 'Create' (Failed, Id=<id>, Duration=2108ms)Server failed to authenticate the request. Please refer to the information in the www-authenticate header.RequestId:<id>Time:2022-10-21T12:15:21.6998519ZStatus: 401 (Server failed to authenticate the request. Please refer to the information in the www-authenticate header.)ErrorCode: InvalidAuthenticationInfoContent:{"odata.error":{"code":"InvalidAuthenticationInfo","message":{"lang":"en-US","value":"Server failed to authenticate the request. Please refer to the information in the www-authenticate header.\nRequestId:<id>\nTime:2022-10-21T12:15:21.6998519Z"}}}Headers:Server: Microsoft-HTTPAPI/2.0x-ms-request-id: <id>x-ms-error-code: REDACTEDWWW-Authenticate: Bearer authorization_uri=https://login.microsoftonline.com/<tenant_id>/oauth2/authorize resource_id=https://storage.azure.comDate: Fri, 21 Oct 2022 12:15:21 GMTContent-Length: 279Content-Type: application/json
and if I update the Authentication redirect to
https://storage.azure.com
then I get the following error:
Executed 'Create' (Failed, Id=<id>, Duration=2349ms)This request is not authorized to perform this operation using this permission.RequestId:<request>Time:2022-10-21T13:14:29.0955823ZStatus: 403 (Forbidden)ErrorCode: AuthorizationPermissionMismatchContent:{"odata.error":{"code":"AuthorizationPermissionMismatch","message":{"lang":"en-US","value":"This request is not authorized to perform this operation using this permission.\nRequestId:<id>\nTime:2022-10-21T13:14:29.0955823Z"}}}Headers:Cache-Control: no-cacheTransfer-Encoding: chunkedServer: Windows-Azure-Table/1.0,Microsoft-HTTPAPI/2.0x-ms-request-id: <id>x-ms-client-request-id: <id>x-ms-version: REDACTEDX-Content-Type-Options: REDACTEDDate: Fri, 21 Oct 2022 13:14:28 GMTContent-Type: application/json; odata=minimalmetadata; streaming=true; charset=utf-8
I am honestly pretty confused at this point, can someone please help me understand how to successfully set up system assigned managed identities?
UPDATE WITH ANSWER
figured it out w/ suggestion from Peter.. so, I'm not a C# developer, but have a programming background & am doing devops for this project, another group is coding the application. I didn't realize that they had specifically used new EnvironmentCredential(); in their code, since they emphasized always needing to use DefaultAzureCredential but the EnvironmentCredential forces the setting of AZURE_CLIENT_ID. This also explains our issue w/ using DefaultAzureCredential because it goes through the list like you linked in the answer, so it sees AZURE_CLIENT_ID is set, and doesn't bother going for MI even though MI has the right permissions.

When using a managed identity you should not provide these env variables. It would also defeat the purpose of not having to store a secret. They are not required in that scenario. It is just one of the many ways DefaultAzureCredential tries to get valid credentials. See this section. If you do not provide them, it will fall back trying to use a managed identity.

DocuSign C# API - USER_LACKS_MEMBERSHIP error for every token-authenticated request

We had a working application, we went through the go-live process, and everything was running live for several days. Then we started getting SSL errors, and we saw that the nuget package for the DocuSign package had an update (I believe this was all for the 11/13/2019 2019 certificates auto-update), so we updated our code, but now every request returns the USER_LACKS_MEMBERSHIP error for every token-authenticated request.
Things I can confirm are not the issue:
We have authenticated the app via account.docusign.com and the oauth signature impersonation scope, and the testing and live paths are in the API approved Redirect URIs.
We have the correct base path in the configuration (https://na3.docusign.net, as shown on our Apps and Keys page)
The base path did not change after we get the token back (The BaseUri on the Account object matches what we started with)
We are using the correct user for the configuration (The value labeled "API Username" in the Apps and Keys page is entered as "IMPERSONATED_USER_GUID" in appsettings.json and successfully used in creating the token as parameter UserID, which also matches our user account's ID shown in the backend, so we are not confusing it with TARGET_ACCOUNT_ID or CLIENT_ID, and shuffling those around causes errors much earlier at the token generation step).
We only have one user: the administrator of the DocuSign account. Their ID appears in the API configuration labeled as "API Username". The DocuSign administration backend doesn't display a membership tab anywhere for us to correct any possible issues with a user lacking membership. As far as I can tell, Membership is a higher tier account option than what we're paying for, so I'm confused how we could be having problems with a feature we haven't bought.
We get this error for checking envelope status. We get this error for trying to create new envelopes. We get this error for trying to get Account information. The only thing we can do is get an authentication token, but then that token can't be used to make any further authenticated requests.
Is there anything I'm missing that could be causing this other than some database error on DocuSign that I can't correct through the tools available to me? The package update changed the order of which class constructor accepts the ApiClient object, and there's a new AccessToken field on the Configuration class (which I filled out, but doesn't seem to have any effect, since we're still adding the Authorization/Bearer header manually). I'm out of ideas on what to try next.

Are you using the production environment or the demo environment?
I suspect that what's happening is that you are getting them mixed. As the baseUrl should not be demo.docusign.net etc. if you're using production (as indicated by your na3.docusign.net address) but you must ensure that the same account/user from production is also used.
So, the 4 things to check:
userId
accountId.
baseURI
authURI (account-d.docusign.com vs. account.docusign.com)
All of these should match and be for the same account in the same env.

Receiving 403 error when accessing Azure function app locked down by Azure AD B2C

We are using AD B2C for authentication on our web app. Last week we started receiving a 403.76 when calling our APIs that are hosted in Azure and locked down by Active Directory using our AD B2C tenant.
We haven't changed any config settings in AD when the change occurred. We rolled back all of our code which didn't help. We verified that our token is valid in jwt.io. We confirmed that our audience is correct and permissions was set properly in app registrations. We can see the easy auth error 403.76 when going in to "Diagnose and solve problems" section of the function app and drilling into 4xx errors.
The function app just does a GetAsync against Cosmos to get your user profile on sign in. However we aren't getting that far, as we are receiving a 403.76 when verifying our token with AD.
We should be able to do a GET against our API and receive data as we were before. Instead we get HTTP status 403 with a sub status of 76.
The error in "Diagnose and solve problems" section:
EasyAuth:AuthorizationCheckFailed. For more details, refer to HTTP Status Codes by EasyAuth Module

We banged our heads against a wall for five days, so I wanted to make sure this was posted on stack overflow for anyone else facing this issue. Especially since it affected customers.
After working with Microsoft 24/7 for the last three days, we finally received word that this was due to an issue on their end with EasyAuth. The workaround was to add this in our Configuration of the function app:
WEBSITE_AUTH_AAD_BYPASS_SINGLE_TENANCY_CHECK = true

Issues using MobileServiceClient and SingleSignOn authentication

So I was just messing around with Azure and decided to look at doing some authentication in a simple Windows 8.1 Xaml based application. I was following the steps outlined in this document.
I Currently setup MobileServices, added an application to the Microsoft Store portal, and also configured the Live Services as outlined in the above link.
Where I am having issues, is when trying to use the Microsoft Account auth SingleSignOn. What's happening is that if I connect using this code:
var client = new MobileServiceClient(MobileAppUrl, MobileAppKey);
var user = await client.LoginAsync(
MobileServiceAuthenticationProvider.MicrosoftAccount, false);
then I get the correct dialog asking for an email and password. When I type it in, it authenticates fine, and works as expected. The problem is when I set the useSingeSignOn flag from false to true, I get the dialog, it asks for permission, and then it gives the following error:
We can't connect to the service you need right now. Check your network connection or try this again later.
Then will then cause an exception when I exit the dialog:
System.IO.FileNotFoundException: The specified protocol is unknown. (Exception from HRESULT: 0x800C000D)":null
I have quadruple checked my azure settings, and they are all correct, as far as I can tell. It's driving me nuts! I have Google and Googled and Googled and found nothing. So then I Binged (doesn't sound as good as Googled), with the same results.
Is there some super secret server setting I possibly missed? Any help/guidance would greatly be appreciated!

Turns out that I just needed to use a different style of signing on. I had to login using the Live SDK, then use the authentication token from that into a different overload of LoginAsync. Now it all works.