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:
Login to a writable domain controller with the right permission that can modify the GPO
Go to Start > Search and Launch Group Policy Management
Select Group Policy Objects > Find Default Domain Controllers Policy > Right click and edit Default Domain Controllers Policy
Expand Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Select “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” > Choose Audit all > OK
Select “Network security: Restrict NTLM: Audit NTLM authentication in this domain” > Choose Enable all > OK
Select “Network security: Restrict NTLM: Audit Incoming NTLM Traffic” > Choose Enable auditing for all accounts > OK
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)
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
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.
Setup Windows Server 2003 domain controller
Setup Windows Server 2008
Adprep the schema in Windows Server 2003
Make Windows Server 2008 a domain controller
Migrate the FSMO from Windows Server 2003 to Windows Server 2008
Decommission Windows Server 2003 domain controller
Raise domain functional level from Windows Server 2008
Setup Windows Server 2008 R2
Adprep the schema in Windows Server 2008
Make Windows Server 2008 R2 a domain controller
Migrate the FSMO from Windows Server 2008 to Windows Server 2008 R2
Adprep the schema in Windows Server 2008 R2
Setup Windows Server 2019
Proceed to make Windows Server 2019 a domain controller –> here is where the error happens
Steps on how to perform FRS to DFRS migration
Always perform System state backup before proceed this on production
Check the replication health on all domain controllers, make sure are healthy before starting
On the Windows Server 2008 R2 domain controller that holes PDC role, launch your command prompt as administrator
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
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.
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
Proceed to Phase 2
dfsrmig /setglobalstate2
dfsrmig /getmigrationstate
got to make sure phase 2 completed only proceed to phase 3
Proceed to Phase 3
dfsrmig /setglobalstate 3
dfsrmig /getmigrationstate
Check the services
After running all phases successfully, it will automatically disable the FRS services and stop it from running
Run net share command to check whether the SYSVOL’s resource has changed to the new path
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.
*Note:
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
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:
Identify compromised accounts
Investigate malicious activities of accounts
Provide best practice security actions to administrators on how to handle accounts that reported by Azure ATP as suspicious or compromised
Provide detail visibility authentication of attacks
Azure ATP able to provide details of attack’s source
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.
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.
Login to your existing domain controller using an enterprise admin account
Run the Windows PowerShell as Admin
Type in the following command to change the forest functional level
#Get Forest level Info
Get-ADForest
#To Set the forest level
Set-ADForestMode -ForestMode <Operating System Name>
#Example: Set-ADForestMode -ForestMode Windows2012R2Forest
Type the following command to change the domain level
#Get Domain level Info
Get-ADDomain
#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!
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
Note:
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;
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
Head to your AADC server and rerun the synchronization
Check the Sync status whether it is completed without error
Both source and target domain controllers has to hold the PDC role to establish the trust.
Make sure you transfer the fsmo
Both domain controllers must be able to ping each other
At target domain controller, Ping <source domain DNS>
Ping domain controller IP addresses
Firewall are disable at both domain controllers
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.”
Sabrina Kay's Blog 