We Keep Coding

Is it possible to preload the username into the popup prompt when calling Microsoft Identity Client AcquireTokenInteractive?

New to Azure AD. I have a Winforms application that I'm adding Azure AD (with MFA) authentication to.
In Azure AD, I've registered an application and added some test users.
The users have MFA enabled (through Azure).
I'm using the Microsoft Identity Client and authorization works as expected.
Is there any way to force the Authentication popup to preload with a user name
and prohibit users from entering a different one?
Here is the code snippet for aquiring the token:
authResult = await PublicClientApp.AcquireTokenInteractive(scopes)
.WithAccount(firstAccount)
.WithParentActivityOrWindow(parentForm.Handle)
.WithPrompt(Prompt.ForceLogin) // or Prompt
.ExecuteAsync();
We would like the popup to be preloaded with a specific username rather than typing or selecting an available one from the prompt.

You can use the WithLoginHint() method and pass the UPN of the account as a parameter:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.identity.client.acquiretokeninteractiveparameterbuilder.withloginhint?view=azure-dotnet#microsoft-identity-client-acquiretokeninteractiveparameterbuilder-withloginhint(system-string)

Exception in Azure AcquireTokenAsync() accessing_ws_metadata_exchange_failed

Regarding adding external Gmail users to the Azure Active Directory Group, I have invited a Gmail user from the azure portal and the Gmail user has granted the consent to access the Application registered in Azure Enterprise Application.
When the Gmail user tried to Sign In into my Single Sign-On page, Azure validation is throwing the exception, when I am trying to acquire token by AcquireTokenAsync() Method
accessing_ws_metadata_exchange_failed
Response status code does not indicate success: 406 (NotAcceptable).
Below is my C# code to validate the users against Azure Active Directory.
var authority = string.Format(CultureInfo.InvariantCulture, "https://login.windows.net/{0}", tenantId);
var authenticationcontext = new AuthenticationContext(authority);
var upc = new UserPasswordCredential(username, password); //gmailusername and password
authenticationResult = authenticationcontext.AcquireTokenAsync("https://graph.windows.net", clientId, upc).Result;

The login flow you are using doesn't really work well with federated users (like these Guests).
Resource Owner Password Credentials (ROPC) grant flow that you are using here is only really meant to be a legacy upgrade path and isn't really modern authentication.
By the way, that login flow also does not support users with Multi-Factor Authentication or an expired password.
You could use Authorization code flow to login(back-end web app/native app).
In the case of a back-end Web app,
authorization code flow works by you redirecting the user to login,
getting a code back which you exchange for tokens.
In native apps it can be used by showing a pop-up of the login page to the user.
It can be used through different overloads of AcquireTokenAsync().

Web application requiring admin consent during token retrieval

My goal is to bypass the login screen and use Azure AD as the Identity Provider.
Given I am already logged in with my Azure AD user, I'd like to retrieve the authorization token using the silent flow and use this for resources that are protected.
I have a web application running on ASP.NET MVC 5 and a user-managed and backed by Azure AD (i.e. federated user). As a starting point, I have followed the steps in this article: Integrated Windows Authentication.
If I understand correctly, I should be able to use silent authentication since my users are federated and my application is registered as a public application.
In Azure AD, my app is registered with the following properties:
The code is straightforward, from the url.
var app = PublicClientApplicationBuilder.CreateWithApplicationOptions(
new PublicClientApplicationOptions()
{
ClientId = "<clientId>",
TenantId = "<tenantId>",
LogLevel = LogLevel.Verbose,
AzureCloudInstance = AzureCloudInstance.AzurePublic,
})
.Build();
var scopes = new [] { "User.Read" };
var result = await app.AcquireTokenByIntegratedWindowsAuth(scopes)
.WithUsername("<username>")
.ExecuteAsync();
The call for acquiring the token throws the following exception:
"AADSTS65001: The user or administrator has not consented to use the application with ID 'xxx' named 'xxx'. Send an interactive authorization request for this user and resource"
Per the documentation, User.Read doesn't need Admin Consent.
So what am I doing wrong here?
EDIT:
I have constructed a URL that prompts for user consent: https://login.microsoftonline.com/tenantId/oauth2/authorize?client_id=clientId&response_type=code&redirect_uri=<myApp>&nonce=1234&resource=User.Read&prompt=consent
It takes me to the screen where I need to pick my account, and after that, I get redirected to my app, where I get the same exception again.
So it doesn't show any consent screen, just asking me to pick the Microsoft account I want to use. Is this because of consent for User.Read is already granted by the admin?
But why am I still receiving the error? I'm a bit confused at this point.

You're mixing two different AAD OAuth mechanisms (aka v1 and v2 endpoints). The v1 endpoint uses Resources (https://graph.microsoft.com) while the v2 endpoint use Scopes (user.read). So when you request resource=User.Read, you are passing it an invalid resource name.
I would recommend using the v2 endpoint with the following URI prototype (line breaks for readability):
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
?client_id={clientId}
&response_type=id_token
&redirect_uri={your_app}
&response_mode=fragment
&scope=user.read

Because Integrated Windows Authentication is a silent flow, the user of your application must have previously consented to use the application or the tenant admin must have previously consented to all users in the tenant to use the application.
You can force user consent through a URL request with prompt=consent, the url will look like:
https://login.microsoftonline.com/<tenant-id>/oauth2/authorize?client_id=<client id>&response_type=code&redirect_uri=<Your-Redirect-URI-Https-Encoded>&nonce=1234&resource=<your-resource-Https-encoded>&prompt=consent
If it needs admin consent, use $prompt=admin_consent instead.(need to use admin account to sign in)
For more details about fix error AADSTS65001, you could refer to this article.

With delegated permissions, every user will need to consent to the application. If you do not want that requirement, a tenant administrator can consent for all users from the Azure Portal.

Create Microsoft Graph GraphServiceClient with user/password unattended

I am creating a console application that connects to Microsoft Graph using the Microsoft Graph API (as shown in https://github.com/microsoftgraph/console-csharp-connect-sample).
Everything is working fine, but I wonder if there is a way where I can authenticate a user (when I already know their user/password) without them needing to manually enter their credentials on the "Sing in to your account" window rendered on the desktop.
The idea is basically to run the application unattended, so there is no need for the user to be entering their credentials when the application starts. I can´t find any relevant information on the subject.
Is that even possible?
EDIT
After following the link #DanSilver posted about geting access without a user, I tried the sample suggested in that link (https://github.com/Azure-Samples/active-directory-dotnet-daemon-v2). Although that is an MVC application that forces users to authenticate (precisely what I wanted to avoid) I have managed to use part of the authentication code in that sample with my console application. After giving authorization to the application manually through a request to https://login.microsoftonline.com/myTenantId/adminconsent I can create a GraphServiceClient in my console app that connects to Graph without user interaction. So I mark the answer as valid.
Just in case someone is in the same situation, the GraphServiceclient is created as:
GraphServiceClient graphServiceClientApplication = new GraphServiceClient("https://graph.microsoft.com/v1.0", new DelegateAuthenticationProvider(
async (requestMessage) =>
{
string clientId = "yourClientApplicationId";
string authorityFormat = "https://login.microsoftonline.com/{0}/v2.0";
string tenantId = "yourTenantId";
string msGraphScope = "https://graph.microsoft.com/.default";
string redirectUri = "msalXXXXXX://auth"; // Custom Redirect URI asigned in the Application Registration Portal in the native Application Platform
string clientSecret = "passwordGenerated";
ConfidentialClientApplication daemonClient = new ConfidentialClientApplication(clientId, String.Format(authorityFormat, tenantId), redirectUri, new ClientCredential(clientSecret), null, new TokenCache());
AuthenticationResult authResult = await daemonClient.AcquireTokenForClientAsync(new string[] { msGraphScope });
string token = authResult.AccessToken;
requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", token);
}
));

One idea is using the "app only" authorization flow. The idea is that you can have long running apps access the Microsoft Graph without user authentication. The main difference is instead of the access token granting access to a particular user, it grants your app access to resources that you've consented to in advance. There will be no user login dialog and you can programmatically fetch access tokens to call the Graph API.
To reiterate that these tokens aren't for a particular user, consider making a GET request to 'https://graph.microsoft.com/v1.0/me'. This will return an error since the access token isn't for a particular user and "me" doesn't mean anything. Requests should be sent with full user ids "like graph.microsoft.com/users/someuser#contosos.com".
More information on this can be found at the Get access without a user documentation page.
Another idea is to let the user authenticate the first time they use your app and then store a refresh token. These tokens live longer (a few months IIRC) and then you won't need to prompt for user consent each time the app runs. Refresh tokens can be exchanged for access tokens that live 60 minutes and those can be used to call Graph API on behalf of users.
More info on refresh tokens: https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_user#5-use-the-refresh-token-to-get-a-new-access-token

I did want to come back out here and share, since I ran into this problem yesterday, and the idea of granting read/write mailbox access for my application... to EVERYONE'S EMAIL BOX IN THE ENTIRE ORGANIZATION... was way over the top for my needs. (And that is exactly what happens when you start talking about granting Application level permissions instead of delegated permissions to your registered app).
It's a simple use case: I had a nightly process that needed to automate sending of emails from a shared mailbox using a traditional AD service account.
Thankfully... even though they are on the march to eliminate passwords (lol)... someone at Microsoft still recognizes my use case, and it's lack of apples-to-apples alternatives in Azure AD. There is still an extension method we can lean on to get the job done:
private AuthenticationContext authContext = null;
authContext = new AuthenticationContext("https://login.microsoftonline.com/ourmail.onmicrosoft.com",
new TokenCache());
result = authContext.AcquireTokenAsync("https://graph.microsoft.com/",
"12345678-1234-1234-1234-1234567890",
new UserPasswordCredential(
Environment.GetEnvironmentVariable("UID", EnvironmentVariableTarget.User),
Environment.GetEnvironmentVariable("UPD", EnvironmentVariableTarget.User)
)).Result;
You can replace those GetEnvironmentVariable calls with your Username (UID) and Password (UPD). I just stuff them in the environment variables of the service account so I didn't have to check anything into source control.
AcquireTokenAsync is an extension method made available from the Microsoft.IdentityModel.Clients.ActiveDirectory namespace. From there, it's a simple business to fire up a GraphClient.
string sToken = result.AccessToken;
Microsoft.Graph.GraphServiceClient oGraphClient = new GraphServiceClient(
new DelegateAuthenticationProvider((requestMessage) => {
requestMessage
.Headers
.Authorization = new AuthenticationHeaderValue("bearer", sToken);
return Task.FromResult(0);
}));
The last bit of magic was to add these permissions to Application registration I created in Azure AD (where that GUID came from). The application has be defined as a Public client (there's a radio button for that towards the bottom of the authentication tab). I added the following 5 DELEGATED permissions (NOT application permissions):
Microsoft Graph
1. Mail.ReadWrite.Shared
2. Mail.Send.Shared
3. User.Read
4. email
5. openid
Since user consents are actually blocked in our organization, another permissions admin had to review my application definition and then do an admin level grant of those rights, but once he did, everything lit up and worked like I needed: limited access by a service account to a single shared mailbox, with the actual security of that access being managed in Office 365 and not Azure AD.

Error while using ADAL.net AcquireTokenAsync call

I am exploring Azure Active Directory. I am trying to see whether I can use my own login page with custom user id/password controls to capture the user credentials and validate against Azure AD. I am using ADAL.net to implement this, however I get an error "parsing_wstrust_response_failed: Parsing WS-Trust response failed". I get this error on the last line of the below code.
The below is my code:
string AppIdURL = ConfigurationManager.AppSettings["AppIdUrl"];
UserCredential uc = new UserPasswordCredential("testuser#domain.com", "test123");
AuthenticationContext aContext = new AuthenticationContext(System.Configuration.ConfigurationManager.AppSettings["AADInstance"]);
AuthenticationResult result = aContext.AcquireTokenAsync(AppIdURL, ConfigurationManager.AppSettings["ClientId"], uc).Result;

Please first click here to view the constraints and limitations of the Resource Owner Password Credentials Grant flow . Base on your error message , is the user federated with WS-Trust ? Please provide more information about your current configuration to help us reproduce this error .
In fact, Resource Owner Password Credentials Grant flow is not recommend. This should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).
If your aim is to customize the sign-in page ,such as add company branding to your sign-in page , you could click here for how to customize the sign-in page .