Editing Kerberos (protocol) (section)

==Drawbacks and limitations==
* Kerberos has strict time requirements, which means that the clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period, and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration [http://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html per MIT] requires that clock times be no more than five minutes apart. In practice, [[Network Time Protocol]] daemons are usually used to keep the host clocks synchronized. Note that some servers (Microsoft's implementation being one of them) may return a KRB_AP_ERR_SKEW result containing the encrypted server time if both clocks have an offset greater than the configured maximum value. In that case, the client could retry by calculating the time using the provided server time to find the offset. This behavior is documented in [http://www.rfc-editor.org/info/rfc4430  RFC&nbsp;4430].
* The administration protocol is not standardized and differs between server implementations. Password changes are described in [https://www.rfc-editor.org/rfc/rfc3244.html RFC&nbsp;3244].
* In case of symmetric cryptography adoption (Kerberos can work using symmetric or asymmetric (public-key) cryptography), since all authentications are controlled by a centralized [[key distribution center]] (KDC), compromise of this authentication infrastructure will allow an attacker to impersonate any user.
* Each network service that requires a different host name will need its own set of Kerberos keys. This complicates virtual hosting and clusters.
* Kerberos requires user accounts and services to have a trusted relationship to the Kerberos token server.
* The required client trust makes creating staged environments (e.g., separate domains for test environment, pre-production environment and production environment) difficult: Either domain trust relationships need to be created that prevent a strict separation of environment domains, or additional user clients need to be provided for each environment.