Moving from Physical AD/Data Server to Office365
-
@BRRABill said in Moving from Physical AD/Data Server to Office365:
I guess the question is ... do we just scrap our AD, and use our Office365 accounts to log in. Do we really need anything more than that?
I don't see why not. What is AD providing for you?
-
@dbeato said in Moving from Physical AD/Data Server to Office365:
@PhlipElder said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
So our company has finally decided to make the jump to all remote.
We are small (let's say 10 people) but we used to be large, so we have a AD domain.
Right now we have a local DC and a local data server. We also use Office365 for e-mail and, of course, Office.
There is no RIGHT answer here, but if you were doing this ... what would you do?
I think there are two parts to look at...
- Keep some sort of AD authentication, or not?
- What to do with data?
For #1 ... I'm not sure.
For #2 ... I am thinking throw the common files onto SharePoint, and put everyone's "home" folder into OneDrive for Business. With 10 people, it won't be hard to do that for each user.
So ... let's hear it, ML ... WWMLD?
1: Yes. AD Sync for on-premises user management works both ways. It does make things simpler to manage.
2: OneDrive for Business is SharePoint on the backend. It's great for setting up things like Check Out/In, Versioning, and Review controls. Permissions based folder and site visibility (think Access-based Enumeration in Windows) are also a big plus.You can do it, but I do suggest keeping a small domain controller on-premises for simplicity in management.
EDIT: BTW, the customer is always responsible for backing up the data in any cloud. I suggest Veeam Backup for O365.
AD Sync does not go both ways, you will need to have sync back licensing which are expensive to get password synchronization and if there is any luck getting the user and group sync back from Office 365 to AD. It is just an additional layer of complexity that while it has its cases is not needed for a company this size.
And it's not fully reliable. It's famously fragile, complex and buggy. Even when MS themselves implement it.
-
@BRRABill said in Moving from Physical AD/Data Server to Office365:
Correct. Local AD for machines and data security.
AD is for management convenience. It provides no security.
-
-
@BRRABill said in Moving from Physical AD/Data Server to Office365:
Just
a) logging into our machines
b) network securityAD provides NO security. Not a thing.
-
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
You don't need AD to log into your machines. In fact, it only makes that harder.
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
So for logins, AD is considered to work against you, not for you, till you get another user or two. And just break even at that point.
-
@Obsolesce said in Moving from Physical AD/Data Server to Office365:
uses Office365 email and Office suite. Nothing more than that, at all. Only going by that, then sure, if you want to keep using
Personally, I'd ditch AD (the stuff you get from on-prem Windows Server - or colo'ed and likely VPN connected server) - you don't need it anymore.
If everyone is working from home, you don't even need to bother with people logging their machines themselves into AAD unless you want to manage those machines - then, might be worth while. Plus, but logging Windows10 into an AAD account, using O365 services all just go, no extra logons required.
Definitely push all personal files to ODfB, and shared to Sharepoint.
Now for the backup solution.
Yes, we know that AD does not provide security - But AD does provide the user list that other things like NTFS or share permissions do use. Of course those things aren't limited to only using AD for their user list, but it's the most common. -
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
-
Now, that said - in this situation I too would ditch AD, it's just extra you don't need.
Since you have O365, you can join the Win10 machines to ADD. then your users can log into their machines using their ADD accounts. You do get some level of control from the free version of ADD included in O365, but nothing like GPO on AD.
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
Now, that said - in this situation I too would ditch AD, it's just extra you don't need.
Since you have O365, you can join the Win10 machines to ADD. then your users can log into their machines using their ADD accounts. You do get some level of control from the free version of ADD included in O365, but nothing like GPO on AD.
The one caveat that I don't think is resolved as of yet:
Local PC set up. User logs on first time with Azure AD. PC is Azure AD joined. User then has MFA. User can then log on and work without MFA prompts going forward.
Catch #1: User will not be able to remote into that PC using RDP. Third party yes, but not RDP.
Catch #2: The PC is tattooed to Azure AD. One cannot join a local AD anymore (IIRC).Managing more than one or two PCs without AD/Group Policy is pure PITA. No peer-to-peer here. No way.
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
FFS.. Why the fuck would there be 10 local users on each machine?
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
but it's the most common.
Which alone means you should question it heavily, because "most common" means "everyone who doesn't do a good job defaults to this". That doesn't make it wrong to use, but should mean that it is highly suspect and requires serious vetting to consider.
-
@PhlipElder said in Moving from Physical AD/Data Server to Office365:
tattooed to Azure AD. One cannot join a local AD anymore (IIRC).
But they will be all working remote, not need to be tied to AD anymore.
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
Nope, maintaining just one, like any normal person.
-
@PhlipElder said in Moving from Physical AD/Data Server to Office365:
Managing more than one or two PCs without AD/Group Policy is pure PITA. No peer-to-peer here. No way.
Totally untrue. First, AD and GP are not connected. You can use either without the other.
Second, neither is even all that good for management. They kinda work, but they are far from efficient. And especially in the modern people working from home work, they fall over like never before.
Even with hundreds of machines, we only consider these sometimes, because in many scenarios you can maintain hundreds of machines better, and more easily, without them.
Even Microsoft has never, ever recommended using them at such a small scale. Below about a dozen, they are just completely in your way pretty much no matter what you do. Above a dozen, even MS only considered them "one" option. A big one, but just one. The idea that there is any scale where they simply make sense all or even nearly all of the time is just fantasy land. They are crufty, complicated tools that depend on a really niche setup that was popular in the 1990s and is almost always existing today only to shoehorn in these antiquated technologies.
-
@dbeato said in Moving from Physical AD/Data Server to Office365:
@PhlipElder said in Moving from Physical AD/Data Server to Office365:
tattooed to Azure AD. One cannot join a local AD anymore (IIRC).
But they will be all working remote, not need to be tied to AD anymore.
No reason before either, it turns out. Like most AD deployments, the reasons given for it were mistakes. From what we see in online discussions and as an MSP, the majority of AD deployments are done by mistake. Either because people believe that they are a requirement (it's common on
to believe that NTFS and SMB are turned on by AD) or that it provides security or is effective for small scale user management. Some combination of the myths around it seem to drive most small deployments of it with people not understanding what they are actually deploying.Of larger deployments, most existed so long ago that modern assessments have not been done.
-
@scottalanmiller But you gotta provide the option of an RMM Or agent correct? Because yes you can do scripting but you still need something to deliver it and not doing it manually. While GP can be used without AD, I would say that using GPOs manually is way more PITA than GPO on an AD. That is a discussion for another topic.
-
@dbeato said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller But you gotta provide the option of an RMM Or agent correct? Because yes you can do scripting but you still need something to deliver it and not doing it manually. While GP can be used without AD, I would say that using GPOs manually is way more PITA than GPO on an AD. That is a discussion for another topic.
Yes, but there are a plethora of options. The question isn't "what's the right approach", the question is "do I need to do this one approach."
And at this skill, generally the best option is "do nothing". The idea that we need this kind of management at all on this scale is weird. There are cases, yes, but it is not the norm.
-
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@dbeato said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller But you gotta provide the option of an RMM Or agent correct? Because yes you can do scripting but you still need something to deliver it and not doing it manually. While GP can be used without AD, I would say that using GPOs manually is way more PITA than GPO on an AD. That is a discussion for another topic.
Yes, but there are a plethora of options. The question isn't "what's the right approach", the question is "do I need to do this one approach."
And at this skill, generally the best option is "do nothing". The idea that we need this kind of management at all on this scale is weird. There are cases, yes, but it is not the norm.
That's reasonable, I do agree is a case by case basis which often than not is not super needed.
-
@JaredBusch said in Moving from Physical AD/Data Server to Office365:
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
FFS.. Why the fuck would there be 10 local users on each machine?
I'll agree that in most - not just 50%, probably more than 95%, machines are frequently 1 to 1.
But I have a situation you clearly know about - it's 7 machines and 10 people over all of them. With a centralized auth setup, either, they all use one account, or I have 10 accounts on all 7 machines.
