I have been trying without great luck to sign in Microsoft OneDrive and sync Sharepoint folder with an invited guest gmail account. I can sign in with the gmail account online to the SharePoint site but when I sync a document library to OneDrive, it is requesting a work/school account.
Isn't B2B designed to allow this as per link:
https://learn.microsoft.com/en-us/sharepoint/sharepoint-azureb2b-integration
Thx
• It is requesting a work/school account because you might not have granted guest access permission to the document library and onedrive account while also enabling external sharing for onedrive and your organization for that guest account.
• Also, please note that since this is guest invitation sign in, you are required to share the content at folder or site level only. Ensure that any policy is not enabled which blocks accessing/syncing of your organization’s resources to social accounts.
Please refer the below link for details on controlling external sharing as well as the policy setting to prevent sync for Azure B2B: -
https://learn.microsoft.com/en-us/onedrive/b2b-sync#control-external-sharing
https://learn.microsoft.com/en-us/onedrive/b2b-sync#policy-setting-to-prevent-b2b-sync
If MFA is enabled on the tenant sharing the content, you may log on using a browser, but can not sync:
https://learn.microsoft.com/en-us/sharepoint/b2b-sync
"Currently the sync client does not support interactive authentication UI when syncing external content. Any policy that would require a sign-in UI such as MFA (multi-factor authentication) or TOU (terms of use) prompt, will prevent the syncing of the external content from that tenant."
Related
We have implemented Microsoft Identity Access Management in our web application login. But when we implement the same in our branches, users are able to login in their personal Hotmail account. As per organization policy personal account should not be accessed from branch outlet. Is the any option block all hotmail account and enable only company account.
login.microsoftonline.com
As suggested by Thomas, you can block all Hotmail accounts and enable only company account while registering the web application in Azure AD.
Please check the supported account type you have selected while registering the web application in Azure AD.
To enable only company account, register web application by selecting supported account type as "Single tenant"
If you have selected Multitenant and personal Microsoft accounts, then users can login with Hotmail accounts. To block that, avoid selecting that option and choose Single Tenant.
Reference:
Validation differences by supported account types - Microsoft Entra | Microsoft Docs
I want to allow people to use some deployments tools to perform actions in their Azure environments.
We currently have a working MSAL.js solution for supporting work accounts to be able to login and acquire the scope https://management.azure.com/user_impersonation using an AAD app.
To move to supporting non-work accounts we:
Verified our application is set to allow all types of accounts
Changed the endpoint used for logins from /organizations to /common
Unfortunately despite the /common it says we need to use a work or school account when we provide something like an #gmail account.
Without being able to acquire a permission scoped to this API we can't list tenants someone has access to so that we can proceed. It seems really backward & poor UX to have a workaround of needing their tenant ID to be manually provided and changing the our login endpoint. Prior we simply made the assumption that it's whatever tenant their AAD account is part of but a default login acquisition only returns the tenant id of the app.
Reproducible example
You can see this behaviour with a Microsoft demo application.
OpenID works with a personal email
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=openid&state=12345
Azure scope does not work
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=https://management.azure.com/user_impersonation&state=12345
What is the right combination of login endpoints and scopes (or multiple steps!) needed to be able to support user impersonation of non-work accounts for acting in Azure?
PS Older Q in a similar vein indicates this may not be possible which is exceedingly frustrating.
Make sure that your AAD application (6731de76-14a6-49ae-97bc-6eba6914391e) is registered as "Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)".
You can also switch the existing AAD application to this type by modifying the manifest file: set "signInAudience": "AzureADandPersonalMicrosoftAccount".
This will allow personal account to sign in.
UPDATE:
Sorry my bad. Azure resources should be only available to work account. Personal account cannot access Azure resources because it doesn't have Azure subscription. When a personal account is added into a tenant as the guest, it will be treated as work account.
If you click on the Try it -> Sign in in this page, you will be redirected to this url: https://login.microsoftonline.com/common/oauth2/authorize?client_id=7f59a773-2eaf-429c-a059-50fc5bb28b44&redirect_uri=https%3a%2f%2ftoken.learn.microsoft.com%2fsignin-oidc&resource=https%3a%2f%2fmanagement.core.windows.net%2f&response_type=code+id_token&******************.
This is v1.0 endpoint which doesn't support personal account.
So for v2.0 endpoint, if you set AAD application type as Accounts in any organizational directory (Any Azure AD directory - Multitenant) or Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox) and use organizations or common endpoint, it will treat your account as a personal account by default, thus preventing you from logging in.
Currently the only way to implement it is to use v1.0 endpoint like this:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=19xxxxxx-68ed-433c-a2c5-5f5cxxxxxx05&response_type=code&redirect_uri=https://localhost/&response_mode=query&resource=https://management.azure.com/&state=12345
Remember to specify the AAD application as Accounts in any organizational directory (Any Azure AD directory - Multitenant) to avoid the account being recognized as a personal account.
If one of our SharePoint online Sites has been shared with a external user using his LiveID (Microsoft Account like hotmail).
Does this external user can be authenticated by our Azure AD to be able to call applications using OAuth? Does this user get a valid access token by our Azure AD?
Yes, it is able for guest users to consent to applications, granting them the same access that members have in your directory.
More detail about guest user management and limitations you can refer here.
my organisation has recently upgraded their Sharepoint to 365. Previous versions of Sharepoint had the facility to grant access to a service account (EMEA\xxx...), however it appears 365 can only grant access to users via an email address. Is this correct? If not, please can you let me know how I can provide access to the service account?
Thanks very much in advance for any help you can offer
Regards,
David
I think you mix up a couple of things here. Office365 separates internal tenant's accounts or external accounts.
External accounts:
External accounts get created when one invites an external user to a shared resource. An external can only be invited based on their e-mail address.
Read more: https://support.office.com/en-us/article/Manage-external-sharing-for-your-SharePoint-Online-environment-c8a462eb-0723-4b0b-8d0a-70feafe4be85
Internal accounts: in a cloud-only ootb setup, internal accounts only live in the Azure Active Directory assiociated with your Office365 tenant. You can extend the setup by using a synchronized or federated setup using a Directory Synchronization tool.
Identities in Azure Active Directory are identified by either the User Principle Name (UPN) or the user's e-mail address. The classic DOMAIN\USER representation is not supported.
With both setups, accounts from your on-premise Active Directory get copied to your Azure Active Directory (AAD). In the synchronized setup the password gets (securily) copied, so that users can log in with their login and password they now from their on-premise experience.
In the federated setup a user gets redirected to an on-premise ADFS end-point for authentication. At this end-point one can still use the DOMAIN\USER format for authentication.
Read more:
https://support.office.com/en-us/article/Understanding-Office-365-identity-and-Azure-Active-Directory-06a189e7-5ec6-4af2-94bf-a22ea225a7a9
In short: you should sync your service accounts towards Office365 and start using their UPN or "virtual" e-mail address. After having synced your service accounts you then can perfectly assign global Office365 admin rights to the AAD identity if that is what you would like to get established.
I need to find out how I can allow our Sharepoint portal to support both windows authentication and form based authentication. The objective is to allow those users in our Active directory to sign into the portal using their active directory credentials, and at the same time we want to allow those users who don't belong to our active directory to register an account online and be able to access our sharepoint portal after their account is approved by an admin.
You need to enable the Dual Authentication for the SharePoint Site. Here one of the class article in the subject
Also you need to deploy the controls for enabling the user to register and create login refer this