For a login to a service, ticket information flow rougly is:
 

• The user logs in and receives a "ticket granting ticket" from Kerberos
• The user tries to access the service, negotiation starts
• The user searches the canonical fqdn of the service in DNS
• The user requests a ticket for the SPN using the CAN-fqdn
• Kerberos sends a ticket to the user. This ticket contains some authentication data, encrypted with the workstation key for the SPN and access information encrypted with the user's key. Both ticket and user information contain a session key, encrypted with the workstation key for the service and the user key for the user. That ensures that the user cannot read or modify information determined for the service, since the user doesn't know the workstation key. The current tickets can be checked via the "klist" command, which works for Linux and Windows, too.
• The user forwards the authentication data from the ticket to the service.
• The service decrypts the information and the session key, and after verification the service can rely on the authenticity of the user and the secrecy of the session key contained in the ticket. For this purpose the service mut know which key to use from the local keytab file and the correct key must be included in the keytab. Apache needs this to be configured correctly in the Apache site configuration.
• The apache kerberos module sets the Remote_User information to the username and sets Auth_Type to "Negotiate". Access to the Directory protected by the authentication is granted and the information received is passed to applications through the apache environment.