Latest Entries »

Reference articles to secure a Windows domain:

Microsoft audit Policy settings and recommendations:

Sysinternals sysmon:!2843&ithint=file%2cpptx&app=PowerPoint&authkey=!AMvCRTKB_V1J5ow


Beyond domain admins:

Gathering AD data with PowerShell:

Hardening Windows computers, secure Baseline check list:

Hardening Windows domain, secure Baseline check list:

Securing Domain Controllers to Improve Active Directory Security

Domain hardening in general:

  • Implement 2 or 3 tier model against Pass the Hash threat
  • FGPP implementation
  • LAPS Implementation
  • Process for proper cleanup of unused AD accounts
  • Reset of krbtgt account,domain admins account,IT administrators account
  • Setting Up Jump servers for Tier0,1,2 users
  • Domain joining of all windows boxes
  • Proper account Management Based on privileges
  • Usage of service accounts to run application instead of local system accounts
  • Review of existing AD accounts/Deletion of Unnecessary Accounts/ Review Ou structuring/GPO etc
  • HoneyToken Account Creation in Local boxes as well domain
  • GPO changes for disabling guest accounts across system,restricted RDP mode,Password Policy changes,disabling internet in member servers
  • GPO for Jump server implementation based on PAW GPO settings
  • Rename existing builtin Administrator account and lockdown
  • Sysmon deployment and WEF setup (WEC for symon events)
  • Use Pingcastle  review to assess the AD security
  • Use Bloodhound ( to assess the AD security
  • Use ADTimeline to assess the AD security


Some interesting sites:

Windows hardening:

Privilege admin workstation:

Delegate WMI access to domain controllers:

This post originally came about after several customers asked how to remove users accounts from Domain Admins and the Administrators group in the domain. These accounts are needed to monitor the systems, so we needed to find a way to get them to read the instrumentation of the system with non-elevated privilege.


Microsoft Office 365 roadmap:

For significant updates, Office customers are initially notified by the O365 roadmap:

As an update gets closer to rolling out, it is communicated through your Office 365 Message center.

Microsoft Azure roadmap:

Microsoft cloud platform:

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



Azure AD custom extensions

How to work with custom extensions:






# Connect to Azure AD with Global Administrator


# Get a User and Read Extension Properties

$aadUser = Get-AzureADUser -ObjectId <youruser> $aadUser | Select -ExpandProperty ExtensionProperty  

# Serialize User Object to JSON


# Explore Object Properties

$aadUser | Get-Member  

# How to: Add Extension Properties

# PS! Can only write to Cloud homed users

$aadUser = Get-AzureADUser ObjectId <yourclouduser>
$extensionProp = New-Object System.Collections.Generic.Dictionary2[System.String,System.String]
Set-AzureADUser ObjectId $aadUser.ObjectId ExtensionProperty $extensionProp

# Check added Extension Properties

Get-AzureADUser -ObjectId <yourclouduser> | Select -ExpandProperty ExtensionProperty

 #region List all users with Extension Properties

$aadUsers = Get-AzureADUser | Select DisplayName, ObjectId
$aadUsersExt = @()
ForEach ($aadUser in $aadUsers) {
    $user = Get-AzureADUser ObjectId $aadUser.ObjectId | Select ObjectId, DisplayName
    $userDetail = Get-AzureADUser ObjectId $aadUser.ObjectId | Select ExpandProperty ExtensionProperty
        foreach ($key in $userDetail.Keys)
            if($key -like extension_<YourTenantSchemaExtensionAppId>_msDS_ExtensionAttr1)
                $ext1 = $userDetail.$key
            elseif($key -like extension_<YourTenantSchemaExtensionAppId>_msDS_ExtensionAttr2)
                $ext2 = $userDetail.$key
            else { $ext1 = ; $ext2 = }
    $obj = [pscustomobject]@{DisplayName=$user.DisplayName; ObjectId=$user.ObjectId; Ext1=$ext1; Ext2=$ext2}
    $aadUsersExt += $obj

# List only users with values for extension attributes

$aadUsersExt | Where {$_.Ext1 -or $_.Ext2} | FT  

# List all users


# Serialize users and extension attributes to JSON

$aadUsersExt | ConvertTo-Json