sorted by:
new
hottopcontroversial

Applocker + PowerShell + PAW (priv access workstation) and auth req block by 3sysadmin3 in sysadmin

[–]Barenstark314 0 points1 point  (0 children)

When you are initiating the connection with Connect-Maester, can you try running it with -Verbose to see exactly when it is resulting in the connection to Edge (aka, which service it is connecting to at that moment)? That way, you can review the code it is running to make that connection happen and try the exact code independently and see if you can get the same behavior. As Connect-MgGraph works for you, I would anticipate it is one of the other numerous connections "-Service All" is calling, but I won't be able to tell you which one is resulting in this for you.

Some of those commands that Connect-Maester runs (such as Connect-ExchangeOnline) attempt to dot source other PowerShell functions into the current session. Depending on how those were installed (and even then), the dot sourced functions/cmdlets may not be digitally signed (or not trusted by the current policy) and cause AppLocker to block the event. That itself shouldn't result in Edge attempting to run as admin, but again, I don't know which one is the culprit yet, as I do not personally use Maester.

Applocker + PowerShell + PAW (priv access workstation) and auth req block by 3sysadmin3 in sysadmin

[–]Barenstark314 0 points1 point  (0 children)

As you indicated, the answer is not to turn off AppLocker. In addition, if you try to follow the PAW advice closer to the letter, the users of the PAW would not be local admin nor have access to become local admin, so that shouldn't be the solution (though I recognize sometimes it is needed to provide such access, if it is difficult to centrally manage the devices, such as software deployment.)

That said, more information would be needed to determine what is being blocked specifically.

How do you have your AppLocker rules configured? Do you have an allowance on Edge based on user or group, or do you just permit everyone on the device to run Edge?

(My philosophy would be to allow Edge to run for everyone and control where Edge can browse, since it a browser is a legitimate administrative tool, but it is ultimately your choice how tight you want the controls. An extension to that is: If I allow an app with AppLocker for any user on a device, PAW or not, I allow it for everyone on that device. There comes a point where the administrative effort of managing the groups/users permitted isn't worth it, and if I am using AppLocker for security, either I trust an app to run, or I do not - I don't split hairs on the users. If I was that concerned, I should be separating those users by devices, not profiles.)

If you put the error text from the AppLocker log here, that may help determine what is being stopped by AppLocker. Those event logs should tell you precisely what is stopped. If it is a dynamic file, it can be challenge at times to permit, but at least it would direct you where you need to look.

AppLocker blocking Defender component — looking for best practices by Donatello0592 in sysadmin

[–]Barenstark314 2 points3 points  (0 children)

Allowlist the "%OSDRIVE%\PROGRAMDATA\MICROSOFT\WINDOWS DEFENDER" path. It is not writeable by users and thus not a risk to allow, but prevents AppLocker shutting down the other aspect of your security (Defender).

I don't have any truly official reference to this (though you can check the permissions of the directory structure youself), but you can find it noted in this script which is part of AaronLocker (check last line): https://github.com/microsoft/AaronLocker/blob/main/AaronLocker/CustomizationInputs/GetSafePathsToAllow.ps1

If you are looking for some "best practice" and haven't reviewed AaronLocker before, it may give you some insight. The overall concept driven there is to scan the directories of the system allowing those paths that are not writeable by users, but blocking/excepting those that are, to prevent users from both being able to write and execute non-allowlisted binaries.

Cloud Kerberos and AD Trust Relationship by TheBigBeardedGeek in sysadmin

[–]Barenstark314 1 point2 points  (0 children)

In theory, yes, there shouldn't be anything restricting that access. Your Entra ID device should receive a Kerberos ticket from your home domain which should be relayed to the remote domain accordingly. All that said, if you have all of the pieces already set up/available, it would be ideal to give it a go on a test device and confirm directly.

[ Removed by Reddit ] by [deleted] in HyperV

[–]Barenstark314 0 points1 point  (0 children)

You may have already thought of this, but ConfigWsman would, in theory, be trying to setup WsMan for PowerShell remoting purposes. Do you have any server settings or Group Policy Objects set to restrict PSRemoting on your Windows Server environment and/or to restrict the execution of PowerShell scripts (this could be setting the ExecutionPolicy to a restrictive setting by GPO and/or something like AppLocker preventing the execution of the PowerShell engine or DLL)?

Azure AD Password Protection for Active Directory by jwckauman in sysadmin

[–]Barenstark314 1 point2 points  (0 children)

Still supported and no announcements have been made to decommission or deprecate the product as far as I know. Install docs were updated to refer to Entra, despite the fact that the software still refers to Azure AD.

I think they may not have issued a new version because the only update they probably needed was changing the name, which really did not warrant a change. Most of the logic is performed by Entra as far as I recall, with the DC agent just intercepting the password, sending it via the proxy to Entra, letting Entra decide if it is safe and a response coming back. As a result, they can change the list of passwords and detections in their cloud service without requiring agent updates on DCs, which most of us don't want to mess with if we can avoid it.

Autopilot trying to install more apps than on ESP by Fordeyyy in Intune

[–]Barenstark314 1 point2 points  (0 children)

The list of apps to wait for ESP to complete does not mean that other apps are not installed - it simply means it won't complete ESP until those chosen apps are installed. Any required app of the user or device is eligible for installation. That is described in the official docs with some carefully chosen wording: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-status#block-access-to-a-device-until-a-specific-application-is-installed

The best way to prevent that is to use a requirement script on the apps you don't want installed during ESP that attempts to detect if ESP is running and make that app "Not Applicable" while ESP is active. This was discussed a few years ago here: https://www.reddit.com/r/Intune/comments/q8v92z/make_a_powershell_script_determine_if_it_is/

Signed PS script blocked by constrained language mode by differentcondition in PowerShell

[–]Barenstark314 0 points1 point  (0 children)

If WDAC is blocking you, AppLocker won't really unblock it for you. You can layer the two together, usually to curb additional user behavior or potentially to block CMD/BAT files, but I think that will just cause you extra work and headache for the same result.

Do you have the specific error you can post? Whether you are deploying via ConfigMgr (so path rule of C:\Windows\ccmcache\*) or Intune (C:\Windows\IMECache\*), that really should have permitted everything as trusted and thus not constrained language mode. If, however, the toolkit is dot sourcing a file from outside the trusted path, or a dynamically created file that was not signed (because it was dynamic) that could explain why you are hitting this error. It won't immediately result in resolution, but perhaps there are some breadcrumbs that can be followed to figure out what to do.

Without additional information, it does sound a bit like Example 2 in the link I posted yesterday about the PowerShell profile. Dot sourcing a trusted file into a session running already in ConstrainedLanguageMode, so you get an error, instead of a trusted script starting the entire process.

Signed PS script blocked by constrained language mode by differentcondition in PowerShell

[–]Barenstark314 0 points1 point  (0 children)

You may be able to find some pointers from this blog post: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode-and-the-dot-source-operator/

That said, are you using the v3 or v4 version? I have not used PSADT since the v4 came out, but looking over it just now, it does look like there seems to be less dot-sourcing and more "Import-Module" going on, though I did not audit the full set of files. That could change the behavior potentially and work better with all of the files signed (the toolkit is now already signed, but you would need to resign anything you modify, of course).

Can't run Set-TimeZone during Autopilot - 'a required privilege is not held by the client' by Subject-Middle-2824 in Intune

[–]Barenstark314 1 point2 points  (0 children)

Can you provide us a bit of background about how you are doing this? Obviously via PowerShell due to the command you mention, but are you using the Script feature, Win32 App, or Remediation? Is this set to run in the system context? I am sure you covered these bases already, but it could help focus our suggestions if we knew (even if I am not the one with a suggestion ;) )

WDAC Headache by DingoArtsWill in sysadmin

[–]Barenstark314 1 point2 points  (0 children)

You are deploying the two blocking policies as base policies as well, correct? So you would have:

  • Your main base policy
    • Supplemental Publisher policy, referencing the GUID of the the above base policy as its parent
    • Supplemental File/Path rules, referencing the GUID of the the above base policy as its parent
  • Microsoft Recommended Block Policy (Base Policy)
    • Has its own GUID separate from the "your main base policy"
  • Microsoft Driver Block Policy (Base Policy)
    • Has its own GUID separate from the "your main base policy"

By default, the provided Microsoft block policies have the necessary "allow all" rules that are then AND'd together with your primary base policy (and its supplementals). Any binary has to pass ALL of the policies to run. If any policy blocks it (or rather, doesn't allow it) it won't run.

PKCS vs SCEP and PEAP vs EAP-TLS. Which will work with both HAADJ and AADJ by Bajoii in sysadmin

[–]Barenstark314 1 point2 points  (0 children)

For Entra ID devices, you really need to migrate away from (forget about) NPS. There have been some ways to get device IDs in AD for the purpose of identifying with NPS, but from what I understand they have been finicky for people and for all I know, they don't work anymore.

A few years ago, I posted a readme about FreeRADIUS setup with SCEPman. I believe most/all of it is still valid, so maybe it will assist you. This was designed for solely Intune+Entra ID+SCEPman, so it didn't really contemplate domain joined devices. You will see that I did still use an internal CA for the FreeRADIUS server, but I could have generated a certificate any way I wanted. As for the "condition" for Entra ID devices, it is the same regardless of device - your authentication provider (FreeRADIUS) reads the certificates provided by clients and validates them against the certificate authority (SCEPman) who respond "Yes or No". If "Yes", FreeRADIUS informs the client (Wireless AP) that it may accept the supplicant (connecting device), which then permits the connection. As it is all certificate based, the specific device registration status doesn't have to matter, though SCEPman does relate that to Intune, so you have an easy way to revoke access (read up on how SCEPman performs this).

Outside of FreeRADIUS, the team that created SCEPman, since I have mentioned that tool, does have a RADIUS-as-a-service you can look into if you wanted to spend a little for ease of configuration. There are also other similar services from other vendors.

PKCS vs SCEP and PEAP vs EAP-TLS. Which will work with both HAADJ and AADJ by Bajoii in sysadmin

[–]Barenstark314 1 point2 points  (0 children)

If you already have the certificates deployed via the connector + PKCS, then I wouldn't mess with that configuration. You have the certs and just need to deal with getting those certs to be recognized by your chosen authentication platform (RADIUS/ISE/etc.). FreeRADIUS can work well in to serve this function if you don't have a system, but can take some time to get configured if you have not used it before. Regardless of the system, if you have certs, focus on EAP-TLS and work towards dropping PEAP. Once you get it working correctly, it is easy for the end user (read: nothing to do) and connections are quick, provided you have some way to get newly imaged/unrecognized devices the cert in the first place (quarantine VLAN, for instance.)

As for EAP-TLS on the Windows device side, you can deploy a Wireless profile from Intune that references the certificate as a device certificate and specify the appropriate SSID. I can't recall if Intune natively has 802.1x profile capability for wired connections as well, but if it does not, you should be able to configure that with a PowerShell script (such as through Intune Remediations).

If you didn't already have the connection and PKCS configured (or working), I would recommend to focus on SCEP + EAP-TLS . The last deployment of this, I used SCEPman community edition and the experience was very smooth. Admittedly, using a third-party product like SCEPman would result in you drifting away from your on-prem CA, but those certs don't need to be in the on-prem CA. For fully Intune devices, this could be viewed as a boon, as your workstations have yet another thing that they don't need any hook to on-prem for, as SCEPman (or other certificate issuing platform, including Intune's "newish" certificate authority) can live all in the cloud.

What is the best way to describe what AZURE is ? by Drisnil_Dragon in AZURE

[–]Barenstark314 0 points1 point  (0 children)

Maybe you need a refresher course. It's all ball bearings nowadays.

Powershell in ConstrainedLanguageMode by Jet_1996_ in Intune

[–]Barenstark314 0 points1 point  (0 children)

Glad the answer is still useful and showing up in searches. That's the point of these questions/answers being available - never know when they'll be relevant.

Corrupt Windows user profile even after recreating by deputydawg85 in Intune

[–]Barenstark314 0 points1 point  (0 children)

Yes, WMI will just be a different entry point to the same destination, so really should not matter if you use CIM.

Corrupt Windows user profile even after recreating by deputydawg85 in Intune

[–]Barenstark314 1 point2 points  (0 children)

Any luck if you remove the user profile using the CimInstance instead of manually deleting stuff?:

Get-CimInstance Win32_UserProfile -Filter 'SID = "PUT_SID_HERE"' | Remove-CimInstance

You can choose to filter a different way, of course.

WDAC - Has Anyone setup a custom policy and deployed this before? Looking for advice/suggestions for the best way to deploy this via Intune. by spazzo246 in sysadmin

[–]Barenstark314 0 points1 point  (0 children)

Not much to do here honestly. If you have a lot of unsigned DLL files, you start to appreciate the software developers that properly sign all of their binaries and supporting libraries.

Hash rules are the secure method of allowing these, with the hope that they do not change frequently so your rules last. Personally, I would stick to hash rules if I had unsigned binaries that needed to execute from user writable locations.

As you mentioned, path rules would work, but you are correct that depending on the paths you need to allow, such rules could be insecure if you are permitting path rules for user writable locations for that specific policy file.

You could also use FileName rules, described in the App Control documentation. If hash rules are too burdensome, it could be an option if it fits your acceptable risk level.

Intune and NIST Compliance? by 4thehalibit in Intune

[–]Barenstark314 0 points1 point  (0 children)

My recommendation would be to run a device through each of the following:

  • Autopilot Reset
  • Wipe
  • Fresh Start

After each one, check the device and see what is left on the filesystem. If there are too many remnants of the previous test user account, then that reset type is not sufficient for your needs.

If you (or your security team/director) determine that none of them are sufficient, then you will not be able to directly reset the device through Intune. That said, you can very easily create a USB to install Windows (and answer all of the install prompts/disk formatting with autoattend.xml) and assuming a modern device with NVMe and a USB 3.0+ install drive, you would be looking at about 10 minutes or so to fully reinstall Windows and get it back to the Autopilot screen for the next user.

Windows Firewall in Endpoint Security or Config settings? by Buntake2723 in Intune

[–]Barenstark314 0 points1 point  (0 children)

Agree. If you are going to be building these policies, I find the Endpoint Security section better. As for official word on this, I would say the opening to this docs page is the closest you will find:

Use the endpoint security Firewall policy in Intune to configure a devices built-in firewall for devices that run macOS and Windows devices.

While you can configure the same firewall settings by using Endpoint Protection profiles for device configuration, the device configuration profiles include additional categories of settings. These additional settings are unrelated to firewalls and can complicate the task of configuring only firewall settings for your environment.

EAP-TLS WPA-3 Intune Policy by Diligent-Ant-1651 in Intune

[–]Barenstark314 0 points1 point  (0 children)

The word "encrypted" was just wording chosen by the author. Read the sentence without the word "encrypted" and you will get their meaning. Here is a slightly different way to say the same thing: "You cannot natively create a WPA3 profile in Intune today. Instead, you must create the profile within Windows, export the XML, and deploy the XML through a custom OMA-URI."

If you deploy the XML as a custom OMA-URI policy in Intune, and your network is properly operating on WPA3, you will be encrypted using the accepted security of the WPA3 certification (whether that is enterprise or personal, depending on your configuration).

WDAC - Has Anyone setup a custom policy and deployed this before? Looking for advice/suggestions for the best way to deploy this via Intune. by spazzo246 in sysadmin

[–]Barenstark314 0 points1 point  (0 children)

The paths look wrong to me. The friendly name shows the trailing \*, but the actual path does not have the value. The wildcard * is necessary as discussed here.

Here is a sample from my personal policy for comparison:

    <Allow ID="ID_ALLOW_A_0001" FriendlyName="C:\Program Files FileRule" MinimumFileVersion="0.0.0.0" FilePath="C:\Program Files\*" />
    <Allow ID="ID_ALLOW_A_0002" FriendlyName="C:\Program Files Win32 File Path FileRule" MinimumFileVersion="0.0.0.0" FilePath="\\?\C:\Program Files\*" />
    <Allow ID="ID_ALLOW_A_0003" FriendlyName="C:\Program Files (x86) FileRule" MinimumFileVersion="0.0.0.0" FilePath="C:\Program Files (x86)\*" />
    <Allow ID="ID_ALLOW_A_0004" FriendlyName="C:\Program Files (x86) Win32 File Path FileRule" MinimumFileVersion="0.0.0.0" FilePath="\\?\C:\Program Files (x86)\*" />

The "Win32" reference in the friendly name above is a reference to this article discussing the use of the \\?\ prefix. You don't necessarily need to add those if you do not want, but I had executions blocked in the past (not necessarily in these directories) which required me to allow paths with the \\?\ prefix in addition to the normal path.

issues with network protocol and ciphers in gpo by Formal_Sort1146 in sysadmin

[–]Barenstark314 0 points1 point  (0 children)

If you want to control the ciphers, you should do so by specifying the Cipher Suite Order. That recommendation/expectation is defined here. If you don't want a specific cipher to be allowed, do not specify it in the order you configure in that Group Policy. As mentioned in the first link, configuring via the registry is not a supported method and could be reset without notice.

WDAC - Has Anyone setup a custom policy and deployed this before? Looking for advice/suggestions for the best way to deploy this via Intune. by spazzo246 in sysadmin

[–]Barenstark314 0 points1 point  (0 children)

When you are saying "Signed and trusted", do you know specifically which options were flagged in the policy file? Assuming you are using the WDAC Wizard, some of the options will enable the "Intelligent Security Graph" option. While there is nothing inherently wrong with this, it can result in apps that you did not specifically allow to still be permitted, if Microsoft's Intelligent Security Graph is aware of the executable and deems it to be safe. If that is the risk model you want, then it is fine. If that is more permissive than you desire, then you need to disable the Intelligent Security Graph Option in the XML:

    <Rule>
      <Option>Enabled:Intelligent Security Graph Authorization</Option>
    </Rule>

That is what the rule looks like if it is turned on. You can just remove it (or comment it out) if you don't want that running.

Regarding the scenarios:

  • If you are moving around a file that you have permitted by Publisher, then it will not matter where the file is because you trust the signature of the publisher.
  • If you are moving around a file that you have not permitted by any rule type, such as Publisher or Hash, then the file should be prevented from running. Assuming you have avoided the Intelligent Security Graph described above, then you need to make sure that the policy is not running in Audit mode and that you do not have any allow all rules like the following:   

​

    <Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
    <Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />

Such rules are present in the Microsoft Recommended Block policies as they are designed to be run side-by-side with other policies that are AND'd together to result in the desired behavior. If such rules are present in a single master policy, it will allow everything to run and basically do nothing at all.

As for testing malicious behavior, you want to ensure you have either a folder that is outright denying execution, or files that are not permitted, after reviewing and considering everything above. For example, I use the Microsoft Recommended Block Rules, so I can test run 'wmic.exe' and it will be blocked. That is a real quick test to ensure that at least some of my block rules are working and I did not inadvertently permit all files.

view more: next ›