Return-Path: Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (Postfix) with ESMTP id 64F133E630; Thu, 14 Jun 2012 17:37:22 -0400 (EDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id q5ELbLnY002457; Thu, 14 Jun 2012 17:37:21 -0400 Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU [18.9.21.41]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id q5EK0Zts021373 for ; Thu, 14 Jun 2012 16:00:35 -0400 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id q5EJxKrL003786 for ; Thu, 14 Jun 2012 16:00:34 -0400 X-Auditid: 1209190f-b7f306d0000008b4-26-4fda42e2ae73 Authentication-Results: symauth.service.identifier Received: from mail-gg0-f177.google.com (mail-gg0-f177.google.com [209.85.161.177]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 31.BC.02228.2E24ADF4; Thu, 14 Jun 2012 16:00:34 -0400 (EDT) Received: by mail-gg0-f177.google.com with SMTP id s5so1883359ggc.36 for ; Thu, 14 Jun 2012 13:00:34 -0700 (PDT) Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GKAaJ+bTXtssmnV9Zr1CabFJ+ZI35LDkjze3+8qLHb0=; b=O8zdFhgVURHjgRhFduppdEmr+T22BATBEnV8HBl89CF5KVylxEt/j9NPTszIYvH3UH rbg/QrFyTkH3od1s6lhBdWaYAApX0zuY/bJJD5mq+3vGGRuWgRtyycdkr8ie2D9qZoR/ dlhY1FHY3pBkO0WFQIJGXoj6atg4Abf3D+gIy7iRAbd3icNuygr3trT4ws/4oB6LUYZr sXd4Ox4Os2RSaTN8rjjypDVtasJdO00wz2Qd3AkaOm3VvjY63k5J2PRDmy5cZ6NJpBeH ydh5StKF29Gt4K9aVXDBAVmg6DpHKTVNIQBobtcSWTUlbW8/qa2Ne7uqxxibItg7181j Dx9A== MIME-Version: 1.0 Received: by 10.60.6.225 with SMTP id e1mr3127193oea.71.1339704034282; Thu, 14 Jun 2012 13:00:34 -0700 (PDT) Received: by 10.182.38.135 with HTTP; Thu, 14 Jun 2012 13:00:34 -0700 (PDT) Date: Thu, 14 Jun 2012 16:00:34 -0400 Message-ID: Subject: multi-hop cross-realm w/o capaths sends request to wrong kdc From: Chaskiel Grundman To: krb5-bugs@mit.edu Content-Type: text/plain; charset=ISO-8859-1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleJIrShJLcpLzFFi42K5GLpwo+4jp1v+Bqtum1o0PDzO7sDo0XTm KHMAYxSXTUpqTmZZapG+XQJXxsTXtxgLTohWbOn8wNjAuEOoi5GTQ0LAROLN4z0sIDajgJHE 7nOvWCHiYhIX7q1n62Lk4hASuMMosf7dZGYIp4dRYsGLg0wgDovAJxaJR/cnsoO08AoISpyc +QRslJBAnsTJry+BOjiAbG+J1cvBtrEIqEo8XbcEqjxAYu/DM0wgtrCAq8T0xb1gNpuArsSZ XRvBbBEBUYmXf4+BjWQW0JF41/eAeQIj/ywk22YhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiX l1qka6KXm1mil5pSuokRGGRCnJL8Oxi/HVQ6xCjAwajEw3uR9Za/EGtiWXFl7iFGSQ4mJVFe FyugEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHelXJAOd6UxMqq1KJ8mJQ0B4uSOO/VlJv+QgLp iSWp2ampBalFMFkmDvZDjDIcHEoSvE7AuBISLEpNT61Iy8wpQVbDCSK4QNbwAK3RAinkLS5I zC3OTIcoOsVoybHuzZEbjBzP3oLIaT0nbjAKseTl56VKifMqgTQIgDRklObBDQYlkvr///9f YpSVEuZlZGBgEOIBugwYIAh5UCJ6xSgODAxh3q+OQFN4MvNK4La+AjqICeggzbM3QA4qSURI STUwcu7ZNtddYGWXm6tj7eaVPH9e+yblvZqw5WTszdO8YbfWnJJJ7bPVtTuR/dlji32c7dV9 n51S9/3dkJq6s7s5ZHXBnKXbvt2dFDWR05OBZbvKir8MB99ZvDtqpfFyX47+Ewlzbs6XMWp+ yW+X773YdaK/IenzBzETzusHC/o0KsRXTH+4xXoXvxJLcUaioRZzUXEiAEUPu+4fAwAA X-Mailman-Approved-At: Thu, 14 Jun 2012 17:37:21 -0400 X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu X-RT-Original-Encoding: iso-8859-1 Content-Length: 2703 I have an environment with two AD domains (in one forest) and a kerberos realm, recently upgraded to a recent heimdal. As part of that migration, the trust between AD and the kerberos realm was redone. Previously, both the root domain and the domain that all the users/resources are in had trusts, but now only the root AD domain has a trust. The heimdal kdcs have [capaths] configured and properly give out realm referrals. The AD servers do not. Lets call the kerberos realm KERBEROS.EXAMPLE.COM, and the AD domains AD.EXAMPLE.COM and REALDOMAIN.AD.EXAMPLE.COM. These names _do_ reflect the domain hierarchy relationship correctly. I only changed the individual labels. After the change, mit krb5 1.9 (1.9.1ish on ubuntu 11.10), cannot get tickets on behalf of user@REALDOMAIN.AD.EXAMPLE.COM for services in KERBEROS.EXAMPLE.COM: % aklog -d kerberos.example.com Note: Operation is performed on cell REALDOMAIN.AD.EXAMPLE.COM Authenticating to cell kerberos.example.com (server XXXX.kerberos.example.com). Trying to authenticate to user's realm REALDOMAIN.AD.EXAMPLE.COM. Getting tickets: afs/kerberos.example.com@REALDOMAIN.AD.EXAMPLE.COM We've deduced that we need to authenticate to realm KERBEROS.EXAMPLE.COM. Getting tickets: afs/kerberos.example.com@KERBEROS.EXAMPLE.COM Getting tickets: afs/kerberos.example.com@KERBEROS.EXAMPLE.COM Kerberos error code returned by get_cred : -1765328316 That is KRB5KDC_ERR_WRONG_REALM Setting KRB5_TRACE reveals the following: [27580] 1339700735.363748: Requesting TGT krbtgt/KERBEROS.EXAMPLE.COM@REALDOMAIN.AD.EXAMPLE.COM using TGT krbtgt/AD.EXAMPLE.COM@REALDOMAIN.AD.EXAMPLE.COM [27580] 1339700735.363759: Generated subkey for TGS request: rc4-hmac/AB6E [27580] 1339700735.363772: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, des-cbc-crc, des, des-cbc-md4 [27580] 1339700735.363839: Sending request (1737 bytes) to AD.EXAMPLE.COM [27580] 1339700735.369349: Initiating TCP connection to stream 192.168.20.8:88 [27580] 1339700735.371149: Sending TCP request to stream 192.168.20.8:88 [27580] 1339700735.372676: Received answer from stream 192.168.20.8:88 [27580] 1339700735.374530: Response was not from master KDC [27580] 1339700735.374547: TGS request result: -1765328316/Realm not local to KDC The library seems to be mixing up the realms, asking for an @REALDOMAIN.AD.EXAMPLE.COM ticket from the @AD.EXAMPLE.COM kdc. If I add some capaths to the client's krb5.conf, the problem does not occur, but I'd really rather not have to do that everywhere. an mit krb5 1.6 client (RHEL5) works without the capaths. [capaths] REALDOMAIN.AD.EXAMPLE.COM = { KERBEROS.EXAMPLE.COM = AD.EXAMPLE.COM AD.EXAMPLE.COM = . }