Defender for Identity: NTLM Warning Troubleshoot

Hi everyone hope you guys are enjoying your weekend, today is actually the day where Malaysian votes for their new leader (Prime Minister).

Prove that I have voted! This year voting allocation for special needs and old folks was really convenient.

Anyway, let’s start the topic of today!

Microsoft recently alerts tenant’s Defender for Identity admin portal due to new requirements require to implement on the domain controller’s GPO.

The warning should look like this in your Defender for Identity Admin portal:

There is a link of recommendations that it should guide you to how to resolve this issue. However, I realize the article by Microsoft did not CLEARLY wrote the steps on how to locate the Group Policy. This feedback had been raised to the authors and they had already attended to it.

In your domain controller’s Event viewer logs you should receive an event ID showing 8004.

It would affect to those domain controllers that does not have this policy enabled. To enable the policy, you should follow the steps below.

Resolution Steps:

  1. Login to a writable domain controller with the right permission that can modify the GPO
  2. Go to Start > Search and Launch Group Policy Management
  3. Select Group Policy Objects > Find Default Domain Controllers Policy > Right click and edit Default Domain Controllers Policy
  4. Expand Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
  5. Select “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” > Choose Audit all > OK
  6. Select “Network security: Restrict NTLM: Audit NTLM authentication in this domain” > Choose Enable all > OK
  7. Select “Network security: Restrict NTLM: Audit Incoming NTLM Traffic” > Choose Enable auditing for all accounts > OK
  8. Go to Start > Search and launch Command Prompt > Run this command “gpupdate /force“. (For immediate apply, do this to all the available Domain controllers with the sensor agent too)



Azure ATP: Troubleshoot sensor keeps disconnecting

Hey guys good morning! Is a rainy day today, just brings the relax mood on.

Here is another topic on Microsoft Defender for Identity, is the troubleshooting on sensors.

When you notice that your sensor keeps disconnecting, while it was fine during the first 2 weeks of the deployment.

There are many possibilities that causes this issue, so I’m glad that there is this Sizing tool that you can use to identify the traffic on the domain controllers and it will provide you recommendation of the hardware requirements that needs increasing or look into it.

Sometimes this is not due to domain controllers or the sensor issue, it could meant that the environment is growing and numbers of applications required the LDAP authentications with the closest domain controllers or the FSMO holder domain controller.

This is how the alert looks like on the ATP portal;

To proof that whether the domain controller needs increment of the hardware resources

  1. Download the sizing tool
  2. Install the sizing tool on the domain controller that has issue with the sensor
  3. *it does not require restart of domain controller
  4. Run the application for 24 hours
  5. It will export a excel file on directory of the application

This is how the reports looks like, filename is TriSizingToolResults_<date>

ATA Summary
Azure ATP Summary

As you can see above the I have 3 domain controllers that exceeds 30k of packets per second, and it recommended me to increase the RAM size.

Below is a diagram of requirements needs to be meet;

I highlighted ones is needs to be met for my 3 domain controllers.


  1. Planning your Microsoft Defender for Identity deployment | Microsoft Docs

Domain controller: Migration of Legacy file replication service to Distributed file service replication

Hey guys hope you are doing well!

Now let’s start off with a topic related to on-premises, which is domain controller. I had encounter a weird situation where I was performing a domain controller migration from a Windows Server 2008 R2 to Windows Server 2019, during the migration process I wasn’t able to proceed to active directory domain services in Windows Server 2019.

I had all the prerequisites checked but this was the first time I have ever encounter this.

This was the error that I encounter during the wizard…

“Verification of replica failed. The specified domain is still using the File Replication service (FRS) to replicate the SYSVOL share. FRS is depreciated.”

The error explains that the SYSVOL is running a depreciated service, called FRS and recommended that I perform a migration of FRS to DFSR.

SYSVOL is basically a folder that contains your Group Policy Management and Scripts and it replicates to all other domain controllers. SYSVOL folder located in C:\Windows in your domain controllers.

FRS is basically the service to perform the replication. Upon research, FRS only supports Windows Server 2000 and 2003 only. Windows 2008 and above depreciate FRS. However, how in the world that FRS is running on Windows Server 2008 R2???

To further investigate this situation, I had to ask whether that the environment has any application servers that is on Windows Server 2003. If the answer is yes, it means that the environment used to be running on Windows Server 2003 or earlier. It seems that the transition/migrate of domain controller was not clean during that time.

There is one article that spoke about the migrate of Windows Server 2003 to Windows Server 2008, doesn’t meaning only migrate the FSMO roles, and majority forgot to migrate the FRS to DFSR. Hence, this FRS was able to carry forward to the Windows Server 2008.

*Note: Below are not detailed steps on how to setup a domain controller, you must at least have knowledge on how to setup a domain controller

The best way to mimic this error was to setup my lab

Why so this transition? Every Operating system works differently.

Make sure you got the right permission account.

  • Setting up domain controller permission required domain administrator rights.
  • FSMO transfer permission required enterprise administrator, and domain administrator.
  • DFSR migration permission required is domain administrator.
  1. Setup Windows Server 2003 domain controller
  2. Setup Windows Server 2008
  3. Adprep the schema in Windows Server 2003
  4. Make Windows Server 2008 a domain controller
  5. Migrate the FSMO from Windows Server 2003 to Windows Server 2008
  6. Decommission Windows Server 2003 domain controller
  7. Raise domain functional level from Windows Server 2008
  8. Setup Windows Server 2008 R2
  9. Adprep the schema in Windows Server 2008
  10. Make Windows Server 2008 R2 a domain controller
  11. Migrate the FSMO from Windows Server 2008 to Windows Server 2008 R2
  12. Adprep the schema in Windows Server 2008 R2
  13. Setup Windows Server 2019
  14. Proceed to make Windows Server 2019 a domain controller –> here is where the error happens

Steps on how to perform FRS to DFRS migration

  1. Always perform System state backup before proceed this on production
  2. Check the replication health on all domain controllers, make sure are healthy before starting
  3. On the Windows Server 2008 R2 domain controller that holes PDC role, launch your command prompt as administrator
  4. Run the following commands
    • dfsrmig /getglobalstate
    • This means that the service is not using DFSR
    • net share
    • Under the Share name, SYSVOL’s referring the resource of C:\Windows\SYSVOL\sysvol, we are going to change it to be C:\Windows\SYSVOL_DFSR
  5. Next, run this following command to start your phases of migration. There are 4 phases of migration.
    • Phase 0: Return – This phase is a fallback option for you. This is only useful if you are in Phase 1 and Phase 2.
    • Phase 1: Start – This phase allow you to start the migration and prepare the SYSVOL to be copy the content to SYSVOL_DFSR. System created a new folder called SYSVOL_DFSR.
    • Phase 2: Redirect – This phase will start to redirect the SYSVOL path/pointer to SYSVOL_DFSR.
    • Phase 3 Eliminate – This phase deletes the SYSVOL folder.
  6. The command to start the phase 1 is
    • dfsrmig /setglobalstate 1
    • dfsrmig /getmigrationstate
    • got to make sure phase 1 is completed only proceed to phase 2
  7. Proceed to Phase 2
    • dfsrmig /setglobalstate 2
    • dfsrmig /getmigrationstate
    • got to make sure phase 2 completed only proceed to phase 3
  8. Proceed to Phase 3
    • dfsrmig /setglobalstate 3
    • dfsrmig /getmigrationstate
  9. Check the services
    • After running all phases successfully, it will automatically disable the FRS services and stop it from running
  10. Run net share command to check whether the SYSVOL’s resource has changed to the new path
  11. This migration doesn’t require rebooting the domain controllers afterwards, but if there is a reboot prompt require before the migration, please proceed the reboot first.


  • Stopping the FRS services without running the migration, would not help resolve the issue
  • If you have child domain, then please also perform a DFSR migration on the child domain’s domain controller that holes the PDC role



Azure ATP: Azure ATP capabilities and mechanism

Hey everyone, hope you guys had a wonderful day. Starting of a new year 2021. I hope everyone stay healthy and stay safe distance from one another or avoid crowded places.

I know that this pandemic has test us in many ways, in terms of physically and mentally. If you manage to get through year 2020 challenges, then give yourself a pad on the back, you did good.

This blog post I’m going to write about what is Azure ATP, before I jump into the topic, I want to say that security is a journey. If you guys have read about the recent news about attacks rises double/triple in the year 2020 and also the news about solarwinds attack, then these are enough proof that hackers are given more chances to attack in this situation, because they know majority businesses or corporates are still vulnerable or not up to par in terms of securing their environment and providing security training to users. Users mistakes in allowing attackers are also risk to the corporate that is why users training is still important to corporates. Losing money/profit to attackers is twice painful to the corporates then purchasing and implementing security technologies/products in the environment. Let’s take ransomwares as an example for this case. Due to this pandemic, I notice quite an amount of corporates are now implementing the concept of “Zero-trust“. If you would like to know what is “Zero-trust”, do feel free to Google them up.

Anyway, alright lets start our topic. The ATP term has been quite awhile in the security industry, or if you still not too sure what is ATP, ATP stands for Advanced Threat Protection. It contains advanced intelligent technology and combination of algorithms to identify and investigate types of malicious behavior and it will select appropriate action to quarantine/block the malicious actions before doing any harm to the environment and provide deep dive detailed reports to administrators.

Azure ATP has been known quite awhile in Microsoft 365, and Microsoft had given a different naming, Microsoft Identity Defender. It’s capability is to:

  1. Identify compromised accounts
  2. Investigate malicious activities of accounts
  3. Provide best practice security actions to administrators on how to handle accounts that reported by Azure ATP as suspicious or compromised
  4. Provide detail visibility authentication of attacks
  5. Azure ATP able to provide details of attack’s source
  6. Reports are real-time and signals back to Microsoft Identity Defender portal

This is just a summary of the entire structure looks like implementing Azure ATP into the environment with Domain Controllers only.

Azure ATP agent is only for on-premises like Domain controllers and ADFS and the agent will send a signal back to Microsoft Identity Defender if detected malicious activities or compromised accounts. I do recommend that you read more about requirements of deploying Azure ATP, before deploying into your customer’s environment. There is a medium impact required.


  1. What is Microsoft Defender for Identity? | Microsoft Docs
  2. Microsoft Defender for Identity architecture | Microsoft Docs

How to change Forest Functional Level and Domain Level?


Make sure you have Enterprise Admin account/permission to run this command and run the PowerShell as Admin. 

If you run into error that you can’t bring up a new Domain Controller due to Operating System is not in the suitable forest functional level, this solution could help you out. RODC is not accepted to run these commands.

I am not sure whether does this require FSMO roles to make the changes towards these functional levels. Hence, I run these commands on the Primary domain controller.

  1. Login to your existing domain controller using an enterprise admin account
  2. Run the Windows PowerShell as Admin
  3. Type in the following command to change the forest functional level
    • #Get Forest level Info
      #To Set the forest level
      Set-ADForestMode -ForestMode <Operating System Name>
      #Example: Set-ADForestMode -ForestMode Windows2012R2Forest
  4. Type the following command to change the domain level
    • #Get Domain level Info
      #To Set the forest level
      Set-ADDomainMode -DomainMode <Operating System Name>
      #Example: Set-ADDomainMode -DomainMode Windows2012R2Forest


Would recommend that you study on the difference between Forest Functional Level and Domain level. I would write a blog post about it soon!


Azure AD Connect: Error 8344 Permission Issue Insufficient Access Rights to Perform the Operation

If your sync service completed with error and the error code is shown below;

Error 8344: Permission Issue Insufficient Access Rights to Perform the Operation

It means that the service account that you used to add the domain during the wizard setup does not have the correct/necessary permissions.

In the wizard, is this part




Please do take note that this is only for Password Synchronization and Password Writeback, for further extend permission please review the references below.

Step by step;

  1. Provide the necessary permission to the service account
    • Add the service account into the Administrators Group (Built-in OU)
    • At the forest level > Properties > Security > Add > service account
      • Next, select the service account, scroll to the permission and check “Replicate Directory Changes All” and “Replicate Directory Change
      • Due to password writeback will be turn on too, another permission you have to give to this service account is the “Change Password” and “Reset Password” under the Advanced
        • Select the service account > Advanced > Select Add > Select Principal > Service account > Descendent User Objects > Check the box for “Change Password” and “Reset Password”
    • Save your changes
    • Refresh
  2. Head to your AADC server and rerun the synchronization
  3. Check the Sync status whether it is completed without error
  4. The End






  1. ADUC – Active Directory Users and Computers
  2. ADS – Active Directory Sync
  3. OU – Organization Unit
  4. AADC – Azure Active Directory Connect

Do check out the latest blog post for this issue here

What to take note when establishing trust between Domain Controllers?

Prerequisites to establish trust;

  1. Cannot be a Read-Only Domain Controller
  2. Both source and target domain controllers has to hold the PDC role to establish the trust.
    • Make sure you transfer the fsmo
  3. Both domain controllers must be able to ping each other
    • At target domain controller, Ping <source domain DNS>
    • Ping domain controller IP addresses
  4. Firewall are disable at both domain controllers
  5. Able to Nslookup each other domains

You will fail with an error if the prerequisites are not met;

“The secure channel verification on Active Directory Domain Controller <DC name> of domain <source domain> to <target domain> failed with error: The specified domain either does not exist or could not be contacted.”