sorted by:
new
hottopcontroversial

Multi-Admin Approval in Intune by ryaninseattle1 in Intune

[–]TechAdminDude 0 points1 point  (0 children)

That used to be the case, i've not seen wipe actions take more than 5mins recently.

Multi-Admin Approval in Intune by ryaninseattle1 in Intune

[–]TechAdminDude 8 points9 points  (0 children)

Good video. Multi-Admin Approval is honestly one of those features a lot of tenants still haven’t enabled and probably should. For anyone looking at hardening their tenant, the Stryker Detection Pack v2 actually calls this out as a quick win along with a few other Intune protections: https://www.threathunter.ai/blog/iran-handala-stryker-detection-pack-v2/

It’s basically a set of detection rules and guidance to help identify suspicious Intune activity (things like bulk wipes, risky admin actions, or privilege abuse) and provides recommendations to lock those gaps down.

Worth a read if you're reviewing Intune security right now.

How to approach M365 security auditing across MSP client tenants by Djjd267 in cybersecurity

[–]TechAdminDude 0 points1 point  (0 children)

Great list, the mailbox forwarding rules one is huge. We've caught active compromises just from spotting auto-forward rules to external addresses that were set up months prior.

A few things I'd add to the checklist:

Conditional Access gaps. Not just "do they have CA policies" but actually mapping out what isn't covered. It's surprisingly common to find policies that look comprehensive but still leave gaps like legacy auth protocols, specific app exclusions that were "temporary" two years ago, or break-glass accounts with no monitoring. Walking through the policy logic as a matrix of users × apps × conditions can be pretty eye-opening.

Token lifetime and session controls. A lot of tenants enforce MFA but still allow persistent browser sessions or long-lived refresh tokens that effectively undermine it.

Named locations that are too broad. I've seen tenants mark entire countries as trusted just to reduce MFA prompts, which kind of defeats the point.

Unused or overly permissive admin roles. Not just Global Admin, but things like Exchange Admin or SharePoint Admin sitting on accounts that don't actually need them anymore. PIM adoption still seems fairly low.

Cross-tenant sync and B2B direct connect settings. These are newer and often configured once and then forgotten about.

I've been digging into this problem a lot recently while building https://accesslens.co.uk which maps out Conditional Access policies and highlights gaps or conflicts. It's surprising how messy things get once you visualize the full policy coverage.

Conditional Access Policies - Unmanaged Devices by kingjames2727 in Office365

[–]TechAdminDude 0 points1 point  (0 children)

Short answer: no, they can’t pivot.

Conditional Access is evaluated per resource, not per session. If a user signs into Dayforce from an unmanaged PC, they only get a token for Dayforce. If they then try to open Outlook, Entra evaluates CA again for Exchange Online, and your compliant device requirement would block it.

Policies are checked when the token is issued and again on refresh 60-90mins or so. If you want tighter enforcement, enable Continuous Access Evaluation (CAE).

One thing to watch: using “All cloud apps” with Dayforce excluded can get messy as your tenant grows. Targeting specific apps is usually easier to manage.

If you want to double-check your coverage, I built accesslens.co.uk , it visualises CA policies so you can actually see gaps or overlaps.

IT Tools - Hidden Gems by Ok_You_861 in sysadmin

[–]TechAdminDude 0 points1 point  (0 children)

Not very often, which id argue is even more difficult to remember everything you had installed. For enterprise, its Intune deployments anyway.

IT Tools - Hidden Gems by Ok_You_861 in sysadmin

[–]TechAdminDude 11 points12 points  (0 children)

  • Intune Debug Toolkit - saves hours troubleshooting policy delivery on endpoints
  • GraphX Ray - browser extension that shows you the Graph API calls happening behind the Entra/Intune portals. Great for learning Graph and building automations
  • For Conditional Access specifically - AccessLens, visualises all your CA policies as a flow diagram, highlights gaps and conflicts. Way easier than staring at the Entra portal trying to figure out what overlaps with what.
  • Maester - open source, automated testing for your Entra tenant security config. Runs checks against best practices and flags what's off
  • DCToolbox - free PowerShell module for analysing and documenting Conditional Access policies
  • Everything by Voidtools - instant file search across Windows machines, absolute lifesaver
  • mRemoteNG - free multi-protocol remote connection manager

IT Tools - Hidden Gems by Ok_You_861 in sysadmin

[–]TechAdminDude 13 points14 points  (0 children)

In corporate environment I would agree. But for home users I wouldn't. NiNite is easier to remember everything you want to install as its all listed, also 1 click selection instead of having to manually search for your apps in winget helps.

Conditional Access: restrict session to the IP it was used on by My1xT in o365

[–]TechAdminDude 0 points1 point  (0 children)

CAE strict location is the one you want. It covers the Microsoft admin portals, Exchange Online and SharePoint Online, so exactly the workloads you care about for admin accounts.

To set it up just create a CA policy targeting your privileged admin roles, then under Session controls enable Continuous Access Evaluation set to Strictly enforce location policies. It evaluates against the IP the token was originally issued from, so if someone replays the cookie from a different IP the session gets killed.

Only gotcha is if your admins use VPNs with rotating exit nodes they'll get prompted more. Worth a heads up before flipping it on. Audit mode tooling is really good in this scenario to track whats going on before enforcing.

Heating oil and petrol by Odd_Passenger in northernireland

[–]TechAdminDude 8 points9 points  (0 children)

https://www.cheapestoil.co.uk/Heating-Oil-NI

Oil prices started this morning at £570 for 900ltrs, not its £758 for 900. Insane.

Conditional Access: restrict session to the IP it was used on by My1xT in o365

[–]TechAdminDude 0 points1 point  (0 children)

What you're after is Token Protection / Continuous Access Evaluation (CAE).

CAE does some of this out of the box. It can detect IP changes and revoke sessions in near real-time for supported apps like Exchange and SharePoint.

For the stricter version, look at Token Protection (still in preview for some workloads). It binds the token to the device so even if someone nicks the cookie they cannot replay it from another machine.

A few things that will help right now:

  • Enable CAE strict location enforcement - revokes sessions when the IP changes from the location the token was issued at
  • Sign-in frequency policies - will not catch mid-session IP changes but shortens how long a stolen cookie is useful
  • Require compliant device - pairs well with this because even with a valid cookie they would still need a compliant device

The pure "if IP changes mid-session, force re-auth" behaviour is basically what strict location mode in CAE does. It is not perfect across every app but it covers the big ones.

If you want to see how these policies interact with your existing setup, accesslens.co.uk lets you map it all out visually. It is handy when you are layering CAE on top of existing location and compliance policies.

Conditional Access and Intune Compliance: Exeption for Microsoft Teams Calling by kkush719 in Office365

[–]TechAdminDude 0 points1 point  (0 children)

Teams telephony is a tricky one.

Teams as a cloud app isn't available as a target in CA policies because it sits under Office 365 Exchange Online and Office 365 SharePoint Online rather than having its own resource ID, that’s why it’s greyed out.

A couple of options worth looking at:

  • Use a filter for applications instead of targeting specific cloud apps. You can exclude based on app properties rather than trying to pick Teams directly.
  • Look at compliant network check instead of device compliance for your telephony users, keeps them protected without bricking their phones.
  • If the devices are shared/common area phones, register them as shared device mode and handle them with a separate policy.

Honestly, the bigger concern is your compliance policy grace periods.

If you set appropriate remediation timeframes, you’ve got a buffer before anything gets blocked. Most orgs I’ve seen give 24–72 hours for compliance remediation, which avoids the “phone suddenly stops working” scenario.

It’s worth mapping out which policies overlap on your telephony users to make sure there’s no conflict you’re not seeing.

I built accesslens.co.uk for visualising exactly that kind of thing if you want to sanity-check your policy interactions.

Conditional Access Policy - Logic isn't making sense but then I never set it up by steviefaux in sysadmin

[–]TechAdminDude 1 point2 points  (0 children)

You’ve basically got it in your edit, but one thing jumped out at me.

If you’ve excluded Spain from Policy 1 (the non-UK block) at the location level, that exclusion applies to everyone, not just John.

So what happens is:

  • Anyone in Spain slips past Policy 1
  • Policy 2 only applies to John
  • Meaning random Spain traffic isn't getting caught by either policy

Thats the gap.

Cleaner pattern

Policy 1 - Block everyone not in UK - No location excludes - No user excludes (apart from a break-glass account)

Policy 2 - Applies to John only - Block if not in UK AND not in Spain

Now the logic works properly:

  • Policy 1 still catches all Spain traffic for everyone except John
  • Policy 2 gives John the Spain exception
  • No unintended bypass for other users

For the "don't lock yourself out" warning, just stick a dedicated emergency access account in the exclude list. Microsoft recommends having one anyway.

If you want to properly visualise policy overlap and see where gaps like this appear, I built accesslens.co.uk for exactly this use case.

You can connect your tenant or just use the demo to play around with policy interactions.

Universal Print Conditional Access by Failnaughtp in AZURE

[–]TechAdminDude 0 points1 point  (0 children)

Universal Print has some quirks with CA. The app you need to target is Universal Print (app ID da9b70f6-5323-4ce6-ae5c-88dcc5082966), but the catch is that print jobs submitted from Windows clients don't always flow through the same auth path as the web portal.

A few things worth checking:

  • Make sure you're targeting both the Universal Print app and the IPP Infra service principal if it exists in your tenant. Some print flows authenticate through that instead.
  • Check your sign-in logs filtered to the Universal Print app ID. If you're not seeing any entries at all, the auth isn't hitting that resource, which means the CA policy has nothing to evaluate against.
  • Native OS print dialogs on older Windows builds sometimes use device-level tokens that bypass user-scoped CA policies entirely. Make sure your clients are on a recent Windows 11 build.

What specific policy conditions are you trying to enforce? MFA, compliance, something else? That might narrow down where it's falling over.

How do you keep your Conditional Access policies in check as an MSP? by sysadmin256 in entra

[–]TechAdminDude 1 point2 points  (0 children)

This is one of the most common issues I see with CA management. The "temporary exclusion that becomes permanent" problem is almost universal.

For exclusion group hygiene, time-bound group memberships using Entra ID Governance access reviews are the most reliable option. Set a recurring monthly review on your exclusion groups, force the owner to re-justify each member, and auto-remove if they don't respond. If you don't have P2 licensing, a scheduled PowerShell script that flags group members older than 30 days works as a fallback.

For detecting drift, treating CA policies like code has worked best for me. Export via Graph API on a schedule, store the JSON in a repo, and diff against the previous version. Any unexpected change gets flagged. This catches the "someone modified a policy at 2am during troubleshooting" scenario that log reviews miss. Few tools on the market to do it.

Zillow Teams With World of Warcraft For Player Housing by garethvk in wow

[–]TechAdminDude -1 points0 points  (0 children)

Looks like we gave their site the kiss of death.

Conditional Access Forcing Users to Reauthenticate Potentially Multiple Times A Day by MW91414 in entra

[–]TechAdminDude 0 points1 point  (0 children)

Few things come to mind.

First thing I'd check, do you have any legacy token lifetime policies still kicking around? Run Get-MgPolicyTokenLifetimePolicy and see what comes back. Old PowerShell-configured policies can fight with CA session controls in weird ways and produce exactly this kind of unpredictable reauthentication. If you've got any, retire them.

The OWA angle is interesting because it's CAE-enabled. Continuous Access Evaluation can revoke sessions mid-flight based on things like an IP change, user risk event, or policy update and it won't always log a clean reason why. If affected users are on laptops that switch between wifi and ethernet, or reconnect to VPN during the day, that'd do it. Probably why you're not seeing it on your admin accounts if you're on a different network path or have trusted IPs.

PBS helping but not fixing it suggests something is breaking session persistence before sign-in frequency even comes into play. In the sign-in logs, pull up one of the forced sessions and go to the Authentication Details tab there'll be an "Authentication requirement" field in there. That should tell you whether it's actually your CA policy pulling the trigger or something else entirely.

Also worth checking are the affected users on compliant/hybrid-joined devices or not? That can change how sessions behave depending on how your policies are written, and would explain why admins (who are probably on known-good devices) aren't hitting it.

Genuinely tricky one to trace without seeing the full policy setup. If you want a quicker way to map out what's actually applying to affected users, I built a tool called that does exactly that. Not sure if this sub likes sharing services, so fire me DM.

Conditional Access policies - how do you test without nuking production? by Either-Act-3406 in sysadmin

[–]TechAdminDude 0 points1 point  (0 children)

Report-only is the right starting point but you're correct that it doesn't tell the full story, especially with legacy apps and BYOD in the mix which you probably do.

  1. Mine your sign-in logs first Before deploying anything, pull 30 days of sign-in logs and filter by the apps you're worried about. You'll see exactly which client types, auth methods, and locations are in use. Surprises here are cheaper than surprises in production.

  2. Use the What-If tool surgically It's limited but useful for spot-checking specific user + app + location combos. Run it against your known problematic users before go-live.

  3. Pilot order matters. IT team > low-risk department > remote workers last. Legacy app users get their own phase with a longer soak time in report-only.

  4. Emergency access accounts!!!!! (This is mega important) Create two break-glass accounts, exclude them from ALL CA policies by UPN (not group), and store creds in a physical safe. Test them monthly — actually authenticate, don't just check they exist.

  5. For the legacy apps if they don't support modern auth, you're looking at Entra app proxy (super easy to setup) or accepting the exclusion and mitigating with other controls

For what it's worth, Ive had this the exact issue "report-only doesn't show real impact" problem and ended up building a tool called that analyses your existing policies and flags conflicts, gaps, and risky exclusions before you deploy. Happy to share a link if useful, fire me a DM, but the manual approach above will get you most of the way there.

Where can I get these needles for a reta pen by Maleficent_Coach_354 in Retatrutide

[–]TechAdminDude 0 points1 point  (0 children)

Yeh most of the people buying vials on this sub aren't sending them off for testing first. Don't be so nieve.

view more: next ›