MPLS alternative
-
@Dashrender said in MPLS alternative:
Heck, I'd be surprised if Hobbit's company is encrypting data between sites - they are instead (management likely not realizing it) completely exposing their prints/fileshares with BT through their MPLS.
I guarantee that they are not. But they are not an in-house ISP. They are doing it for LAN traffic, not to build their own Internet backbone.
-
@Dashrender said in MPLS alternative:
what would you do for a management solution for 300+ users on company owned equipment?
It's not that easy to say what TO do. That requires a lot of research. But knowing what NOT to do is a lot simpler. AD is absolutely not a good solution for a lot of sites. Even Microsoft hasn't recommended that in a long time. That's why they moved to Azure AD internally as their product for that long ago.
We have no reason to believe that they even need user management, there's no way to have that assumption. I've worked in companies that size that saw zero value to having that and I see that play out time and time again. The need for user management on the OS is probably around 50/50.
So without even knowing if the need user management, it's impossible to even start to guess how best to approach it.
-
The need for user management at the OS level primarily comes from LAN-based design. Not 100%, but maybe 85%. Once you are LANless / Zero Trust, the need to control the users at the device level changes dramatically. There are good reasons to still want it, but it has to become a business need, not a "nice if all other things were equal." It comes at high cost and carries risks, so you have to have a value that supersedes those values to justify it.
-
@hobbit666 said in MPLS alternative:
Think more reading and seeing some examples might help my little head compute it all might help
Two simple examples...
LANbased Legacy User Management: Active Directory
LANless Alternative: JumpCloud, AzureADLANbased Legacy File Management: SMB or NFS Mapped Drives / Shares
LANless Alternatives: OneDrive, NextCloud, Google Drive, DropBox -
Another example of LANbased vs LANless thinking or approach...
Old Days: Log into your desktop and the desktop gives you immediate access to files, applications, etc.
Modern Way: Log into desktop, then log into applications so that the applications are not trusting the device but authenticate the user.
-
@scottalanmiller said in MPLS alternative:
@hobbit666 said in MPLS alternative:
Think more reading and seeing some examples might help my little head compute it all might help
Two simple examples...
LANbased Legacy User Management: Active Directory
LANless Alternative: JumpCloud, AzureADLANbased Legacy File Management: SMB or NFS Mapped Drives / Shares
LANless Alternatives: OneDrive, NextCloud, Google Drive, DropBoxThose i get, but what about printing to office printers, or accessing the Citrix farm.
As i said E-mails and files are getting slowly moved to o365 and OD4B -
@scottalanmiller said in MPLS alternative:
Another example of LANbased vs LANless thinking or approach...
Old Days: Log into your desktop and the desktop gives you immediate access to files, applications, etc.
Modern Way: Log into desktop, then log into applications so that the applications are not trusting the device but authenticate the user.
So how to you handle the "log into dekstop"? AzureAD or local user?
Then if we are using Office 365 Desktop apps like Word Excel can we use Single Sign On from AzureAD or would it be best to get the users to log in everytime? Same with OneDrive -
@hobbit666 said in MPLS alternative:
Those i get, but what about printing to office printers.....
So printing is a weird one. Typically printing desires physical proximity and no security. The nature of printing is insecure. Do you really need printing security? And do you really need to print from one site to another instead of printing locally? These things are possible, just really rare.
Printing does have options to use some LANless design, but typically we ignore this here as we are talking about a peripheral device that simply "doesn't matter" enough.
So I guess the real question is... since you can "just print" without any discussion or design whatsoever, what's the actual problem that you are trying to solve? I'm not sure what the question is. Whether you have LANbased or LANless design, if you hook up a USB printer you just print, if you hook up a network printer, you just print. They really fall outside of this discussion unless there is some extra factor that we can't anticipate.
-
@scottalanmiller said in MPLS alternative:
@Dashrender said in MPLS alternative:
Heck, I'd be surprised if Hobbit's company is encrypting data between sites - they are instead (management likely not realizing it) completely exposing their prints/fileshares with BT through their MPLS.
I guarantee that they are not. But they are not an in-house ISP. They are doing it for LAN traffic, not to build their own Internet backbone.
sure - but do you want your ISP snooping through your traffic? I definitely don't want Cox or anyone Cox allows on their network to see my traffic.
-
@hobbit666 said in MPLS alternative:
or accessing the Citrix farm
So this is already LANless, and requires no MPLS or VPN already. This only seems complex because it's already been made complex. But if you just deploy Citrix XenApp, it "just works". It's already functional with nothing more needed.
I know, because we do this here. This is another "it works by default", you have to break its default to have the issue.
-
@Dashrender said in MPLS alternative:
@scottalanmiller said in MPLS alternative:
@Dashrender said in MPLS alternative:
Heck, I'd be surprised if Hobbit's company is encrypting data between sites - they are instead (management likely not realizing it) completely exposing their prints/fileshares with BT through their MPLS.
I guarantee that they are not. But they are not an in-house ISP. They are doing it for LAN traffic, not to build their own Internet backbone.
sure - but do you want your ISP snooping through your traffic? I definitely don't want Cox or anyone Cox allows on their network to see my traffic.
And that's why YOU should never used a leased line!
-
@scottalanmiller said in MPLS alternative:
@Dashrender said in MPLS alternative:
what would you do for a management solution for 300+ users on company owned equipment?
It's not that easy to say what TO do. That requires a lot of research. But knowing what NOT to do is a lot simpler. AD is absolutely not a good solution for a lot of sites. Even Microsoft hasn't recommended that in a long time. That's why they moved to Azure AD internally as their product for that long ago.
We have no reason to believe that they even need user management, there's no way to have that assumption. I've worked in companies that size that saw zero value to having that and I see that play out time and time again. The need for user management on the OS is probably around 50/50.
So without even knowing if the need user management, it's impossible to even start to guess how best to approach it.
Don't limit this to just user management - what about device management?
-
@scottalanmiller said in MPLS alternative:
So this is already LANless, and requires no MPLS or VPN already. This only seems complex because it's already been made complex. But if you just deploy Citrix XenApp, it "just works". It's already functional with nothing more needed.
I know, because we do this here. This is another "it works by default", you have to break its default to have the issue.
How are they logging in? What authenticating the users?
-
@hobbit666 said in MPLS alternative:
So how to you handle the "log into dekstop"? AzureAD or local user?
Me here at my job? Local user. We have no need for a central point of compromise, we have nothing that would make that extra cost, complexity and risk offset. It would literally have zero value for us. But for those that need it, AzureAD works a lot like AD in how it allows you to sign in and is quite easy to use.
-
@hobbit666 said in MPLS alternative:
@scottalanmiller said in MPLS alternative:
So this is already LANless, and requires no MPLS or VPN already. This only seems complex because it's already been made complex. But if you just deploy Citrix XenApp, it "just works". It's already functional with nothing more needed.
I know, because we do this here. This is another "it works by default", you have to break its default to have the issue.
How are they logging in? What authenticating the users?
What's doing it today? Not the MPLS, because that has zero security. So what's doing it now for you?
-
@scottalanmiller said in MPLS alternative:
The need for user management at the OS level primarily comes from LAN-based design. Not 100%, but maybe 85%. Once you are LANless / Zero Trust, the need to control the users at the device level changes dramatically. There are good reasons to still want it, but it has to become a business need, not a "nice if all other things were equal." It comes at high cost and carries risks, so you have to have a value that supersedes those values to justify it.
I completely agree - though I assume that the company will want people to not use local admin accounts - or is that even over reaching?
-
@Dashrender said in MPLS alternative:
@scottalanmiller said in MPLS alternative:
@Dashrender said in MPLS alternative:
what would you do for a management solution for 300+ users on company owned equipment?
It's not that easy to say what TO do. That requires a lot of research. But knowing what NOT to do is a lot simpler. AD is absolutely not a good solution for a lot of sites. Even Microsoft hasn't recommended that in a long time. That's why they moved to Azure AD internally as their product for that long ago.
We have no reason to believe that they even need user management, there's no way to have that assumption. I've worked in companies that size that saw zero value to having that and I see that play out time and time again. The need for user management on the OS is probably around 50/50.
So without even knowing if the need user management, it's impossible to even start to guess how best to approach it.
Don't limit this to just user management - what about device management?
Those are very different things. AD is a user management system, but has no device management. So that's created a totally different discussion. Most people with AD use local device management via GPO. AD does a good job of making people think that GPO is centralized, but it is not. The info is centralized, but the management is done locally via a GPO agent on the Windows boxes.
-
@scottalanmiller said in MPLS alternative:
What's doing it today? Not the MPLS, because that has zero security. So what's doing it now for you?
We log into citrix workspace with our AD credentials
-
@Dashrender said in MPLS alternative:
@scottalanmiller said in MPLS alternative:
The need for user management at the OS level primarily comes from LAN-based design. Not 100%, but maybe 85%. Once you are LANless / Zero Trust, the need to control the users at the device level changes dramatically. There are good reasons to still want it, but it has to become a business need, not a "nice if all other things were equal." It comes at high cost and carries risks, so you have to have a value that supersedes those values to justify it.
I completely agree - though I assume that the company will want people to not use local admin accounts - or is that even over reaching?
Why would they care? Can someone care? of course. There are good cases for caring. There are good cases for not caring. In a LANless world, you don't necessarily care very often because you aren't in the business of trying to centrally control the device. But that doesn't mean you can't, or even shouldn't, but it's purely an option.
-
@hobbit666 said in MPLS alternative:
@scottalanmiller said in MPLS alternative:
What's doing it today? Not the MPLS, because that has zero security. So what's doing it now for you?
We log into citrix workspace with our AD credentials
So you already have a dangerous attack vector exposed across the MPLS today. But so there are two steps here....
- How to make XenApp LANless and the answer is "it already is."
- How to secure it given that it has a major security flaw in how it is tied to AD?
There are lots of ways to do number 2. And one of the answers can be VPN, but VPN meaning something wholly different from how you are using it with MPLS. It's using VPN as a 2FA tool, rather than as an encryption or LAN connection tool. This is the standard that most people do, because it's easy to understand and managers like hearing "VPN" because they don't get it. But this is the pattern "everyone" uses to secure XenApp, but it's nothing like what we were talking about with VPN for site to site connections. It's client to client connection from an end point directly to the XenApp server or farm.
