Why am I known as a user?

At a minimum, the hostname of the Active Directory server, a password or key for the connection, and the information that my user has sudo privileges should be configured somewhere on the server. But where?

The ldap nsswitch module.

This probably means the nslcd daemon (aka nss-pam-ldapd), configured via /etc/nslcd.conf – not the first choice for AD¹ but it still does the job. Find the file libnss_ldap.so.2 (sorry, I don't recall offhand where Debian puts them) and run dpkg -S on it to determine the owner package.

Password authentication is generally not handled via nsswitch – despite the 'ldap' module being listed in the 'shadow' row, you will rarely if ever find shadow password entries in LDAP. Instead, a dedicated PAM module in /etc/pam.d/* performs network authentication in a more direct way.

Since you have nslcd for nsswitch, you probably also have either the standalone pam_krb5 for authentication, or possibly the same pam_ldap from nslcd.

¹ (More common options for AD integration would be sss SSSD or winbind Samba Winbind, which would additionally handle logon through Kerberos for SSO; they come with both an nsswitch module and a PAM module.)

a password or key for the connection,

If nslcd is in use, then the machine credentials will likely have been deployed manually. In a proper AD-style setup, this would be /etc/krb5.keytab storing the Kerberos credentials for the machine account (klist -k to view).

But proper Kerberos usage with nslcd is a little fiddly to set up (and my patches to improve it have had no reaction from the developer), so it's more likely that you'll find a plain-text binddn and bindpw in the /etc/nslcd.conf.

If you're lucky, the previous admin will have manually set up per-machine accounts there. If you're really (un)lucky, the previous admin might have just deployed their Domain Admin credentials to all servers... (Which would have worked, because nslcd doesn't perform any AD-specific "Netlogon" RPC calls – it acts as a basic LDAP client, which only needs user-level credentials and does not require a "workstation trust relationship" as Windows calls it – but is certainly not what you want to find all over the place.)

[For future reference] A proper AD "domain join" should always have a dedicated computer account for each machine, its credentials stored either in krb5.keytab for SSSD/nslcd or in secrets.tdb for Winbind. Either of those could be provisioned using the realmd tool, although more direct adcli for SSSD or net join for Samba can also be used.

the information that my user has sudo privileges

While technically possible to store this in AD (sudo has both direct LDAP support and SSSD support), your nsswitch.conf does not have a 'sudo' row, therefore it's most likely that everything is configured through the regular /etc/sudoers (plus /etc/sudoers.d/*).

You can use sudo -ll to see which sudoers rules apply to you and where they come from.

The privileges might have been granted to an AD group by name, or your account might have been added to a local 'wheel' or 'sudoers' group (local groups can have non-local members).

[For reference] If I remember correctly, SSSD can also generate sudoers rules from Windows Group Policy.

And why isn't my username listed in getent passwd?

It is not uncommon for Active Directory integration to be set up as non-enumerable, both for performance (to help programs which foolishly insist on listing 1000s of accounts when they could've done a single getpwnam lookup) and for security/privacy.

In your case, enumeration might have been disabled client-side as part of nslcd.conf, and/or achieved through AD-side access control lists (think chmod 0711 but for LDAP OUs).

You could use ldapsearch or Apache Directory Studio to check what you're able to see directly. (Note that ldapsearch has a separate "defaults" file and does not share configuration with nslcd, so you may need to manually tell it about the URL.)

You have ldap authentication enabled on your system, so that answers how you are able to log in. There's a central LDAP server against which you're authenticated. That's typical for an AD setup.

At a minimum, the hostname of the Active Directory server, a password or key for the connection, and the information that my user has sudo privileges should be configured somewhere on the server.

Let's go through this one by one:

hostname of the Active Directory server

Agreed, somehow your computer needs to know which LDAP server to ask. /etc/ldap.conf and /etc/openldap/ldap.conf is where the LDAP client looks by default.

a password or key for the connection

Depends on how you establish the connection/trust. In an AD, that might be kerberos configuration.

information that my user has sudo privileges

I'm guessing that is solved implicitly via group memberships.

You're not being listed by getent because that would require enumerating the LDAP directory, and a) that might be huge and b) that's something that might (very reasonably) be forbidden.