System Admin - checklist for Don'ts and Important points please!
-
@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.
-
Maybe I'm alone but on the top of my list:
- Only use Microsoft as a last resort when all other options have been explored.
- If you get paid by the hour disregard #1.
-
@Pete-S said in System Admin - checklist for Don'ts and Important points please!:
Maybe I'm alone but on the top of my list:
- Only use Microsoft as a last resort when all other options have been explored.
- If you get paid by the hour disregard #1.
So, so true.
-
@Pete-S said in System Admin - checklist for Don'ts and Important points please!:
Maybe I'm alone but on the top of my list:
- Only use Microsoft as a last resort when all other options have been explored.
- If you get paid by the hour disregard #1.
Option 1. - What do you say / do when the Owner specifically states, Windows Only environment. NIX and Apply need not apply -
-
@gjacobse said in System Admin - checklist for Don'ts and Important points please!:
@Pete-S said in System Admin - checklist for Don'ts and Important points please!:
Maybe I'm alone but on the top of my list:
- Only use Microsoft as a last resort when all other options have been explored.
- If you get paid by the hour disregard #1.
Option 1. - What do you say / do when the Owner specifically states, Windows Only environment. NIX and Apply need not apply -
Then it's a last resort scenario and you use Windows.
-
@gjacobse said in System Admin - checklist for Don'ts and Important points please!:
@Pete-S said in System Admin - checklist for Don'ts and Important points please!:
Maybe I'm alone but on the top of my list:
- Only use Microsoft as a last resort when all other options have been explored.
- If you get paid by the hour disregard #1.
Option 1. - What do you say / do when the Owner specifically states, Windows Only environment. NIX and Apply need not apply -
Look for another job
-
@gjacobse said in System Admin - checklist for Don'ts and Important points please!:
@Pete-S said in System Admin - checklist for Don'ts and Important points please!:
Maybe I'm alone but on the top of my list:
- Only use Microsoft as a last resort when all other options have been explored.
- If you get paid by the hour disregard #1.
Option 1. - What do you say / do when the Owner specifically states, Windows Only environment. NIX and Apply need not apply -
You say "okay, but you are the CIO because you are making the IT decisions and all risks and problems are on you because I'm just pressing the buttons you tell me to press, not running IT."
-
@IRJ said in System Admin - checklist for Don'ts and Important points please!:
@gjacobse said in System Admin - checklist for Don'ts and Important points please!:
@Pete-S said in System Admin - checklist for Don'ts and Important points please!:
Maybe I'm alone but on the top of my list:
- Only use Microsoft as a last resort when all other options have been explored.
- If you get paid by the hour disregard #1.
Option 1. - What do you say / do when the Owner specifically states, Windows Only environment. NIX and Apply need not apply -
Look for another job
An IT job, rather an a hobby. An owner doing that is 1) running IT and 2) not trusting you and 3) viewing his "business" as a hobby and approaching everything around his emotions rather than making business decisions.
There's no purpose for IT people in a "business" like that because we don't have any value to add.
-
@scottalanmiller 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!:
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.
This given me clarification and agreed!
