|
or don't run scripts that require elevated permissions in user environments
|
# ? May 8, 2024 16:18 |
|
|
# ? May 18, 2024 15:47 |
|
Ugh yeah the deprecation of the msonline PS commands and only allowing graph api calls has been a nightmare. Just getting a list of users with a filter has been troublesome and commands that are supposed to work return nothing. Not to mention the ps app needing admin consent.
|
# ? May 8, 2024 16:48 |
|
Submarine Sandpaper posted:Giving the help desk access to the CLI instead of converting the MSO script that cleared the 2fa for a user is not really helpful. az cli has like a dozen authentication options, including WAM which might allow for: Thanks Ants posted:Could you put the keys into the windows credential store using your MDM platform per user and have your script refer to this? my preference for this kind of thing is to have the scripts run remotely, and just provide an interface to trigger them using whatever task running tool you want from ADO to rundeck to whatever
|
# ? May 8, 2024 16:52 |
|
ptier posted:This is what we have ended up doing. Little boiler plate in the beginning of the script. The only thing I don't like / makes me not put it in "the wild" is that the secret is in the script. Could do a new one for each person... but we are transitioning to an integration platform where we are just going to turn all the scripts into forms. Its a long process but will get us further away from day to day powershell, which I find a bonus for all of our helpdesk staff unless they want to play and then they can learn with some training wheels. The Fool posted:az cli has like a dozen authentication options, including WAM which might allow for:
|
# ? May 9, 2024 03:35 |
|
Aunt Beth posted:We’ve moved towards institutionalizing the day to day powershell in Powershell Universal UIs, it’s such an extensible platform for $500/year we get so much value out of it That is really cool! Wish I had seen that like 5 years ago. For us, we have so many integrations we need to make between a ton of different systems an integration platform was the next step for us and using powershell to do advanced processing in AD was the main thing we need it for.
|
# ? May 9, 2024 13:47 |
|
It’s so good. And the scheduling engine it incorporates is so much better than task scheduler. Plus being able to create API endpoints has been very valuable too, we use it a lot to more or less function as a SQL stored procedure, you call the endpoint, pass it URL parameters, it runs a DB query using MSSQL powershell and returns JSON. But the UI I built that allows group and role management and other level 0/1 task delegation across both our on prem AD and Azure AD has been by far the most valuable.
|
# ? May 10, 2024 01:16 |
|
Boogalo posted:Ugh yeah the deprecation of the msonline PS commands and only allowing graph api calls has been a nightmare. I hate it all so much. A “solution” to a nonexistent problem.
|
# ? May 10, 2024 02:50 |
|
ptier posted:This is what we have ended up doing. Little boiler plate in the beginning of the script. The only thing I don't like / makes me not put it in "the wild" is that the secret is in the script. Could do a new one for each person... but we are transitioning to an integration platform where we are just going to turn all the scripts into forms. Its a long process but will get us further away from day to day powershell, which I find a bonus for all of our helpdesk staff unless they want to play and then they can learn with some training wheels. Can’t you keep the secret in Azure key vault then call it securely from your script with headless auth to lessen issues with having the secret in the script
|
# ? May 12, 2024 03:38 |
|
yes you can
|
# ? May 12, 2024 03:44 |
|
tehinternet posted:Can’t you keep the secret in Azure key vault then call it securely from your script with headless auth to lessen issues with having the secret in the script Yes, and now I know a thing. I will admit I did not dig into it much just because it was not going to be the solution we used anyways. So, yea, don't pay attention to the goon behind the curtain.
|
# ? May 13, 2024 19:18 |
|
Is it recommended to have a M365 global administrator that is excluded from conditional access policies with a strong password that never logs in and is just there in case you lock yourself out? Secondly, do you still use a separate admin account if you're using MFA and CA?
|
# ? May 14, 2024 01:52 |
|
kiwid posted:Is it recommended to have a M365 global administrator that is excluded from conditional access policies with a strong password that never logs in and is just there in case you lock yourself out? Yes, this is called a break-glass account and is usually tied to some alerting so that a bunch of alarms go off if it ever gets used. quote:Secondly, do you still use a separate admin account if you're using MFA and CA? Yes. Fairly standard separation of concerns. Separate privileged accounts should also have MFA and CA.
|
# ? May 14, 2024 02:05 |
|
I have: standard synced account (t2) elevated synced account with local windows admin on servers and sql and access to some azure resources (t1) GA cloud only account (t0) unsynced to M365 AD domain admin account (t0) test admin (t1) test standard (t2) exclude from conditional access sure, but leave MFA on if possible and have alerts on it. I would have to doublecheck our break glass M365 GA unsynced (t0) accounts, I believe they are MFA on but we multi registered our MS authenticators so both my boss and I can get in. There are two accounts. We have an alert on them that pings us if they get logged into at all. I do not remember where the password is I should check They were set up according to MS's M365 best practices. Fun thing about that is having the break glass accounts puts us over the recommended maximum number of assigned GA accounts so its impossible for us to pass both recommended controls. Hybrid AD/exchange is fun Oh yeah this doesn't count our 2nd prod tenant for a specific thing and the dev tenant Boogalo fucked around with this message at 02:30 on May 14, 2024 |
# ? May 14, 2024 02:17 |
|
How do you have MFA enabled on an account without CA? I think I tried this today with a test account and it still logs in without prompting MFA. Do you use the legacy per-user MFA to enforce it? edit: also holy poo poo that's a lot of accounts.
|
# ? May 14, 2024 02:23 |
You can set a MFA tenant security policy and/or set on the user object iirc.
|
|
# ? May 14, 2024 02:41 |
|
I have: Standard user account, has MFA, no elevated permissions Cloud admin account, has MFA, has contributor on all of our subscriptions plus admin access on a couple of external services, can PIM for User Admin, Application Admin, and Role Admin Domain admin, no mfa but requires a jump box, not synced to entra, but I only need to use this like once a year With PIM and CA, I definitely look sideways at environments with a bunch of distinct accounts these days.
|
# ? May 14, 2024 05:23 |
|
In the past I've seen GA without any CA but I think that's.... not wise If anything two GA break-glass accounts with MFA and using FIDO2 Key with a Yubi Key and PIN is perfect.
|
# ? May 14, 2024 07:07 |
|
Next question. Does anyone use device filtering in conditional access policies? If so, am I supposed to use the Device ID or the Object ID? The policy says "DeviceID", but it didn't work until I added the Object ID.
|
# ? May 14, 2024 14:46 |
|
Not an answer to your question, but when working with application registrations and enterprise apps I can never keep straight if I'm supposed to use the application id, or the object id of the application registration or the enterprise app. It feels like it's different every time and the documentation isn't clear.
|
# ? May 14, 2024 14:56 |
|
Never mind, I removed the Object ID and it was still working. I then removed the Device ID and it stopped working. I added back the Device ID and it started working again. Seems it was one of those things where I should have waited 15 minutes for the change.The Fool posted:Not an answer to your question, but when working with application registrations and enterprise apps I can never keep straight if I'm supposed to use the application id, or the object id of the application registration or the enterprise app. It feels like it's different every time and the documentation isn't clear. I agree, I've been developing an intranet app that uses M365 oauth/saml and there are actually 3 IDs. Application, Object, and Tenant. I was using the wrong ID combinations for a little bit. Confusing.
|
# ? May 14, 2024 15:10 |
|
"Waiting 15 minutes" is always the way with a lot of this M365 stuff. Especially when you're doing stuff in Teams and PSTN.
|
# ? May 14, 2024 16:10 |
|
Thanks Ants posted:"Waiting 15 minutes" is always the way with a lot of this M365 stuff. Especially when you're doing stuff in Teams and PSTN. We call it "cloud time" around these parts. Especially with Intune and waiting for policies to apply. Out of 16 PCs, 12 will do it right away and then 4 will take like half a day because CLOUD TIME!
|
# ? May 14, 2024 18:21 |
|
|
# ? May 18, 2024 15:47 |
|
Found that with Exchange Online authentication policies, sometimes you make the policy change a few minutes before it's due to refresh anyway, other times it takes four hours.
|
# ? May 14, 2024 18:35 |