System Admin - checklist for Don'ts and Important points please!
-
@openit said in System Admin - checklist for Don'ts and Important points please!:
- Not recommended to convert Physical Server which has Domain Controller to Virtual Machine.
- Need to choose right Generation (1 or 2) type VM on Hyper-V, because later we can't change the generation.
- Don't set Static IP of some server/machine without consulting Network Team, to avoid conflicts with existing DHCP scope.
Your inputs matters a lot to me, and might help others in community as well.
Thanks!
1: That depends. A DC could be virtualized until such time as one is ready to run a full migration. Server 2019 ADDS requires DFSR. So, existing FRS DCs would need to be migrated to DFSR first. This is an invasive process that requires System State backups of FSMO/PDCe and at least one secondary DC.
2: Always Gen2 unless the OS to be dropped into the VM does not support it. P2V of older workloads for example. Use what is required.
3: The subnet should be documented somewhere. MAC addresses, IP addresses, DHCP scope(s), DHCP settings, and so on. Advanced IP Scanner is free and is a good place to start if none exist. There are other tools out there.
4: Group Policy: Follow best practices. Don't touch the Default Domain and Default Domain Controllers policies. Always set up the OU/GPO structure and settings according to the org's needs.
5: Hyper-V standalone: We don't join the host to the guest's domain. It presents a barrier to a ransomware compromise.
6: Backup: A backup is not considered "Good" until it is fully bare metal/hypervisor restored. Spot file/folder restores are not a verification method.
7: No Remote Desktop Protocol (RDP) port forwards (NAT) from the Internet (alternate port) to 3389 on the intended destination. Ever. Use Remote Desktop Gateway and add DUO or other 2FA to the mix.
-
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
7: No Remote Desktop Protocol (RDP) port forwards (NAT) from the Internet (alternate port) to 3389 on the intended destination. Ever. Use Remote Desktop Gateway and add DUO or other 2FA to the mix.
Is this because only RDG supports MFA? not the end clients themselves?
-
@Dashrender said in System Admin - checklist for Don'ts and Important points please!:
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
7: No Remote Desktop Protocol (RDP) port forwards (NAT) from the Internet (alternate port) to 3389 on the intended destination. Ever. Use Remote Desktop Gateway and add DUO or other 2FA to the mix.
Is this because only RDG supports MFA? not the end clients themselves?
Because RDG provides a layer of protection against TSGrinder and its cohort.
It's bad news to publish an RDP listener direct to the Web. Has been for a very long time now.
-
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
@Dashrender said in System Admin - checklist for Don'ts and Important points please!:
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
7: No Remote Desktop Protocol (RDP) port forwards (NAT) from the Internet (alternate port) to 3389 on the intended destination. Ever. Use Remote Desktop Gateway and add DUO or other 2FA to the mix.
Is this because only RDG supports MFA? not the end clients themselves?
Because RDG provides a layer of protection against TSGrinder and its cohort.
It's bad news to publish an RDP listener direct to the Web. Has been for a very long time now.
Not any worse than publishing any service to the web without some third party control (fail2ban, etc).
Stupid people using stupid weak passwords is not a failure of the protocol.
-
@openit said in System Admin - checklist for Don'ts and Important points please!:
Not recommended to convert Physical Server which has Domain Controller to Virtual Machine.
Better first rule: Don't make "specific" rules. Figure out the underlying technical reasons for things and make rules based on underlying technology.
Example: People say not to P2V a DC. But you only have to say this because people don't understand the basics. So let's break it down and expose the general rule that if people knew, they'd not have to memorize specifics.
DCs are typically distributed databases. DDBs require the full cluster to be coherent. They are clusters requiring the cluster to be treated as a single entity, because it is. You can't isolate a node within the cluster and change its data or it becomes corrupt.
So because we know that a DC is designed to be used in a DDB cluster, and that clusters can't have isolated node manipulation we then know that we can't snapshot, restore, roll back, etc. any of their nodes.
Next we need to understand what a P2V is. It's a snapshot of a machine, then the snap is put into a file based container (like a VHD or QCOW), drivers are injected for the desired platform, and it is then fired up on top of a hypervisor.
So since we know that clusters can't be snapshotted.... we then know that AD DCs can't be P2Vd unless they are standalone or some other mechanism detects that action and addresses it.
Voila, know what a DC is and how it works (which is really trivial stuff) and how databases, clusters, snapshots, etc. work and you don't need to memorize anything and suddenly you find that this same knowledge applies to hundreds of other things you deal with every day.
-
@openit said in System Admin - checklist for Don'ts and Important points please!:
Need to choose right Generation (1 or 2) type VM on Hyper-V, because later we can't change the generation.
Okay, but general rule... don't make haphazard decisions without research. Trying to memorize tricky details like this will make you go crazy. The number of these kinds of itty bitty details will go on forever and are 100% dependent on the specific technology that you choose to use.
Why not make the rule that you use KVM instead of Hyper-V, BTW?
-
@openit said in System Admin - checklist for Don'ts and Important points please!:
Don't set Static IP of some server/machine without consulting Network Team, to avoid conflicts with existing DHCP scope.
Or use DHCP to do it. Even better in most cases.
-
@IRJ said in System Admin - checklist for Don'ts and Important points please!:
You should focus on what to Do instead of Don't. If you think at least didn't do this, you still wont be making the best decisions.
Agreed. What not to do will go on forever. There's no end to what not to do.
-
@IRJ said in System Admin - checklist for Don'ts and Important points please!:
Having a list of DOs is even silly. It you want to know about a particular area like domain controllers, then research about domain controllers. Your 1st point isn't a valid one because people who deal with Active Directory know that there would be zero reason to ever convert a DC from physical to virtual. You would just promote and demote domain controllers. This goes back to Windows 2000 Active Directory (and maybe before) so it isnt really a new concept.
IRJ is correct on all points here.
You are approaching IT as a set of checkboxes. It isn't. The only way to do IT well is to learn the fundamentals, then learn the specifics, and apply them. Everything else is both harder, if not impossible, and ineffectual. It might seem like a shortcut... just distill your job to dos and don'ts, or the checkboxes, but IT doesn't and can't work that way. If it did, we'd have no reason to exist because everything would already be automated. IT is hard, it just is. It's complex. But the more you accept that from the beginning, the easier it gets. Learn the basics, and the specifics get easy like in my AD example.
He's also right... the rules about P2V conversions of AD DCs is weird because it's something that should never come up in any situation where you cared about doing things right at all, the only time the thought process even exists is for situations where you weren't following good practices in the first place and aren't following them in the future. And then it only applies when you have more than one DC. And only old versions because recent ones have protection for this (still a bad idea, but it works.) And all of this is stuff you don't need to learn, because just learning what AD is and the high level view of how it works lets you figure it all out automatically anyway.
-
@JaredBusch said in System Admin - checklist for Don'ts and Important points please!:
Always Generation 2. There should never be a reason in 2020 that anyone should use anything else. For the exceptions, they will already know they are exceptions.
Right, the pattern here is the "Always, Unless you can't" rule. Meaning, you always want Gen 2, the exclusive reason you'd ever choose Gen 1 is because Gen 2 isn't an option for you. In which case there is no real decision to be mad. The logic is so simple...
Gen 2, unless impossible, then Gen 1. If that also is impossible, stop.
This kind of thing applies as a general pattern over and over again.
-
@JaredBusch said in System Admin - checklist for Don'ts and Important points please!:
There are only 4 systems in a network that require a static IP.
Router
Main hypervisor that runs 3 & 4 below.if 3 & 4 are not on the hypervisor, it has no need for a static address
DHCP server
DNS ServerAnd even this isn't actually true, it's still assumptions. In reality, the only things that need static are the router and if it is a separate device from the router, the DHCP server.
You never need it for DNS because DNS can get handed out from DHCP. Hypervisors, too. Except in the case where they are the hypervisors for the DHCP VM, in which case they might need a static IP, but not necessarily.
-
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
3: The subnet should be documented somewhere. MAC addresses, IP addresses, DHCP scope(s), DHCP settings, and so on. Advanced IP Scanner is free and is a good place to start if none exist. There are other tools out there.
This is a great point. The rule about checking with networking assumes that failure has already happened - that you are assigned a networking task that doesn't have documentation. You really should never have a situation where this comes up. Just like the P2V of the AD DC. I realize that you (OpenIT) were just making examples, but all of your examples were of things that shouldn't have rules, because they shouldn't need rules in the first place. They are rules to deal with problems that, if you are taking the time to make rules to fix problems, you should just remove the problems instead.
-
@JaredBusch said in System Admin - checklist for Don'ts and Important points please!:
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
@Dashrender said in System Admin - checklist for Don'ts and Important points please!:
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
7: No Remote Desktop Protocol (RDP) port forwards (NAT) from the Internet (alternate port) to 3389 on the intended destination. Ever. Use Remote Desktop Gateway and add DUO or other 2FA to the mix.
Is this because only RDG supports MFA? not the end clients themselves?
Because RDG provides a layer of protection against TSGrinder and its cohort.
It's bad news to publish an RDP listener direct to the Web. Has been for a very long time now.
Not any worse than publishing any service to the web without some third party control (fail2ban, etc).
Stupid people using stupid weak passwords is not a failure of the protocol.
There is, and again it's a tends to issue, with RDP. And that is that RDP tends to be tied to AD, to a point where it is assumed. Because of the way that RDP gets exposed, and because of the problems of tying it to internal AD, you end up with a need for "exposed security" measures on the RDP that aren't really feasible when you are dealing with an AD account (like locking up after three failed attempts.) If you do that, anyone on the outside can lock anyone on the inside's AD account any time that they want making RDP a really simple DoS attack vector.
RDP itself isn't special. It's highly secure. But people tend to just assume that RDP will be tied to AD, and they are nearly always correct. But RDP itself is just as secure as say SSH. It's just that SSH basically never gets tied into AD and on to internal user accounts in the same way, so the problems aren't the same (that and SSH normally gets Fail2ban solving the issue even further.)
So like everything else here, if we look for general rules we can identify the problem, the potential solutions, etc. Because the issue isn't about RDP, isn't unique to RDP, can be avoided with RDP, and can occur without RDP.
The real rule is a need for security around publicly accessible vectors when tied to internal mechanisms.
-
@IRJ
I have no idea, if I opened any dumb or stupid kind of thread, but still receiving informative responses.study and research in areas where you want expertise - Yes, it is obvious
Rome was not built in a day - agreed, neither me expecting to build my career a day
-
@Obsolesce said in System Admin - checklist for Don'ts and Important points please!:
@openit said in System Admin - checklist for Don'ts and Important points please!:
I want to make a checklist of Don'ts and important things to consider from your experience, which are necessary for me to play smooth in next System Admin job.
Following are few examples of Don'ts or important things to consider, please add your point:Not recommended to convert Physical Server which has Domain Controller to Virtual Machine.
Need to choose right Generation (1 or 2) type VM on Hyper-V, because later we can't change the generation.
Don't set Static IP of some server/machine without consulting Network Team, to avoid conflicts with existing DHCP scope.Your inputs matters a lot to me, and might help others in community as well.
Thanks!In addition to not P2Ving a DC:
- Don't pee on your servers.
I'm not sure where you want to draw the line as far as what not to do...
Thanks for advise, Lol
While I learn from tutorials, LAB etc,. obviously I can't come across the real world scenarios or problems, so was asking you people to throw any points which comes to your mind in System Admin area, based on your past experience or bitter experience let's say.
Because, my next step could be in any enterprise firm as a System Admin, just to be prepared other than learning from tutorials, LAB etc.
-
@JaredBusch
Here I understand, you found me wrong, when it comes to my intention of this thread, I'm not expecting response for 3 points I mentioned, it's just few examples for your reference. Obviously I learned those Don't points while I work, learn on tutorials and LAB.Those above 3 points are just as example, so you can understand my expectations and throw some valid or important or Don't points.
-
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
@openit said in System Admin - checklist for Don'ts and Important points please!:
- Not recommended to convert Physical Server which has Domain Controller to Virtual Machine.
- Need to choose right Generation (1 or 2) type VM on Hyper-V, because later we can't change the generation.
- Don't set Static IP of some server/machine without consulting Network Team, to avoid conflicts with existing DHCP scope.
Your inputs matters a lot to me, and might help others in community as well.
Thanks!
4: Group Policy: Follow best practices. Don't touch the Default Domain and Default Domain Controllers policies. Always set up the OU/GPO structure and settings according to the org's needs.
5: Hyper-V standalone: We don't join the host to the guest's domain. It presents a barrier to a ransomware compromise.
6: Backup: A backup is not considered "Good" until it is fully bare metal/hypervisor restored. Spot file/folder restores are not a verification method.
7: No Remote Desktop Protocol (RDP) port forwards (NAT) from the Internet (alternate port) to 3389 on the intended destination. Ever. Use Remote Desktop Gateway and add DUO or other 2FA to the mix.
Thanks @PhlipElder
This kind of reply was my expectation.
Others may say, there could be 100s of Don'ts if we keep discussing, I understand that, but I'm asking you which is very important for Don'ts because you can't revert back, because it could lead to a disaster, or something you learned from your Bitter Experience in past etc.
-
@scottalanmiller said in System Admin - checklist for Don'ts and Important points please!:
underlying technical reasons
@scottalanmiller
I understand about "figure out underlying technical reasons ", I have been trying for the same, let's say, yesterday I was going deep about BCDR (Business Continuity and Disaster Recovery), which given me clarification on In and Out. -
@scottalanmiller said in System Admin - checklist for Don'ts and Important points please!:
@PhlipElder said in System Admin - checklist for Don'ts and Important points please!:
3: The subnet should be documented somewhere. MAC addresses, IP addresses, DHCP scope(s), DHCP settings, and so on. Advanced IP Scanner is free and is a good place to start if none exist. There are other tools out there.
I realize that you (OpenIT) were just making examples
Exactly, those are just some examples, so you people can thrown some valuable info for me, from your past experience, I understand, there could be 100s or 1000s of Don'ts kind of things, but at least some of points from your bitter experience can lead me to understand different perspectives to study or research etc. while I continue my learning through reading articles online, attending courses on Udemy, doing things on my LAB.
@Dashrender @IRJ @JaredBusch @Obsolesce @PhlipElder @scottalanmiller
-
@openit said in System Admin - checklist for Don'ts and Important points please!:
but at least some of points from your bitter experience can lead me to understand different perspectives to study or research etc
Those are tough, because our experiences are unlikely to help you. They will be with specific tech, versions, installations, configurations, etc. and following our experience might not only be non-applicable, but it might be backwards for you.
Example... I've lost data on a RAID 5 that had no business being a RAID 5. If you try to learn from my experience, you might just avoid RAID 5, but your drives, your server, your use case have essentially zero chance of being similar to mine and RAID 5 on modern SSDs might be exactly what you need.
Or you might think from someone's experience that doing an AD DC restore is bad and can't be done, but in your case it might easily be the right thing to do and work just fine.
The point is, in IT you can't ever learn from peoples' experience in this way. Learning the under the hood details and understanding how things work and why experiences mean what they do is necessary for the experiences to be useful. So my RAID 5 experience would be useful to you only when you understand all the ins and outs of RAID and can see my mistake in context of both my setup and how it may or may not apply to yours.
