How does Kerberos authenticate a user in phase 1 without the password ever crossing the network, and what is pre-authentication for?

Question

Accepted Answer

The AS reply is encrypted with a key derived from the user's password, so only the real user can decrypt the session key inside; pre-authentication adds a timestamp encrypted with that key to the request, so the AS only answers users who already proved knowledge of the password.
In the basic exchange the AS does not check a password at all: it just looks up the user and encrypts its answer with the user's key. If someone else asked in the user's name, they would receive a reply they cannot open. Authentication happens implicitly, on the client, when decryption succeeds. The password itself is never transmitted.
That basic version has a weakness the Kerberos specification itself points out: anyone can request an AS-REP for any user and take it home. The reply contains data encrypted with a password-derived key, which is perfect material for an offline password-guessing attack (today known as AS-REP roasting).
Pre-authentication fixes this: the AS-REQ carries an extra field, typically the current timestamp encrypted with the client secret key (PA-ENC-TIMESTAMP). The AS decrypts and checks it before answering. Active Directory requires pre-authentication by default; accounts where it is switched off are a classic finding in penetration tests.
Go deeper:

RFC 4120, Section 3.1.1: Generation of KRB_AS_REQ — pre-authentication and why it is recommended.
 MITRE ATT&CK: AS-REP Roasting (T1558.004) — the attack on accounts without pre-authentication, with detections and mitigations.