|
bobua posted:I read about that, but it seemed that was meant for azure based virtual machines. Seemed possible to sort of get it to work via vpn, but felt hacky. You can use just good old AAD for azureVM management. This is so you can still ldap to your m365 tenant iirc
|
#
?
Aug 30, 2022 16:15
|
|
|
|
| # ? Apr 26, 2024 06:14 |
|
|
bobua posted:Jesus christ this is frustrating. Yes. In AAD under the user object and security you'll find any whfb or 2fa devices used from the user. This isn't a PW so you would not want it syncing.
|
|
#
?
Aug 30, 2022 16:18
|
|
|
bobua posted:Jesus christ this is frustrating. If they have a FIDO key they can authenticate using that on whichever device they walk up to. If you want people to use a password then you can do that, you have to turn off Windows Hello. Hello is a much better system though as it allows authentications to happen via the token stored in the TPM of the machine so you throw fewer requests in front of your user for them to authenticate if they are using devices that pass all your compliance checks.
|
|
#
?
Aug 30, 2022 16:18
|
|
|
bobua posted:I read about that, but it seemed that was meant for azure based virtual machines. Seemed possible to sort of get it to work via vpn, but felt hacky. Yea. It is hacky. Because MS doesn't want you doing it. It's really designed for when you have legacy apps that don't support modern standards. Modern AAD-only is better in situations where it works, but worse in situations where it doesn't work. I don't mean that in a dismissive "you should know this!" kind of way, just trying to describe modern reality with a shrug.
|
|
#
?
Aug 30, 2022 16:28
|
|
|
bobua posted:Jesus christ this is frustrating. Yes, it doesn't sync. As someone else mentioned, it's not something you want to sync for security reasons. Think of it like this, a user has their cloud identity, which can be logged into from anywhere. That's different than traditional AD and has security implications. So one of the ways we deal with that is seeing what device people are logging into and assigning a token or temporary trust to their device. Log in using your Azure AD credentials the first time, do a modern auth with MFA, check the device out, then say "yes, this user can log into this machine. Let's set up a way for them to log in easily that isn't using their 'full' authentication each time, because every time a user uses that 'full' authentication it increases risk." I agree. It can often be difficult to get a feel for the broad strokes of something from documentation. I'd look for some Ignite talks on the topic of identity management and modern desktop. You're a bit behind and jumping into the deep end on something that differs quite a bit from your current experience. Internet Explorer fucked around with this message at 17:04 on Aug 30, 2022 |
|
#
?
Aug 30, 2022 16:42
|
|
|
If you need a feel for it then have a play with https://docs.microsoft.com/en-us/microsoft-365/enterprise/modern-desktop-deployment-and-management-lab?view=o365-worldwide
|
|
#
?
Aug 30, 2022 16:59
|
|
|
Also, once you remap your mental model, passwordless authentication using something like MS Auth is absolutely the loving poo poo. My password is super long and annoying, but all I have to do is match two numbers on my phone? AND it's more secure? Yes please.
|
|
#
?
Aug 30, 2022 17:04
|
|
|
Passwordless? I'm trying to herd 20 SaSS into SSO. I can't keep breaking these users minds.
|
|
#
?
Aug 31, 2022 01:16
|
|
|
I promise you, no one is going to complain about not needing to remember a password.
|
|
#
?
Aug 31, 2022 01:38
|
|
|
the hardest thing about migrating to sso is convincing the end users that yes, it is actually that easy
|
|
#
?
Aug 31, 2022 01:45
|
|
|
Especially AAD vs ADFS or ping/okta/whatevet
|
|
#
?
Aug 31, 2022 14:34
|
|
|
At a high level: A user logging into a computer that is AAD joined for the first time the same as a user logging in to a computer that is AD joined for the first time: the identity provider lives somewhere other than the laptop and needs to thus be reachable. If the user fucks up, you need to reset their password in the identity provider, then the user needs to make sure that fair hotel Wi-Fi is configured right so that they can also connect to the identity provider. A user logging in to a computer that is AAD joined for the first time and they also have a Fido token is way the hell easier than anything else before. Once you get Hello for Business trust set up right, it just works. A user returning to an offline laptop that is AAD joined is the same as a user returning to a laptop that is AD joined. The user enters a credential that is validated against a locally cashed trust store, and is then permitted to access the laptop. At a high level, the difference between AAD and AD is that one of them is available anywhere, receiving development, and will do a pretty good job of securing your poo poo. The other requires an FTE to maintain securely as well as dedicated specialized subject matter expert talent in your SOC, if you have one at all. Most businesses do not have the resources to deploy or maintain active directory and should not be doing it anymore. I hope this helps. Potato Salad fucked around with this message at 17:35 on Aug 31, 2022 |
|
#
?
Aug 31, 2022 17:30
|
|
|
Wizard of the Deep posted:Also, once you remap your mental model, passwordless authentication using something like MS Auth is absolutely the loving poo poo. My password is super long and annoying, but all I have to do is match two numbers on my phone? AND it's more secure? Yes please. I think this is the trick right here. It's maybe easier to think of the access token that's stored on a laptop's local AAD Passport (a registry, if you will, of who has logged in when, what methods were used to authenticate them, what methods should be used in the future if at all) as a virtual smart card with a pin or fingerprint reader. First: When the user logs into a computer for the first time, the computer talks to Azure AD and, upon successful authentication and validation of authorization, synthesizes what's....huh, actually very similar in cryptographic capabilities to a virtual smart card for that user in the local Passport. Next: Just like how a smart card can require a pin or a thumbprint or whatever fancy schmancy hardware the manufacturer of the smart card wants to glue on as a second factor to release the credentials on the physical card, the virtual smart card on the local AAD Passport can be configured to only release the cloud authentication token for the user if a Hello for Business pin, thumbprint, face id, or whatever is recognized. In this way, the passport's stored credential is metaphorical for the secret stored on a physical smart card, the secret's release mechanism that is usually hardware defined in the real world is instead defined and controlled by Hello for Business, and the release factor is built into the laptop or entered as a pin. Finally: if the user ends up loving up with a physical smart card enough times and the smart card is smart enough, they would have to walk to a security desk and have the release mechanism reset. what's nice with Azure AD is that the user can launch this reset process from the laptop itself pre-login: essentially, they would use their O365 account credentials to validate against Azure itself (the security guard in this case), Azure also confirms whether the stored passport token is also valid, and if everything matches up, allows the user to choose a new PIN or re-register their thumb/face/buttprint. so, if the user fucks up in the lock out their pin, their online user account is the recovery factor. if they also happen to gently caress up their online account, the user can call IT and get their online account unfucked through whatever process you decided is best, then go and unfuck their local Hello for Business with their laptop and hotel wifi I am wondering if putting this in terms of how smart cards used to work makes any sense for you Potato Salad fucked around with this message at 17:56 on Aug 31, 2022 |
|
#
?
Aug 31, 2022 17:53
|
|
|
Enterprise Windows Q&A: Hello for Buttprint
|
|
#
?
Aug 31, 2022 17:56
|
|
|
Potato Salad posted:Enterprise Microsoft Q&A: Hello for Buttprint I think it's time this thread grew while encapsulating the spirit of what came before it. Azure stands on the giants of small business server.
|
|
#
?
Aug 31, 2022 18:11
|
|
|
This all started as me having some ConfigMgr questions as I was just getting started with the tool, and since then I've changed jobs to one where I was the highest tier SME in the entire org around ConfigMgr. And then I've slowly transitioned off that into more general "Microsoft Server" stuff with a big healthy dollop of Azure stuff. I know there's an AWS thread, but no generic "cloud" thread, and no "Azure" thread. "Enterprise Microsoft Q&A: Hello for Buttprint" probably encompasses Azure as a cloud platform plus managing devices in a "modern" way, although it'd be nice if it had Azure in the title. Maybe "Enterprise Microsoft/Azure Q&A: Hell for Buttprint". There's no OP and I couldn't be arsed to write one anyways. But I could throw some more links there, I guess write a few words about the "scope" of the thread. Or hell we could make a new one.
|
|
#
?
Aug 31, 2022 20:31
|
|
|
The landscape is ever changing so idk why you'd give yourself a documentation job for this forum. That'd be like moderating it
|
|
#
?
Aug 31, 2022 20:38
|
|
|
I agree. Let's change the name to reflect this being the Azure thread as well.Submarine Sandpaper posted:The landscape is ever changing so idk why you'd give yourself a documentation job for this forum. That'd be like moderating it No thank you!
|
|
#
?
Aug 31, 2022 20:42
|
|
|
...oh poo poo!
|
|
#
?
Aug 31, 2022 23:08
|
|
|
I saw a Sun demo ages ago with their thin clients and smartcards and it was magical, someone would sit down and shove their ID badge into the client and their desktop would appear, they'd pull the badge out and it would go away again instantly. They moved to another thin client and the session would appear again instantly. It looked insanely useful for things like healthcare. I've no idea if Windows ever got something as slick as that.
|
|
#
?
Sep 1, 2022 00:38
|
|
|
RDS can do it, I've seen it, but it's often just easier to build a chain of trust that's Good Enough for Most Identity then leave harder things like RDG/RDSH integration with H4B by the wayside the rising popularity of autopilot is probably shoring up some of the gaps in the trust/signals chain, at least
|
|
#
?
Sep 1, 2022 01:25
|
|
|
How often do you delete a user account in M365 vs. just blocking sign in and removing license? I just joined and org and we have hundreds of inactive accounts that are either old employees or external users and my OCD wants to delete them but I’m scared to. Additionally, when I look at reporting in Azure AD, it makes it look like a high percentage of my users don’t have MFA set up, etc etc when really the active users do. Anyway, should I care about these inactive or external user accounts?
|
|
#
?
Sep 2, 2022 21:17
|
|
|
Yes, but no if you have reason to keep them which could be as simple as "legal or bob said".
|
|
#
?
Sep 2, 2022 21:31
|
|
|
If they're inactive and unlicensed, it probably doesn't really matter that much, as long as you have good reporting on accounts being reactivated. I would still probably automate the process around deleting old accounts after, say 3-6 months. It's good security hygiene to remove accounts that aren't expected to be necessary any more, and it'll shrink the haystack when you're looking for a needle. There's a separate setting in Exchange Online/O365 to mark a mailbox for legal/audit holds. Something that's cyclical (like a VP's nibling that gets to be an intern every summer, or seasonal workers that return regularly every year) would probably get their own role protecting them from clean-up. I haven't had to touch it in a while, but I remember there was a weird issue in Azure where the MFA was reported wrong in one place, and another area where it's right. I think the info you can pull from the PowerShell module is generally the correct choice, but verify that independently.
|
|
#
?
Sep 2, 2022 21:35
|
|
|
It's my job to follow up with managers every 30 days on whether they want an account to continue being active or if IT can delete. Even our ex-CEO's account was deleted after 90 days.
|
|
#
?
Sep 2, 2022 22:36
|
|
|
Delete them just so you don't have hundreds of entries appearing for people who don't work at the company when you try and do normal tasks like adding people to groups. If deleting an account breaks a process then it's good that you find that out.
|
|
#
?
Sep 2, 2022 22:45
|
|
|
these days it is honestly better to get into the practice of deleting things instead of holding on to things
|
|
#
?
Sep 2, 2022 23:22
|
|
|
Potato Salad posted:these days it is honestly better to get into the practice of deleting things instead of holding on to things this also does not only apply to technology
|
|
#
?
Sep 3, 2022 01:48
|
|
|
Submarine Sandpaper posted:Yes, but no if you have reason to keep them which could be as simple as "legal or bob said". Wizard of the Deep posted:If they're inactive and unlicensed, it probably doesn't really matter that much, as long as you have good reporting on accounts being reactivated. I would still probably automate the process around deleting old accounts after, say 3-6 months. It's good security hygiene to remove accounts that aren't expected to be necessary any more, and it'll shrink the haystack when you're looking for a needle. There's a separate setting in Exchange Online/O365 to mark a mailbox for legal/audit holds. GreenNight posted:It's my job to follow up with managers every 30 days on whether they want an account to continue being active or if IT can delete. Even our ex-CEO's account was deleted after 90 days. Thanks Ants posted:Delete them just so you don't have hundreds of entries appearing for people who don't work at the company when you try and do normal tasks like adding people to groups. If deleting an account breaks a process then it's good that you find that out. Potato Salad posted:these days it is honestly better to get into the practice of deleting things instead of holding on to things nexxai posted:this also does not only apply to technology Would any of you be open to chatting with me for 30 mins to take a look at what I’m dealing with? If so, please PM me. Thank you!
|
|
#
?
Sep 8, 2022 16:49
|
|
|
I'm currently pricing SQL Server licensing for a 3-node HA cluster (1x8C16T CPU per node). MSRP is about CAD $14,344 per node totalling CAD $43,032 which when it comes to SMB is insanity in my opinion. Alternatively, we can go the CAL route with 50x CALs totalling CAD $10,450 + $899 for the server license. Currently the server is accessed strictly by internal employees. However, my problem is that in the next year or two we will be launching a custom CRM with a customer portal that pulls customer data from our ERP database and delivers it to the customer's dashboard (open contracts, etc.). My understanding is that a portal that a customer logs into with their own account will require a CAL for each login which would get pretty out of hand and could potentially end up being more expensive than the core licensing. So, my options are to either suck it up and pay the core licensing or I was considering using SSIS and build an ETL pipeline to export data to a MySQL database which the customer would hit instead. This data would be refreshed nightly and wouldn't be real-time and considering the CRM will run in a Linux environment anyway, could work out. Anyone got a better idea? edit: Another alternative would be using VM affinity to have the SQL VM only able to migrate between 2-nodes rather than 3 which would cut the cost down to a measly $30k instead. kiwid fucked around with this message at 20:46 on Sep 8, 2022 |
|
#
?
Sep 8, 2022 20:36
|
|
|
at least use postgre for ETL, mysql is long in the tooth that's not a bad plan, if the nightly refresh is acceptable and you don't need immediate writeback if timeliness may become important down the road, you might need core licensing now :/
|
|
#
?
Sep 8, 2022 20:46
|
|
|
Potato Salad posted:if the nightly refresh is acceptable It's possible that a nightly refresh will no longer be acceptable and real-time data (or close to real-time) necessary, unfortunately. Running the ETL job every 5 minutes could still work but at that point I get concerned about performance unless I design the pipeline intelligently to only grab new and updated data rather than truncate. Ugh... why the gently caress is this poo poo so expensive?
|
|
#
?
Sep 8, 2022 20:54
|
|
|
when people start expecting realtime data, synchronization works up to a point.... but the absolute bare moment that somebody starts to want to writeback from the crm, you're hosed and consistency is no longer possible yeah it's loving expensive, I'm so sorry edit: supporting that high frequency etl pipeline from a hardware/  perspective would also end to being expensive in its own right, heckdo it raw, do it live Potato Salad fucked around with this message at 21:10 on Sep 8, 2022 |
|
#
?
Sep 8, 2022 21:07
|
|
|
You know, you *can* create an MSSQL Failover Cluster with two nodes and a witness. If your infrastructure does a good job of staying up, consider maybe saving cost here. It may not represent that much risk.
|
|
#
?
Sep 8, 2022 21:19
|
|
|
kiwid posted:I'm currently pricing SQL Server licensing for a 3-node HA cluster (1x8C16T CPU per node). MSRP is about CAD $14,344 per node totalling CAD $43,032 which when it comes to SMB is insanity in my opinion. Are you working with a DBA on this stuff? Hopefully one that isn't clueless. If not, I'd try to find someone with those skills. Doing this solely from the infrastructure point of view is likely to cause problems in the future if there's growth.
|
|
#
?
Sep 8, 2022 21:24
|
|
|
kiwid posted:I'm currently pricing SQL Server licensing for a 3-node HA cluster (1x8C16T CPU per node). MSRP is about CAD $14,344 per node totalling CAD $43,032 which when it comes to SMB is insanity in my opinion. Are these 3 physical servers running SQL server, or just a VM running on that cluster? If it's just a VM should be able to cover just licensing the VM regardless of the underlying VM infrastructure assuming you have software assurance. Anything with external users pretty much rules out CAL based licensing otherwise.
|
|
#
?
Sep 8, 2022 23:18
|
|
|
Internet Explorer posted:Are you working with a DBA on this stuff? Hopefully one that isn't clueless. If not, I'd try to find someone with those skills. Doing this solely from the infrastructure point of view is likely to cause problems in the future if there's growth. I assume you are referring to the ETL pipeline? It's something we already have established for our data warehouse but no, it'd be me, the sole IT guy here doing this. Maneki Neko posted:Are these 3 physical servers running SQL server, or just a VM running on that cluster? If it's just a VM should be able to cover just licensing the VM regardless of the underlying VM infrastructure assuming you have software assurance. Anything with external users pretty much rules out CAL based licensing otherwise. It's just a single VM running on the cluster. I haven't reached out to my Microsoft licensing vendor yet to confirm but from what I've gathered, you need to license by physical cores and not VM. Then you also need to license each physical server cores that the VM might be booted up on via HA. It's like the Windows Server Standard licensing I suppose. If you have 6 VMs running on one physical machine then you can get away with 3 licenses (2 VMs per license). But if you have a 2-node HA cluster, you would need to license 3 per node, even if you only ran 3 VMs per node normally to allow for each node to boot up all 6 VMs in the event of a failure. Am I wrong? kiwid fucked around with this message at 16:19 on Sep 9, 2022 |
|
#
?
Sep 9, 2022 16:11
|
|
|
You can buy MSSQL licenses as a subscription to run on-prem through the CSP programme, speak to your reseller. This might be better than buying the licenses.
|
|
#
?
Sep 9, 2022 16:24
|
|
|
Thanks Ants posted:You can buy MSSQL licenses as a subscription to run on-prem through the CSP programme, speak to your reseller. This might be better than buying the licenses. Never heard of that but I'll check it out, thanks.
|
|
#
?
Sep 9, 2022 16:26
|
|
|
|
| # ? Apr 26, 2024 06:14 |
|
|
kiwid posted:It's like the Windows Server Standard licensing I suppose. If you have 6 VMs running on one physical machine then you can get away with 3 licenses (2 VMs per license). But if you have a 2-node HA cluster, you would need to license 3 per node, even if you only ran 3 VMs per node normally to allow for each node to boot up all 6 VMs in the event of a failure. You are not correct, for SQL server running on a VM you can just license the number of cores assigned to the VM (with a minimum of 4). If you are running a bunch of VMs on your cluster it makes more sense to look at other options, but that does not sound like your case. For DRS type situations as far as I'm aware you don't even need to worry about SA but any competent Microsoft licensing vendor should be able to confirm that. quote:With SQL Server, you can: https://www.microsoft.com/en-us/Licensing/product-licensing/sql-server Maneki Neko fucked around with this message at 20:07 on Sep 9, 2022 |
|
#
?
Sep 9, 2022 20:04
|
|