swarohi Posted January 17, 2018 Posted January 17, 2018 Hi all, If you were in the process of setting up a domain for your school network, what are some of the best practices you would adhere to in order to have a secure and efficient network? This is something I will be doing over the half-term to fix a botch job that was done before I started and want to make sure I get it right! Equipment wise, we have two HP Proliant servers with 160gb of ram and 12 cores each. There are around 200 computers (desktops and laptops) in the school and then a few MFP and BYOD devices. Thanks a bunch 1
FN-GM Posted January 17, 2018 Posted January 17, 2018 This could be a long conversation! One thing that many people don't do is having a unique local admin password on each machine. It is a massive security hole by having them all the same. You can use LAPS to automatically generate a random password for each machine every 30 days or so and then store it in AD - https://www.microsoft.com/en-us/download/details.aspx?id=46899 3
swarohi Posted January 17, 2018 Author Posted January 17, 2018 Definitely guilty of doing the same thing! It's definitely a long conversation but hopefully we get some good ideas that can be used as reference for others in the future .
mavhc Posted January 17, 2018 Posted January 17, 2018 Script the whole thing, probably in powershell, so you can make it repeatable. Anything you can't script, document. Syncing to O365 and Google Apps requires email addresses, even if they don't have email accounts, so think about the format you're going to use. 18JoeB, 18JBloggs, JoeB, JBloggs, depends on the size of the school. Add 1 Level of OU for the school name, in case you merge with another school. Where to add it is the question Root>SchoolName>Computers>Room1 or Root>Computers>SchoolName>Room1 Move Admin users out of Users so you can add more security. Set up imaging to use a thin image, so you just put the new Win10 wim on WDS/etc and then scripts/gpos/sccm/mdt does the rest. Run https://www.pingcastle.com/ to find AD flaws. Read about Pass The Hash etc. 1
SHimmer45 Posted January 17, 2018 Posted January 17, 2018 This could be a long conversation! One thing that many people don't do is having a unique local admin password on each machine. It is a massive security hole by having them all the same. You can use LAPS to automatically generate a random password for each machine every 30 days or so and then store it in AD - https://www.microsoft.com/en-us/download/details.aspx?id=46899 so how would this work in an actual environment if you needed to login as the local admin, its something i have seen but wondered about how it would actually be usable.
mavhc Posted January 17, 2018 Posted January 17, 2018 so how would this work in an actual environment if you needed to login as the local admin, its something i have seen but wondered about how it would actually be usable. It's more for end users, if you really have to give someone remote the password. Tech staff can just use an AD account that's been made local admin via GPP etc 2
ChrisMiles Posted January 17, 2018 Posted January 17, 2018 This could be a long conversation! One thing that many people don't do is having a unique local admin password on each machine. It is a massive security hole by having them all the same. You can use LAPS to automatically generate a random password for each machine every 30 days or so and then store it in AD - https://www.microsoft.com/en-us/download/details.aspx?id=46899 I don't agree with this. Having the same Local Admin password is no less secure than having a domain admin account at all. Furthermore, in a properly configured domain no private information should be stored on local machines. Choose a secure password. It's easy to change on mass using GPO as needed. I agree with the scripting suggestion. I recently built a brand new 2016 domain on Hyper-V and had everything down to software installs scripted into powershell and command lines and as a result I was able to rebuild it from scratch several times in minutes. There are other things I'd suggest: Use a private sub domain of your external domain such as ad.myschool.org, don't use .local or .internal or anything similar as you cant get SSL certificates for them. Create a new domain admin account, set the Administrator account with a random secure password then disable it and never use it again. Consider future licensing costs when working out how to split/combine certain roles between servers. Don't use domain admin accounts for services, syncs and LDAP access just because it's easy. Don't use service accounts on more than one service. Make sure to always employ the principal of least privilege. Dont make teachers local admins no matter how much they moan about it. Test test test test test! 1
mavhc Posted January 17, 2018 Posted January 17, 2018 Script your tests where possible so you can test everything after every change. Login as teststudent, copying file to x should allow, y should fail, login as testteacher, x should allow, y should allow, etc. Can reach http://www.youtube.com as teacher, can't as student. Don't let anyone run any code that's not whitelisted by yourself, via SRP etc. Encrypt everything from the start, make sure your backups work, script backup tests 1
Arthur Posted January 17, 2018 Posted January 17, 2018 (edited) I don't agree with this. Having the same local admin password is no less secure than having a domain admin account at all. Having identical local admin passwords is widely regarded as poor security practice. I agree with @FN-GM on this one. https://download.microsoft.com/download/7/7/a/77abc5bd-8320-41af-863c-6ecfb10cb4b9/mitigating%20pass-the-hash%20(pth)%20attacks%20and%20other%20credential%20theft%20techniques_english.pdf Accounts with administrative access on a computer can be used to take full control of the computer. And if compromised, an attacker can use the accounts to access other credentials stored on this computer. In addition, many organizations have deployment and operational processes that result in defining the same administrative local account and password on many computers. Maintaining identical passwords makes it significantly easier for attackers to compromise all computers that use them and obtain all credentials stored on these computers. IT support processes typically do not require the built-in local administrator account to log on over a network connection, which is a common attack vector for lateral movement using credential theft. https://adsecurity.org/?p=1790 The real problem with local accounts on a computer in an enterprise environment is that the term “local” is a misnomer. If 50 computers on a network have the local administrator account of “Administrator” and a password of “P@55w0rd1!”, first of all that’s a HORRIBLE password. Second of all and more to the point, if one of those computers is compromised, they will all be compromised. Windows is very helpful. So helpful that if you pass the local admin credentials to another computer with the same local credentials, access is granted as if you logged on with the target system credentials. Dump administrator credentials on one to get admin on all! The best way to mitigate this issue is to ensure every computer has a different local administrator account password that is long, complex, and random and that changes on a regular basis. Edited January 17, 2018 by Arthur 1
mavhc Posted January 17, 2018 Posted January 17, 2018 Put your support domain accounts in a protected group so they're not cached on client machines https://superuser.com/a/1185831 1
FN-GM Posted January 17, 2018 Posted January 17, 2018 (edited) I don't agree with this. Having the same Local Admin password is no less secure than having a domain admin account at all. Having all the same local admin passwords will mean all the machines have the same hash. Then it will mean hackers can replay that hash on all the other computers on the domain and just freely wonder around the network. The local admin rights combined with other vulnerabilities means you can elevate yourself to domain admin. Having random passwords on each machine contains such attack. This is the first thing check on a penetration test. Take it you don't have them done at yours? Edited January 17, 2018 by FN-GM 1
FN-GM Posted January 17, 2018 Posted January 17, 2018 (edited) Also don't forget to add protection on your switching infrastructure. Just a few off top of my head. 1. Disable CDP and LLDP. Attackers can cause denial of service by flooding the switch with junk info. 2. Limit the number of Mac addresses on each port. It will stop DHCP starvation attacks, in just seconds a bit of software can use up all the available IP on a DHCP server by using lots of mac addresses to make DHCP requests. As well as that it will stop an attack that fills up your MAC Address table with rubbish, once the table is full the switch turns into a hub and then they eves drop on the traffic. 3. Make sure there is no dynamic protocols enabled that can negotiate a dot 1 q trunk link. 4. Never use VLAN 1. Never have clients on the native vlan on dot 1 q trunk links. It means attackers can VLAN hop and go into other VLANS. It also helps to have only the VLANS you need on each switch. EG don't have your DMZ on a switch that serves your clients. 5. Enable the BPDU guard on client ports. It will stop anyone causing a denial of service by make loops in the network. It will also stop spaning tree attacks. 6. Enable DHCP snooping, it will stop denial of service attacks via rouge DHCP servers (sometimes happens accidentally). It will prevent man in the middle as well. 7. I can't remember the name off top of my head, but there is something to disable ARP Poisoning as well. This will stop man in the middle attacks. 8. VLANs can help contain some attacks. 9. Disable VTP if you have Cisco. Attackers can exploit it and delete your VLANS! 10. Don't use TELNET to manage switches, password etc are transmitted in plain text. Use SSH. Infact disable Telnet so nobody can use it accidentally. Edited January 17, 2018 by FN-GM 1
FN-GM Posted January 17, 2018 Posted January 17, 2018 Disable startup repair on Windows. It will prevent this - Hacking and security: Windows 7 ‘Startup Repair’ Authentication Bypass 1
rrrrr Posted January 17, 2018 Posted January 17, 2018 I don't agree with this. Having the same Local Admin password is no less secure than having a domain admin account at all. Furthermore, in a properly configured domain no private information should be stored on local machines. Choose a secure password. It's easy to change on mass using GPO as needed. I agree with the scripting suggestion. I recently built a brand new 2016 domain on Hyper-V and had everything down to software installs scripted into powershell and command lines and as a result I was able to rebuild it from scratch several times in minutes. There are other things I'd suggest: Use a private sub domain of your external domain such as ad.myschool.org, don't use .local or .internal or anything similar as you cant get SSL certificates for them. Create a new domain admin account, set the Administrator account with a random secure password then disable it and never use it again. Consider future licensing costs when working out how to split/combine certain roles between servers. Don't use domain admin accounts for services, syncs and LDAP access just because it's easy. Don't use service accounts on more than one service. Make sure to always employ the principal of least privilege. Dont make teachers local admins no matter how much they moan about it. Test test test test test! FN-GM is correct on this. Also never set local admin passwords using GPO GPPreferences. The xml for this gpo is readable by all domain users and the password is easily reversed. 1
computer_expert Posted January 17, 2018 Posted January 17, 2018 FN-GM is correct on this. Also never set local admin passwords using GPO GPPreferences. The xml for this gpo is readable by all domain users and the password is easily reversed. An update removed the ability to set the password via GPP (the field is greyed out after the update is installed) Disabling SMBv1 is a good bet too, providing that you don't have any kit that can only speak SMBv1 (old nas drives, Server 2003/XP boxes, old network printers with scan to file share capability etc) 1
FN-GM Posted January 17, 2018 Posted January 17, 2018 An update removed the ability to set the password via GPP (the field is greyed out after the update is installed) If you set it up before hand, it will still have the XML is sysvol.
ChrisMiles Posted January 18, 2018 Posted January 18, 2018 (edited) Having all the same local admin passwords will mean all the machines have the same hash. Then it will mean hackers can replay that hash on all the other computers on the domain and just freely wonder around the network. The local admin rights combined with other vulnerabilities means you can elevate yourself to domain admin. Having random passwords on each machine contains such attack. This is the first thing check on a penetration test. Take it you don't have them done at yours? Thank you for explaining. However, am I wrong in thinking that they would still need to find out the password and log into one machine before they could abuse this? How might they go about doing that without the password? Wouldn't most attack vectors be just as effective on domain accounts? Any of the attacks that allow changing/resetting the password would change the hash wouldn't they? And what do you do if you need to use the local admin account occasionally? Do you maintain a list of random passwords for each machine, do you use a pattern/calculation based on some other aspect of the machine? Edited January 18, 2018 by ChrisMiles
oggster Posted January 18, 2018 Posted January 18, 2018 Thank you for explaining. However, am I wrong in thinking that they would still need to find out the password and log into one machine before they could abuse this? How might they go about doing that without the password? Wouldn't most attack vectors be just as effective on domain accounts? Any of the attacks that allow changing/resetting the password would change the hash wouldn't they? And what do you do if you need to use the local admin account occasionally? Do you maintain a list of random passwords for each machine, do you use a pattern/calculation based on some other aspect of the machine? The local admin password for each machine is stored in a new attribute field in the computer account in AD. The LAPS deployment guide explains how to secure this attribute so only users you define can read it. 1
FN-GM Posted January 18, 2018 Posted January 18, 2018 Thank you for explaining. However, am I wrong in thinking that they would still need to find out the password and log into one machine before they could abuse this? How might they go about doing that without the password? Wouldn't most attack vectors be just as effective on domain accounts? Any of the attacks that allow changing/resetting the password would change the hash wouldn't they? There is a way to get the hash with standard user rights and maybe a boot disk. That hash can then be used on other machines. And what do you do if you need to use the local admin account occasionally? Do you maintain a list of random passwords for each machine, do you use a pattern/calculation based on some other aspect of the machine? @oggster is right. Just to expand, there is a little utility to make it easier. Ours passwords are all random. LAPS provide group policy templates for you to specify how complex and how often to re-generate them etc. 1
mavhc Posted January 18, 2018 Posted January 18, 2018 Disable booting from anything except the SSD; if you have AMT change the password; encrypt the drives and use secureboot. Could just not have local admin accounts. Disable client recovery reagentc.exe /disable. Disable everything in BCD (probably not optimal code, please fix if not): bcdedit /deletevalue {current} recoverysequence bcdedit /set {bootmgr} bootems off bcdedit /set {bootmgr} advancedoptions off bcdedit /set {bootmgr} optionsedit off bcdedit /set {bootmgr} recoveryenabled off bcdedit /set {bootmgr} displaybootmenu false bcdedit /set {current} bootems off bcdedit /set {current} advancedoptions off bcdedit /set {current} optionsedit off bcdedit /set {current} bootstatuspolicy IgnoreAllFailures bcdedit /set {current} recoveryenabled off Don't limit number of MAC addresses on the switch port your VM host is on :-)
FN-GM Posted January 18, 2018 Posted January 18, 2018 Don't limit number of MAC addresses on the switch port your VM host is on :-) Goo point, the above stuff I spoke about is more for client ports out in the wild.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now