Intune & PowerShell: Creation of Email accounts automation on Outlook

Hey guys and girls, hope you all are having a good day. Today’s topic has a relation of 3 platform.

  • Intune/Microsoft Endpoint Manager
  • PowerShell
  • Outlook App (Windows)

This topic is more related to migration situations, so basically the environment is running IMAP and are on the stage of migrating to Office 365. Hence, to allow users to able to proceed to make use of the new mailbox and having to receive latest emails without disruption or downtime, would need to create the office365 email account on their Outlook profile.

If you notice that you have an email account, user@abc.com with the type “IMAP” on your outlook default profile, but you would like to also add the user@abc.com with the type “Microsoft Exchange” on the outlook default profile too. This is where the issue happen, majority would just proceed to try to add the account from the Outlook app but it will never let you successfully add the new account in and return with the message saying “This account has been added.” It seems to me that the Outlook App unable to differentiate TYPES. If you dig into Google Search you will only get articles, guiding you to create a new Profile just for the Office 365 account.

Wait…there is a solution to this. Please don’t bother raising case to Microsoft Support from Intune, if you’re lucky you will meet a support that willing to go extra miles for you. Usually the support would recommend you to turn on this feature from Intune “Automating the creation of outlook profile for Exchange Accounts” this only applies to new profile not existing profile.

So basically the solution is simple but I’m still unable to find an automation way to perform this. Hence, manually, but luckily is was just a small business organization, else I’m poof of words. Just type organization that is not willing to spent other migration products such as BitTitan and etc..

Anyway, to create an email account o the default outlook profile we would need to

  1. Launch your Start/Windows button
  2. Search for “Control Panel”
  3. Search for “Mail” in Control Panel
  4. Select the Mail > select “email accounts”
  5. Then select “New”
  6. Enter the following details and click Next
  7. Wait for the establish processing…
  8. You will now have 2 user@abc.com accounts in the default Outlook Profile with different types, IMAP and Microsoft Exchange.

If you are still wanting to go with having 2 profiles in Outlook to serve each types here is a simple PowerShell Script that you can upload to Intune;

#This is to create new Profile with the new Profile name
New-Item -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\Profiles\<Profile Name>" -Value ""

#This is to allow the prompt to users to choose which Outlook profile
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Exchange\Client\Options" -Name "PickLogonProfile" -Value "1"

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.

References:

  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.

*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

References

  1. https://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distributed-file-system-replication/

Azure ATP: How to Remediate Enumeration activities or other attacks?

Hey every good evening, and hope you guys are having a nice day today. Just another topic about Azure ATP here, a.k.a Microsoft Defender for Identity.

If you come across this before and then you would already know what is it for. If you are new here, then let’s just have a brief explanation what is it about. Azure ATP is basically a cloud-service that leverages your on-premises to perform identifying, detection and monitoring of your domain controller’s user objects activities and behaviors.

Newly deploy Azure ATP in your environment would take 48 hours to 72 hours for the Azure ATP to study the behaviors of each accounts, but this is also depend how large is your objects in your environment.

Anyway, a bit of side track just now. This blog post objective here is that if you ever encounter the 5 types of attacks, Reconnaissance, Compromised credentials, lateral movements, domain dominance and exfiltration alerts from the Azure ATP.

You may refer to this link here to learn how to remediate and understand how to manage the alerts.

Azure ATP: Does Admin’s actions recorded by Office 365 Audit?

Hey everyone, hope you guys are having a nice evening. Today’s blog post is about Azure ATP and Office 365 audit.

So the situation is like this;

Majority Office 365 tenant has more then 1 global administrators. Whenever, a global administrator would like to capture other administrators actions, they would query those events from Office 365 audit. So for Azure ATP, I notice it is not available in Office 365 audit, but for Defender Endpoint it exist in the audit. Summary, you can’t audit actions being taken in Azure ATP portal.

Scenario: If a global administrator, deletes an alerts from Azure ATP, it would remain deleted and there is no recycle bin to restore the alert back unless you regenerate the same situation to trigger the detection. This delete action is not recorded into the Office 365 audit.

Office 365 audit
Azure ATP on deleted alerts

I do not see this as a show stopper, I am still testing other ways to get this working. Stay tune…

References:

  1. https://docs.microsoft.com/en-us/defender-for-identity/working-with-suspicious-activities
  2. Search the audit log in the Security & Compliance Center – Microsoft 365 Compliance | Microsoft Docs
  3. DefenderATP Audit logs – Microsoft Tech Community

Azure ATP: What is the Retention Period of Reports?

Hey Hey everyone, good morning, is Saturday here in Malaysia. Hope you guys are doing well. This week blog post is about another Microsoft Defender for Identity, a.k.a Azure ATP. The terms are up to your suit and understanding.

I think is very reasonable to know what is the retention period that the Azure ATP’s Reports. Why? Because of Auditors

Upon researching to gather articles from Microsoft site and there weren’t an article talking about how long the reports store in Azure ATP. I do know that the reports in Microsoft security max are either 30, 60 or 90 days.

Thus, I had to raised a case to Microsoft Support and they return the answer that the retention period is 180 days. I did request whether they were able to locate any article from Microsoft that state it but none.

To locate Reports in Azure ATP, simply go to https://portal.atp.azure.com , select the 2nd Icon on the left taskbar.

Azure ATP: How to do exclusion detection?

Hi and good weekend to you. I haven’t been writing blog post for 1 week due to Chinese New Year holiday, 1 week off from doing YouTube videos and writing blog post, and spending quality time with my family. This is the first Chinese New Year celebration without visiting friends or other family members. E-angpao has become our replacement of physical AngPao. Seeing how this pandemic pushes technology forward and forcing people from all different generation to use technology, is amazing.

Anyway, this blog post I’m going to be talking about how you as administrator you can exclude certain situation from the Azure ATP detection. Azure ATP stands for Microsoft Defender for Identity. There are few situation you can exclude from Azure ATP detection such as Backup accounts and replication accounts. Take note this is only based on my experience or Microsoft recommendation but is not a MUST to exclude them.

How the alerts works in Azure ATP, is that when ever the account is behaving one of the detection it will notify an alert to the Azure ATP portal and to administrator’s email. So imagine if you have Azure AD Connect in your environment, your Azure AD Connect service account is notifying your administrator every 30 minutes, because the default replication time is every 30 minutes. Annoying right? Once you confirmed that this is the service account used only for replication, here is how you could whitelist it from the Azure ATP detection;

*This is for replication account, for others situation the exclude value may differ, these steps below is mainly to gain understanding how to exclude and where to locate the exclude.

  1. Login to https://portal.atp.azure.com
  2. Select Settings
  3. Under the Detection category
  4. Select Exclusion
  5. Locate the detection type and select it
  6. There you would see 3 sections for your choices on how you want to exclude it
  7. You can exclude based account name, hostname, IP addresses, subnets and etc..
  8. Key in the value and remember to save it
  9. This changes apply immediately

Recommended that you monitor 24 hours. For your information, email notification doesn’t have to be send to same tenant users, it could be external party domain but beware of your auditors.

The portal is a simple user interface, not as confusing as the Security and Protection portal.

References:

  1. https://docs.microsoft.com/en-us/defender-for-identity/configure-detection-exclusions

Azure ATP: gMSA limitation for single label domain

Good afternoon everyone, and Happy Holiday to you all. Today’s blog post is another Azure ATP, or you could say Microsoft Identity Defender or MDI for short.

As you might know that gMSA is a type of service account for Windows Server 2012 and above. For some reason it failed to establish authentication between a Windows Server 2016 and Azure ATP portal for this particular environment. This environment is running single label domain on a Windows Server 2016. It was migrate from Widows Server 2008 R2 to Windows Server 2016.

To locate the logs in the server that you installed the sensor to further identify the cause and issue,

C:\ProgramFiles\Azure Advanced Threat Protection\<sensor version> \Logs

In the server where your sensor installed, if you notice the Azure ATP services keeps stopping and starting, from the services.msc, then it means there is problem with the sensor trying to establish the connection to the Azure ATP.

There wasn’t much article found to prove that gMSA limitation with single label domain, so I go ahead and proceed a testing. I created a managed service account with no special permission included, and add the credential to the Azure ATP > Directory Service. Upon monitoring, there wasn’t any alert prompt from Azure ATP, Azure ATP alert is pretty instant when detected failure on authentication.

So the resolution was to use managed service account instead of the gMSA account for this situation. The sensor start to working well with managed service account.

Active Directory: Troubleshoot ADPREP /DOMAINPREP “Access is denied” issue

Good day, hope you guys are having a good weekend. This blog post is about active directory portion. My situation was the environment contains Windows Server 2008, and would wish to upgrade to Windows Server 2008 R2, by setting up new VMs with Windows Server 2008 R2 Operating System. The environment contain a parent domain and 2 child domains. Due to Microsoft has stop supporting pushing updates to legacy servers, the environment had to use a third-party product to support the pushing of windows update to the legacy servers and the product is also served as Anti-virus/malware.

Before you are going to prep domain and forest you have to make sure your account has the proper permissions to perform the prep.

While I was about to prep a child domain using the command prompt in elevation mode, I receive an error saying “Access is denied”, there was no log to refer to, to know about details what caused this issue. Same goes to event viewer logs.

After long research there was no resolution and the next try was to disable the third-party product and re-run the adprep command and was able to run successfully.

If you have other issues with adprep, you may refer the logs from this path “C:\Windows\Debug\adprep\”.

References:

  1. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731728(v=ws.11)

Azure ATP: How to setup a gMSA account?

Hey guys hope you all are staying indoors and cautions about your health. Today’s blog post is to understand what is gMSA account, how to create them and why does it required for setting up Azure ATP (a.k.a Microsoft Identity Defender ATP).

gMSA stands for group managed service account, below reference that you can refer to understand details about it. You only need to setup a gMSA account for Windows Server version 2012 and above, it is recommended to use gMSA account for you Azure ATP deployment if your Domain controller fall on the versions 2012 and above.

Why gMSA and not usually service account (user object)? It improves the security and automatic password management. It works similar as a managed service account functionality and with extended capabilities, such as password is being managed by your Active Directory and every 30 days a new password is assigned to this service account automatically. If you have mix of legacy domain controllers and newer version of domain controllers, you would need both type of service accounts.

Note:

  • Azure ATP directory service connection, doesn’t required a gMSA account, to be a member of domain admin
  • If your server doesn’t have the root key created, then run the Add-KdsRootKey command with following parameter “-EffectiveTime“, with value immediately or scheduled.

For this Azure ATP case, all domain controllers with sensor must have managed password permission/right on the gMSA account. Make sure your account has a domain admins right to be able to perform the following setup below;

How to setup a gMSA account?

  1. On your domain controller
  2. Open/Launch PowerShell cmdlet
  3. Type the following command
    New-ADServiceAccount -Name <ATP service account name> -DNSHostName <FQDN of 1 of your domain controller> -PrincipalsAllowedToRetrieveManagedPassword <domain controller hostname01$>,<domain controller hostname02$>
  4. Sample of the command
    New-ADServiceAccount -Name AzATPSvc -DNSHostName DC01.contoso.com -PrincipalsAllowedToRetrieveManagedPassword DC01$, DC02$
  5. Retrieve your change result command
    Get-ADServiceAccount -Identity AzATPSvc -Properties PrincipalsAllowedToRetrieveManagedPassword
  6. Testing the service account command
    Test-ADServiceAccount -Identity AzATPSvc

If your customer is highly concerns about what sort of permission this account is assigned you may run the command below;

  1. Get-ADServiceAccount -Identity AzATPSvc -Properties MemberOf

Sample image

References:

  1. https://docs.microsoft.com/en-us/defender-for-identity/prerequisites#-sensor-requirements
  2. https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_AddMemberHosts
  3. https://adsecurity.org/?p=4367