The blade in the portal: https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade/quickStartType//sourceType/
If you edit a registered app in this preview blade and add API permissions you will hit the limit on number 30. This limit is enforced across the total of all API's.
The fact that Graph alone has more than 30 delegated permissions makes this absolutely stupid and will break integration between applications.
Does anyone why this is planned on being enforced as it is extremely restrictive and will break any future integration plans?
Microsoft support told me that it is preview, and yes it is, but this is what they are planning and it concerns us.
This restriction will be removed for apps that only support Azure AD accounts. For apps that support both Azure AD accounts and personal Microsoft accounts this limit will continue to be enforced.
Related
We are looking to set up a solution to monitor primarily the Global Admin role in Azure AD, so if a user is added to or removed from the role an e-mail is sent to a specific mailbox.
On our local AD we have a working solution for this, but I can't seem to find a similar solution for AAD.
In the Office 365 Security & Compliance Center > Alerts > Alert Policies there is a policy called "Elevation of Exchange admin privilege" which basically does what I want, except it only targets the Exchange Admin role.
I've tried creating a new policy from scratch, but as far as I can tell there is no way to choose to target a specific role. There is only the "Granted Exchange admin permission" and nothing really comes up when I search for "role" or "admin" in the "Activity is" drop down.
I've also looked at the MCAS (MS Cloud App Security) policies but nothing there seems to be what I need either.
I found this article: Monitor Office 365 admin role changes in all customer tenants but it seems to be geared more towards multitenant environments and requires quite a bit och additional setup. I was hoping there was a simpler solution for a single tenant environment.
Kind regards
If you have MCAS, I think it's possible that you have PIM as well (privileged identity Management. it requires aad P2 skus. But assuming you do, then it's very simple to do this. You would just go into the PIM in azure, click azure ad roles, click manage roles, choose the global admin role, Click role settings, and you will see options like this
If you don't have PIM, then it becomes quite a bit more complicated but could probably be less complicated than your example, you could set up log analytics to ingest azure ad data, and using a query pull out that information (role assignment event for example), then you could set up an alert in monitor referencing a log analytics workspace. https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics
The documentation for the Azure AD on-behalf-of flow indicates that combined consent does not work for personal Microsoft accounts. It says that "other strategies present themselves."
It only actually provides one other strategy (using a combined AAD application for both the web app and the middle tier service). Are there actually other strategies to solve this or is there just this one?
No drawbacks to the single application approach are listed. Are there any drawbacks? I assume there must be some otherwise using a single application would the default approach and not a workaround for this specific problem.
Thanks!
first of all, I'm absolutely new to Azure, so if my questions sound uneducated, that's the reason.
I'm looking for a guide or better—an understanding of how much effort is involved to provide automated user provisioning and de-provisioning as a SaaS provider as per here.
At the moment, my SaaS is not listed in the Azure Active Directory application gallery and instead, my clients enable SSO (Single Sign-On) by configuring single sign-on to applications that are not in the Azure Active Directory application gallery as per here.
In an ideal scenario, my clients will continue configuring single sign-on to applications that are not in the Azure Active Directory application gallery. That being said after they successfully configure the integration should enable automated user provisioning and de-provisioning with my SaaS.
Right, where do I start? :)
You have two options: SCIM 2.0, or Microsoft Graph. You can use one or the other individually, or both together.
Option 1: SCIM 2.0
Start here: Using System for Cross-Domain Identity Management (SCIM) to automatically provision users and groups from Azure Active Directory to applications
Azure AD natively supports SCIM 2.0, a standardized way of exchanging identity information that could also work with other SCIM-compatible systems.
One advantage is that there's a chance you can re-use this work for a different identity source system. Another is that the Azure AD provisioning service will take care of filtering and only sending you the users and groups the customer has assigned to the app.
A disadvantage is that you will be more constrained to the schema and protocol of SCIM 2.0, as compared to what you could get with native integration with Microsoft Graph.
Option 2: Microsoft Graph
Start here: Use delta query to track changes in Microsoft Graph data
The Microsoft Graph API has two change-tracking features which your app can make use of to sync changes to users and groups: change notifications (you get a ping every time something changes) and delta query (you retrieve all changes since the last time you checked).
The advantage here is you have much greater control over the sync process and options, and you'll have the option to provide very rich integrations (if relevant) with Office 365 and other Microsoft cloud services.
I have build a web application based on Azure. I have a web api service as backend and angularjs as frontend hostet in Azure.
I want to create a login page with individual user accounts. After some reading I found different user authentification strategies. Some use SQL database for managing user accounts. Some use Azure Active Directory. When I have to use Azure AD and when SQL databese?
my opinion is to compare what the benefits you will get
Azure AD:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-whatis/
For IT Admins, Azure AD provides an affordable, easy to use solution
to give employees and business partners single sign-on (SSO) access to
thousands of cloud SaaS Applications like Office365, Salesforce.com,
DropBox, and Concur.
For application developers, Azure AD lets you focus on building your
application by making it fast and simple to integrate with a world
class identity management solution used by millions of organizations
around the world.
Azure AD also includes a full suite of identity management
capabilities including multi-factor authentication, device
registration, self-service password management, self-service group
management, privileged account management, role based access control,
application usage monitoring, rich auditing and security monitoring
and alerting. These capabilities can help secure cloud based
applications, streamline IT processes, cut costs and help assure
corporate compliance goals are met.
Do it yourself with your database,you will have to do all above yourself e.g SSO with Office365
So you have to ask yourself what your app does? and choose the approach fits your needs
The application managing its own user accounts in SQL is called forms based authentication. It's how most internet applications used to work, but it came with a lot of downsides.
Users had to remember a password for each site, but often reused passwords across multiple sites. If one site got hacked and lots the password database, user's accounts on other sites could become compromised.
To prevent this, sites had to make sure that they stored passwords correctly (salted and hashed with a slow algorithm) and apply other kinds of operational security to protected the database.
Then token based authentication came along which let applications delegate the authentication piece to an external 3rd party. This allows users to log in to multiple apps with the same username and password.
Most of these 3rd party login providers like Google, Microsoft, Facebook etc. have specialist working on these services and are therefore more likely to be secure than anything you create yourself.
So, unless you have really good reasons not to, I would recommend using a 3rd party login provider like Azure AD and possibly others.
I'm working with the Google+ Domains API using a service account for domain wide delegation. Unfortunately, we're having difficulties with our client regarding the authorization model, because in theory we have access to all G+ data (even from the CEO etc..), while they would like to exclude a group of people.
Is this possible? Otherwise, only thing is to expect the developers to not abuse of their rights?
Not possible. You could use regular 3legged during development (store each user's permissions) and switch to domain-wide at the end under client supervission. Then leave the appengine without any developers on your side, only one client account that has control and gives you permission to develop as needed later.