I use Microsoft 365 for my 5-person business and am currently very satisfied, even if it is not always easy.
Under "Security -> Authentication methods -> Policies" I have enabled the following methods for all users (target).
Microsoft Authenticator
SMS / Text message
Email OTP
However, when my users log in to Microsoft 365 for the first time and are asked to protect their account, they can only select Microsoft Authenticator. The option for alternative methods is not shown at all (only myself can do it ...). Users can only select the "other authenticator app" option.
What am I doing wrong? We have 1 colleague who has such an old phone that she can't even download Microsoft Authenticator from the Play Store. She should have the option that she can use SMS + Mail.
I am very grateful for your help!
Kind regards,
Dennis
Administrate with Azure Active Directory (Security -> Authentication methods -> Policies)
You may have security defaults enabled.
Security Defaults in Azure AD
You may also want to check that you do not have conditional access policies in place to only allow signing in from web portals or Office 365 apps via app-based MFA.
Related
Microsoft Graph uses application permissions for background services. For Outlook APIs, application permission Mail.ReadWrite grants access to all mailboxes.
Is there a way to restrict access to a particular mailbox?
https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference
No you should use delegate access in that instance and the Mail.ReadWrite.Shared grant which will give access the Mailbox of the Owner and any of the Mailboxes Shared with that users (eg they have been delegated access to).
I agree what your talking about would be a nice feature being able to opt out of Application permissions for certain mailboxes/users etc is a requirement that comes up but the ability to do so doesn't exist. One way to mitigate that is with logic on the server side eg force the application to check a group before accessing Mailboxes etc and make sure auditing is switch on so you can catch any malicious use of the tokens and credentials.
Graph authentication through Client Credentials flow - Will my app have access to just my user account or to the whole organization?
https://github.com/microsoftgraph/microsoft-graph-docs/blob/master/concepts/auth_v2_user.md
This is now possible according to Microsoft Docs.
Some apps call Microsoft Graph using their own identity and not on
behalf of a user. These are usually background services or daemon apps
that run on a server without the presence of a signed-in user. These
apps make use of OAuth 2.0 client credentials grant flow to
authenticate and are configured with application permissions, which
enable such apps to access all mailboxes in a organization on Exchange
Online. For example, the Mail.Read application permission allows apps
to read mail in all mailboxes without a signed-in user.
Administrators who want to limit the app access to a specific set of
mailboxes can use the New-ApplicationAccessPolicy PowerShell cmdlet to
configure access control.
We have included list of all applications assigned to a User - as an applications ribbon - in a webpart in sharepoint. We have used this API call to retrieve the applications:
https://alignedenergy.okta.com/api/v1/users/[user#domain]/appLinks
It works fine, but this retrieves ONLY the list of applications that are administrator governed.
Please advice: Why is it not returning the list of all org-defined and user-defined apps/bookmarks for every authenticated user from Okta?
We are in a hurry to complete the integration of OKTA and SHAREPOINT (waiting to release because of this problem).
Thanks in advance.
The reason why user-defined apps and bookmarks are not exposed through the API is because of privacy reasons. We strive to make sure our users 100% trust the Okta platform for handling their personal and sensitive information in the most secure and privacy-aware fashion.
What if a user creates a bookmark that points to a bank site he doesn't want the administrator to know about? We actually allow that and deny the ability even for an administrator or super use account (which is effectively the identity you impersonate with when using an Okta API key) to get access to that information.
Personal Okta apps and bookmarks are in Okta and should stay in Okta for privacy reasons. I hope that makes sense but feel free to send us a note at developers#okta.com if you want to discuss your needs further.
We've been working with EWS Managed services for a while now, however we would like to transition over to using the RESTful API for Office 365.
Is it possible for an application to access all of our users data without their consent? We have an in-house application that we would like to get some O365/Sharepoint data to our users. Using SSO isn't really an option, as we don't want to keep asking our users to give consent (we assume they already give it). Specifically, we want access to calendars and mail.
Are these "service/application level" accounts available in O365 yet? I think I read a while ago that they are on the roadmap but I have not seen anything since.
Would it be best for us to continue using impersonation with EWS for now until it is ready? (For some reason, EWS is painfully slow when getting data, meanwhile our tests with O365 SSO are a great deal faster, but we do not want SSO).
Apologies if this does not meet the requirements for SA questions. Thanks.
EDIT. Daemon and Service Apps are now possible with Office365. Check out this link.
Building Daemon or Service Apps with Office 365 Mail, Calendar, and Contacts APIs (OAuth2 client credential flow)
App-level authentication is coming soon. Basically an organization administrator will have to consent to allow the application access to mailboxes in their organization, then you'll be able to authenticate as the app, rather than acting on individual users' behalf.
I'd say keep working on your prototype using the user consent model that's in place now, and keep an eye on our blog or my Twitter account (#JasonJohMSFT) for the announcement for app-level auth.
Here's the scenario
3rd Party App, with a back end. Customer uses the app.
Back end needs to access user's exchange information, assumedly via EWS
Back end is running in our datacenter/cloud, not customers.
Cannot require local administrator involvement
Want to avoid storing username/password in our back end.
Want to support both Office365 and on-premise.
I believe this is currently impossible, but wanted to verify:
Impersonation would be a great way, but requires Administrator
Token based authentication is not used for this. It is for a mail app to use for SSO to the backend, not for the backend to access Exchange.
OAUTH would be ideal, but is a) for Office365 only currently b) requires a portion of the back end to be hosted by Azure c) The Azure install has to be linked to the Office365 install and is for the local administrator only.
Is my analysis correct? Any options I've missed?
You're mostly correct. OAuth is currently for Office 365 only, so that would rule out on-premise. However, with OAuth you do not have to host your back-end in Azure. You would need an Azure tenant to register your application, but the app itself is not required to be hosted in Azure. If you use EWS, then even with OAuth you will need some admin involvement, because EWS requires a permission scope that requires the app to be registered in the target tenant, users can't consent using a registration from another tenant.
If you use the REST APIs, which are in preview, you wouldn't need an admin's involvement, users could consent for themselves. That would get you almost where you want to be (assuming the REST APIs provide the data that you're after), but wouldn't support on-premise.
So to add to this mostly correct answer from Jason:
using pure rest, you need only create a "multitenant" application and users can self-consent.
You can also use an OAuth token to authenticate to EWS - but only if the delegate Full Access To Mailbox is selected. This also doesn't require admin consent but is a big scope (but necessary because EWS doesn't understand scopes)
Overview
Our SharePoint 2010 application will be launched from a 3rd party application, let's call it HealthApp, via an embedded URL. Much of the time the user will be logged into HealthApp from a shared workstation. As a result, SharePoint will not sign in automatically using the Active Directory credentials.
Requirements
We need single sign-on.
We need to continue to use Active Directory as the STS for various reasons.
Authentication from a stand-alone browser on the user's workstation will need to work as it does now.
Authentication Info
HealthApp can pass a username and any other custom identifier information we want as URL parameters.
The username will match the users Active Directory username.
We will not have a password.
We need some way to authenticate the user based only on the username/identifier.
Possible Solutions
Is there any way to bypass the password check in Active Directory?
This would appear to be the simplest solution if possible.
Can we
extend the Active Directory provider to authenticate using a generic
user and then log into SharePoint with the username passed on the
URL?
Any other suggestions?
I would think there would have to be some way to do this but have not had much experience with claims based authentication with SharePoint.
Thanks for any insight.
Me also facing same issue for authenticating users over share point site that uses claims authentication.As per requirements my app needs to access share point data. So to authenticate
over share point server from an app we need to provide some authenticated claims with the request so that share point STS can issue an authorization ticket to access the share point site resources. after spending more than 2 days in googling i found some interested article that may help to authenticate users from client app against identity provider systems.
OAuth library
this resides between app and identity provider system. using this you get an authenticated claims that will further use to authorize over share point server with the help of Share point STS.