Tag: Active Directory

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: 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

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

Azure AD Connect: What to know about In-place Upgrade from version 1.0 to 2.0 ?

Hi everyone, hope you guys are having a blast weekend. Today I would like to bring to you Azure AD Connect.

In the past, the 1.0 in-place upgrade, I would have to kept a record of the “before” changes of settings, such as the organization units, and etc. This would likely need me to schedule a day to capture the settings.

Anyway, not all of the 1.0 version can support the in-place upgrade to 2.0 version, if you have an older Azure AD Connect, that do not support in-place upgrade you would need to plan a migration or transition, to the 2.0 version. It may sounds simple, but there are few things you would need to take note of, that is avoiding duplicated records sync to Office 365, and duplicated service accounts, else you will likely get more stuff to clean up in the end. Is good to plan your transition and your clean-up first.

*Note: 31st August 2022, 1.0 version will be end of life

For those who are on the supported version of 1.0, that can perform in-place upgrade to 2.0 version, here are some tips or hint you can take note of before performing the upgrade,

  1. Full backup on the server
  2. Make sure you know what are the impacts
  3. Make sure the existing service account has the required permissions based on the 2.0 prerequisites
  4. During the upgrade, the wizard will request you to re-enter the global administrator account from Office 365
  5. You do not need to keep a record of the existing organizational unit because it will automatically bring forward the settings to your 2.0, same goes with your SSO, password hash settings, or device join settings
  6. Yes, version 2.0 does support single-label domain

If you would like to know more about the prerequisites of version 2.0, feel free to refer the references below,

References:

  1. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-upgrade-previous-version
  2. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history

Active Directory: Setup Multiple Enterprise Root Certificate Authority in a Single Forest For Zero Downtime

Hey guys and girls, how are you all doing working from home? Please stay safe and keep your distance.

Today’s topic is about creating multiple root certificate in a single forest, please take note that this is not a best practice by Microsoft but it was the right solutions for my situations. There will not be errors/stopping you to proceed, if you setup multiple root certificate authority.

So basically I have this tested on my lab only I proceed into production. Whenever you aren’t confident about the solutions please always run your lab. Don’t give people heart attack. Active Directory is a sensitive being.

My situation is that we have existing Windows Server 2008 R2 and is moving to Windows Server 2019, currently there is a root certificate authority siting in Windows Server 2008 R2 and would like to transition to Windows Server 2019 without downtime. Hence, Migrating is not the right word for this situation, because Migration required downtime. Imagine people working from home unable to VPN access into the work environment. You will get the scream and shout by them, Good Luck.

For having a multiple root CA, so that at the network layer/firewall layer, the network administrator can create another certificate access for user to VPN access using either the old Root CA or new Root CA. Hence, zero downtime.

Step by Step:

  1. You have to add the roles and feature into your Windows Server 2019
  2. Once you have the role installed and the configuration setup (just follow the default configuration, please choose Enterprise Root CA)
  3. Make sure your instance naming or certificate authority name is not duplicated with your other certificate authority server name
  4. This is the result of successful setup of the certificate authority
  5. So now you got to make sure the certificate authority server has its certificate propagate on its local machine too
  6. Launch Start > Run > mmc
  7. MMC > File > Add/Remove Snap-in… > Certificates
  8. Certificates > Computer account > Local computer > Finish
  9. Certificates (Local Computer) > Expand the folder > Personal > Certificates
  10. Certificates (Local Computer) > Expand the folder > Trusted Root Certification Authorities > Certificates
  11. Because now the forest has 2 Root CA, so your trusted root CA folder would have 2 Root CA certificate
  12. To export the new root CA certificate to your network administrator, Launch your command prompt on the Root CA server > run the following command
    • certutil -ca.cert <filename>.cer
  13. To allow the other server members of the forest, please access to the server and follow step 6 to step 9, remove the old Root CA
  14. Then run a gpupdate /force command line > Reboot the server, to have the changes reflected
  15. Perform a checking whether the changes has reflected to the other server(s) after performing step 13 to 14, please access to their local computer certificate and check. Repeat step 6 to step 10.

*Note:

  1. Do not export the Root CA certificate and import to the servers, because this would beat the purpose Enterprise Root Certificate Authority
  2. If you have a larger environment it would take awhile for the change to replicate. Hence, continue the gpupdate /force until you receive the result you wanted on the server

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)