Tag: Domain Controller

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.

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