Archive for October, 2019

Azure AD – APP registration concepts

App registration concepts:

The application registration in your tenant enables you and others to authenticate against your Azure Active Directory. Another option is to authentication through an application secret. A default application registration on its own cannot do much more than validating that the user has valid login credentials.



Create Client Id and Client Secret for Azure Active Directory


Content: The Microsoft Identity Platform (MIP) and Azure AD app registration. It offers developers a simple and secure way to provide secure sign-in to an app or/and access to other Azure resources like Graph API, SharePoint, … It’s also capable to protect in house API. It let Ops manage assignation and rapidly grant or revoke permissions.

To do that you need to register the application in Azure Active Directory and use one of the authentication/authorization libraries provided by Microsoft.

The MIP uses the OAuth 2.0 and OpenID authorization flow model which define four actors during the authentication flow:

  • The user, the resources owner, he/she use the application/web pages and give permission
  • The application, it acts as an OAuth client, it requests token and consumes resources on behalf of the user
  • The Microsoft Identity platform, the authorization server. It issues tokens, grant or deny access to resources and verify users and applications claims
  • The user’s resources, on a Resource Server, it’s the access point for the user’s data. It’s generally based on Graph API

OAuth 2.0 and OpenID are the two faces of the same coin. OpenID is used for authentication (AuthN) and OAuth 2.0 for authorization (AuthZ).

The process uses endpoints. You can get the information by using PowerShell and the AZ Module to query the oAuth 2.0 metadata document.

$TennantId = (Get-AzTenant).id[0] 

$oAuth2TenantInfmation = Invoke-RestMethod -Uri "$($TennantId)/v2.0/.well-known/openid-configuration" -Method get 

The $oAuth2TenantInfmation contains all the endpoints and information you need.

To get the authorization endpoint:


In the AuthN phase, the user is redirected to an endpoint in Azure (**/oauth2/v2.0/authorize where Tenant ID is used for the current tenant, Common for any works or Microsoft account, Consumers for Microsoft account only and Organization for works account only).

The user enters his/her credential, consents to the permissions and get a token (ID_token) to return to the application (via the return URL). The application can verify the token to identify the user.

This is the basic authentication/authorization process with OpenID/oAuth 2.0

Microsoft provides several libraries and frameworks to deal with the authorization/authentication process see

To be able to sign in and access resources an application needs to be registered to Azure Active Directory. But before going further in application registration there are few other concepts to understand.

First, you need to determine who will use the application? There are several cases:

  • Restricted to one Azure AD tenant, this is the case for most in house applicationThe endpoints URI contain the tenant ID
  • Open to any Azure AD tenants, this is the case for multi-tenant applications
    The endpoints URI contains organizations
  • Open to anyone including other Azure AD tenants and Microsoft accounts, this the case for public applications
    The endpoints URL contain Common (or consumers if the application only accept Microsoft account)

Another thing is how the application works and behaves. It will determine which client library to use and how permissions consent.

We need to look at how the application interacts with the user. Does the application interact directly with the user or does it need to work whiteout any user interactions?

In other words, for an application that reads the user calendar, does it read it only when the user opens the application or every time in a background task on the server side.

In the same way how the application works, is it a Front/back application, an API or desktop application?

How can we register the application, as we see we may need a URI, sometimes a certificate or a secret?

App registration can be done in the Azure Portal or by using PowerShell. For PowerShell, you will need the AZ module. It works with Windows PowerShell 5.1 and PowerShell core

install-module name AZ scope CurrentUser  

Import-module name AZ 


$ApplicationName = "DemoDev-To" 

$ApplicationUri = "" 

$ApplicationReplyUri = @("","https://localhost:44321/signin-oidc") 

$AzureApplicationObject = New-AzADApplication -DisplayName $ApplicationName -IdentifierUris $ApplicationUri -ReplyUrls $ApplicationReplyUri HomePage $ApplicationUri 

The ApplicationName will be displayed in the Azure Portal and will later identify the application.

For the ReplyUrls parameter, I used an array and not a string. An application can have multiple environments (Dev/UAT/Prod) and respond to different URI.

The $AzureApplicationObject contains the configuration result. You will get two important ID, ObjectID and ApplicationID. These two objects will be needed to configure the client library.

HomePage is not needed but it helps to identify the application later in the Portal.

Now let’s try to create a Secret based application registration.

$ApplicationName = "DemoDev-To-Key"  

$ApplicationUri = ""  

$ApplicationReplyUri = @("","https://localhost:44321/signin-oidc")  

$AzureApplicationObject = New-AzADApplication -DisplayName $ApplicationName -IdentifierUris $ApplicationUri -ReplyUrls $ApplicationReplyUri HomePage $ApplicationUri  

$AppPlainTextPassWord = "SomethingYouCanType"  

$SecureStringPassword = ConvertTo-SecureString -String $AppPlainTextPassWord -AsPlainText -Force 

$StartDate = get-date 

$EndDate = $startDate.AddYears(2)  

New-AzADAppCredential -ObjectId $AzureApplicationObject.ObjectID -Password $SecureStringPassword -startDate $StartDate -enddate $EndDate 

Get-AzADApplication -ObjectId $AzureApplicationObject.ObjectID | New-AzADServicePrincipal -startDate $StartDate -enddate $EndDate 


Application is now created in Azure AD, you can now start to assign users.

I got request form IT Security team to block DNS query malware in DNS Service.

They guide me with follow this link. 

ex: Add-DnsServerQueryResolutionPolicy -Name “BlockListPolicy” -Action IGNORE -FQDN “EQ,*.onion” -PassThru

Unfortunately, this PowerShell command works only Windows server 2016 or greater.

For previous versions read those articles:

third-party DNS firewall:



Graph explorer:

News from ignite 2019:


Resources for MS graph API:


How to access Azure AD using Microsoft GRAPH:



New MS graph API add-on for splunk:



By default the log events are stored for 90 days. You have to archive the logs to storage account if you want to keep more than 90 days.



By default log is stored in 90 days you have to archive the logs to storage account if you want to keep them more that 90 days.




How to:

Getting Around the Basics of Azure Automation for Office 365


Automation runbook gallery:


Redirect Azure automation output to a file ( or blob container in Azure terminology) ?


Process automation for Intune and AzureAD:

Process automation for Intune and Azure AD with Azure Automation



Here are resources about Azure and Office365,

let me summarize:

Office365 : is an offer of MS services and hosted applications – Saas ; in clear you pay for a service (sharepoint,exchange,office…) and you don’t manage the infra behind (like CPU,RAM,Storage,Security)

Azure: is a cloud (private/public) offer – paas/Iaas ; compared to Office365, MS provide just the plumbery (hyper-v, Storage, CPU, RAM, network) and you manage the applications, the Operating system, the security and patches, the applications ; in short “it is like a lego or a Mecano!”, and with Azure you can mix your on-premises IT infra with Azure in the cloud (and vice-versa)

Web resources for Azure:

Domains FAQ:

Domain take over:

Azure tips and tricks:

Azure subscription and naming convention:

Azure RBAC:

Manage VM:


Azure cost calculator:

White papers:

Azure health status:

Choose the right authentication method:

AzureAD connect:

Other resources:

To go deeper:


Seyf’s blog:

Web resources for Office 365:

Office 365 for business get started:



Productivity library (scenarios):

Technical decks:

Technical references:



‘In the Cloud’:

Office blog:    and

Intune blog:

Azure AD Resources

Domains FAQ:

Domain take over:

Azure tips and tricks:

Azure subscription and naming convention:

Azure RBAC:

Manage VM:


Azure cost calculator:

White papers:

Azure health status:

Choose the right authentication method:

AzureAD connect:

Other resources:

To go deeper:


Seyf’s blog: