Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Date: Wed, 3 Aug 2016 12:09:20 +0000 (UTC)
From: "Shawn Eion Smith (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Message-ID: <JIRA.12993631.1469823267000.211520.1470226160855@Atlassian.JIRA>
In-Reply-To: <JIRA.12993631.1469823267000@Atlassian.JIRA>
References: <JIRA.12993631.1469823267000@Atlassian.JIRA> <JIRA.12993631.1469823267067@arcas>
Subject: [jira] [Commented] (DIRKRB-605) Remote Admin client init creates a
 TGT, which cannot be used to aquire a TGS for kadmin/admin
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 03 Aug 2016 12:09:23 -0000


    [ https://issues.apache.org/jira/browse/DIRKRB-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405816#comment-15405816 ] 

Shawn Eion Smith commented on DIRKRB-605:
-----------------------------------------

Yes, we're working against the MIT Kerb, but we're not using the client directly.  We started there, but because of the use of the JAAS login module we realized that it would never work against MIT (do to the expectation of the TGT exchange).   We've spent a few days trying to figure it out.  I'm not sure we'll be able to use any of the existing Java libraries to build a GSSAPI tunnel to execute the admin calls through.  We're going to switch to OpenJDK today to try to trace more deeply through the built in GSS code (we can't follow the entire call chain in Oracle Java due to the lack of source packages).  If that doesn't work, I think the only option will be to tackle it at the protocol level directly.  We'll keep you informed of what we find.

> Remote Admin client init creates a TGT, which cannot be used to aquire a TGS for kadmin/admin
> ---------------------------------------------------------------------------------------------
>
>                 Key: DIRKRB-605
>                 URL: https://issues.apache.org/jira/browse/DIRKRB-605
>             Project: Directory Kerberos
>          Issue Type: Bug
>            Reporter: Shawn Eion Smith
>         Attachments: command-line-kadmin.png, kerby-kadmin-tgs-request.png, kerby-kadmin-tgs-response.png, kerby-kadmin-tgt-request.png
>
>
> It's certainly possible I'm misunderstanding, but doing wire traces show that the jaas authentication attempting to access kadmin in RemoteAdminClientTool is not retrieving  a TGS for kadmin/admin, but rather a TGT.   That TGT cannot be used to acquire a TGS as per policy.  
> Per the func spec (https://github.com/krb5/krb5/blob/50a3c3cbeab32577fba2b21deb72a64015c48ec7/doc/kadm5/api-funcspec.tex#L775) "Two Kerberos principals exist for use in communicating with the Admin
> system: kadmin/admin and kadmin/changepw.  Both principals
> have the KRB5_KDB_DISALLOW_TGT_BASED bit set in their attributes so
> that service tickets for them can only be acquired via a
> password-based (AS_REQ) request."
> Please correct me if I'm misunderstanding.  Thanks.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)