We help IT Professionals succeed at work.

Secure Domain Controllers Environment

Mohammed Hamada
Mohammed Hamada used Ask the Experts™
on
Dear experts,
We have done a penetration test and one of the oracle servers had a vulnerability which through it the penetration test experts manage to get the hash of the Domain admin users and then get the NTDS database of the entire AD Users.

How is it possible to check the current hash being utilized and to strengthen this on Active Directory servers? The currently installed servers are Windows 2016.

I would appreciate your recommendations.

Thank you
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Distinguished Expert 2018

Commented:
Ask the pentesters, it's their job to make recommendations.

Ask yourself why a domain admin account was even in use on the oracle server.
Adam BrownSenior Systems Admin
Top Expert 2010

Commented:
The first thing you'll want to do is check on your service accounts to make sure they aren't allowed to log in interactively, but it's also important to make sure those accounts aren't being granted domain admin rights. Service accounts rarely require that level of permission, so you'll want to limit those permissions if they do. The pen test report should give you some good information on exactly how they were able to obtain the hash(es). Most likely they pulled off a "Golden Ticket" attack. https://www.varonis.com/blog/kerberos-how-to-stop-golden-tickets/ has some info on how this works and how to stop it.

Regarding the hash in use, that information isn't particularly helpful to solving your problems. Hashes are just cryptographically scrambled password values. They are used to verify that a password is valid without transmitting the password, so the hash will change every time you change the password for the account. And not by a small amount. There really isn't much you can do (yet) to secure the hashes more than they already are. There are plenty of utilities that allow someone with domain admin rights to dump the whole password hash database for every account, so the real key is, of course, protecting your domain admin accounts, either with Multi-Factor Authentication or by limiting rights.
Lee W, MVPTechnology and Business Process Advisor
Most Valuable Expert 2013

Commented:
First, I agree with McKnife - the Pen Testers should be advising you what to do to prevent what they did.  Otherwise, they're just hackers stealing your data.

Second, Domain Admin accounts should not be used to log in to ANYTHING other than Domain Controllers.  At least one of your issues is that you allowed someone to log in to the Oracle server using a domain admin account.  BAD.

You administer NON-domain controllers using Administrator accounts.  You don't necessarily need separate ones per server (though if the data is sensitive, you might want it that way). As a general rule, you do the following:

Domain Admins - ONLY administer domain controllers - VERY FEW people in the organization should have a domain admin account.  NEVER share domain admin accounts among multiple admins.
Server Admins - ONLY administer non-domain controller servers in the domain. (and you can be more granular than that too:  File Server Admins, Database Admins, Oracle Admins, Microsoft SQL Server Admins, etc., etc.)
Workstation Admins - ONLY administer users' computers (Again, you can be more granular; Main Office Workstation Admins, Satellite Office Workstation Admins, Development Workstation Admins, etc., etc.)
Mohammed HamadaSenior IT Consultant

Author

Commented:
The pentester provided their report and recommendation but it focused on the penetrated application (Oracle in this case). Because they consider that Microsoft security test is something different that what is assigned to them in that case so they choose to cover only their scope (I think its something financially motivated).

Domain admins is limited (since its a bank, they know well how to cover this) but they wanted to know if there's anyway to strengthen the hash or whatever protocols is being used by MS on the network.

I suggested using BaseLine security GPO, But I am seeking a professional advise.
Distinguished Expert 2018

Commented:
Look as said: plain and simple: for an attacker, if he got his hands on the hash, he has almost won. So just don't let anyone use domain admins on anything but administrative workstations or DCs. That's all. If you use it on an oracle server or any other server, then that is your fault.

The hash cannot be strengthend, only the password itself, but if the attacker has no way to get a hash then your goal is met.
Lee W, MVPTechnology and Business Process Advisor
Most Valuable Expert 2013

Commented:
As I said:

Domain Administrator accounts should ONLY administer domain controllers - VERY FEW people in the organization should have a domain admin account.  NEVER share domain admin accounts among multiple admins.

And never log in to a non-DC with a domain admin account (implied by "Domain Administrator accounts should ONLY administer domain controllers") - if this had been the enforced policy, the pen tester would never have gotten in.

The other thing you can do is implement 2FA on domain admin accounts.
Mohammed HamadaSenior IT Consultant

Author

Commented:
This is what I was looking for,
https://www.petri.com/windows-server-protected-privileged-accounts 

Credential Guard, Active Directory Protected Users and Authentication Policies and Silos

The features of that the Active Directory Protected Users offer are :
Cached credentials. I.e. users cannot log in offline when there is no access to a domain controller.
The Kerberos ticket-granting ticket (TGT) must be received when users log in and cannot be reissued automatically, preventing the use of long-term keys.
Default credential delegation (CredSSP), stopping credentials being cached in plaintext even if the Allow delegating default credentials policy is set.
Windows Digest authentication.
NT LanManager (NTLM) NTOWF – a function for generating keys based on user passwords.
If the domain functional level is Windows Server 2012 R2 (or higher), Protected Users can’t:

Renew Kerberos ticket-granting tickets longer than the original 4-hour TTL
Log in using NTLM
Use DES or RC4 for Kerberos pre-authentication
Be delegated using constrained or unconstrained delegation
Senior Consultant
Awarded 2017
Distinguished Expert 2018
Commented:
Mohammed HamadaSenior IT Consultant

Author

Commented:
Thanks a lot everyone and esp Shaun, The amount of useful stuff you have is fascinating. I have demo the Tier groups, Protected user groups and Silo to my client and they were extremely happy about it however the only problem which they have is the cached credentials which I guess by design doesn't expire.

My client can't disable NTLM because they want to cache credentials for some users but they want those to expire because apparently some of the users were able to login offline even after months of not being connected to the Domain.

I am not sure if you have anything different than what I have checked but I would appreciate your thoughts on this one.