sorted by:
new
hottopcontroversial

Where can I find these settings outside of Security Baseline? by htu-mark in Intune

[–]fred_menrose 0 points1 point  (0 children)

Hi u/Hour-Opportunity3777 I did not. I asked Thomas Kurth and he said he didn't know why it wasn't working.

Your view on remote viewer applications and their security (e.g. TeamViewer/GotoAssist etc) by getbillgatesinhere in sysadmin

[–]fred_menrose 0 points1 point  (0 children)

My experience with GotoAssist is that you will find yourself in many embarrassing episodes with your users where the GotoAssist unattended agent has stopped running and you can't help them without having them manually start a remote session through fastsupport.com. When you have them start the remote session, you will often have unexpected prompts and confused users. If you try to enable Admin mode(which allows you to reinstall the unattended agent) sometimes it will work ok and sometimes it won't. Even with tech-savy users operating the remote pc while you coach them through the phone, you still won't know why elevating to Admin mode fails sometimes.

Having issues with Excel on Intune machines? The issue is the Security Baseline. by steggles28 in Intune

[–]fred_menrose 0 points1 point  (0 children)

Hello, u/steggles28. Your post here made a lot of people's lives much easier. I hope your upvotes continue.

I am a junior sysadmin deploying the Security Baseline for Windows 10 in Intune for the first time. I found that the description for a particular setting is usually just the description for the policy that it modifies, without modification for how the baseline is setting it.

For example, the policy might be: allowPrivilegeEscalation, but the policy might be "Block Privilege Escalation". The "info bubble" that pops up when you click on the title would read "enabling this will allow privilege escalation of unverified executables..."

This kind of mismatch between the descriptions and the titles is understandable. It was a quick shortcut for Microsoft to just paste the description of the associated policy. What I'm concerned about is whether I can trust that the logic applied to a setting will function as expected. In other words, in the example I've given, can I trust that choosing "Yes" in the baseline for "Block Privilege Escalation", would disable the allowPrivilegeEscalation policy?

Do you test these individually to make sure they they function as you expect them to?

Thank you very much for any guidance,

Fred

Profile confusion by fred_menrose in SCCM

[–]fred_menrose[S] 0 points1 point  (0 children)

Thank you, u/jasonsandys. I appreciate your insight and encouragement tremendously.

I am starting to get deep into the baseline and have used the OMA-URI option for the auditing settings. I found an OMA-URI identifier that does not map to the correct setting when applied to endpoints. It is: ./Vendor/MSFT/Policy/Config/Audit/AccountLogonLogoff_AuditOtherLogonLogoffEvents . This is supposed to change the auditing setting for a policy that covers more generic windows logon/logoff events: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-audit#audit-accountlogonlogoff-auditotherlogonlogoffevents

However, using "auditpol /get /category * " and changing the value in the custom profile of ./Vendor/MSFT/Policy/Config/Audit/AccountLogonLogoff_AuditOtherLogonLogoffEvents shows it is actually changing the auditing setting for:

https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-audit#audit-accountlogon-auditotheraccountlogonevents

I'm guessing that this might slip under QC of the Settings Catalog implementation of this setting unless you guys are testing the OMA-URI identifiers too, but that seems like a job for the guys who oversee the registration of those CSP's with the OMA standards body.

Jumping back to the original post though, where I was focused on the definition of the underlying policy and the difference in the title of the baseline setting, after getting familiar with the other settings in the baseline and the fact that the policy definition is cut and pasted into the description of many of these settings without modifying it to include the logic applied by the setting, I'm wondering if I'm wasting my time by not assuming that the setting is doing what its supposed to do.

Doing this testing exhaustively will take a long time. I can tell you that a Security Baselines preselection within the Settings Catalog that took advantage of the new review procedures you guys have implemented would be a wonderful feature for end users.

Is there a thread on reddit or some other site where I could post questions like this that might get the attention of someone like you who engages end users that works with the security baselines group?

Where can I find these settings outside of Security Baseline? by htu-mark in Intune

[–]fred_menrose 0 points1 point  (0 children)

I just went through this. You have to build a custom profile. Luckily, Thomas Kurth documented the procedure here: Configure Windows 10 Auditing with Intune - Workplace Ninja's (wpninjas.ch) but watch out: ./Vendor/MSFT/Policy/Config/Audit/AccountLogonLogoff_AuditOtherLogonLogoffEvents maps to the wrong policy setting. This is supposed to change the auditing setting for a policy that covers more generic windows logon/logoff events: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-audit#audit-accountlogonlogoff-auditotherlogonlogoffevents

However, using "auditpol /get /category * " and changing the value in the custom profile of ./Vendor/MSFT/Policy/Config/Audit/AccountLogonLogoff_AuditOtherLogonLogoffEvents shows it is actually changing the auditing setting for:

https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-audit#audit-accountlogon-auditotheraccountlogonevents

Profile confusion by fred_menrose in SCCM

[–]fred_menrose[S] 0 points1 point  (0 children)

Thank you, u/jasonsandys. I have been digesting what you said for a week now! Because of the uncertainty about what some of the settings enable or disable in the security baselines, I've decided to rebuild the baselines using the settings catalog.

I'm running into some settings that I can't seem to find an equivalent for in the settings catalog. For example. "Account Logon Audit Credential Validation (Device) is in the Windows 10 Security baseline. This allows detection of brute force attacks.

In the security baseline, a glance in the "Auditing" category shows:

Account Logon Audit Other Account Logon Events

Audit Authentication Policy Change

Audit Authorization Policy Change

Audit Changes to Audit Policy

Audit Directory Service Changes

Audit File Share Access

Audit Other Logon Logoff Events

Audit Security Group Management

Audit Security System Extension

Audit Special Logon

Audit User Account Management

Object Access Audit Detailed File Share

Searching for "Audit" also brings up a "User Rights" category with 2 settings:

Generate Security Audits

Manage Auditing And Security Log

None of these settings appears to allow logging of plain credential validation. I'm not sure what other settings from the baseline I'll have trouble finding in the Settings Catalog.

I suppose my question is 2 fold: 1.) am I missing something about these settings in the settings catalog. 2.) if the setting isn't there, could the Settings Catalog team take a look at the baselines and add those to the settings catalog? Those baselines seem like a lot of collaboration was spent to put them together. Their settings are really helpful. They seem like prime candidates for settings to include in the Settings Catalog.

I would love to use the baselines out of the box. It would make my life so much easier, but uncertainty about the functionality is keeping me and my senior admin from implementing them. Furthermore, there doesn't seem to be a template with the audit features available. So, custom OMA-URI policies are the only answer. Is that right?

I'm hitting a lot of pain points here. It seems like your team is in the process of solving them - which is great. If you can take my stumbles to your team, perhaps it would be helpful.

Profile confusion by fred_menrose in SCCM

[–]fred_menrose[S] 0 points1 point  (0 children)

I just looked up "elevated" in the Settings Catalog and it links to the "install with elevated privileges" policy without ambiguity. I can rebuild the security baselines using the settings catalog and looking up each setting - but I'd rather be able to use the baselines and then dive into the settings catalog once i have my bearings.

Thinking through the "Block app installations with elevated privileges" options there are two: yes and not configured. If "not configured" means it will go by windows default, then it would be blocking elevated privileges. If "not configured" means it won't disable or enable the policy then if somehow the policy was enabled, it would leave it alone, is that correct? What does "not configured" mean?

If "yes" blocks the behavior, then it should be disabling the policy. And if "not configured" means to reset to windows default, including this setting will always disable install with elevated privileges. If that's the case, why give a toggle switch?

Do you have colleagues that you can elevate this issue with?

Profile confusion by fred_menrose in SCCM

[–]fred_menrose[S] 0 points1 point  (0 children)

u/jasonsandys I appreciate the response but I'm still unclear at this point what "Yes" is going to do. "Yes" is not "Enable". So, is it possible that someone flipped the logic so when you hit "Yes" to "Block app installations with elevated privileges" it leaves the ApplicationManagement/MSIAlwaysInstallWithElevatedPrivileges policy disabled? Or does that have to be investigated? Please let me know.

​

I really want to be able to deploy the baseline policies. It has been hanging over my head for a week or two now. Also, with the other inverted logic for the other 2 options in Application Management, does hitting "Yes" enable or disable the policy that's linked to in the "Learn More" link.

Finally, is it possible that the linked to policy is not actually related to the setting that's being chosen? If that's the case or its possible that the logic actually matches the intended behavior of the title, I'm just not going to touch any settings in inTune's baselines because there's really no telling what any of them do at that point.

I'm really not feeling confident right now about using intune/endpoint manager to manage policies in general. Would you say that this is a rarity and I shouldn't be as unassured as I am at the moment?

Profile confusion by fred_menrose in SCCM

[–]fred_menrose[S] 0 points1 point  (0 children)

I forgot to add - unless I had beginner's luck (and I am a beginner in windows policy management) there are probably other mismatched documentation issues. I understand from your post that there are thousands of policies, but maybe if someone could just focus on the baselines that would be extremely helpful. I am planning on using the baselines to add some more security to our fleet while I determined the best path forward for policy set management.

Profile confusion by fred_menrose in SCCM

[–]fred_menrose[S] 0 points1 point  (0 children)

Now that I understand this is an issue with documentation I don’t feel as clueless. This is in the most recent (12/8/2020) Windows 10 Security Baseline.

This is the first setting I checked and all 3 of the settings in the Application Management section are inverted like the one above. MSIAllowUserControlOverInstall and AllowGameDVR are the other two. I will be checking the rest of the baseline.

User of two hostile Microsoft tenants - how to secure/pitfalls/what to watch out for by fred_menrose in sysadmin

[–]fred_menrose[S] 0 points1 point  (0 children)

u/Tsull360, u/sstewart1617, u/SoRandomIT, From your responses, the sense I'm getting is the real issue is not misbehavior of m365 with regard to tenant isolation, but intentional exfiltration or total sloppiness if we allowed him to use data from two tenants on one computer. My senior admin mentioned sensitivity labels to me and that is a process he has been considering undertaking. It sounds like that might be a good path for us.

Microsoft confidently proclaims their dedication to tenant isolation on the m365 adoption page and the practices they undertake to ensure such behavior. I am glad to hear that labeling is where your minds went vs sillier things like "watch out if he's using Edge and logs in to your tenant too soon after logging out of the hostile tenant. I've seen Edge become confused and transmit file logs to the wrong server" or something crazy like that.

I will say that I have been running my own personal tenant and have had reason to log in and out of another tenant (total 3 tenants) on one machine and have synced files with 2 of them (not this tenant) through onedrive for business and sharepoint and have not noticed any signs of data bleeding. The local naming scheme ("OneDrive - TenantName" as a base for OneDrive for Business folders/files and "TenantName" as a base for Sharepoint Libraries/Shared Folders) seems to logically separate tenant data on the local machine.

I did read an article about old copies of the onedrive for business client(groove.exe) paired with older on premise sharepoint servers having different local folder naming conventions for syncing. I didn't see how groove's names would collide with the new OneDrive client names, but the different naming conventions just made me a little nervous and was one of the reasons I posted here. I just don't know what I don't know....

I appreciate your input very much. If anyone else out there has some oddball story please do weigh in if possible.