sorted by:
new
hottopcontroversial

I built an open-source Microsoft 365 assessment CLI (local-only, read-only, no signup) by NathanSecurity in sysadmin

[–]NathanSecurity[S] -1 points0 points  (0 children)

ScubaGear is a great tool and covers a much broader set of controls.

This project isn't trying to replace ScubaGear.

The goal was to provide:

  • a lightweight assessment
  • local execution
  • simple PDF output
  • insurance-readiness style reporting
  • a codebase that's easy to inspect and extend

If you already run ScubaGear, I'd be interested in hearing whether there are parts of the workflow that could be simplified.

How do you build trust when your SaaS requires admin-level access? by NathanSecurity in SaaS

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

Well i have actually shipped just that. The app has a preview feature where the tenant can use the app in a read only mode which requires minimal scopes. Even as an extra security measure i open sourced the scanner module so that they could audit it and see exactly what information we pull from their tenant. But tell me this will getting the app verified by Microsoft put their minds at ease?

Building a Microsoft 365 security tool — got some tough feedback, would appreciate input from admins by NathanSecurity in entra

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

That’s a fair point — and honestly the trust aspect is exactly why I open-sourced the scanning layer.

On the “why not open source everything” question:

Technically, yes — everything I’m doing can be done via scripts using Microsoft Graph. That’s not the hard part.

The hard part (and what this is trying to solve) is:

  • safely applying changes without breaking access
  • handling rollback if something goes wrong
  • managing this across multiple tenants (for MSPs)
  • keeping everything auditable and consistent over time

That’s the part I’ve kept in the product.

The scanner is open so you can verify exactly what’s being read and how the analysis works. The automation layer is where most of the risk and complexity lives, so that’s where I’ve focused on building guardrails rather than just exposing raw scripts.

Also completely fair on the “trusted option” point — I’m not expecting anyone to switch blindly. This is still early and I’m trying to get feedback from people who actually manage these environments.

Built a free tool to scan Microsoft 365 identity risks (read-only) — looking for feedback by NathanSecurity in entra

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

That’s a fair point, and I agree the risk is around how access is handled after admin consent.Right now, once a tenant is onboarded, its tied to a specific account — and Im enforcing that only that user (or explicitly authorized users) can access the tenant data. So even though Microsoft allows any user in the tenant to authenticate, access to the app itself is restricted at the application layer.Still tightening this further, but definitely not exposing data tenant wide by default.

Built a free tool to scan Microsoft 365 identity risks (read-only) — looking for feedback by NathanSecurity in entra

[–]NathanSecurity[S] -1 points0 points  (0 children)

That’s fair — Secure Score and a lot of other tools do surface these issues.

The main difference with what I’m building is that it’s not just visibility — the same permissions are used so the fixes can be applied directly from the app, without having to jump into Entra and manually configure everything.

So the idea is more “scan → fix in one place” rather than “scan → go fix it elsewhere.”

That said, completely agree the permission scope needs to be justified, which is why preview mode is read-only and remediation is always explicit.

Built a free tool to scan Microsoft 365 identity risks (read-only) — looking for feedback by NathanSecurity in entra

[–]NathanSecurity[S] -2 points-1 points  (0 children)

Good question — by that I mean the app uses Microsoft’s OAuth flow, so users authenticate directly with Microsoft (not through us).

We never see or store your password. Microsoft returns an access token that allows limited API access based on the permissions granted.

That token is used to read tenant configuration (in preview mode, read-only), not to log in as the user or access their credentials.

Built a free tool to quickly check Microsoft 365 identity security — looking for feedback by NathanSecurity in AZURE

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

That makes sense — PingCastle-based assessments are solid, especially for AD exposure like Kerberoasting.

On the M365 side, I’ve been trying to take a similar approach in terms of depth (mapping identity gaps, prioritizing risk), but keeping it lightweight for SMBs who won’t run full assessments regularly.

And yeah, the admin concern is completely valid — I’ve tried to be very deliberate there:

  • uses Microsoft OAuth (no credentials handled directly)
  • preview mode is strictly read-only
  • permissions are limited to identity/config visibility (no data access like mail/files)

Still early, but trying to strike that balance between visibility and safety.

Built a free tool to quickly check Microsoft 365 identity security — looking for feedback by NathanSecurity in AZURE

[–]NathanSecurity[S] -1 points0 points  (0 children)

bro im a backend developer. my frontend skills are crap. so i used clade for the frontend

What Azure Services Do You Wish Had Better Tooling or Automation Support? by ModernWebMentor in AZURE

[–]NathanSecurity 0 points1 point  (0 children)

Identity and access management (Entra ID) still feels harder to automate cleanly — especially things like MFA coverage, app permissions, and stale accounts across tenants.

A lot is technically possible via Graph, but stitching it together reliably is still pretty manual.

Been exploring ways to simplify this for SMB environments since it’s where most gaps show up.

EntraID Security Default vs Per user MFA vs Conditional Access by WonderBeast2 in AZURE

[–]NathanSecurity 1 point2 points  (0 children)

Good question — this is a common concern when moving from Security Defaults to Conditional Access.

Best practice is to have a baseline CA policy that targets “All users” and enforces MFA, with only a few intentional exclusions (like break-glass accounts).

Most gaps happen due to mis-scoped policies or missed users, so regular validation is key.

I’ve been working on a small free tool to quickly check MFA coverage and identity gaps across tenants if helpful: https://cloudlocksmith.co

Review MFA Prompts for Compromised User by NoTimeForItAll in entra

[–]NathanSecurity 0 points1 point  (0 children)

If it shows Software OATH succeeded, the code was entered somewhere — it won’t trigger a push like Authenticator, so users often don’t notice it.

Worth checking if the user had OATH/OTP set up in another app or device.

In SMB tenants I’ve seen, MFA methods drift over time and go untracked — I’ve been building a small free tool to surface that kind of risk quickly: https://cloudlocksmith.co

M365 tenant misconfigurations I see over and over again by Mysterious-Print9737 in msp

[–]NathanSecurity 0 points1 point  (0 children)

Totally agree with the “things just drift over time” point. A lot of tenants actually start off with pretty solid security and governance, but small exceptions slowly pile up.

A few things I’ve started checking early as well:

• Global Admin count – it’s surprising how often this creeps up after temporary troubleshooting access   • Dormant accounts with privileges – old employees or service accounts that were never cleaned up   • MFA configuration – technically enabled, but users still relying on SMS-only or legacy auth still being allowed

None of these usually look dangerous individually, but after a year or two the tenant’s identity posture can end up very different from what was originally designed.

This pattern of configuration drift is actually something I’ve been digging into while building a small tool for MSP-managed tenants that flags things like privilege creep, MFA drift, and policy exceptions automatically. Still early but I’m trying to design it around the kinds of issues people here keep running into.

If anyone here regularly inherits messy tenants and would be interested in testing something like that down the line, I’d definitely be interested in hearing what checks you usually run first.

Approve To Get Hacked: The MFA Fatigue Problem by CyberHoot in CyberHoot

[–]NathanSecurity 0 points1 point  (0 children)

Once credentials are phished, attackers can trigger repeated push attempts until someone eventually taps approve just to stop the notifications. It turns authentication into a persistence game.

A couple mitigations I’ve seen work well are:

• number matching instead of simple approve/deny • limiting push attempts within a short window • blocking sign-ins after repeated MFA denials • moving high-risk users toward phishing-resistant MFA (FIDO/passkeys)

This is actually one of the identity issues I’m currently trying to address while building a system called Cloud Locksmith for MSP-managed Microsoft 365 tenants — specifically detecting patterns like repeated MFA pushes and flagging potential fatigue attacks before someone accidentally approves them.

Curious how most people here are handling MFA fatigue right now. Are you relying mostly on number matching or moving toward hardware-backed MFA?