Skip to main content

Security & ADMF

One of our key concerns in IT is security. The very fact that you are considering adopting the Active Directory Management Framework (or already have done so) probably has a lot to do with exactly that concern.

Of course, that brings up several concerns with the ADMF itself:

  • How can I use it safely?
  • What security-related settings does it need?

Using ADMF safely​

The ADMF project is an Open Source project, hosted on github. It is written by "the community" or - as your security team or management may point out - "some stranger from the internet".

And they are correct to not be too happy about that.

The maintainer of the ADMF project is Friedrich Weinmann, a security engineer working for Microsoft at the time this is written. This does not make it a Microsoft product! There are no support cases, Enterprise Agreements are meaningless, no SLA.

One would be right to be concerned.

Supportability​

One of the big compensating factors however: This is built for Windows PowerShell - a Microsoft language that is frozen in its current state, with no updates (other than security) planned for. It is intended for administrating Active Directory, a service with virtually no updates / changes in sight.

So, what currently works can be expected to keep working virtually indefinitely.

Not an ideal situation, but not as deadly as it would be for a more volatile situation. There are three main arguments in favor despite its nature as community project with "best effort" support:

  • There is no other tool offering comparable capabilities. Especially not with Enterprise support.
  • It does not prevent falling back to current practices. If everything else fails you can at least go back to the current status quo.
  • It is Open Source: Worst case, blockers & issues can be addressed with sufficient own time investment.

Trusting that foreign code​

The greater argument regarding ADMF however, is usually around how to trust that code. There is a lot of it, and you do not have any insights into who actually can modify it. Even if you believe that is all from that one Engineer and consider him of trustworthy character, is his computer secure? Has his Github account not been compromised? Has he not ever written insecure code? Are his automation platforms secure?

And all that not just for the state of the code right now, but also going forward into the future ...

This is never a truly simple discussion, but there are some counter arguments:

Risk vs. Risk

A big part of security management is weighing risks. Pre-ADMF there is one big risk you already have: Lack of manageability & insights into your Active Directory security configuration.

When arguing against Open Source community projects, many forget about the already existing risks, and how adopting the new tools mitigates those. It should be factored in.

That said, there still is, of course, a significant risk in using those tools, many of which listed above. So, how can we further mitigate risks?

Create your own mirror (Fork)

One of the key recommendations for ADMF deployments, is to take the source code (from Github) - and not the published Modules in the PowerShell gallery. Keep your own copies of the source code in your own, internal Source Control System. If you followed the setup guidance: In the same source control system you use for the ADMF configuration files / modules.

Then build the modules from there into your own, internal PowerShell repository.

This makes you independent to any public changes, ensures you can always go back to a stable version, if an update breaks anything. It also means, that if this project is compromised in some way, this has no immediate effect on you.

It also allows you to review changes of updates, and do it from within your own, controlled environment.

Full Code Review

You do not want to trust foreign code blindly? Well, it is open source - you can always read it and make sure there are no issues.

This obviously takes a lot of time & effort, but needs not be as problematic as you may at first believe. The reviewer does not need to fully understand the full code - a security review would look for security related issues:

  • Do the modules make network requests?
  • Does the code call the Windows API inappropriately?
  • Are unexpected commands used?

You may want to create your own list of things to look for, but it should not be required to understand the full business logic itself.

Once you have done the initial review - which you absolutely should do on your own mirror's copy, not the original Github code - you can evaluate future updates based on the changed lines, rather than requiring another full review: Source Control systems allow you to compare changes between versions on a line-by-line basis.

Delayed Copy

A variant that requires less effort, but offers some assurance: When updating the ADMF code, create the copy of the source code in a new branch in your own Source Control system and do not apply the update!

At least not right away.

By leaving it to stew for a time frame (a week? a month?), you can delay issues with new versions and give Antivirus Solutions time to catch up, if that latest version has been compromised.

ADMF Security: Settings needed, protocols used​

The ADMF is perfectly fine to use in a full offline environment. The computer(s) running the tools must ...

  • Be Windows Computers (Client or Server matters not)
  • Be able to run the PowerShell code. If you use PowerShell hardening, you either must make an exemption for that computer, or allowlist all modules involved.
  • Have the ActiveDirectory & Group Policy modules installed. Usually by installing the Remote Server Administration Tools Server Feature/Windows Optional Feature.

For its workload, the ADMF requires network access to the managed Forests:

  • ADWS: The Active Directory Web Services are used for the bulk of operations. This is what the official Microsoft ActiveDirectory PowerShell module uses.
  • LDAP: The Leightweight Directory Access Protocol is needed for some operations, the default Active Directory network protocol.
  • WinRM: The Windows Remote Management protocol is used for some operations that either require execution from within the domain to reliably work (e.g. ACL owner resolution) or require file operations (e.g. Group Policy).

You can target specific domain controllers within a domain, so these protocols need not be allowed on all domain controllers. By default, ADMF will attempt to communicate with the PDC Emulator of any given domain.

info

The computer running ADMF need not be a member server in the targeted domain or forest. There is no requirement for a trust between the computer's domain and the target domain. The computer need not be a member in any domain.