Giter Club home page Giter Club logo

adeleg's Introduction

ADeleg

Build Release Issues

Is an Active Directory delegation management tool. It allows you to make a detailed inventory of delegations set up so far in a forest, along with their potential issues:

  • Objects owned by users
  • Objects with ACEs for users
  • Non canonical ACL
  • Disabled ACL inheritance
  • Default ACL modified in schema
  • Deleted delegation trustees

It also allows you to document your delegation model in JSON files, to obtain a more readable view:

Usage

Download the latest release here and double click on it for a graphical interface:

Screenshot of GUI

You can also use the tool from a terminal by passing any option to it (if you don't want to pass any particular option, just use --text):

Screenshot of CLI

If you want to export results, you can choose a CSV output using --csv my.csv This is also suitable if you are interested in differences introduced since a previous dump (e.g. in PowerShell, diff (cat export_new.csv) (cat export_old.csv) )

Results should be concise in forests without previous work in delegation management. If results are too verbose to be used, open an issue describing the type of results obscuring interesting ones, ideally with CSV exports or screenshots.

You can start using this inventory right away, in two ways:

  1. look for highly privileged resources which have no reason to have any delegation set up on them, since they are only supposed to be managed by forest-wide administrators

View by resource

  1. you can also start the other way around, and look for trustees which have no reason to have any right delegated to them (e.g. day-to-day end user accounts)

View by trustee

FAQ

How do I know if one result is important? Should I consider everything a problem? You should start reviewing delegations on your critical assets (domain controllers, domain admins, their admin workstations, servers with sensitive business data, etc.): are these delegations needed for a user or service to do their work? could they not work with fewer access rights, or on fewer objects?

My forest has years of delegations built up, how am I supposed to handle that many warnings? You may want to run the analysis periodically and only focus on differences, so that you can start from a baseline and clean up delegations little by little over time.

Can I import results from this tool into product ? Yes, if your tool knows how to parse CSV: .\adeleg.exe --csv dump.csv

How does it work?

This tool enumerates security descriptors of all objects, then filters out "expected" ACEs:

  • Inherited ACEs, since we are only interested in the original ACE upper in the tree;
  • ACEs in the defaultSecurityDescriptor of the object class in the schema;
  • Some special cases which need to be handled manually.

Special cases currently include:

  • object owners under a container with a CREATE_CHILD delegation
  • ACEs for CREATOR_OWNER which are replaced and split in two in some cases during inheritance
  • AdminSDHolder ACEs, for principals with adminCount set to 1
  • KDS Root Keys, RODCs, ADCS, ADFS, Exchange, etc. are work in progress

Copyright

All icons packaged with this project are the property of Microsoft Corporation. For source code licensing, see LICENSE.md.

adeleg's People

Contributors

commial avatar mtth-bfft avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

adeleg's Issues

Merged ACEs should be supported by the engine

When modifying ACLs using GUIs (e.g. PowerShell, COM objects), ACEs for the same trustee and with the same { flags, object type, inherited object type } are merged. The engine currently treats such ACEs as orphans, and fails to see that expected ACEs are there.

CSV output not easy to manage

this format of csv output has ',' delimiter for distinguished name AND for other values. Excel thinks distinguished name are multiple values and put each CN/OU value into different columns

Compute inheritance sources and perform a complete canonicality test

The current canonicality check could miss inherited ACEs in the wrong order.

To check that the order indeed is:

  1. Explicit Deny ACEs
  2. Explicit Allow ACEs
  3. Inherited Deny ACEs from direct parent
  4. Inherited Allow ACEs from direct parent
  5. Inherited Deny ACEs from grandparent
  6. Inherited Allow ACEs from grandparent
  7. etc. until the root of the naming context

we need to compute inheritance sources for all objects.

This could be done with GetInheritanceSource from advapi32.dll, but it might be way too slow for our usecase.

Ignore owner and ACEs on objects created through a CREATE_CHILD delegation

Objects created through a CREATE_CHILD delegation on a container come up as results in analysis, which causes a great lot of noise:

  • their owner is the principal who created the object
  • their ACL may have explicit ACEs derived from CREATOR_OWNER (e.g. from the schema, or from parent containers)

This causes a lot of noise and makes analysis harder, e.g.:

  • for computers joined by non-administrators
  • for DNS records created by computers for themselves

This feature would require, when considering object X, with an owner Y or an explicit ACE for Y, a LDAP lookup to fetch all groups Y belongs to, another LDAP lookup for the ACL of X' s parent, and an Authz check to see if Y had the rights to create X. Only one such trustee should be tolerated for each object.

A faster (less precise) way of doing this would be to lookup Y' s groups and check if any parent container has a delegation to create objects of such types (and that delegation does not include any deny ACE for CREATE_CHILD in any intermediary container which would have matched Y's groups).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.