I understand that the principle of Kerberos is to allow authentication between users and services on an unsecured network. Tickets generated by the authentication and ticket-granting service support secure communications and don't require a password to be transmitted across the network.
The flow relies on the auth server in the KDC (s) having a shared secret with the client (c).
However, at some point, the user itself must have been created and generally, users are created from client machines (you don't usually log onto the domain controller to create users)
So how do the user and secret key (Kac) get created in the first place and stored in the KDC database if the password/secret is never sent across the network?
The administration of principals in a KDC's database is outside the scope of the normal Kerberos protocol. Usually it's done using some auxiliary protocol, and each KDC can implement it in any way it wants.
For example, MIT Kerberos has the (SunRPC-based) kadmin protocol, and the kadmin client indeed sends the actual administrator-specified password to the kadmind service running on the KDC. (The RPC message is encrypted using the Kerberos session key, of course.) Heimdal has its own kadmin protocol, mostly incompatible with MIT's but working the same way.
(Both also have "local" versions of the kadmin tool, which directly accesses the KDC database backend – this is how the initial admin accounts are created, typically by running kadmin.local on the server console or through SSH.)
Microsoft Active Directory has several user administration protocols, some of them dating to pre-AD days, but the primary mechanism is LDAP (usually over an GSSAPI/Kerberos-encrypted session, but occassionally TLS-encrypted).
To create a new account in MS AD, the administrator creates an LDAP 'User' or 'Computer' entry with the plain-text 'userPassword' attribute, and the domain controller automatically transforms this attribute into Kerberos keys (instead of storing it raw). The commonly used "AD Users & Computers" applet (dsa.msc) is really an interface to the LDAP directory.
All of the above implementations also support a second administration protocol, the kpasswd protocol whose sole purpose is to allow an existing user to change their password. As you'd expect, it also works by transmitting the user's new password over the network, again making use of Kerberos authentication and encryption. (Password changes can also be done via AD's LDAP or MIT/Heimdal's kadmin, but kpasswd has the advantage of being supported by all three.)
As a final side note, the PKINIT extension uses X.509 certificates to authenticate the AS-REQ – in which case the client doesn't know their own shared secret, so the KDC in fact sends the whole Kc to the client over the network (encrypted using a session key negotiated via DH, somewhat like TLS would). This is mostly used in Active Directory environments with "smart card" authentication.