notapplemaxwindows

Dude works for MS and gets to build this on company time, while aided by colleagues. It's really not a "community built" project. But its still amazing.

That's likely because it's a new domain only; you can see the official resource in your own Microsoft 365 admin center 😄

This was published back on the 23rd March > [https://msmessagecenter.com/MC1259822](https://msmessagecenter.com/MC1259822)

A password policy is just that, a policy for passwords. You should have authentication guidelines (or an authentication policy) in addition that state all of the above things you mentioned.

Yes, 1000%, your emergency access (or break glass) accounts need MFA enforced via Conditional Access. Also: * Create dedicated policies * Keep them cloud only * Use the fallback domain in case of domain-related issues * Monitor usage with Log Analytics or Defender for Cloud * Limit admin mistakes with admin units * Enforce phish-resistant or passwordless MFA I've written this in more detail [here](https://ourcloudnetwork.com/best-practice-for-emergency-access-accounts-in-microsoft-entra/).

It's not just about the piece of paper. It shows potential new employers a growth mindset, discipline and dedication. Me? I want to learn, and I want to be able to prove that learning with my little piece of paper. Every "old timer" I have worked with in the last 10 years has preached the same bullshit "Exams are pointless", while they have their NT server exam cert framed on their desk, yet they get confused between AD and Entra, and try to sell Tin over cloud. They always scramble for their exams when they think their job is at risk. In my opinion, do the exams and enjoy the process of learning. If you are the only one who does exams and learns in your department, I guarantee your colleagues will become somewhat dependent on your knowledge.

Use Microsoft Graph PowerShell. The best way to learn is to install the Microsoft.Graph.Authentication module and just use Invoke-MgGraphRequest. I've written a book on Microsoft Graph PowerShell for Administrators if you are interested.

Would you even be able to list out all of the services within Microsoft 365 you need? In 99% of cases, it comes down to 2 or 3 high-value use cases which would necessitate a license uplift. IMO what you are asking for would be useful, but just plain overkill. Usually, the high-value use cases should pay for the uplift, and then the rest of the conversation is just increasing TCO and adoption of said license.

No just move on. If they reach out to you, you can fix it for a fee.

Start by installing the Microsoft Graph PowerShell module, something like this: Install-Module Microsoft.Graph -Scope CurrentUser Then use the following to connect: Connect-MgGraph Do you get the same error? I have a GitHub repo with plenty of resources to get your going with Microsoft Graph PowerShell > [https://github.com/DanielBradley1/Microsoft-Graph-PowerShell](https://github.com/DanielBradley1/Microsoft-Graph-PowerShell)

If you are looking to use Graph, you could create a multi-tenant application and have your customers consent to it? Then it would be fairly easy to obtain an access token for each tenant. Unfortunely without that pre-consented application, I don't think there is any other option for Graph access to another tenant via GDAP.

I wrote a guide on setting up cloud-based auth with RADIUSaaS [here](https://ourcloudnetwork.com/setup-wireless-radius-auth-for-entra-joined-devices-and-cloud-pki/).

The GraphSDK works on v5.1.

You can just look at the Microsoft Graph Explorer application in Microsoft Entra. If assignedment is not required, all users can login. If assignment is required, look who is assigned to it.

If you can access a domain controller, are any of the accounts with administrative roles in Microsoft Entra, synchronised from on-premesis AD?

Let's take the default app: **Microsoft Graph Command Line Tools**. If user1 is a global admin, connects to the app and assigns the **user.readwrite.all** permission to the app, then they can modify users. Suppose the Microsoft Graph Command Line Tools is enabled for anyone to connect (it shouldn't be, but it is by default). If user2 (who is assigned the **User Administrator** role) connects to the app, they can modify users thanks to both the fact that the user.readwrite.all permission is consented to the app AND they are a user administrator. Say user3 comes along, they are assigned the **Group administrator** role in Microsoft Entra. They connect to the Microsoft Graph Command Line Tools app and attempt to modify users, but they cannot, as they are only a Group administrator, see what I am saying? For user2, it's not a security concern as they could have just modified the user from the web portal anyway and for user3, they cannot modify users as they don't have the role assigned. Now, the application context is different. If someone connects to the application in the application context, they are not doing so as their own user, so anyone can use the permission in that case, providing that know the application credentials. But you shouldn't, wouldn't and can't connect to the Microsoft Graph Command Line Tools in the application context. Going one step further, you should NOT be using the Microsoft Graph Command Line Tools app, but instead your own application with the assignment required option enabled. Users should be assigned by group membership, then PIM should be used to relevant their group membership and role to get access.

>t Ignite they were reviewing the new management api and it was a factor they called out. You are sharing the application connection where previously you were logging with your credentials and looking at your permissions. > >The initial time you connect you need to have privileges in the app registrations as the app will get registered there, if anyone else uses it then it will use the same app registration as previously. Yes, but only providing that you have a role assigned in Microsoft Entra that covers that permission. Previously, if you had a role assigned, you could connect to the PowerShell module regardless. Now you can do selective assignments, custom app registrations, delegated and app-only context, and Conditional Access. The role would grant you permission to the web portal anyway, so its more of a control issue, not security concern..

That it simply not true :) I have lots of detail on set and security in my book. Actually you have MORE control over this API than the previous

>Authentication Administrator Then your best bet is to create an App registration with the UserAuthenticationMethod.ReadWrite.All, then have your engineers connect to it to issue a Temporary Access Password for a user who has forgotten their password. Then the engineer can have the user update their own password.

Resetting user's passwords is a privileged task. With the Graph API, you even have to use the Directory.AccessAs.User.All permission and have the AuthenticationAdministrator role assigned. I don't see how the authentication administrator role will give them too much access, provided you allow them to reset user passwords anyway.

I wrote a blog on setting up Authentication Strengths [here](https://ourcloudnetwork.com/how-to-setup-require-authentication-strength-in-conditional-access/). However, Authentication Strengths is about enforcing stronger methods of authentication, not about the single sign-on experience... Of course, everything you are saying is relevant to Azure AD Joined machines where you have Azure AD Connect in your environment, I assume this is your setup? If so, Microsoft have a breakdown of the Windows-Integrated SSO experience for on-premise resources while your machine is Azure AD Joined > [https://learn.microsoft.com/en-us/azure/active-directory/devices/device-sso-to-on-premises-resources#how-it-works](https://learn.microsoft.com/en-us/azure/active-directory/devices/device-sso-to-on-premises-resources#how-it-works) If this isn't the case for your environment, I am struggling to understand what the issue is. Can you confirm how your environment is configured?

Thanks for the feedback! Yes this is just a generic script I wrote when I saw this post… adding filters to the Get-MgUser command would be very simple, I have some guidance on it here https://ourcloudnetwork.com/how-to-use-get-mguser-with-microsoft-graph-powershell/

Hi u/electrical23456, you don't necessarily have to go through each service and pull reports from each one. The LastSignInDateTime property (Inactive Sign-in with Password and/or MFA) and the LastNonInteractiveSignInDateTime property (Last token refresh from an app that is signed in) should give you enough information to determine if the user is active or not. I have a script I created on my blog here ([https://ourcloudnetwork.com/create-an-inactive-m365-user-report-with-microsoft-graph-powershell/](https://ourcloudnetwork.com/create-an-inactive-m365-user-report-with-microsoft-graph-powershell/)) that will create a report of users with these 2 values including any licenses they have assigned. Simply sort the columns in Excel once you have the report to achieve your desired result!