Does anyone know what Security Enabled in Microsoft Teams is? I used the MS GRAPH API to connect and it returned a column named security enabled with a true or false
Microsoft Teams is built on top of Groups. The securityEnabled property is inherited from the Group object:
Specifies whether the group is a security group. If the mailEnabled property is also true, the group is a mail-enabled security group; otherwise it is a security group. Must be false for Office 365 groups.
Related
Microsoft Graph API has support to retrieve mail rules for individual mail boxes. Is there any API to get the list of rules configured by Admin for the organization?
https://graph.microsoft.com/v1.0/users/user-id/mailFolders/inbox/messagerules
Not that i am aware of using Microsoft Graph API. At this point Graph API supports only individual mailboxes. The closest one i can see is that you can application permission to query other mailboxes as well. But it won't tell or get you the list of rules configured by admin for the organization. Being said that you can consider filing an uservoice so that it can be considered to be implemented. As an alternate you can use from Exchange PowerShell (something like Get-Trasportrule).
I was looking at Alerts APIs for Microsoft Security Graph and it seems like you can't create a new alert by an API? I was wondering if there is anyway I can programmatically create a new alert into Azure Sentinel?
Security alerts are supplied by Microsoft security providers, so creating alerts is not currently an allowed method under Microsoft Graph Security. However, you can create incidents from alerts in Azure Sentinel. Please refer to this documentation.
There is currently a Sentinel REST API that you can programmatically interact with Azure Sentinel, see below (Swagger 2.0 Specs, in preview)
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/securityinsights/resource-manager/Microsoft.SecurityInsights/preview/2019-01-01-preview/SecurityInsights.json
For creation/update of a new incident, see example: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/securityinsights/resource-manager/Microsoft.SecurityInsights/preview/2019-01-01-preview/examples/incidents/CreateIncident.json
For a creation of a scheduled alert rule: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/securityinsights/resource-manager/Microsoft.SecurityInsights/preview/2019-01-01-preview/examples/alertRules/CreateScheduledAlertRule.json
Hope this helps, I assume by "alert" you mean an incident.
I'm automating Microsoft Teams lifecycle (create, add membmers and owners, etc), and I have Teams with a set of Owners and Members (the Owners are also Members). Now when I use the Remove owners endpoint of the Microsoft Graph, I'm noticing some inconsistencies.
Expected behaviour: Owner gets removed as Owner, but stays in place as Member (both in Azure AD as in Microsoft Teams).
Observed behaviour
v1.0 endpoint: In Azure AD, it's as expected. In Microsoft Teams however, the user stays marked as Owner (in the members list) with the associated permissions. I have been waiting for weeks, it just doesn't update.
beta endpoint: In Azure AD, it's as expected. In Microsoft Teams however, the user is removed completely. He doesn't exist in the membership list anymore and he cannot access Microsoft Teams anymore.
It looks like membership changes happening through the Microsoft Graph API don't propagate correctly to Microsoft Teams.
What is supposed to be the correct behaviour? Is it an issue with the Graph or with my approach?
The expected behavior is the /beta variant. This reason for the different behavior isn't clear but it likely stems from the Teams APIs still being in beta and v1.0 not being fully aware of Teams (or the additional attributes it needs to change).
If you are looking to migrate a user from Owner to Memeber, you would make two calls:
Remove the user from the Owners list using DELETE /groups/{id}/owners/{id}/$ref
Add the user to the Members list using POST /groups/{id}/members/$ref
Using PHP and the Microsoft Graph API I'm fetching a user by querying:
https://graph.windows.net/<tenant>/users/<userId>?api-version=2013-11-08
This works fine, but only returns the standard fields for the user object. According to the documentation I'm supposed to be able to use $select=* to get all the user data, like this:
https://graph.windows.net/<tenant>/users/<userId>?$select=*&api-version=2013-11-08
However this gives me the following error:
{"odata.error":{"code":"Request_BadRequest","message":{"lang":"en","value":"The ability to use the $select query option to define a projection in a data service query is disabled. To enable this functionality, set the DataServiceConfiguration. AcceptProjectionRequests property to true."}}}
How can I enable "AcceptProjectionRequests"? I find nothing about this in the documentation or in other SO-threads.
The APIs you are referencing above are Azure AD Graph which is different than the Microsoft Graph APIs. It might be worth your time to have a look at the Microsoft Graph APIs and consider transitioning away from Azure AD Graph. The general guidance from the Azure AD Graph team recommends using the Microsoft Graph instead of the Azure AD Graph. You can read more about the differences and the Azure AD guidance here.
Having said that, Azure AD Graph does not support $select (as stated in the blog posting I linked to above). Microsoft Graph does support $select for doing query projections (see Microsoft Graph or Azure AD).
Currently (as of 7/8/2016) Microsoft Graph supports most of the directory features that Azure AD Graph supports, but not all. In some cases, Microsoft Graph supports functionality that is not in Azure AD Graph (such as ability to make $select projection queries).
Per OData spec, $select=* can either return all entity properties or a default set of properties (provided the default set contains all key properties). The Microsoft Graph implementation is the latter and it will return a set of key properties. In order to get all the necessary properties you need, you will need to explicitly request the entire list you want unless they happen to be within the default set.
I setup and MVC 4 application and added authentication against our Azure AD server as outlined here: http://msdn.microsoft.com/en-us/library/windowsazure/dn151790.aspx
Authentication works as expected. However, I'm not getting any roles back by default. There should be several AD groups created and I would like to use them to role restrict the application via the [Authorize] attribute in MVC.
I can't really find a good place to even start figuring this out. Can anyone give me an outline or point me to a good tutorial?
I should mention that I'm not the administrator for our Azure account, so I need to be able to tell our admin what to do if any setup is required on that side.
First, tokens returned by Azure AD do not currently contain claims for roles or groups, so you need to get them from the Graph API. Second, roles in Azure AD that are returned by the Graph API are not necessarily intended for use in an ISV/LoB app, and in general you should use security groups for authorization instead. To perform authorization, you should use the checkMemberGroups or getMemberGroups operations in the Graph API, which are transitive and valid for this purpose.
If you check out the following resources in order, I think your questions will be answered. You'll learn how to authenticate to the Graph, call it, and configure your application to use the result of the group operations to perform authorization:
Using the Graph API to Query Windows Azure AD -- This is the second walkthrough to complete now that you've done the web SSO one.
Authorization with Windows Azure Active Directory
MVC Sample App for Azure AD Graph
Blog post describing checkMemberGroups and getMemberGroups
How do I get role and group membership claims for users signing in via Windows Azure AD? -- This one is out of date in regards to the methodology for authentication and the UI for managing users/groups, but it's still useful. Pay special attention to the section on the custom ClaimsAuthenticationManager, which gives you an idea of how to inject role/group data into the ClaimsPrincipal object early so that it can be used in the [Authorize] attribute or other authorization logic.
Sean answer is a bit outdated. You can now configure Azure AD so it will include groups or roles inside JWT token so it will be included into ClaimsPrincipal.Current.Claims so standard [Authorize(Roles = "yourRoleName")] attribute will work.
Here is introduction post. Which basically says you have two options:
Use groups claim - you need to change groupMembershipClaims value in app manifest and later in application you can check for ClaimsPrincipal.Current.FindFirst("groups").Value to see in what group user is (you only get group id). You can write you own Authorize attribute that use this. more info
Define roles for you application and then use normal code for testing if user is in role:
[PrincipalPermission(SecurityAction.Demand, Role = “yourRoleName”)]
[Authorize(Roles = “yourRoleName”)]
if (ClaimsPrincipal.Current.IsInRole(“yourRoleName”)) { //do something }
You need to edit roles in you app's manifest.
More info here and here. Values needed to be set in manifest are described here
What is really strange is that you can't assign more than one role to group from Azure web page. You need to use azure graph api for this.
If you can't see Users and Groups tab in Azure portal you probably need Azure AD Basic or Premium edition. If you are working on free azure subscription you can use free Azure AD Premium trial to test stuff.