Intune device configuration profiles— what is best practice?
Posted by Axelpeach@reddit | sysadmin | View on Reddit | 20 comments
We use Intune for our MDM. Was curious to know how y’all configure your configuration profiles for Windows devices.
I guess my main dilemma is that an individual on our security team is pushing us to lump ALL settings of the same policy type into one profile. (Ie, all settings catalog settings in one profile, all administrative templates in one profile). As a way to lessen the amount of profiles that we have.
Eg, All edge settings, M365 app settings, chrome settings into one profile.
Is this frowned upon?
I guess I would create+name them by their purpose/function. This seems like what a lot of orgs do, l based on initial research.
Asleep_Spray274@reddit
Why is the security team driving the configuration? They drive the policy, end point team implements.
hihcadore@reddit
Exactly. Sounds like they mean “baseline policy” but don’t know enough to ask for it. Or know enough to comb through 20 profiles to find the settings.
I’d say, hey security dudes, I’ll create an extra special policy just for you, you can audit your baseline and see exactly what configs are applied and what devices are excluded. Leave the rest of the endpoint management to my team. I don’t want edge case settings lumped into one.
Besides I have idea how this would even work. You’d have no way to have granular settings per department.
disclosure5@reddit
The thing to be aware of is that Intune has no gpresult equivalent. I've walked into problematic laptops with 120 policies applied because people massively overcomplicated the "policy per item" rule they had, and then it simply became too hard to work out what policy had a broken setting. The lower the number of policies to investigate the better.
The whole "Endpoint security" tab has a "Microsoft Windows 11 Baseline" that covers a tonne of things and ideally covers as much of your security as possible.
screampuff@reddit
2 options:
Microsoft.Graph.Beta.DeviceManagement module, Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
Get-MgBetaDeviceManagementConfigurationPolicy will let you query settings where you can use search terms that appear in the settings name.
Alternatively, create a dummy policy with conflicting setting, scope it to a test or single machine and wait for a settings conflict to appear, it will tell you which profiles contain the setting.
Though a good naming convention should avoid this problem in the first place.
slm4996@reddit
However this policy easily overlaps with BitLocker and other policies unless you change associated items to unconfigured. And Intune does have some policy conflict reporting, although it usually only tells you which policy conflicts, not the setting.
LaDev@reddit
That seems pretty far out of scope for a sec guy to care about? Usually just the resulting policy is the area of concern.
Is he validating config compliance by just looking at Intune policies? If so that's shit.
cedricmordrin@reddit
The community has already gone through this. Modularize for flexibility. Check out this project it works very well as a starting point. https://github.com/SkipToTheEndpoint/OpenIntuneBaseline
monstaface@reddit
Do you keep all your GPO's in one single policy?
Demented_CEO@reddit
Why is this a discussion? If the metric your org wants to track is number of profiles, then raise your concern to the C-level if you have to that your team is not focused and is creating future tech debt.
Microsoft doesn't bill per profile. Intune doesn't limit how many profiles you can have nor does it break after X many profiles. Syncing your fleet isn't any more cumbersome with more profiles.
Naming conventions should be clear, cohesive, and agreed upon org wide. I'd do one profile per setting or group of related settings. When something breaks or fails, you can very quickly diagnose it.
Intune provides reports on what has been pushed and what hasn't. It's much easier to sift through that information when you're not doing printer configuration and browser settings all in one place.
There's no dilemma and there's no problem with Intune. This smells like a culture problem and that needs to be addressed before too opinionated people fixate any longer on irrelevant issues.
GremlinNZ@reddit
There is actually a limit on profiles which I think was 500 a few years ago and then increased?
Yeah, apparently someone managed to hit the limit...
ninadpathak@reddit
The best practice answer depends on your threat model. Microsoft publishes baseline configurations for Intune, but the baseline doesn't account for your specific user population's access patterns.
The configuration profile decision that causes the most headaches downstream is the balance between restrictiveness and usability. Profiles too strict generate workarounds. Profiles too loose get flagged in security audits.
The pragmatic approach: start with the Microsoft recommended settings, run them through a risk assessment against your data classification, then tighten the controls that map to your highest-sensitivity data types.
gumbrilla@reddit
It wouldn't work on our work flow. If I'm working on a single app or configuration are , I create a new profile, tie it to a group, and exclude it from the config I'm aiming to replace. I then widen the group to include test machines, then widen it eventually to more and more machines.. The last step being to deploy to all devices, and remove the old config deployment, and clean up the device group I used
If everything was in some huge profile, then we'll it's just going to suck, for no actual benefit I can see. Reducing the number of profiles is not a metric I'd be used. Unused profiles sure, or out of date profiles sure, but if they are active, what benefit?
slm4996@reddit
I prefer a baseline policy per os, that is shared across all devices (or nearly all), then a policy per application or application suite. Security policies get broken down by related or interdependent things in a policy.
Then of course anti-virus gets a baseline, with per group exclusion policies.
Of course some things will be templates instead of setting catalogs, or maybe imported admx (but those fall into the per application rules above).
DotcomBillionaire@reddit
Consider having a single profile for settings that affect all machines, then additional profiles to meet the granular needs of each role or department.
Temporary-Library597@reddit
This. As should always the case, build as simply as possible, and add complexity only when necessary.
Evening_Link4360@reddit
Horrible idea to lump them together. I name policies like this: OS - Category - what does it do. For example: Windows - Security - Firewall. Or Windows - Device Mgmt - Screensaver
bbqwatermelon@reddit
Not entirely. It takes less time to find a particular setting with more inclusive profiles. This comes in handy when there is a conflict and intune is too dumb to show which profiles are conflicting (oma-uri for example). I view config profiles almost diametrically opposed to GP...
The_NorthernLight@reddit
We do a “default settings” profile for all of the role/usecase agnostic settings, and then we breakout the role or app specific settings in their own profiles.
I understand what your coworker is aiming to do, and that has to do with deployment speed. The problem is that if a single mistake is made in the single profile it can cause serious havoc to recover from.
Modern profiles deploy incredibly quickly and in fact can deploy changes faster because the profile is much smaller and easier to make changes too.
screampuff@reddit
Best practice has typically been to organize settings by their underlying purpose, or the category of control they fall into. Ie: edge settings in a policy just for edge, OneDrive in a policy for OneDrive.
Ask your security team if/when a business need arises that a particular group of computers or users needs a single setting to be different, are you going to duplicate the entire profile minus that one setting?
Fake_Cakeday@reddit
It would make it difficult once you started having different types of needs for different types of devices.
Although I do see the allure if you have some pretty simple needs.
We have 3 standard profiles, 2 shared devices, 2 guest browsing kiosk profiles and an ever growing amount of kiosks as digital signage or something like that.
If we want all our security stuff on everything, but we find out that a shared profile and a kiosk profile doesn't work with a particular setting, then we just have to find that particular config setting and exclude those two profiles.
And not make a full set of confg settings profiles that are 99% the same for all of them.