ad-ldap-enum has been inventoried on Rawsec's CyberSecurity Inventory.

https://inventory.rawsec.ml/tools.html#ad-ldap-enum

What is Rawsec's CyberSecurity Inventory?

An inventory of tools and resources about CyberSecurity. This inventory aims to help people to find everything related to CyberSecurity.

More details about features here.

Note: the inventory is a FLOSS (Free, Libre and Open-Source Software) project.

Why should you care about being inventoried?

Mainly because this is giving visibility to your tool and improve its referencing.

Badges

The badge shows to your community that your are inventoried. It looks good but also shows you care about your project, that your tool is referenced.

Feel free to claim your badge here: http://inventory.rawsec.ml/features.html#badges, it looks like that , but there are several styles available.

Want to thank us?

If you want to thank us, you can help make our open project better known by tweeting about it! For example:

So what?

That's all, this message is just to notify you if you care. Else you can close this issue.

Can we have a flag to pull the full list of LDAP attributes for users? I find myself wanting more information, but not sure it is worth trying to narrow that down. Thoughts?

When values are not found, ad-ldap-enum sometimes outputs rows with different numbers of columns, instead of outputting a consistent number of columns with empty strings for values that aren't found. This causes problems when passing ad-ldap-enum output files to other tools.

I'm not sure if this applies to just Domain Group Membership, but many (though not all) members of the groups Domain Admins, Domain Computers, Domain Controllers, and Domain Users did not have a Distinguished Name returned. Additionally, all computer account members of Domain Users and Domain Computers were missing both Member Status and Group Distinguished name values.

The problem is not that the values were not present, but the output did not contain empty strings in their place. Instead, entries missing the Distinguished Name contained 3 columns instead of 4. I believe entries missing both Member Status and Group Distinguished Name contained only 2 columns. This problem was limited to the Domain Group Membership file in my case but may also apply to other files, apologies for the lack of detail. Further testing is required.

For the time being I am using the following function to normalize the number of columns in output files, but ideally a fix should be implemented to output empty strings in place of values (such as Group Distinguished Name) ad-ldap-enum can't retrieve.

def normalize_csv(file_path):
    """
    Normalize a CSV file by adding empty columns to each row as necessary.

    Args:
        file_path (str): The path to the CSV file.

    Returns:
        None
    """
    # Read the CSV file
    with open(file_path, 'r') as file:
        reader = csv.reader(file)
        rows = list(reader)

    # Find the maximum number of columns in the CSV
    max_columns = max(len(row) for row in rows)

    # Normalize the rows by adding empty columns
    normalized_rows = [row + [''] * (max_columns - len(row)) for row in rows]

    # Write the normalized rows back to the CSV file
    with open(file_path, 'w', newline='') as file:
        writer = csv.writer(file)
        writer.writerows(normalized_rows)

Running the script with no arguments should bring up the help page vs erroring out.

Unfortunately ad-ldap-enum.py is not compatible with python3.

Can anyone estimate how long it would take to migrate the script to python3?

Remove carriage returns and/or line feeds from user comment output to flatten in text.

Add the functionality to recursively go through group membership and display nested groups flattened out.

On the HackTheBox machine Escape, the guest user was enabled on a DC. I attempted to authenticate using the password '' but the tool refused to accept it as a valid parameter value. Even when I used the prompt parameter, the issue arose.

Additionally, I attempted to use PassTheHash via the null NTLM hash, 31d6cfe0d16ae931b73c59d7e0c089c0, but the DC responded incorrect password.

We need to figure out the password null password (could be checking if variable exists vs. null). We also need to figure out why PassTheHash seems to not be accepted some time.

Once the https://github.com/cannatag/ldap3/tree/dev branch is merged into master and pushed to pip, we can support LDAP channel binding due to cannatag/ldap3#1087 already being merged. Channel binding applies to both LDAP and LDAPS connections.

Please note that LDAP signing requirements can be achieved through using LDAPS or LDAP with STARTTLS. This tool does not support LDAP with STARTTLS.

The error you may receive IF LDAP channel binding is required is Invalid credentials or domain were provided. You could also use the -verbosity flags as needed to debug the LDAP traffic.

When -u is given a fully qualified domain, the script will state that incorrect username or password was given. For example:

-u crowesec\username < ok
-u crowesec.net\username < wrong auth

Within the HackTheBox Sauna and Forest machines, the same error occurred despite the domain being valid:

Valid domain:

• https://www.n00py.io/2020/02/exploiting-ldap-server-null-bind/

Once authenticated, the tool ran fine.

This repository should consider moving to ldap3 over python-ldap as ldap3 is entirely Python-based while python-ldap is Python/C. python-ldap does not work easily on Windows which causes this tool to be Linux focused only seen here:

• https://www.python-ldap.org/en/python-ldap-3.3.0/installing.html

More information regarding the change can be found here:

• https://sixfeetup.com/blog/new-ldap3-python-ldap-library

Additionally, the Impacket suite uses ldap3 as their LDAP module which causes issues as both modules use the ldap Python naming scheme within import methods particularly on Kali Linux systems.

I don't think changing this tool to ldap3 will be an incredible amount of work once the data structure and manipulation is understood.

The methods get_password_last_set_date and get_last_logon_date are duplicating code. Calculating time-stamps should be made generic to allow for future expansion.

Ran the following:
python3 ad-ldap-enum.py -l <IP> -d <domain> -u <username> -p <password>

Fix the error message on line 419 from 'LDAP server is available' to 'LDAP server is not available'

Queried our LDAP server. Got this:
ldap.UNAVAILABLE_CRITICAL_EXTENSION: {'desc': 'Critical extension is unavailable'}
Quick Google search turns up:
http://blogs.adobe.com/apugalia/ldap-error-code-12-unavailable-critical-extension/
https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec439052.html

...commonly occurs when asking an LDAP Server to return paged results but the LDAP doesn’t support the PagedResultsControl extension.

SunOne 5.2 and 6.3 don’t support PagedResultsControl extension.

...which is the problem I'm running into. Unfortunately, setting the batch size parameter to 0 on such systems is also not going to help, as there is (in our case) a hard limit on the return size configured.

One way around this is to rewrite queries to parse out the enumeration in small steps, using query strings with wildcard operators. For example, querying sn="dav*", sn="daw*", etc., and then combining the results later. Of course, any arbitrary query string has to match the actual data in LDAP and be adjusted in the event the return exceeds whatever arbitrary cut-off size is implemented.

Any hope that ad-ldap-enum would be updated to support these edge cases situations?

I can see why that would not be super important, since the objective is AD enumeration and not just LDAP enum...

As seen just now, query was to my AD logon server. Any hints?

$ python ad-ldap-enum.py -l host-fqdn -d my-domain -u me -p my_pass
2017-07-05 15:00:55 INFO Querying users
2017-07-05 15:06:32 INFO Querying groups
2017-07-05 15:14:01 INFO Querying computers
2017-07-05 15:15:16 INFO Building users dictionary
2017-07-05 15:15:16 INFO Building groups dictionary
2017-07-05 15:15:16 INFO Building computers dictionary
2017-07-05 15:15:16 INFO Exploding large groups
Traceback (most recent call last):
File "ad-ldap-enum.py", line 460, in
ldap_queries(ldap_client, base_dn, args.nested_groups)
File "ad-ldap-enum.py", line 210, in ldap_queries
groups_dictionary[group_key].members = get_membership_with_ranges(ldap_client, base_dn, group_key)
File "ad-ldap-enum.py", line 387, in get_membership_with_ranges
membership_results = query_ldap_with_paging(ldap_client, base_dn, membership_filter, ['distinguishedName'])
File "ad-ldap-enum.py", line 356, in query_ldap_with_paging
msgid = ldap_client.search_ext(base_dn, ldap.SCOPE_SUBTREE, search_filter, attributes, serverctrls=[ldap_control])
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 586, in search_ext
timeout,sizelimit,
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in _ldap_call
result = func(*args,**kwargs)
ldap.FILTER_ERROR: {'desc': 'Bad search filter'}

Authentication passwords are being sent Plain-text, there should be a way to bind in an encrypted method like in PHP, VB and most languages
https://blogs.technet.microsoft.com/heyscriptingguy/2005/12/09/how-can-i-use-alternate-credentials-when-searching-active-directory/

If the tool is unable to bind through a null/authenticated or insecure/secure LDAP connection, the tool outputs an error rather than a statement stating "Unable to bind to requested LDAP connection." See the current output now:

Can we have it pull the spns associated with domain user accounts?

These attributes will be stored in the servicePrincipalName attribute for each user account if there are existing spns.