deny local logon

from the results of a recent pen test, despite us having a domain password policy that adheres to Microsofts own recommendations, the security testers flagged up some powerful accounts (domain admins) with easily compromised passwords. Whereas we have strengthened these as per their recommendations, these accounts had been subject to a GPO that denies local logon to any system .they appear to link to service accounts which clearly shouldn't be domain admins but were setup by an old 3rd party who managed IT support.

My question is, out of curiosity, is that our security team seem to think the fact these accounts are prevented form local logon, vastly reduces the risk if these accounts were compromised. what is your view, I presume there are still other methods that could be used if these accounts were compromised, to access systems and resources (e.g perhaps used to map a network drive to a system with sensitive info). or do you agree with our security team that the fact the accounts are subject to GPO that denies local logon - that therefore reduces the impact if someone guessed these supposedly weak passwords.
Who is Participating?
oBdAConnect With a Mentor Commented:
Well, it reduces the risk a bit, but not 'vastly'. "Deny local logon" just means that: local logon. It doesn't prevent network logon, exploiting shares, it doesn't prevent remote management using WMI or whatever else is available, it doesn't prevent creating new admin account(s) that are allowed to logon locally, ...
Look at it this way: if these accounts wouldn't be able to actually use their credentials, then they wouldn't need to be in the Domain Admins group to start with.
btanConnect With a Mentor Exec ConsultantCommented:
A privileged user with weak password will be one of the weakest link that can be compromised and this risk is greater. In fact, the denial should be remote access instead of local logon for privileged users. Attacker penetrate and move laterally to other connected servers easily if they allow remote access and move vertically easily if local logon allows such service account to be used - compromised servers and services in total give greater damages.

If you take CVSS as gauge, the score is higher (more severe) depending on the "remoteness" of the attacker relative to the vulnerable component.
That is, the more remote an attacker is to the vulnerable component (in terms of logical and physical network distance), the greater the Base score will be.

Further, this metric now distinguishes between local attacks which require local system access (such as with an attack against a desktop application) and physical attacks which require physical access to the platform in order to exploit a vulnerability (such as with a firewire, USB, or jailbreaking attack).
So a better posture is to deny user from interactively login instead - That is to restrict the machines to which a user can log on interactively. Domain administrators can restrict to which domain machines a domain user can log on interactively by using the AD “Log On To…” user account property.

The scenario that is serious is instead the use of local accounts for remote access e.g.
when an administrative local account has the same user name and password on multiple machines, an attacker with administrative rights on one machine can easily obtain the account’s password hash from the local Security Accounts Manager (SAM) database and use it to gain administrative rights over the other machines using “pass the hash” techniques.
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
Local logon is the most secure logon method available. Denying local logon while allowing Network logon is, in my opinion, not an increase of security in any way. Local Logon requires physical access to a system, so if someone gets to a point where they can utilize the Local Logon right, they have already gotten to a point that is well beyond all your other security measures. The vast majority of attacks will come from remote locations, and denying local logon will not do anything to stop these kinds of attacks, and having domain admin accounts that have network logon, remote desktop logon, and other logon capabilities with weak passwords is significantly more dangerous than domain admins with local login rights.

For instance, a domain admin account without local logon access will prevent someone from logging in when they're on site with that account, but then they just need to log in to another computer using RDP and that account and they have full Network access immediately.

Even allowing "Log on as batch" can easily result in compromised systems, since it allows a user to create a script that generates a new domain admin account without login restrictions and run it with higher privileges using the Scheduled Tasks feature.

Basically, you will want to make sure your service accounts are only granted the permissions they need and have secure passwords. Just denying local login to them provides a 0% reduction of risk.
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

I have a question for you: how did the pentesters find out that these account passwords were "easily compromisable"? They should not even be in the position to find that out. Or did you tell them how the passwords are / what rules you follow?
pma111Author Commented:
I presume they used a utility that did some sort of word list attack against any accounts they enumerated.
McKnifeConnect With a Mentor Commented:
Ok, so again: how could they manage to even try these passwords?  Let's say they have been granted access to a domain client pc with a standard restricted domain user and they could enumerate all accounts that are domain admins:
net group domain-admins /domain

Open in new window

They get names, let's say SuperJoe.

How would they go about to crack SuperJoes password or at least determine it is a weak one? This is something they need to tell you - there is your problem.
Adam BrownSr Solutions ArchitectCommented:
McKnife, there are two ways you could determine if administrative accounts have weak passwords:
1. Examine domain password requirements. If they are not set to require complexity/sufficient length and there is no FGPP set up to increase the requirements for administrators, it is a safe assumption that the passwords for those accounts are not strong.

2. If a utility is able to act in the context of the system account on a Domain controller, it can examine the AD database to obtain the password hashes that are stored there for each account (acting in the system context is very easy if you have administrative access already). Once you have the password hashes for all domain accounts, you can then compare those hashes with a rainbow table of common/weak passwords. This type of thing is very difficult to pull off without complete access to the environment, but if that is granted to a security auditing team they can do so in a matter of minutes without difficulty. This is most likely what they did to determine the password strength of the accounts in question.
Adam, you don't have to tell me, I know such things. But still, I don't quite agree:
knowing the pw policy does not let us assume anything. These passwords could be weak, but who says most admins are lazy? I wouldn't. Also, having system access to the DC? How would the pentesters not mention this? It cannot be that pma's company granted them that level of access, this would be a funny concept for a pentest.

I am always trying to give sound advice. We need more info about what the PTs said and did, otherwise this will lead nowhere.

So to continue on my question addressed to pma "How would they go about to crack SuperJoes password or at least determine it is a weak one?"
You can't just start a script that goes guessing passwords even if you were allowed to use that account for local logons. Immediately, that account would be locked out. Guessing would be over. To get a judgement about the quality of the password, one would at least need the hash of it, so those pentesters did either tell you something different and you completely misinterpreted it, or they had a go at the pw hashes. Obtaining a hash is only possible if you have admin access to a machine where such a domain admin account is used on.

Ask the pentesters or this will lead nowhere.
btanExec ConsultantCommented:
Should have enforce 2FA for any remote access esp of those for admin access remotely. The newer OS vetsion have a better controls over such admin access exploiting via the PtH attack
Programs are prevented from leaving credentials in memory after a user logs out

Allows Remote Desktop Protocol (RDP) connections without putting the user's credentials on the remotely controlled computer

A new Protected Users group, with member's credentials that can't be used in remote PtH attacks
pma111Author Commented:
to clarify, a weak password in their view, is still one which meets minimum characters length of 10 with complexity enabled, as per the policy. But this doesn't prevent selections such as Administrator01 (that wasn't an example, but for arguments sake). I believe this is called a virtual brute force when they try a selection of common passwords against all accounts - which then doesn't lock them due to account lockout policies.
I have no idea what a "virtual brute force" should be.
What was it that the pentesters said? Was it, as Adam assumed, that they just judged the password policies that were applied to the domain admins or was it the password itself? If the latter, how did they do that?
btanExec ConsultantCommented:
Reading what the pentester as "common words", I deemed they are referring to dictionary based brute force since it is using common word. Password complexity policy is required.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.