Active Directory: Logon script not working on user device when its inside (FQDN domain name\NETLOGON folder)

Hi everyone, hope you guys are taking care of yourself. Meanwhile, I’m not really in a great mood today, as there were some conflicts at work, well that’s what happen when you got to deal with humans right? Pretty normal, I guess.

Anyway, I still wanted to write a post about the experience I had today, and it did take me sometime to realized that there was something in between the user’s laptops/desktop and Active Directory that was causing the script unable to ran. Anyway, the environment did not have anyone who is technical but is still not easy to troubleshoot a problem when non-technical users only give you less than an hour to find out what is the problem. Luckily, I did meet someone who knows well enough the infrastructure of the environment….

I understand that the politics are so strong between parent companies and branches, but we all have a life to move on, so politics are just excuses to delay tasks or projects to complete. We are all being paid to do tasks, not to spend 8 working hours to gossip and drill down other’s conflicts.

So, enough of chit chat corporate news.

I realized that deploying logon batch file script via Group Policy Object wasn’t working (The script is located the SYSLOG\LOGON folder and FQDN domain name\NETLOGON folder), same goes with AD’s user object’s profile > Logon Script (The batch script is located in the FQDN domain name\NETLOGON folder) and using the Driver mapping feature inside GPO too.

I thought at first it could be my scripting issue but somehow double clicking the batch file script directly onto the user’s device it works. So, I started to think what could be in between the user’s device and active directory. Is it firewall? Is it Microsoft Defender? After clicking the user’s device network settings and realized they have Zscaler product installed.

Zscaler Proxy, where there were policy preventing any remote script running on user’s device. This logon script was to map share drive automatically on the user’s device. During their first practice of how to map drive was to manually map them on their own.

Well, Zscaler was beyond my scope. I don’t have the rights to request the environment to whitelist a script. I can only find out and advise them whether they still want it.

In the end, they told me to just leave the script as a backup for the user.

If you try to search for an answer, there won’t have any on the internet. It was all based on your troubleshooting skillset.

CheckPoint Firewall & Microsoft Sentinel: Troubleshoot Data Connector Disconnected

Hi everyone, hope you guys are staying safe and keep yourself healthy. Would like to share you another troubleshooting experience of mine.

I noticed that the CheckPoint connection status was disconnected from the data connector in Microsoft Sentinel portal. Hence, I put on my thinking hat to troubleshoot this issue. It was tricky though but luckily the troubleshooting command manage to give me some hints, what was causing this disconnection.

My findings were:

  1. Syslog connector still exist
  2. CheckPoint Firewall forwarder connector was not found

I proceed my next action on troubleshooting it,

  1. I ran the troubleshooting command from the Microsoft Sentinel data connector for CheckPoint in the Syslog connector VM (Centos)
  2. It shows me that I need to change my Syslog’s SELinux mode to permissive
  3. To modify the SELinux mode run the following command, this is where the mode located, is inside the directory/file below “/etc/selinux/config”:
    • vi /etc/selinux/config
  4. Change the SELINUX=enforce to SELINUX=permissive
  5. Click the button “ESC” on your keyboard
  6. Type the command to save and quit: wq!
  7. Click the button “ENTER” on your keyboard
  8. Restart the VM by typing the command sudo reboot

First issue completed but there was a second issue prompt, it mentions that it would require me to disable auto-sync to prevent duplicate records sync to Microsoft Sentinel. Hence, the next action is below,

  1. Type the following command sudo su omsagent -c 'python2 /opt/microsoft/omsconfig/Sripts/OMS_MetaConfigHelper.py --disable'
  2. Restart the VM by typing the command sudo reboot

You might not like my idea of rebooting the Syslog connector VM, no worries you can proceed to follow just by restarting the service instead.

Noted:

Kindly note that the command above may not suit your situation because different Linux Operating System has their own command language. Anyway, the concept is pretty common sense.

References:

  1. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/changing-selinux-states-and-modes_using-selinux
  2. https://learn.microsoft.com/en-us/azure/sentinel/troubleshooting-cef-syslog?tabs=cef

Windows Server Update Services: Troubleshoot the Tools folder is missing

Hi everyone. Hope you guys did enjoy your weekend. I would like to bring to you on troubleshooting some missing folders or its contents in Windows Server Update Services (WSUS).

Usually, you would face such situation is when you are in the progress of reinstall the WSUS, and you notice that the “Tools” folder is missing. This tools folder you would find it at C:\Program Files\UpdateServices. What’s inside that folder is the WSUS execution file, wsusutil.exe. Without this file you can run any WSUS services.

There might be more problems that you would face during reinstalling of WSUS. Above is only one of the problem that you may face.

One of the symptoms to know whether the Tools folder is missing is when you tried to run the Post-Install of the WSUS, you will end up with error, unable to proceed the Post-Install.

Solution

  1. On the WSUS server > Launch Command Prompt as Administrator
  2. Type the following command fsc /scannow
  3. This command is used to scan the System Files and recover the missing files
  4. Then run a reboot on the server
  5. Check back the folder existence, it should be recovered

References:
1. https://social.technet.microsoft.com/Forums/windowsserver/en-US/509b5daf-6246-4f14-9ebd-c88c8967dd34/wsus-2012-tools-directory-missing

Active Directory: Why You Should Not Use Default Domain Policy as your Password Management?

Hi fellow friends! Hope you guys are healthy and staying safe. Today’s topic is about Active Directory on-premises.

Why are there default domain policy and default domain controllers’ policy? Is it for me to use it? Can I alter it?

There are still people recommend using default policies. However, what will happen afterwards no one care to know about it.

“What’s the implications?”

“Why can’t I use default policies?”

I do faced challenges when people are telling me “I have been using a separate group policy to manage password and it works.”. To me just saying is just prove nothing. To prove your point, is using Lab environment.

Using group policy to manage different password is not supported, because whatever policy that you created under the child layer/level it will be overwritten by the default policies. Hence, no point.

Based on Microsoft recommendation, any default policy coming from Active Directory, should not be modify or you can keep the modification to minimum, such as enable more audit features. Active Directory is sensitive. Anything that is default remains default.

I would recommend using the Fine-Grained Password Policy and/or the LAPS for password management. LAPS has been around for quite some time and Fine-Grained Password too but there are still people not aware about this feature from Active Directory.

Fine-Grained Password policy is great, when you have multiple groups of people/administrators you would want to control their password requirements. However, each policy you created in the Fine-Grained Password, it follows based on the priority level, you would need to take note on it. Keep it minimum on the policies.

Not all domain/forest functional levels support this feature of fine-grained password policy. You can refer back to the articles I have in here at the references, below.

References:

  1. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements–level-100-
  2. https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policy

Microsoft Exchange: Unable to export Exchange attributes (MxExchArchiveGUID) from Active Directory after shut down

Hi everyone, has been awhile, due to Chinese New Year. Anyway, is good to be back!

Situation for this issue, is that you have shut down the Microsoft Exchange server and you are in the process of rebranding (Example, changing UPN, email address or Logon), but you encounter that some users having the issue to open their online archiving. Hence, you would like to export their MsExchArchiveGUID from Active Directory and perform a comparison with the Cloud’s Archive GUID instead of turning on the Exchange Server (You do not want to make your effort redundant). However, no matter how you try with this command on your Active Directory, Get-ADUser -Filter * -Properties * | Export-csv filename.csv and you still can’t get them to show up on your csv file.

This article would require review of the reference links.

Don’t panic! All you got to do is:

  1. Prepare a test PC (OS version of Windows 10 at least) or a server (Non-critical ones, OS version of Windows Server 2012 R2) that is a domain joined
    • I would recommend using a test PC, to avoid the hassle of checking whether the Windows Server is critical or notor the hassle of stuck at Exchange Server Wizard (Role Selections)
  2. Prepare an account that has a domain admin rights.
  3. Make sure you know what your Exchange Server’s version (Example, CU 2013, CU 2010, CU 2016, or CU 2019).
    • If you don’t remember you can always relocate the Exchange Server’s object from your AD. Else, you have to guess.
  4. Logon the PC with the account that has domain admin rights > Install the RSAT tool onto the PC
    • Recommended RSAT tools are: Active Directory Domain Services and Lightweight Directory Services Tools, and Server Manager
  5. Install IIS 6 Metabase Compatibility and IIS 6 Management Console
  6. Reboot the PC
  7. Relogin to the PC with the account that you had logon too, go to browser and search for your Exchange Server CU version and then download the package
  8. Export/eject the .iso file, run the Setup.exe
  9. Choose the option of not to allow windows update > Next
  10. Agree the license agreement > Next
  11. On Recommended setting page > Choose recommended or not.
  12. On the Server role Selection > Choose only Management tools > Next
  13. Location of the installation you can remain with the default
  14. On Checking the prerequisites page, if you faced any of these errors just follow the instructions on how to resolve them or Google Search how to do it based on your PC’s OS version.
  15. Once you have successfully downloaded the exchange management tool you can start to export your msExchArchiveGUID
  16. Once finish remember to revert you configuration to the PC

References:

  1. https://learn.microsoft.com/en-us/exchange/install-exchange-2013-using-the-setup-wizard-exchange-2013-help
  2. https://learn.microsoft.com/en-us/exchange/iis-6-compatibility-components-not-installed-longhorniis6mgmtconsolenotinstalled-exchange-2013-help
  3. https://learn.microsoft.com/en-us/powershell/exchange/filter-properties?view=exchange-ps#archiveguid

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)

References:

  1. https://learn.microsoft.com/en-us/defender-for-identity/configure-windows-event-collection#event-id-8004

Microsoft Purview: Things to know when you are using Name Entities as Data Classification in Data Loss Protection

Good morning, and I would like to wish my fellow Indian friends a Happy Deepavali and hope you enjoy your long holiday with families or friends!

Let’s begin with our topic of today!

I was not really expecting that this would be an experience that I would never forget.

Attention Require

Before you would want to recommend name entities classification, there are few things you should take note from Microsoft article.

  1. Policy tip does not support name entities on Office 365 apps (64 bits and 32 bits)
  2. If you created a DLP rule containing a name entity and credit card as your condition and enable policy tip. Hence, even if your content contains credit card information only, the policy tip on your office 365 apps would not show up too.
  3. For further list of what does the name entities does not support, feel free to review the following references.

Suggestions

I would suggest that you either acknowledge this and move on with deploying DLP as silently monitoring at the backend or proceed to enforce and send with notification instead. Best to enforce it.

If you would still want your policy tip to work for non-name entities than you would have to create an extra rule to manage. Still keep the DLP policy as minimal as possible based on the locations type.

I would suggest that to perform these in your lab environment, if you are new to name entities. Hence, you would know that matching confidence level and what was able to cover in its matching capability.

Microsoft Support would likely request you to perform removal of the PolicyNudges Key from Registry Editor or Run the SARA application as resolution. However, this does not work.

References:

  1. https://learn.microsoft.com/en-us/microsoft-365/compliance/named-entities-use?view=o365-worldwide

Active Directory and DNS: Why you should not practice adding 8.8.8.8 in DNS forwarder?

Hi everyone and hope you are doing great today. A new day is a new start.

If you are the type of engineer that treat every DNS feature as it must add 8.8.8.8 or filling the DNS forwarder with values, then you must having trouble in understanding active directory and its DNS functionality.

Why mistakes happen?

When you are in a rush to rectify connectivity to the internet and the only idea is to point to 8.8.8.8 as the DNS. However, amending this into your DNS as your practice would impact the connectivity by an additional delay in DNS resolution and potentially adding a point of failure.

How DNS resolution works actually?

These are the basic order of resolution attempts. The first to reply wins either it’s right or wrong.

First phase: Local Windows Host File

Second phase: Computer’s DNS Server list

Third phase: Internal DNS Server

Fourth phase: Designated Conditional Forwarders

Fifth phase: DNS forwarders

Sixth phase: Root hints

What are the impacts?

Host file is static. It should only be used for troubleshooting and then immediately set back to it’s default after resolving the issue via internal DNS Servers.

If your DNS is only pointing to 8.8.8.8, it will reach out externally for DNS resolution. This means it will give you internet access but it will not resolve local DNS. Thus, will prevent your devices from communicating to Active Directory and devices won’t be able to grab policies, logins will be really slow and would cause intermittency with the domain.

Doing this would allow the local DNS queries will broadcasting your internal request to the internet. However, this is not recommended as its violating of your security policies.

DNS forwarders that points to 8.8.8.8 only are using your ISP connection to hop to 8.8.8.8 when resolving DNS. You have a local DNS resolution much closer that will speed up requests if used instead.

Moreover, if your DNS is set to 8.8.8.8, DNS failures may seem to be an ISP outage when your ISP connection if fine. If there is a failover rules set in place that are NOT using your ISP’s DNS, your system may failover when there is not an outage.

If you disabled root hints, one external DNS provider outage can stop external DNS resolution at your business.

Your Windows firewall internally would see you are on public network, which can cause it to start blocking network traffic. When you have a domain controller in your environment with its primary or secondary DNS pointing to an external address like 8.8.8.8, it can cause the same as well. Checking and unchecking IPv6 is a temporarily fix the public error, but it will continue happening until you remove 8.8.8.8.

It’s recommended that any domain controller/DNS servers local network interface should always point to another domain controller/DNS interface then itself, never to an external IP.

DNS Forwarders should be configured in the DNS management console to point to external DNS servers of your ISP. Doing this should resolve external DNS resolution.

References:

  1. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings
  2. https://www.mirazon.com/stop-using-8-8-8-8-for-your-production-network/#:~:text=That%20is%20not%20recommended%20and,connection%20to%20hop%20to%208.8

Active Directory and Microsoft Defender for Identity: Defender for Identity agent failed to communicate with domain controller

Hi guys hope you guys are having a nice day today. Today I would like to bring to you about an experience that I had met involving the defender for identity and domain controller.

The problem was the defender for identity stop working all of the sudden and same goes to the group policy. This environment has more than 1 domain controllers running and only 1 of them having issue. There was no one to keep track of what was being done previously.

There was no proper error code to be found in the event logs, on the affected domain controller mentioning what was the reason. There was list of Kerberos error code and intermittent sync on the DNS, DFS replication and directory sync.

Hence, I have collected the event logs on the affected domain controller and the defender for identify logs from C:\Program Files\Azure Advanced Threat Protection Sensor\version number\Logs. Based on my findings, that the affect domain controller’s computer object was not in the default domain controller organizational unit.

These was what in the defender for identity logs shows:

A task was canceled. Error DirectoryServicesClient Microsoft.Tri.Infrastructure.ExtendedException: Failed to communicate with configured domain controllers

Warn GroupManagedServiceAccountImpersonationHelperGetGroupManagedServiceAccountAccessTokenAsync started. Error Service Controller Extension ChangeServiceStatus failed to change service status [name=AATPSensor status=Running Exception=System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed. at System.ServiceProcess.ServiceController. WaitForStatus(ServiceControllerStatus desiredStatus,TimeSpam timeout]

Resolution

  1. Schedule a downtime if required
  2. Analyze the affected domain controller’s computer object location
  3. Move the affected domain controller into the default domain controller Organizational Unit
  4. On impacted domain controller, run the command sc triggerinfo kdssvc start/networkon.  By doing this, we are changing the trigger for the Microsoft Key Distribution Service (KdsSvc) to start the service as soon as the network is available
  5. Then restart the affected domain controller

References

  1. https://docs.microsoft.com/en-us/defender-for-identity/troubleshooting-using-logs

Azure AD Connect: Reminder All version 1.x is Retiring this August, 2022

Hi fellow friends, hope you guys are having a good day today, everyday is a brand new day.

Today’s article here is to remind you that the Azure AD Connect all version 1 will be expiring soon, on 31st August 2022, this year this month.

What happen if you don’t upgrade before the due date?

Basically you will face service disruption such as accounts, computers objects and passwords will be affected.

Accounts/User objects:
– New users created in Active Directory will no longer synchronized to Microsoft 365 cloud

– New values added into the accounts/user will no longer reflecting the updates/changes into your Microsoft 365 cloud

– Basically any changes you make towards the accounts/user that you would like to sync to Microsoft 365 would not allowed

Computer objects:

– If your environment has Microsoft Intune or Hybrid join devices then you will have issue onboarding new devices to Microsoft Intune

Passwords:

– If your environment allow users to reset their own password from Microsoft 365 and synchronized back the new password to the Active directory would not be not allowed

– This is affecting the environment that has password writeback feature enabled in the Azure AD Connect

Any concerns should I take in for the current configuration before upgrading?

  1. Remember your Microsoft 365 global administrator credential, because you are require to re-establish the connection when you are performing an upgrade of the Azure AD Connect
  2. Make sure your server’s storage, Operating System and RAM size is still following the best practice
  3. Make sure you are following the new version of Azure AD Connects prerequisite

References:

  1. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history#retiring-azure-ad-connect-1x-versions