{"action":"created","issue":{"url":"https://api.github.com/repos/heimdal/heimdal/issues/173","repository_url":"https://api.github.com/repos/heimdal/heimdal","labels_url":"https://api.github.com/repos/heimdal/heimdal/issues/173/labels{/name}","comments_url":"https://api.github.com/repos/heimdal/heimdal/issues/173/comments","events_url":"https://api.github.com/repos/heimdal/heimdal/issues/173/events","html_url":"https://github.com/heimdal/heimdal/pull/173","id":150449718,"number":173,"title":"Fix QAS Bug 21711: Kerberos BAD_INTEGRITY error with 2008 R2 RODC","user":{"login":"DavidMulder","id":2014292,"avatar_url":"https://avatars.githubusercontent.com/u/2014292?v=3","gravatar_id":"","url":"https://api.github.com/users/DavidMulder","html_url":"https://github.com/DavidMulder","followers_url":"https://api.github.com/users/DavidMulder/followers","following_url":"https://api.github.com/users/DavidMulder/following{/other_user}","gists_url":"https://api.github.com/users/DavidMulder/gists{/gist_id}","starred_url":"https://api.github.com/users/DavidMulder/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DavidMulder/subscriptions","organizations_url":"https://api.github.com/users/DavidMulder/orgs","repos_url":"https://api.github.com/users/DavidMulder/repos","events_url":"https://api.github.com/users/DavidMulder/events{/privacy}","received_events_url":"https://api.github.com/users/DavidMulder/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2016-04-22T19:12:15Z","updated_at":"2016-07-17T04:47:19Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/heimdal/heimdal/pulls/173","html_url":"https://github.com/heimdal/heimdal/pull/173","diff_url":"https://github.com/heimdal/heimdal/pull/173.diff","patch_url":"https://github.com/heimdal/heimdal/pull/173.patch"},"body":"BAD_INTEGRITY error when trying to kinit:\r\n\r\nERROR: VAS_ERR_KRB5: Failed to obtain credentials. Client: SLED10-32$@F.QAS,\r\nService: SLED10-32$@F.QAS, Server: ad2-f.f.qas\r\nCaused by:\r\nKRB5KRB_AP_ERR_BAD_INTEGRITY (-1765328353): Decrypt integrity check failed\r\n\r\nMS changed code for RODCs in 2008R2. MS does state that ALL krgtgt/REALM tickets SHOULD be sent using principal name type of KRB5_NT_SRV_INST, instead of KRB5_NT_PRINCIPAL.\r\n\r\nFrom Microsoft:\r\n\r\n\"I believe we discovered the problem. There isn’t a bug in Windows. \r\nThere’s been a code change to address another issue which puts in additional\r\nchecks for Kerberos tickets. The problem is with the Unix clients when the\r\nclient request a TGT. The Unix clients are using Name-type Principal\r\n[KRB_NT_PRINCIPAL (1)] instead of using Name-type Service and Instance\r\n[KRB_NT_SRV_INST (2)]....\"\r\n\r\nFurther correspondence suggests that other tickets should be formatted to use:\r\n\r\n\"TGT’s should always be KRB5_NT_SRV_INST. As far as principal type, it\r\ndepends on the name type being used. If it’s in the form of http/ or\r\nmssqlsvc/, etc then it would use KRB5_NT_SRV_INST. If it is host/ then it\r\nwould be KRB_NT_SRV_HST. If it’s in the form of a UPN then it would be\r\nKRB_NT_ENTERPRISE_PRINCIPAL.\""},"comment":{"url":"https://api.github.com/repos/heimdal/heimdal/issues/comments/233165019","html_url":"https://github.com/heimdal/heimdal/pull/173#issuecomment-233165019","issue_url":"https://api.github.com/repos/heimdal/heimdal/issues/173","id":233165019,"user":{"login":"jaltman","id":206466,"avatar_url":"https://avatars.githubusercontent.com/u/206466?v=3","gravatar_id":"","url":"https://api.github.com/users/jaltman","html_url":"https://github.com/jaltman","followers_url":"https://api.github.com/users/jaltman/followers","following_url":"https://api.github.com/users/jaltman/following{/other_user}","gists_url":"https://api.github.com/users/jaltman/gists{/gist_id}","starred_url":"https://api.github.com/users/jaltman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jaltman/subscriptions","organizations_url":"https://api.github.com/users/jaltman/orgs","repos_url":"https://api.github.com/users/jaltman/repos","events_url":"https://api.github.com/users/jaltman/events{/privacy}","received_events_url":"https://api.github.com/users/jaltman/received_events","type":"User","site_admin":false},"created_at":"2016-07-17T04:47:19Z","updated_at":"2016-07-17T04:47:19Z","body":"@DavidMulder My apologies for the delay in responding but the subject matter required a bit of thought.  \r\n\r\nLet me first address the question of principals with the service name \"krbtgt\".    My reading of RFC4120 is that all principals with a service name of \"krbtgt\" should be treated as type NT-SRV_INST either whenever the principal type is NT-UNKNOWN.   NT-SRV-INST principal types are treated special in that a request for a referral is implied without requiring the canonicalize flag.   In Heimdal this special casing of NT-SRV-INST occurs in kdc/krb5tgs.c need_referral().    Problems will occur if the client creates a principal of type NT-PRINCIPAL when the actual type is unknown.  \r\n\r\nOne question that this raises is, what does Windows do when the service name is \"krbtgt\" but the principal type is NT-UNKNOWN?   By my reading of the text, Windows should work fine in that case.\r\n\r\nI agree that krb5_parse_name_flags() should be modified to set the type to KRB5_NT_SRV_INST when the service name is \"krbtgt\" (aka KRB5_TGS_NAME).   Lets commit that as a single isolated change.\r\n\r\nRFC4120 says \r\n\r\n> If the first component of a name identifies a service and the remaining components identify an instance of the service in a server-specified manner, then the name type of SRV-INST SHOULD be   used.  An example of this name type is the Kerberos ticket-granting service whose name has a first component of krbtgt and a second component identifying the realm for which the ticket is valid.\r\n\r\nThis implies that a principal of type NT-SRV-INST should not be assumed to be a \"krbtgt\" or that the same rules apply to the principal that apply to \"krbtgt\".\r\n\r\nHeimdal's kdc/krb5tgs.c need_referral() behavior needs to be altered to ensure that if the principal type is NT-UNKNOWN and the service name is \"krbtgt\" then the behavior is the same as if the type was NT-SRV-INST and service name \"krbtgt\".  need_referral() currently does not validate the service name nor does it handle the case of NT-UNKNOWN and \"krbtgt\".\r\n\r\nI believe that the KDC should whenever it receives an incoming request with principal type NT-UNKNOWN apply transformation rules to assign an appropriate type for internal processing.  However, the service name principal type returned to the caller must be NT-UNKNOWN if the client specified NT-UNKNOWN.  Otherwise, the Java 1.6 Kerberos client implementation will fail to accept the response.  It would be worth testing to determine if this behavior has been altered in subsequent releases.   The fixes for the need_referral() behavior should be a separate commits.\r\n\r\nThe next question is should a principal whose first component is the service name \"host\" be treated as type NT-SRV_HST when the type is NT-UNKNOWN.   I believe the answer is \"yes\" both in the krb5 client, the kdc and in GSS.   RFC 4120 says:\r\n\r\n> If the first component of a name identifies a service and there is a single component following the service name identifying the instance as the host on which the server is running, then the name type   SRV-HST SHOULD be used.  This type is typically used for Internet services such as telnet and the Berkeley R commands.  \r\n\r\nAs such, designating an unknown principal with first component \"host\" must only be considered NT-SRV-HST when the number of components is 2.\r\n\r\nRFC 4120 continues with:\r\n\r\n> If the separate components of the host name appear as successive components following the name of the service, then the name type SRV-XHST SHOULD be used.\r\n\r\nHeimdal currently does not properly handle NT-SRV-XHST in lib/krb5 and in lib/gssapi/krb5.\r\n\r\nRFC 4120 finishes with:\r\n\r\n> A name type of UNKNOWN SHOULD be used when the form of the name is not known.  When comparing names, a name of type UNKNOWN will match principals authenticated with names of any type.  A principal authenticated with a name of type UNKNOWN, however, will only match other names of type UNKNOWN.\r\n\r\nHowever, Heimdal's krb5_parse_name_flags() sets the principal type to NT-PRINCIPAL not NT-UNKNOWN when all other options are exhausted.\r\n\r\nRFC 5179 \"Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism\" defines NT-SRV-HST-DOMAIN which is similar to NT-SRV-HST but supports 3 components.  First component is the service, second is the host, and third is an application specific domain.  Heimdal currently does not support NT-SRV-HST-DOMAIN.  It does not apply to the service \"host\".\r\n\r\nFinally, Heimdal requires configuration support to permit specifying service names that should be treated as NT-SRV-HST or NT-SRV-HST-DOMAIN when processing krb5_parse_name_flags(), in the kdc, and in gss.  I propose \r\n\r\n  [service_principal_type]\r\n       service = type\r\n       service = type\r\n          ....\r\n        service = type\r\n\r\nwhere the types are those specified in lib/krb5/principal.c nametypes[].    This mapping should be supported by the krb5 client, the kdc and gss.   This mechanism will permit the appropriate assignment of principal types by the client and the appropriate mapping of NT-UNKNOWN to principal type by the KDC.\r\n\r\nThere are a significant number of to do items and quite a bit of interop testing that will be required.  Can your employer assist with this work?\r\n"}}
{"actor":{"display_login":"jaltman"}}