Uploading Graph credentials to Azure key Vault

If you have been following along with the recent articles I have been posting, you’ll know that I have been detailing how to use saved credentials from an Azure AD application to access multiple tenants using the Microsoft Graph. This post showed you how to create an Azure AD application inside multiple tenants and generate those credentials:

Using the Microsoft Graph with multiple tenants

Part of that process involved saving the Azure AD application credentials into locally encrypted XML files. I detailed how the encryption process for these configuration files locks those files to a single user on a single Windows 10 machine. Thus, if those files were copied to another location they couldn’t be used as you see below.

The potential challenge is, what if you want to use those credentials on multiple machines? And, what happens if the original machine on which those credential resides fails or is inaccessible? What is needed is a process to backup these files to somewhere secure in the cloud. Luckily, I know just the solution – Azure Key Vault.

To make things easy, I have created a free program to upload these credentials into an Azure Key Vault of your choosing. You’ll find the program at:

https://github.com/directorcia/Office365/blob/master/az-keyvault-saveto.exe

Simply download it and put into the same directory that the XML credential files for the domains live, as shown above.

When you run the program you’ll need to nominate an admin account for the Azure Key Vault destination as well as login into that Azure tenant into which you wish to save the credentials to. That tenant will need to have an Azure paid subscription.

Once you have logged into the destination tenant, you’ll be asked to select the subscription you wish to use for the Azure Key Vault. Remember, you need to have a paid Azure subscription to achieve all this.

When you enter the name of the destination Azure Resource Group for the destination Azure Key Vault, you’ll be warned if it already exists and if you are happy to use it. If no matching Azure Resource Group is found a new one will be created. Azure Resources Groups are just management containers for things like Azure Key Vaults.

You are then asked for the name of destination Azure Key Vault in that Resource Group. Again, the program will check to see if an Azure Key Vault of that name already exists and ask you whether you wish to use it. A single Azure Key Vault can hold many credentials, so using just one is fine if you choose to.

If the Azure Key Vault doesn’t already exist in that Azure Resource Group, a new one will be created with the name entered.

The destination Azure Key Vault will then be checked to determine whether a similar set of credentials already existing in there with the same name. If so, you’ll be given the option to use these existing entries or abort.

In most cases, with an Azure Key Vault with those credentials will not already exist so they can be written into the Azure Key Vault as shown above. At the end of the process, you’ll be given the option to delete the local XML configuration files if you want.

This process will continue through all the local XML configuration files for all the domains as shown above.

When the program has completed if you go and look in the destination Azure Key Vault, under the Secrets option on the left menu, you should find an entry for each configuration file uploaded as shown.

Effectively, you have now ‘backed up’ the Azure AD application credentials for all the tenants you have configured to a central secure location in Azure Key Vault.

I’ve also created a program here:

https://github.com/directorcia/Office365/blob/master/az-keyvault-saveto.exe

That will copy the credentials from Azure Key Vault and save them as local XML credential files. The good thing with this is now you can ‘restore’ these credentials securely to any Windows 10 machine.

Start by downloading the following file:

https://github.com/directorcia/Office365/blob/master/az-keyvault-saveto.exe

and placing it in a location where you want the Azure AD application credentials to be restored to.

When you run the program you’ll be asked to login to the Azure tenant with the Azure Key Vault containing the credentials you wish to restore as shown above.

You’ll then be prompted to select the subscription inside that tenant in which the Azure Key Vault is located as shown above.

Next, you’ll be prompted for the Azure Resource Group in which the Azure Key Vault lives as shown above.

Finally, you’ll be asked to select the Azure Key Vault inside that Azure Resource Group in which the credentials are stored. Remember, an Azure Resource Group can have many different resources, including multiple Azure Key Vaults if you choose.

The four credentials for each domain will be extracted one at a time and you will be prompted to hit CTRL+V (Paste) to save these in an encrypted format in the local directory. Thus, you’ll need to repeat this CTRL+V (Paste) process four times for each domain. I detailed this process previously if you need to understand it.

When the program is complete, if you look in the current directory, you should now see the familiar XML configuration files, four for each domain, as shown above. A copy of these credentials still remains in Azure Key Vault. You can now run any of the other Graph reporting programs on this machine as now the credential files are local o that machine.

These two programs now allow you to save the Azure AD application credential list into Azure Key Vault and restore them from there onto as many other Windows 10 workstations as you wish. Credentials are still stored securely locally and in Azure Key Vault.

Adding Microsoft To Do as a recommended app with Windows Information Protection

I’m a big fan of Microsoft To-Do but recently noticed that I was having trouble syncing data from my Windows 10 desktop to my other devices. Everything looked fine on my desktop but the next troubleshooting step I took revealed my problem as you can see below.

A Windows Information Protection (WIP) policy is preventing the use of Microsoft To Do on this device.

Ah ha, I had indeed recently changed my Windows Information Protection (WIP) policy for the desktop. This change had inadvertently stopped Microsoft To Do syncing as well as preventing me from logging in.

To solve the problem you need to add the Microsoft To Do app to the list of Protected apps in the Intune App Protection policy for the device, which by default, isn’t there.

Navigate to the Intune App Protection policy in question and view the properties as shown above. On the right hand side, select the Edit link next to Targeted apps as shown.

You should then see the Targeted apps as shown above.

Scroll to the bottom of the list of Protected Apps and select the +Add link at the bottom as shown.

This process is similar to one I documented a while back for Adobe Acrobat:

Adding Acrobat as an allowed app

The difference this time is that Microsoft To Do is a store app.

To identify the app you need to search for the store app on the Microsoft Store as shown above. When you locate the app and view the URL you will see a unique identifier as shown. In this case, for Microsoft To Do, it is 9NBLGGH5R558.

You’ll then need to visit this URL:

https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9NBLGGH5R558/applockerdata

Doing so will spit out the information you need to add the app as a protected app to your policy. To view the result for other store apps just insert the appropriate identifier into the URL instead of the one for Microsoft To Do shown here.

Thus, for Microsoft To Do you’ll need:

“packageIdentityName”: “Microsoft.Todos”

“publisherCertificateName”: “CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US”

Back on the Add apps page opened earlier, change the pull down at the top of the page to be Store apps. Then enter the information for Name, Publisher and product name as:

Name = Microsoft To Do

Publisher = CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

Product name = Microsoft.Todos

Select OK at the bottom of the dialog to save the changes. Then select Review+Save to update the policy.

You can either wait for the policy to be pushed down or force a sync from the device sync settings in the user account information for the Windows device. Once the policy has been updated to the machine you’ll be able to open and use Microsoft To Do or any store app you have configured. Doing so fixed my Microsoft To Do issue by allowing me to login to the app again on the desktop and sync information.

Using the Microsoft Graph with multiple tenants

In a recent article:

Making PowerShell automation easier with the Microsoft Graph

I showed how to use the Microsoft Graph to embed an Azure AD application in a single tenant and then use that to make Graph queries against. What happens when you want to that across multiple tenants?

To achieve this you’ll need to basically do three things:

1. Embed a ‘static’ Azure AD application in all the tenants you wish to access.

2. Give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access the tenant values.

3. Run a Graph request against these Azure AD applications in each tenant and extract the results you want.

This article is going to look at Step 1 of this process.

So, the task at hand is to create a ‘static’ Azure AD application in all the tenants we want to access. I have detailed how to achieve this manually before here:

Using interactive PowerShell to access the Microsoft Graph

That may prove time consuming if you wish to do this across many tenants, so I have automated it via a freely available program here:

https://github.com/directorcia/Office365/blob/master/graph-adapp-add.exe

You can download the file into any directory on your machine. Best best is to use a Windows 10 machine that already has the AzureAD PowerShell module installed. This program will also generate a number of configuration files in the current directory for each domain you connect to.

Running the program will launch the PowerShell script as shown. You’ll then be prompted for the name of your Azure AD application. This is the display name that will appear inside your Azure AD. This name will be the same across all tenants you connect to. Here I’ve chosen to call my Azure AD application ciaops.

You’ll then be prompted for the email address of a tenant administrator with the rights to create an Azure AD application.

You’ll then be take through the normal sign in process for that tenant with that user as shown above. This will include any MFA if required.

The tenant will be check to see if an existing Azure AD application of the same name already exists and if it does you’ll see a warning like shown above. The program will then skip adding an Azure AD Application to this tenant and move on to the next tenant.

Assuming no Azure AD application of the same name exists in that tenant you’ll see that a new Azure AD application of that name is created. When a token is created in a tenant there are fours pieces of information that will need to be saved:

1. Application ID

2. Object ID

3. Application secret

4. Tenant ID

Each of these will be written to a secure configuration XML file I’ll explain in detail below. For now, just appreciate that these values need to be written securely to files so they can be used later. To achieve that, the program uses the get-credential PowerShell command to capture these securely to be written.

To complete this process all you need to do is use the Paste command (i.e. CTRL+V) when prompted at the password field as shown.

So here, simply hit CTRL+V and then ENTER. The actual value you are pasting is a few lines up in the display as you can see above if you need it.

You’ll need to complete that process four times for each variable as shown above.

You are then prompted for the next domain you wish to add an Azure AD application to. You repeat the same entry process for each new domain you wish to use.

When you have no more domains to configure, simply press Enter at the admin domain prompt. At that point, the program will disconnect from any Azure AD and use the captured credentials to check whether it can access all these tenants. To do this, it reads from the saved configuration files and makes a basic read request to the Microsoft Graph using the Azure AD application details for each tenant to verify success. It merely tests that it can get the Graph API for that tenant.

At this point you now have an Azure AD application of the same name, inside each tenant you configured, with no permissions to anything with the Graph.

If you now return to the directory where you ran the program from you’ll see a number of additional files as shown above.

The graph-adapp-set.txt is a log of the whole process so you can see what has happened.

You’ll also see four XML files per tenant. These contain the important variables for the tenant mentioned previously. They are in format of:

<domain>-tenid.xml – holds encrypted Tenant ID

<domain>-appsec.xml – holds the encrypted application secret of the Azure AD application for the tenant

<domain>.objid.xml – holds the encrypted Object ID of the Azure AD application for the tenant

<domain>.appid.xml – holds the encrypted Application ID of the Azure AD application for the tenant

Storing these details on a workstation is not the most secure option I agree, but it’s a starting point for what I’ll show you down track (read Azure Key Vault). However, because some people want the flexibility and simplicity of local files that’s where this starts.

If you examine one of these XML configuration files more closely, as shown above, you’ll see that the variable name (here AppSec) is stored in the Username field and the Password field has a long string of characters. You’ll notice that these characters actually don’t in anyway match the actual Appsec value that was captured earlier. That value was:

This means that the actual tenant variables save in the files are encrypted, so they can’t be easily recovered.

To get the unencrypted values back you’ll need to use the PowerShell import-clixml as shown above.

Well, you maybe thinking that it is easy enough to copy these configuration files to another PC and decrypt them there. Not so fast my sneaky friend, because the way these details are encrypted is that they are locked to just THAT machine and just THAT logged in user! As you can see from the above, if you try and decrypt these files with another user on that same PC or on another machine, you can’t.

All of this comes about because of the use of the export-climxl command to save the variables, which says:

The Export-Clixml cmdlet encrypts credential objects by using the Windows Data Protection API. The encryption ensures that only your user account on only that computer can decrypt the contents of the credential object. The exported CLIXML file can’t be used on a different computer or by a different user.

That’s why you needed to do that CTL+V paste command for each variable previously so that the variable could be saved as a credential object and take advantage of this encryption process.

This has now achieved STEP 1 in the process I spoke about initially to allow secure access to multiple tenant using the Microsoft Graph.

So what does the program actually do to each tenant behind the scenes? It is easy to see. Simply visit the Azure AD Directory location in the Azure portal for that tenant. If you then select the App registration from the menu on the left, and ensure you are viewing All Applications, you should see the application with the name you entered displayed on the right as shown above. Here, ciaops.

If you select the application name to get more details you’ll many of the variables saved to XML files as shown above.

If you then select API permissions on the left you will see that, as yet, no permissions have been given to this Azure AD Application (although they will be in an upcoming article).

However, we are not quite done yet as I have also created a program that will remove all of these Azure AD applications created quickly and easily. To do that download the program:

https://github.com/directorcia/Office365/blob/master/graph-adapp-del.exe

You need to place it into the directory where all the tenant configuration file are located as shown. Double click the program to run.

To remove that Azure AD application you’ll need to log back into every tenant interactively as shown above. You’ll see the same of the tenant that it wants credentials for in the program flow.

Once you have provided access to the tenant, the Azure AD application will be deleted along with the configuration files. You’ll then be take to the next tenant and asked to repeat the process.

Once there are no more configuration files found the program will end.

Remember, this program will delete every matching tenant it finds configuration files for in the current directory. If you only want to delete a subset of the total tenants you have configured, move the other configuration files out of the current directory until this process is complete.

In summary then, the programs that I have created and made available for free will create a ‘static’ Azure AD application in all the tenants you select. The idea in upcoming articles will be to show you how this ‘static’ embedded Azure AD application can now be used to report and potentially change the configuration of multiple tenants quickly and easily. I also provided a program to also remove all these Azure AD applications from tenants.

Next step will be to give the Azure AD applications appropriate permissions and then get some information from the tenants WITHOUT the need of manually logging into each.

Making PowerShell automation easier with the Microsoft Graph

About 2 years ago I released a free PowerShell script that allowed you to check for email forwards on mailboxes in a Microsoft 365 environment. I wrote about that script here:

https://blog.ciaops.com/2018/07/05/powershell-script-to-check-outlook-mail-rules/

This is still the most comprehensive method in my books for checking for all the various type of forwards on a mailbox and I recommend you continue to use the script which you’ll find freely available at:

https://github.com/directorcia/Office365/blob/master/o365-exo-fwd-chk.ps1

As good as that script is, there are still challenges for many people actually using it I have found. This mainly revolves around getting an appropriate PowerShell environment running, installing the Exchange Online PowerShell modules, connecting to Exchange Online with PowerShell and so on. I have detailed how to do all that over the period here but I still find that many struggle to make use of the PowerShell script.

So a new approach is in order. In short, I have a new version of this script that is a single EXE file you can download and use here:

https://github.com/directorcia/Office365/blob/master/graph-mbx-rules.exe

It is important to note that this script does not make any changes to users or their mailboxes, it just reads and reports their mailbox rules using the Microsoft Graph. As yet, it can’t check more exotic things like direct mailbox forwarding or sweep rules, but you gotta start somewhere!

Let me show you how it works.

You’ll need a PC that is running a current version of PowerShell. A Windows 10 PC will work fine. You should also have the AzureAD PowerShell module loaded prior in your environment. To do that, all you need to do is run an elevated PowerShell console and type install-azuread. However, hopefully most people already have this loaded.

Download my new file from:

https://github.com/directorcia/Office365/blob/master/graph-mbx-rules.exe

and copy it anywhere on your machine as shown above. Double click to run the file.

You should now see a window like shown above.

The program will first check for the Azure AD PowerShell module. It will then prompt you to log into your tenant of choice.

You’ll go through your normal login process to a tenant as shown.

Including using MFA if required.

Once logged into the tenant, a new Azure AD application will be created in the tenant with a unique name as shown above. The name in this case is CIAOPS-20200415232309. With the app created in the tenant, appropriate permission are added to that app to allow it to do things like read the list of users, their mailboxes, etc.

After this app has been created and permissions applied to it to allow it to do its work, those changes need to be consented or approved by someone (typically the same user that initially logged into the tenant). Unfortunately, from what I can see, consent can only be managed via the browser. With that in mind, the required URL is copied to the clipboard and you are prompted whether you wish to open the default browser to complete this process. Copying the consent URL to the clipboard allows you to manually paste it to your browser session of choice. This is handy if you are working in multiple tenants currently.

You’ll now be prompted to login to the tenant again, but this time in a browser.

You should then see a list of requested permissions as shown above that you’ll need to accept for this process to complete.

If you look at the top of the dialog to see what is requesting permission you should see the name of the Azure AD application as noted previously. Here again that is CIAOPS-20200415232309.

Also note that there is only one write permissions requested, the majority are only read. Where do these permission come from? To use the Microsoft Graph, for example, to list the email folders for a user you use the command here:

https://docs.microsoft.com/en-us/graph/api/user-list-mailfolders?view=graph-rest-1.0&tabs=http

in which you’ll see to do this you need the permissions:

Mail.ReadBasic.All, Mail.Read, Mail.ReadWrite

I have tried to keep the rights requires as basic as possible but I am using what the Graph provides.

You’ll see that it needs a number of permissions to accomplish this. Basically, I have automated the process I detailed how to do manually before here:

https://blog.ciaops.com/2019/04/17/using-interactive-powershell-to-access-the-microsoft-graph/

After you Accept the permissions, you should be return to the home page of your tenant as shown. If for reason the consent page doesn’t appear or something else strange happens, just paste in the URL and try again. Sometimes web request don’t always work.

If you now return to the program you’ll see that it is prompting you to confirm that you have completed the consent stage. Type Y and press ENTER to continue.

Because the web consent step can take a short while to complete I now wait 10 seconds, just in case, for this to complete.

The program will continue, getting all the information it needs and then starting to report on user mailboxes as shown above.

Once all mailboxes have been checked the Azure AD application created to facilitate this process (here CIAOPS-20200415232309) is deleted from your tenant to leave zero touch.

If you then press any key, the program will complete.

If you now look in the source directory you will see two new text files as shown above.

The first file, graph-mdx-rules.txt is basically a debugging log file that records what happens during the initialisation phase of the program.

The file mbx-rules.txt is basically a copy of the results.

Note, both of these file get overwritten each time the program runs.

Hopefully, this new program makes it much easier to get the information your need. However, because much is automated and simplified, some may be concerned as to what is actually happening behind the scenes. Well, thanks to the wonders of Azure AD you can easily see.

To review the whole process, open you Azure portal and navigate to Azure Active Directory and then Audit logs as you see above.

In there you should find an entry that corresponds to the Azure AD application being added as shown above. Note the name corresponds to the one details previously, here CIAOPS-20200415232309.

You should then see entries where permissions have been added to Azure AD application as shown above.

A bit further along, you’ll see where consent was granted to the Azure AD application as shown above.

Lastly, you’ll also see where that Azure AD application is completely deleted from the environment leaving no fingerprint.

This is a new approach to automation that I believe will work well. There is still a lot of work that needs to be done and there are still some limitations but hopefully, this can be the first of many scripts I create and make available in this simplified way. Thus, I’d love you to try the program and tell me what you think. what works, what doesn’t? What would you like to see and how can it be improved? No matter what it is, I’d love to hear your thoughts, which you can send me directly via email director@ciaops.com.

Look out for more updates and new scripts at my GitHub repository – https://github.com/directorcia/Office365

Viewing and removing OneDrive for Business Sharing with PowerShell

One of the great abilities of OneDrive for Business and SharePoint Online is the ability to quickly and easily share a link to a file with people outside your organisation.

I’m not going to show you how to do this in this article but if you need to see how this is done have a look at:

Share OneDrive files and folders

In the above example you’ll see that the file Employee Engagement Plan.docx has been been shared by the owner with an external user (Lewis Collins).

Somewhere else, you can see that this user (Lewis Collins) has the document open to work on.

One of the benefits of sharing using OneDrive for Business is that the sharing rights can easily be revoked by the original user if desired.

The easiest way to achieve this would be simply to hit the cross next to the external users name in the web interface as shown above.

The original user would then be prompted the Remove the external user, which they would do to remove access.

That all works fine when you have a small number of shared files and a small number of users working with a file. It becomes a lot more problematic when you start scaling to many users as you can see here:

What happens when you need to find just one user to remove sharing from amongst a list of hundreds of users?

PowerShell to the rescue!

1. Connect to SharePoint Online via PowerShell. You can use my script at:

https://github.com/directorcia/Office365/blob/master/o365-connect-mfa-spo.ps1

to do this. You’ll need to know the tenant name prior i.e. the part before the .onmicrosoft.com (e.g. mydomain.onmicrosoft.com)

2. Run the PowerShell command:

Get-spouser -site https://<mydomain>-my.sharepoint.com/personal/<user>_<mydomain>_onmicrosoft_com -limit all

to display of all the users who have access to the specific OneDrive for Business site.

In this list you should find your external user in the format of:

<user@externaldomain.com>#ext#<mydomain>.onmicrosoft.com

This may vary slight but you should also be able to identify the user by their Display name if needed.

3. Run the PowerShell command:

remove-spouser –site https://<mydomain>-my.sharepoint.com/personal/<user>_<mydomain>_onmicrosoft_com  -loginname <user@externaldomain.com>#ext#<mydomain>.onmicrosoft.com

4. Run a sharing report

In the source OneDrive for Business, select the COG in the upper right corner and then the option OneDrive Settings.

Now select More Settings on the left and Run sharing report from the options that appear on the right as shown above.

Nominate a folder for this report to be sent to.

You’ll receive an email when the report is ready. It will be in Excel format as you can see above.

Open the file and do a search for the external email address of the removed users.

The removed users should not appear in the report as expected.

If you now look at the sharing option for file(s) in that OneDrive for Business you should find that the removed user no longer appears, as shown above.

If the external user, who has just been removed, actually has the file open at the moment that access is removed they will see:

and be prompted to Reconnect. If they then attempt to reconnect they will see:

and will be denied access going forward.

Note – This removes that users access to ALL files shared in the OneDrive for Business location, not just for a single file.

I also have another freely available script at:

https://github.com/directorcia/Office365/blob/master/o365-spo-extusr.ps1

that will display a list of all externally shared across your tenant as shown above.

If you do have a situation where you have large numbers of shared files or shared users in OneDrive for Business and you wish to make bulk removal easier, I’d encourage you to look at PowerShell as an option. However, remember, this option will remove ALL sharing for that user(s) across the WHOLE OneDrive for Business.

Branding your Microsoft 365 tenant

Branding is great way to improve the visual look and feel during the login experience but may also help mitigate phishing compromises in a small way by providing uniqueness. It only takes a few moments to brand your tenant and branding will also start showing up in a number of different areas when you use Microsoft 365 services.

This video takes you through that process and shows you how easy it is to set up. a link to the video is here:

https://www.youtube.com/watch?v=PFXzmlypyDM

and the article mentioned in the video is here:

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/customize-branding