AD on top of something that depends on it
-
Re: @scottalanmiller said in XenServer 6.2 servers down. I have no Xen skill. Most likely networking? Help!:
@NerdyDad said in XenServer 6.2 servers down. I have no Xen skill. Most likely networking? Help!:
I always try to make sure that I have an administrative local user to every system, just in case I cannot get to AD.
That, and never have AD on top of something that depends on it. That's like locking your keys in your car.
Reading through yesterday's super IPOD fail thread, I caught this statement and wanted to force @scottalanmiller to clarify an overly broad statement.
What should have been said is you do not build AD on top of something that only depends on AD.
In the modern, typically Windows based, SMB environment, there is almost never a reason for multiple domain controllers let alone multiple hypervisor hosts.
This means that you will have your AD on top of your system. This does not mean that your system cannot be joined to AD for management purposes.
In fact, from the Hyper-V side of things, this is the normal method.
None of that negates the ability to connect with non AD authenticated accounts to manage things.
You have to plan ahead and ensure something crazy like AD dependent storage is not sitting there, but AD joined hypervisors with AD on the hypervisor is nothing to be worried about.
-
@JaredBusch In that example, Hyper-V is not depending on AD, just using it. If it depended on it and AD went down, you'd have a different problem.
-
Interesting - You join Hyper-V to AD, can claim it's not dependent upon it... Yeah I suppose technically that's true as long as there is at least one non AD (local) account on Hyper-V that can access Hyper-V when AD is down.
This seems to be happening less and less though. For example, I disable all local accounts when I join a Windows machine to AD.
I suppose JB would say - well you idiot, don't disable the local account. Leave it there as a back door for yourself. and assuming you put a good password on it, I suppose that's doable. Definitely a consideration in the SMB.
-
Typically, when I am installing a system, I like to keep a local account with a strong password that only the IT manager and I know, while also adding AD authentication as well for more manageability. I believe that this is best practice because example like yesterday's episode. But this is generally more for systems that are not apart of the core infrastructure, such as the host or storage. When it comes to host and storage, the storage is isolated from the house network and just attached to the host. They both would use a set of credentials that are local and not tied to AD for reasons such as this.
I believe in wargaming with Murphy's law in my head. Can I foresee all possible failures? No, but hopefully I can be prepared for when Murphy attempts to change the playing field to the real world. In doing so, I try to mitigate as many risks as possible before they can happen.
-
You are shooting yourself in the foot for not having any local accounts. That is a big mistake. We have all seen workstations lose their trust relationship before and it could just as easily happen to servers.
You can make local accounts secure by completely disabling network access on them so they cannot UNC or connect to other servers on the network.
-
@Dashrender said in AD on top of something that depends on it:
Interesting - You join Hyper-V to AD, can claim it's not dependent upon it... Yeah I suppose technically that's true as long as there is at least one non AD (local) account on Hyper-V that can access Hyper-V when AD is down.
This seems to be happening less and less though. For example, I disable all local accounts when I join a Windows machine to AD.
I suppose JB would say - well you idiot, don't disable the local account. Leave it there as a back door for yourself. and assuming you put a good password on it, I suppose that's doable. Definitely a consideration in the SMB.
No, JB would say, FFS stop conflating shit. A hypervisor is not a server or desktop OS.
-
@JaredBusch said in AD on top of something that depends on it:
@Dashrender said in AD on top of something that depends on it:
Interesting - You join Hyper-V to AD, can claim it's not dependent upon it... Yeah I suppose technically that's true as long as there is at least one non AD (local) account on Hyper-V that can access Hyper-V when AD is down.
This seems to be happening less and less though. For example, I disable all local accounts when I join a Windows machine to AD.
I suppose JB would say - well you idiot, don't disable the local account. Leave it there as a back door for yourself. and assuming you put a good password on it, I suppose that's doable. Definitely a consideration in the SMB.
No, JB would say, FFS stop conflating shit. A hypervisor is not a server or desktop OS.
Or.... platform versus system.
-
This is like a certain company making software that would require authentication against the said company's systems and no local accounts. Not pointing any fingers, just saying.
-
It amazes me that so many IT people (not anyone on here) think domain controllers are some mythical, fragile creature that needs all these special exceptions and needs 100GB of RAM etc.
Back in the NT4 days, domain controllers were a fragile, mythical creature but not anymore. I remember praying to all the gods when demoting a NT4 or 2000 domain controller.
In Windows 2012, domain controllers are pretty simple and reliable. They also require minimal resources and should rarely be touched. DCs should not have a GUI anymore and you should be using RODC domain controllers when you can. Everything can be controlled remotely with a GUI interface via Server Manager so there is literally no need to remote into a DC anymore.
-
@JaredBusch said in AD on top of something that depends on it:
No, JB would say, FFS stop conflating shit. A hypervisor is not a server or desktop OS.
LOL same difference
