Browsed by
Category: GraphAPI

Microsoft Graph and Client ID’s

Microsoft Graph and Client ID’s

Recently I have been working in PowerShell to access Microsoft Graph, primarily to interact with Intune. My starting point has been the Samples provided by Microsoft here:¬†https://github.com/microsoftgraph/powershell-intune-samples while extending the samples to modify the AAD user objects I started getting Access Denied even with a Global Admin account, really weird right, well it comes down to the $clientid variable in the samples which are for the “Microsoft Intune PowerShell” Service¬†Principal, I needed to use the “Microsoft Azure PowerShell” Service Principal.

Sounds easy enough right? After spending a little time scouring the internet I couldn’t find the “ClientID” for Azure Active Directory, in the end I got around it by finding the GUID on another blog (Don’t recall the Blog).

Which got me thinking, this information should be stored somewhere on the Tenant, and after much investigation I’ve fond the Service Principal’s via using the AzureAD PowerShell module with the “Get-AzureADServicePrincipal” command, if your tenant is look mine you will have a flash of objects fly by we have over 300+ objects in ours, luckily I have demo Tenant which I can run Get-AzureADServicePrincipal to obtain the full list of ClientID’s which are there by default, with Intune enabled we have 21 objects, in this solution we are only looking for the 2 ClientID’s for Microsoft Azure PowerShell and Microsoft Azure PowerShell, which are (The full connection scripts for PowerShell to Microsoft Graph have a look in the samples in the above link):

AAD ClientID = “1950a258-227b-4e31-a9cf-717495945fc2”

Intune ClientID = “d1ddf0e4-d672-4dae-b554-9d5bdfd93547”

To note when you return the full list of the Service Principal’s with PowerShell the ClientID is named AppID.

Depending upon how the Service Principal’s have been configured you might not be able to use the AppID in PowerShell to invoke commands on Microsoft Graph.

Good Luck

Steve.

Send an email with GraphAPI and PowerShell

Send an email with GraphAPI and PowerShell

To follow on from this blog post where we interrogated the GraphAPI to obtain information regarding the user object which invoked the call. We are going to use GraphAPI and PowerShell to Send an email, I know what you’re say, “But Steve I can just use the Send-MailMessage commandlet” which is true, but what the this solution gets you is a record in your Sent Items of the email. All of this without even needing to think about setting up anything to do with SMTP.
So the major difference from the last script to this one is that we need to construct a JSON object, which we then POST to GraphAPI, rather then using a GET function like we did previously. An example of this is:

In my sample I have kept it simple with a single recipient, a Subject, and body. But there is a vast amount of information which you can define for the email your sending, you can find more about it here.
For a full copy of script please look here

Good Luck

Steve

PowerShell GraphAPI

PowerShell GraphAPI

In the last blog post we went over what the GraphAPI is and why it’s all powerful, with this post we are going to go over how you can leverage the GraphAPI via PowerShell.
First things first we need to register an application at https://apps.dev.microsoft.com/ this is pretty straight forward, just make sure you save the Client Secret when you create it as you will only see it once! the other thing to note is that you need add a platform as “Web” this address does not need to resolve, nor does your PowerShell Scripts need to use it.
The other important part on this page is to allocate permissions to the application which all depends upon what you want to interrogate the GraphAPI, for more information have a look here where Microsoft has documented the process in more detail then I have.

So we now have the Application ID from the new application, the Client Secret, and the Redirect Address, we can now create a simple PowerShell script like the below (update the Variables to match your environment).

Once you have updated the Script to match your environment you can now execute it and you should see something like this:

@odata.context : https://graph.microsoft.com/beta/$metadata#users/$entity
id : 2f2916e5-953c-4c5d-9f52-bd5db8131d49
accountEnabled : True
assignedLicenses : {@{disabledPlans=System.Object[]; skuId=c7df2760-2c81-4ef7-b578-5b5392b571df}, @{disabledPlans=System.Object[]; skuId=061f9ace-7d42-4136-88ac-31dc755f143f}}
assignedPlans : {@{assignedDateTime=2017-01-18T19:43:48Z; capabilityStatus=Enabled; service=SharePoint; servicePlanId=e95bec33-7c88-4a70-8e19-b10bd9d0c014}, @{assignedDateTime=2017-01-18T19:43:48Z; capabilityStatus=Enabled;
service=SharePoint; servicePlanId=5dbe027f-2339-4123-9542-606e4d348a72}, @{assignedDateTime=2017-01-18T19:43:48Z; capabilityStatus=Enabled; service=exchange; servicePlanId=efb87545-963c-4e0d-99df-69c6916d9eb0},
@{assignedDateTime=2017-01-18T19:43:48Z; capabilityStatus=Enabled; service=MicrosoftCommunicationsOnline; servicePlanId=0feaeb32-d00e-4d66-bd5a-43b5b83db82c}…}
businessPhones : {}
city :
companyName :
country :
department :
displayName : Steven Hosking
givenName : Steven
jobTitle :
mail : mail@AusIgnite2017.onmicrosoft.com
mailNickname : steve
mobilePhone :
onPremisesImmutableId :
onPremisesLastSyncDateTime :
onPremisesSecurityIdentifier :
onPremisesSyncEnabled :
passwordPolicies :
passwordProfile :
officeLocation :
postalCode :
preferredLanguage : en-AU
provisionedPlans : {@{capabilityStatus=Enabled; provisioningStatus=Success; service=exchange}, @{capabilityStatus=Enabled; provisioningStatus=Success; service=exchange}, @{capabilityStatus=Enabled; provisioningStatus=Success;
service=exchange}, @{capabilityStatus=Enabled; provisioningStatus=Success; service=exchange}…}
proxyAddresses : {SMTP:mail@AusIgnite2017.onmicrosoft.com}
refreshTokensValidFromDateTime : 2017-01-18T07:01:55Z
showInAddressList :
state :
streetAddress :
surname : Hosking
usageLocation : AU
userPrincipalName : mail@AusIgnite2017.onmicrosoft.com
userType : Member

If you want to test other options you can change the URL on Line 2 of the script “$uri = “https://graph.microsoft.com/beta/me/”” to query anything which has been published via the GraphAPI, you can find more information here and browsing through the options on the left of the page.

You can also find all of the references of the Beta calls for the GraphAPI which at the moment includes all of the calls for Intune, these might not work on your subscription today, these GraphAPI calls will be green lit for your subscription once it has been migrated over to the Ibiza portal (portal.azure.com).

Good Luck

Steve

What the heck is the GraphAPI and why should I care?

What the heck is the GraphAPI and why should I care?

So recently I have been spending time learning about the new Preview Intune Portal which is moving over to the Ibiza Azure Portal. As part of this migration from the existing Silverlight Intune portal to the new Ibiza portal Microsoft is working on exposing a vast amount of information (if not all) for your Intune Subscription via the GraphAPI. I’m going to quote from the Microsoft Graph website here the GraphAPI is “One endpoint to rule them all”, I’m sure there is a joke about rings and volcano’s that could be put in here.
But in all seriousness GraphAPI is well on it’s way to living up to that tag line, today as i write this there is already a vast amount of objects from the Office world which are already available to interrogate for example you can do a simple “Get” request on: https://graph.microsoft.com/v1.0/me you will be able to see a JSON response. I’m sure you have just clicked on the link and you got a JSON reply looking something like this:
{
“error”: {
“code”: “InvalidAuthenticationToken”,
“message”: “Bearer access token is empty.”,
“innerError”: {
“request-id”: “c6a2dcfe-4ee6-489a-9de3-a5573c6e2576”,
“date”: “2017-01-27T03:35:07”
}
}
}

So as you might have guessed by now it’s not completely straight forward to interrogate the GraphAPI, this is actually a really good thing as you need to provide an access token to be able to query the data from GraphAPI. To test a query you can use the Graph Explorer which you can find here: https://graph.microsoft.io/en-us/graph-explorer
By default it will be signed in with a “Demo Tenant” where you can test out the API calls, but once you sign in you can interrogate your own data you will be prompted to allow the Group Explorer access to your data during logon so you know what type of items which the GraphAPI has access too.
If we run the same link as we previously ran in the GraphAPI you will get a JSON reply which looks something like this:
{
“@odata.context”: “https://graph.microsoft.com/v1.0/$metadata#users/$entity”,
“id”: “2f2916e5-953c-4c5d-9f52-bd5db8131d49”,
“businessPhones”: [],
“displayName”: “Steven Hosking”,
“givenName”: “Steven”,
“jobTitle”: null,
“mail”: “steve@AusIgnite2017DEMO.onmicrosoft.com”,
“mobilePhone”: null,
“officeLocation”: null,
“preferredLanguage”: “en-AU”,
“surname”: “Hosking”,
“userPrincipalName”: “steve@AusIgnite2017DEMO.onmicrosoft.com”
}

As you can see GraphAPI is quite secure, in that you can’t just randomly query the GraphAPI objects from another company without a Access Token. In this demo the Graph Explorer handles the process of obtaining access to your Subscription be it Intune, Office 365, or Azure Active Directory.
It’s also worth noting as of today to access the Intune sections of the API you need to change the v1.0 to Beta in the URL’s, in saying that not all Intune subscriptions have currently been migrated to the Ibiza Portal which enables the GraphAPI so you might not be able to test this, to find more information regarding the Intune GraphAPI have a look here as it will be continually updated during the roll of the Ibiza Portal support.

In future blog posts I will explain the process to query the GraphAPI with PowerShell.

Good Luck

Steve