Forum Widgets
Latest Discussions
Role of End User Team after Defender for Endpoint Rollout
Our Company is using SentinelOne (S1) as AV/EDR currently. SOC team had the full access of S1 environment. We have just started the pilot of Defender for Endpoint (MDE). Now the toolset contains Intune as well. May I know what is the best way to handle the administration because End User Team has the access of Intune? How others are handling this situation?
Device control with Defender for Endpoint
Dear all, I need some help on an issue I have been experiencing with my device control policy recently. This policy was configured under attack surface reduction rules in Intune and has been working fine until recently. This policy is used to block all USB ports of corporate machines by default unless they are explicitly allowed. As already mentioned, it works perfectly by blocking all USB ports and we have the option to unblock some if needed. Now, here is the problem I am recently experiencing: We have like twenty-five branches located in different countries, and there is only one policy in Intune in place for all the countries, including the head office. If I exclude a device and allow it to be used in the head office using its serial number, it works fine, but if the same USB stick is connected to a branch office computer, it is blocked again, and there is no conditional access policy configured to warrant such behavior. I appreciate any help that will lead to solving this issue. Best regards Alieu Here are some screen shots of my policy in Intune: 1. 2. 3 4.
Incorrect Identification of Local Admin in Defender for Endpoint
Hello everyone, I am facing an issue with Microsoft Defender for Endpoint where a user is incorrectly identified as having local admin rights. In the Devices menu of the workstation in Defender, the user is tagged as a local admin. This is also confirmed when searching in Advanced Hunting with the following query: DeviceLogonEvents | where LogonType == "Interactive" and IsLocalAdmin == true and AdditionalFields contains "\"IsLocalLogon\":true" However, after checking the user's workstation, I found that the user is not part of the local or domain administrator group. The user cannot perform privilege escalation. It is worth noting that the user has another domain account with admin rights. Additionally, the user's workstation has been AAD joined with his account, so he may have had admin rights on the computer at one time, but not anymore. Has anyone encountered a similar issue or have any suggestions on how to resolve this? Thank you!
Unable to enable tamper protection using MDM
I’m working on implementing Tamper Protection for Windows devices using a custom MDM solution with the Defender CSP, but I’ve run into some issues and could use your help. A couple of questions: What specific data needs to be sent with the Defender CSP to enable or disable Tamper Protection? I’ve tried using the Defender, but I’m not sure about the correct value to set. Are there any permissions or enforcement scope settings that need to be adjusted for a custom MDM to manage Tamper Protection? I tested Intune on some devices, and Tamper Protection couldn’t be enabled there either. Could there be a specific hierarchy or prerequisite settings in the Microsoft Defender for Endpoint portal that I’m missing? If anyone has experience with this or has any insights, I’d really appreciate the help. Thanks in advance!
Baseline Assesment Auditing Status Unknown
Hi I am working with Microsoft Defender Vulnerability Management with the feature called Baseline Assessment. I created a Baseline Profile with CIS compliant configurations and It was applied to 10 devices for testing. Checking the compliant status I can observe that the Auditing Configurations are showed as Unknow. Someone has experimented this situation? Any recomendation? Thanks for any comments.MDE On boarded Linux Devices not visible in Intune or Entra ID
We recently started on boarding our Linux Servers and endpoints to MDE, and so far we have onboarded a couple of them through manual deployment with installer script. We have also enabled Endpoint Security Management to scope to Linux devices and have enabled the same in Intune as well so MDE can act as sensor to apply policies. It's been over a couple of days but we are not seeing those devices in Intune or Entra as Microsoft's documentation states. For context, the versions are 20.04, and 22.04. Even though the health state of sensor is healthy, and mdatp is not in passive mode, we are still not seeing the devices in either Intune or Entra. Any help would be appreciated since we are pressed down to resolve this as quickly as possible.
ASR Device Control policy update registry conflict
Hi, I'm working with a customer who's rolling out DfE Device Control and we have come across some strange behaviour when changes to the groups and rules are made from the Intune ASR page. Reviewing the PolicyGroups and PolicyRules REG_SZ keys under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager shows that changes are appended to both keys, not replaced, creating a XML stream of legacy policies and groups. Is this expected behaviour? This creates new policy GUIDs each update which isn't obvious to know if the new policy is active or not and from testing does lead to long delays in devices becoming denied/allowed despite the changes pulled down to these keys. Is there some way to determine the active policy GUID? The customer will need to semi-frequently add new USB drives to the allow group/policy which from testing seems to work more reliably if you delete the 2 registry keys, run a sync, and try access the drive than waiting for it to append the updated group and policy XML code-block. Are changes to device groups via Intune meant to automatically update on the machines and follow policy rules? NB: They are hybrid machines using co-management with only Endpoint Protection workload moved over so far. Machines also onboarded into Defender for Endpoint. Thanks :)
Device Control blocking Network Print Jobs???
Suddenly I'm seeing my InTune test group getting print failures to network printers with: "The current print job was rejected due to Device Control Print Restrictions. Rejection Reason: Print blocked by Defender rule..." (Event IDs 372 and 871) I have 1 Device Control policy that allows our Encrypted USB drives (no printer option checked) and blocks all other USB drives (no printer option checked). I have no Defender rules that explicitly block print jobs... I've edited local group policy to disable Point and Print Restrictions I've edited local group policy to disable Enable Device Control Print Restrictions I've created a custom InTune configuration policy to disable both of the above, yet this issue persists... Why is Device Control suddenly blocking printing to network printers? I've been troubleshooting this for over a week and it's completely maddening! Has anyone else run into this? It's preventing us from rolling out Defender org-wide.
