Enumerating Active Directory Without Credentials: A Practical Guide for Security Assessments

Active Directory enumeration is often associated with valid domain credentials. In many penetration tests, the first question is much simpler “What can an attacker discover before authenticating at all?”. An assessor entering an internal network may initially have nothing more than an IP address, a network connection, and perhaps a suspected domain name. Yet Active Directory environments expose multiple supporting services—DNS, Kerberos, LDAP, SMB, RPC, and others—that may reveal valuable information before authentication takes place.

This makes unauthenticated enumeration an important part of internal VAPT and red-team reconnaissance. The goal is not necessarily to compromise Active Directory immediately. Instead, it is to determine how much information the environment exposes to an unknown or unauthenticated system and whether that information can be used to build a clearer picture of the domain. This blog explores practical approaches for enumerating Active Directory without domain credentials, what information each technique may reveal, and how the findings can influence the next phase of an authorized security assessment.

What Does “Without Credentials” Actually Mean?

Unauthenticated Active Directory enumeration does not necessarily mean that every request reaches Active Directory anonymously. Instead, it means the tester begins without a valid domain username and password. Information may still be obtained from several sources. For example:

• DNS records may expose domain controllers.
• Kerberos responses may help confirm whether usernames exist.
• LDAP may permit anonymous queries in poorly configured environments.
• SMB may allow null-session access.
• RPC interfaces may expose domain information.
• Service banners can reveal operating system or infrastructure details.
• TLS certificates may disclose hostnames and domain names.

The amount of information available depends heavily on the configuration and age of the Active Directory environment. Modern Windows domains generally restrict anonymous enumeration significantly more than older environments. Nevertheless, unauthenticated reconnaissance remains valuable because even small pieces of information can be combined.

Step 1: Start With Network Discovery

Before attempting Active Directory-specific enumeration, determine which hosts appear to provide domain infrastructure. Common Active Directory-related ports include:

A host exposing several of these ports is a strong candidate for a domain controller.At this stage, the objective is simply to determine whether the target behaves like Active Directory infrastructure.

Step 2: Discover the Active Directory Domain Through DNS

DNS is one of the most valuable services during credential-less Active Directory reconnaissance. Active Directory depends heavily on DNS, particularly SRV records. If the domain name is already known, query the LDAP service records:

nslookup -type=SRV_ldap._tcp.dc._msdcs.example.local

Alternatively:

dig SRV _ldap._tcp.dc._msdcs.example.local

DNS alone may therefore reveal:

• Active Directory domain name
• Domain controller hostnames
• Domain controller IP addresses
• Global Catalog servers
• Kerberos servers
• Internal naming conventions
• Site-related infrastructure

Without authenticating once, the assessor has already started reconstructing the internal network architecture.

Step 3: Identify the Domain Through LDAP RootDSE

One of the most useful LDAP reconnaissance techniques is querying RootDSE. RootDSE contains metadata describing the LDAP server and Active Directory directory structure. Unlike normal LDAP objects, certain RootDSE information may often be queried without performing a complete authenticated directory search. For example:

ldapsearch -x -H ldap://10.10.10.10 -s base -b "" defaultNamingContext

Step 4: Test for Anonymous LDAP Access

Discovering RootDSE information does not automatically mean that unrestricted anonymous LDAP enumeration is enabled. The next step is determining whether directory objects can actually be queried anonymously. For example:

ldapsearch -x -H ldap://10.10.10.10 -b "DC=corp,DC=example,DC=local"

If anonymous directory queries are permitted, substantially more information may become available. Possible exposures include:

• User accounts
• Computer accounts
• Groups
• Organizational Units
• Group memberships
• Service Principal Names
• Descriptions
• Password policy-related objects
• Domain configuration

This would represent a significant information disclosure finding. In properly hardened Active Directory environments, unrestricted anonymous LDAP enumeration should generally fail.

Step 5: Check SMB Without Authentication

SMB is another important protocol to examine. A simple initial test is:

smbclient -L //10.10.10.10 -N

The -N option instructs smbclient not to request a password. A tester can then determine whether any of those shares permit anonymous access. Potentially exposed files might include:

• configuration files
• deployment scripts
• backup files
• documentation
• password spreadsheets
• software installers
• log files

Even when directory enumeration fails, anonymously accessible shares can provide valuable reconnaissance information.

Step 6: SMB Enumeration with NetExec

NetExec provides a convenient way to check SMB hosts during an internal assessment. For example:

nxc smb 10.10.10.10

Even without authentication, the response may provide information such as:

• hostname
• Windows version
• domain name
• SMB signing configuration
• SMBv1 status

Those details help establish the environment before any credentials are obtained.

Step 7: Check for SMB Null Sessions

Historically, Windows environments sometimes allowed null sessions, where SMB/RPC connections could be established using an empty username and password. They are considerably less common in modern Active Directory environments but remain worth checking during assessments. One simple test is:

smbclient -L //10.10.10.10 -U "%"

Another approach is RPC:

rpcclient -U "" -N 10.10.10.10

Successful anonymous RPC enumeration can be particularly valuable because it may expose a significant portion of the domain structure.

Step 8: RPC Enumeration Without Credentials

RPC exposes several interfaces used by Windows systems. Important examples include:

SAMR – Security Account Manager Remote Protocol
LSARPC – Local Security Authority Remote Protocol
SRVSVC – Server Service Remote Protocol

If anonymous RPC access is available, an assessor may retrieve useful information without authenticating. Start with:

rpcclient -U "" -N 10.10.10.10

That may already confirm that the target is a domain controller. This represents one of the more useful unauthenticated enumeration conditions because the resulting username list can influence later authentication testing.

Step 9: RID Cycling

Even where direct user enumeration is restricted, poorly configured SMB/RPC environments may expose account information through RID cycling. Every Windows security principal receives a Security Identifier. For example:

S-1-5-21-111111111-222222222-333333333-1105

The final value “1105” and it is the Relative Identifier, or RID. If anonymous SID lookups are permitted, an assessor may attempt to resolve different RID values into usernames. Tools such as enum4linux-ng can help test this condition.

enum4linux-ng -A 10.10.10.10

Even if LDAP does not permit user enumeration, RPC-based SID lookups may still reveal accounts in incorrectly configured environments.

Step 10: Enumerating Users Through Kerberos

One of the most interesting credential-less Active Directory enumeration techniques uses Kerberos. Kerberos authentication begins before a password is necessarily validated. Depending on the request and the domain configuration, the Key Distribution Center can return different responses for an existing username and a nonexistent username

This behavioral difference may allow user enumeration. For example, Kerbrute is commonly used during authorized Active Directory assessments:

kerbrute userenum -d corp.example.local --dc 10.10.10.10 users.txt

Kerberos responses can then help determine which account names are valid.

Step 11: Obtain Domain Information Through TLS Certificates

LDAPS and HTTPS services may leak additional infrastructure information through certificates. For example:

openssl s_client -connect 10.10.10.10:636

The certificate could contain:

CN=DC01.corp.example.local

or Subject Alternative Names such as:

DNS:DC01.corp.example.local
DNS:corp.example.local

Step 12: Check for Active Directory Certificate Services

If Active Directory Certificate Services is deployed, certificate-related infrastructure may become visible during unauthenticated reconnaissance. Useful DNS names may include patterns such as:

CA01.corp.example.local
PKI.corp.example.local
ADCS.corp.example.local
certsrv.corp.example.local

Web enrollment may be exposed through:

http://server/certsrv/ or https://server/certsrv

The presence of the endpoint does not automatically represent a vulnerability. However, identifying AD CS early is important because later authenticated testing may need to examine:

• Certificate templates
• Enrollment permissions
• Subject Alternative Name configuration
• Authentication EKUs
• Certificate mapping
• Enrollment agent permissions
• Web enrollment
• NTLM relay protections

Unauthenticated enumeration is therefore often about identifying attack surfaces for later validation, not necessarily exploiting them immediately.

Enumerating Active Directory without credentials is a valuable reminder that authentication is not always the starting point of an AD assessment. Even before a tester has a valid username or password, services such as DNS, Kerberos, LDAP, SMB, RPC, and TLS can reveal useful information about the environment. In isolation, each exposed detail may appear minor. A domain name from DNS, a hostname from a certificate, an SMB banner, a valid username discovered through Kerberos, or a response from RPC may not constitute a serious weakness by itself. The real value comes from correlating these individual findings into a broader picture of the domain.

For penetration testers and red-team operators, credential-less enumeration should therefore be treated as a dedicated reconnaissance phase rather than something to skip while waiting for credentials. Understanding how the underlying protocols behave and how their results can be combined—is what turns basic enumeration into meaningful Active Directory security analysis.

In the end, successful AD reconnaissance is rarely about finding one perfect command. It is about collecting small pieces of information, validating them across multiple protocols, and gradually turning them into a clear understanding of the environment.