Microsoft has published an article at https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites#harden-your-azure-ad-connect-server to harden the Azure AD Connect server. The fifth bullet point recommends restricting NTLM on the AADConnect Server, which links to Microsoft’s documentation on restricting outgoing NTLM traffic to remote servers.
After enabling NTLM auditing, I am seeing event ID 8001 for 2 connections that would be blocked if outgoing NTLM traffic were set to Deny All as recommended by Microsoft. The client process is C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe and the target server is ldap/DomainDnsZones.<fqdn> and ldap/ForestDnsZones. .<fqdn>. We have observed this with both v1.x and v2.x of the AAD Connect software.
My questions:
I contacted MS and the support engineer indicated that I should just enable Deny All. However the engineer was unable to provide any documentation showing that it’s normal for these 2 outgoing NTLM connections to exist, nor could show any documentation indicating that denying these 2 connections would not cause any problems (the engineer didn’t suggest adding exceptions for these 2 connections either). So I wanted to ask the community to see if others have any experience with this.
Thanks,
-Aakash Shah
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/BY3PR06MB8114CDD0D5E8EBC5A69ACAD2F2CF9%40BY3PR06MB8114.namprd06.prod.outlook.com.
I intend to test this in my lab this week.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce6itd3NEOPSX55Nh9psTQXD1GdXVzoY0qP-0XeRhXvHqQ%40mail.gmail.com.
| Network security: Restrict NTLM: Audit Incoming NTLM Traffic | Enable auditing for all accounts |
| Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers | Audit all |
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce715jj39_X3Khf5JGWhExF7RXLEdaeX4CKKTjrymNg%3DjA%40mail.gmail.com.
Charlie Sullivan
Principal Windows Systems Administrator
Boston College
197 Foster St. Room 367
Brighton, MA 02135
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce715jj39_X3Khf5JGWhExF7RXLEdaeX4CKKTjrymNg%3DjA%40mail.gmail.com.
Charles, Michael: Thanks for your help in checking on this!
Charles:
Yes, I have these auditing options enabled. I also have this enabled on the AAD Sync Server, but I suspect that won’t make a difference with the results:
Network security: Restrict NTLM: Audit NTLM authentication in this domain: Enable all
We do run a delta sync periodically via a scheduled task, although the timestamps of the scheduled task don’t correspond with the NTLM events I’m seeing so I’m not sure that’s related either.
I’ll also wait to see Michael’s results to see if they match your results. If they do, then that would imply there is something unique in our environment causing this outbound NTLM connection.
Thanks,
-Aakash Shah
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzz%3DrGm5-F59xGR2xyXFn7xr6M0v1%3D9gpQgWU45ccHutGPw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/BY3PR06MB811433E14E8021051A5314A7F2D49%40BY3PR06MB8114.namprd06.prod.outlook.com.
Hello! Just a friendly check in to see if anyone had a chance to see if they are seeing similar NTLM audit events in their environment?
Thanks!
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzznCh2WiyJ%2BV8eD4On%3DcB2oCYr09xqBaMWu_RWwwEo7szA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0P221MB083401BF476E96A54C20B206F2AA9%40SJ0P221MB0834.NAMP221.PROD.OUTLOOK.COM.
Thanks – much appreciated!
-Aakash Shah
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce7C_f2ACw5-5qQnzRg-v%3Dtnpm%3DRGbvuT%2BcPUNuw3vUfdQ%40mail.gmail.com.
We have not just been auditing, but blocking outgoing NTLM from the AAD Sync server and we have had no problems.
In the NTLM/Operational log I see Event ID 4001 blocking a few outbound connections, but not the AAD Sync process. Let me know if there is something else I can check.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0P221MB083472E5F5D8880FDF5C5AFBF2AB9%40SJ0P221MB0834.NAMP221.PROD.OUTLOOK.COM.
Thanks for the reply Charles!
It sounds like we have something unique in our environment that is triggering this.
I’ll wait to see if Kurt or anyone else shows these events. If not, I’ll dig further with Microsoft.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/5c4b1071cbc487b5da977b9eab0f9922%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0P221MB083472E5F5D8880FDF5C5AFBF2AB9%40SJ0P221MB0834.NAMP221.PROD.OUTLOOK.COM.
After you get a chance to enable NTLM auditing, I was curious to know if you see any outbound NTLM communication from the AAD Connect to the DCs (the log shows the target servers as “ldap/DomainDnsZones.<fqdn>” and “ldap/ForestDnsZones.<fqdn>”) from the client process “C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe”.
I am hoping we are not unique in having this communication in our environment. If anyone is getting this error and has blocked NTLM on their AAD Connect server, that will help confirm that no problems arise when blocking NTLM from their AAD Connect server.
Thanks!
-Aakash Shah
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce6T8PNdr7nJZ7fNU_OE1o22B%3Da9VOZ8ZnEZ2VYmOKbvTQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0P221MB0834DABF1FF77CE9321B76D3F2AD9%40SJ0P221MB0834.NAMP221.PROD.OUTLOOK.COM.
Thanks for the information! So it definitely seems like there is something unique in our environment that is causing these calls.
Good call on the Kerberos issue. The referenced account in the event entry hasn’t been explicitly denied to only use Kerberos (it’s not in the Protected Users group), and I’m not showing any authentication errors in the Security not “Authentication” folder logs on the DCs either.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzzna6uy6GKpN8-YmycSn%2BbdMRsgG1bDbL2v0krEsKUQCCQ%40mail.gmail.com.