Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/the-useless-one/pywerview/llms.txt

Use this file to discover all available pages before exploring further.

By default, PywerView connects to the domain controller over plain LDAP on port 389. The --tls flag overrides this and forces all LDAP traffic through an encrypted LDAPS connection on port 636. This matters for two concrete scenarios: retrieving Group Managed Service Account (gMSA) managed passwords, where the domain controller refuses to return the msds-managedpassword attribute over an unencrypted channel, and certificate-based (SChannel) authentication, where --tls determines whether PywerView uses a direct LDAPS connection or falls back to StartTLS with an EXTERNAL SASL bind.

When to Use --tls

1. Retrieving gMSA Managed Passwords

The get-netgmsa command can enumerate Group Managed Service Accounts. However, the sensitive msds-managedpassword attribute is only returned when the connection is made over TLS. Without --tls, the field is silently absent from the output.
Always use --tls when querying gMSA or any other sensitive attribute that Active Directory withholds over plain LDAP. Even when not strictly required, an encrypted channel is better operational practice and prevents credential material from travelling in cleartext over the network.
Without --tls — managed password not returned:
pywerview get-netgmsa -t srv-ad.contoso.com -u 'SRV-MAIL$' --hashes $NT_HASH --resolve-sids
distinguishedname:       CN=gMSA-01,CN=Managed Service Accounts,DC=contoso,DC=com
objectsid:               S-1-5-21-863927164-4106933278-53377030-3115
samaccountname:          gMSA-01$
msds-groupmsamembership: CN=SRV-MAIL,CN=Computers,DC=contoso,DC=com
description:
enabled:                 True
With --tls — managed password present:
pywerview get-netgmsa -t srv-ad.contoso.com -u 'SRV-MAIL$' --hashes $NT_HASH --resolve-sids --tls
distinguishedname:       CN=gMSA-01,CN=Managed Service Accounts,DC=contoso,DC=com
objectsid:               S-1-5-21-863927164-4106933278-53377030-3115
samaccountname:          gMSA-01$
msds-managedpassword:    69730ce3914ac6[redacted]
msds-groupmsamembership: CN=SRV-MAIL,CN=Computers,DC=contoso,DC=com
description:
enabled:                 True

2. Certificate (SChannel) Authentication

When you pass --cert and --key for SChannel authentication, --tls controls how PywerView establishes the authenticated session:
PywerView connects to LDAP port 389, upgrades the connection with StartTLS, then performs an EXTERNAL SASL bind presenting your certificate. This follows the Microsoft MS-ADTS specification. Use this mode if your DC has StartTLS enabled and port 636 is not accessible.
pywerview get-netuser -w contoso.com --dc-ip 172.16.0.55 \
  --cert user.crt --key user.key \
  --username administrator
For a full walkthrough of certificate extraction and SChannel usage, see SChannel Authentication.

LDAP Signing and Channel Binding

If the domain controller enforces LDAP Signing or LDAP Channel Binding, standard ldap3 will fall back to simple (unauthenticated-level) authentication and may be rejected. To work against DCs with these policies enabled, install the ldap3-bleeding-edge fork:
pip install ldap3-bleeding-edge
This package is ldap3 2.10.1 plus six pending pull requests that add signing and channel binding support. PywerView automatically detects and uses it when present. You can confirm it is active by enabling debug logging with -l DEBUG. Without it, PywerView silently falls back to simple authentication, which will be rejected by hardened DCs.

Build docs developers (and LLMs) love