Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 163
  • Last Modified:

Active Directory Audit

There is an Audit finding by an external auditor - they found some AD accounts with no password required and asking us for justification of those. Now I know those accounts got created while application installation with "no password" and "no expiry" and used by application only. After installation password policy was setup and hence those accounts won't meet the password policy. Those accounts are just member of Domain User group and no one can use those accounts to access any server on domain. Is there any way I can provide evidence to auditor that those accounts are not vulnerable?
0
A D
Asked:
A D
  • 5
  • 4
  • 3
  • +3
2 Solutions
 
Austin TexasSystems EngineerCommented:
What is to prevent you from applying passwords to these service accounts now? You can apply a password to the account and then enter it in the appropriate service in services.msc under the Logon tab.
2
 
A DAuthor Commented:
Applying passwords will be application change request which can be done later considering budget n all but  I believe these accounts are not vulnerable as they can not be used to access any resources on domain. If auditors are happy if we can provide some evidences then probably we may not need a change request.

Is there any way to show evidence that these are just domain users and not privileged accounts and not being used by humans but just by the application?
0
 
Dan McFaddenSystems EngineerCommented:
No, you cannot prove that domain accounts with no required password, are not vulnerable.

In fact, any domain accounts, with no password required AND no expiry, are a massive vulnerability.  

IMO (not a humble one) there is no justification for allowing these accounts to exist in this state.

You cannot guarantee that someone has not found these accounts and is not using them for what ever they want.  The default membership in the Domain Users group, most of the time, grants sufficient access to certain server resources (for example: file shares) where these accounts could cause issues.

Accounts in the Domain Users group ARE privileged accounts.  Membership in the Domain Users group means that after entering valid credentials (username & password), you have valid security token(s) that can be used to access resources that require an authentication token.

How do you know that accounts in the Domain Users group, cannot access any resources?  There are plenty of places where "everyone/anonymous" is allowed.  Even if you removed these anonymous permissions and replaced it with "Authenticated Users," these accounts are considered authenticated users.

The fact that your domain has domain accounts that do not require passwords, leads me to believe that, if one were to look around, they would find defaulted permissions on various resources.  Places were authenticated and/or anonymous (everyone) credentials have Read/Write/Delete (or even Full Control) access.  Also leading me to believe that your infrastructure may not be as secure as you might think.

On matters such as these (security, policy, access, permissions), I have quiet strong opinions.  This probably reads as a harsh assessment, but the risk that these accounts represent are unacceptable from a security viewpoint as well as from a business standpoint.

My suggestion is to submit your change requests (there are no significant budget impacts since the changes are configuration changes) and fix the accounts that the auditors have highlighted.

Dan
2
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
A DAuthor Commented:
Thanks Dan,

What you mentioned is still applicable if accounts are restricted through GP of Deny logon locally at the first instance? I think we should apply this GP on those accounts and then perform assessment of CR from application perspective which may be time consuming activitiy?

Do you think it will be still a concern even if accounts are restricted through this particular GP?
0
 
Dan McFaddenSystems EngineerCommented:
OK, so now the "No Password Required" accounts cannot log on locally to computers.  That does not prevent the account credentials from being used by an account that can log on locally and then run an application as another user.

The risk still exists.

Do these "No Password Required" accounts have the "Log on as a service" permission?  Meaning these accounts can register and start a process as a service.  If another account can log on locally somewhere, the "No Password Required" accounts can still be used.

Yes, my opinion is, the risk still exists even if you remove the log on locally permission.

Dan
1
 
A DAuthor Commented:
Thanks Dan, Yes, the accounts have "Log on as a service" and "Log on As Batch" permission through GP. Considering this, if we add them into "Deny logon locally",  and besides this we can mention that a application CR will be raise to for complete assessment. Considering this will that help us to stand in a somewhat safe position?
0
 
Dan McFaddenSystems EngineerCommented:
No, you are not in a safe position, the security risk still exists, as I stated above.  These "No Password Required" accounts, are highly privileged!  They are allowed to run as a service and as a batch process.

Since there are no passwords on these accounts, anyone that knows a username of one of these accounts, can run a service and a process as a batch.

Dan
1
 
gheistCommented:
+ anyone logged in to AD can retrieve them.
1
 
Gary PattersonVP Technology / Senior Consultant Commented:
Agree 100% with Dan (and your outside auditor).  I see no way to justify these accounts from a security perspective.  They violate best practices, and create a potential attack vector.  

Any time you allow a potential intruder with a mechanism to become an "authenticated user" without actually performing authentication, you put your systems at risk.
1
 
McKnifeCommented:
There is no doubt anyone agrees that they will need a password ASAP. But assessing the risk is a little more than what has been done. You need to ask: if an attacker knew, what would he be able to do.
And no, standard users cannot register services, no matter if they know about such an account.

1 The most interesting thing is of course: can we use this account to logon somewhere? No, we can't, you set a policy that prevents it.
2 the 2nd most interesting thing: can we access network resources with an account that has restrictions as in (1) - surely. But would that be more resources than the attacker has already access to? You need to answer that.
1
 
gheistCommented:
Many drivers add unprotected services and directories. You can manipulate that for profit.
0
 
McKnifeCommented:
? What's the connection? Users cannot install drivers. If we are talking about admins, it's a different scenario. The author needs to define his scenario - what should we protect against?
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
Author isn't asking us to help him protect his network or resources.  

Author is looking for an argument that he can use with his auditors to convince them that s/he has  taken adequate steps to mitigate risk on these accounts with no passwords (GP, limited permissions) and hopefully get them to change this audit action item to "no action required".

Too many present and future variables to grant an exception to something this basic.  No good answer as far as I'm concerned but "follow best security practices and at a minimum secure these accounts with a password".
1
 
McKnifeCommented:
That's what he said.
I tried to point out that there an assessment would have to ask "what are these accounts used for, what access do they have and would an attacker be in the position to abuse this"
It is the author's turn to provide more info on these accounts.
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
What are these accounts used for?

My position is that it doesn't matter for the purpose of this discussion.  These accounts provide, at a minimum, a possible mechanism for an unauthenticated attacker to escalate to "Authenticated user", and that's enough for me to say, "violates best security practices" and "potential attack point" - without even going to the other two questions.

But for fun, let's do that:

What access do they have?

Even if access is tightly restricted today, and there are no valuable resources exposed to these accounts today, remember that in networks and in security things change.  Additional rights and memberships get granted.  Groups get changed.  Errors get made.  Exploits are discovered.  As a result, even if resources accessible to these accounts are strictly limited at the moment, it doesn't mean that in the future they won't have, accidentally or intentionally, wider access, or access to a particular valuable resource.

Would an attacker be in the position to abuse this?

We don't know in advance.  If we did, we'd close that hole before it could be exploited.  But since we don't know what avenue an attacker will take to successfully compromise the network, we can't really evaluate how an attacker might be able to use these accounts for harm.  

Securing a network is about raising bars to entry, and password protecting all accounts is a bare minimum bar, if you ask me.
1
 
Dan McFaddenSystems EngineerCommented:
As always, when an question like this is posted, the amount of info given is limited.  Then best that can be done is to try to answer, as directly as possible, with the best info from out collective experience.  

From the OP, I took the main question as being:

Is there any way I can provide evidence to auditor that those accounts are not vulnerable?

- and -

Is there any way to show evidence that these are just domain users and not privileged accounts and not being used by humans but just by the application?

I felt that it was necessary to highlight this point:  allowing unprotected accounts (aka:  those lacking a required password to invoke & use) to exist in your domain, is not justifiable.  Period.

The source of the question appeared to be due to an internal audit to assess the corporate network environment.  Given the context of an internal audit and the resulting question, the given answer was presented.

IMO, the need to do a deep dive into Security Best Practices was not necessary since the questions came from an audit.  Meaning, someone else is asking the questions (or should be) that have been mentioned above.

I completely agree that risk assessment, is a multifaceted monster and requires more time than what can be given to a question posted on EE.

And to the point:  
... would an attacker be in the position to abuse this?
That answer is simple enough.  Yes.  If an attack vector is open, you know it will be eventually found, that is not a question.  It's never of question of if, but when.

And if you are the SysAdmin who knows that accounts with "No Password Required and Account Does Not Expire" attributes exist, you, the SysAdmin, are at fault.  Especially if it arises from a 3rd party internal audit where the existence of these accounts was questioned.

Dan
2
 
A DAuthor Commented:
Hi Guys,

Thanks for your answers and that helped me in my discussion with auditors. I have shared system generated group membership data and group policy with them and practically shown  them that these accounts can not be used to logon to application or database servers or shared folders on application or database servers can not be altered using these accounts - for the system they are auditing us. Also share with them a Change Request number and told them that an assessment will be done to protect these accounts and will be completed and delivered in a month of time.

Although this gesture did not make him very happy but might help us in getting few audit observations than getting a major NC.

Auditors are still on-site and checking other areas of the system. I'll keep this thread open till end of next week and will share the audit findings on this particular area on this thread.
0
 
A DAuthor Commented:
We might get few observations but we already have a Change Request and a plan in place to take appropriate action for those observations. Though we did not yet get full audit report and expecting the same in few weeks, we are anticipating no major NC in this particular area. Thanks for sharing your valuable inputs.
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 5
  • 4
  • 3
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now