Return-Path: 
 <users-return-242245-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
X-Original-To: apmail-tomcat-users-archive@www.apache.org
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id DB4AE10009
	for <apmail-tomcat-users-archive@www.apache.org>;
 Tue, 11 Jun 2013 18:06:46 +0000 (UTC)
Received: (qmail 72076 invoked by uid 500); 11 Jun 2013 18:06:43 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 71956 invoked by uid 500); 11 Jun 2013 18:06:43 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 71947 invoked by uid 99); 11 Jun 2013 18:06:43 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Jun 2013 18:06:43 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [81.169.162.220] (HELO h1611079.stratoserver.net)
 (81.169.162.220)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Jun 2013 18:06:36 +0000
Received: from [192.168.178.36] (pD9E83044.dip0.t-ipconnect.de
 [217.232.48.68])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by h1611079.stratoserver.net (Postfix) with ESMTPSA id 6A8984948012
	for <users@tomcat.apache.org>; Tue, 11 Jun 2013 20:06:16 +0200 (CEST)
Message-ID: <51B76717.1040403@internetallee.de>
Date: Tue, 11 Jun 2013 20:06:15 +0200
From: Felix Schumacher <felix.schumacher@internetallee.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: Tomcat7 and SPNEGO configuration questions
References: 
 <B807816A7D472E45A5CCD2ED352AC142027E25884262@AUSP01VMBX11.collaborationhost.net>,<51AB70B6.1060706@internetallee.de>
 <B807816A7D472E45A5CCD2ED352AC142027E25884266@AUSP01VMBX11.collaborationhost.net>,<51AF9BB4.6090303@internetallee.de>
 <B807816A7D472E45A5CCD2ED352AC142027E2588426F@AUSP01VMBX11.collaborationhost.net>
In-Reply-To: 
 <B807816A7D472E45A5CCD2ED352AC142027E2588426F@AUSP01VMBX11.collaborationhost.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Hi Edward,

Am 10.06.2013 21:31, schrieb Edward Siewick:
> Felix,
>
> Thanks for the example. And yes, I agree -- my setup isn't getting far enough to attempt an authentication of an end user. I *think* I've got the keytab and MSA aspect working. So two possibilities seem worth digging at. First, there's likely a gap in my understanding of the http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html instructions. I'm trying to use the most simple authentication / authorization example available in the default Tomcat7 kit, the manager-gui <auth-constraint> / <role-name> and an ordinary conf/tomcat-users.xml. Regarding  the web.xml, the HowTo only mentions that SPNEGO is to be used, vice BASIC. Other than swapping the string BASIC for SPNEGO, though, I'm out of guesses on that point in the instruction. Is there something more needed in the web.xml?
No, there is nothing else needed in web.xml. Authentication will be done 
by using SPNego and authorization by whatever realm you have configured 
for the context.
>
> Second, I'm restricting my configuration to only AES256 (aes256-cts-hmac-sha1-96) and a keytab created only for AES256. Is the default pre-built Tomcat7 kit known to work with that, by just adding Oracle's jce_policy-6.zip?
In my example I used tomcat 7.0.40 with openjdk 7u21 without any 
modifications. My server keytab held an aes256-cts-hmac-sha1-96 encoded 
key. So tomcat has no problems per se with that encoding-combination.
> I'm picking at this because, where my log trace seems OK with the AD MSA's keytab, for a user authentication it jumps straight to a logout:
>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
>                    [Krb5LoginModule]: Entering logout
>                    [Krb5LoginModule]: logged out Subject
>
> It's at this point that your trace goes on to "Using builtin default etypes for permitted_enctypes," authenticates an end user, and seems to be waiting for further end users. It does pick up both type 18 (AES256) and 17 (AES128), but only reports using the AES128:
My old trace was produced with an aes128 encrypted key, so that may 
explain that. I had to enable aes256 explicitly for apacheds, which I 
hadn't bothered first.

With aes256 the trace looks like this:

...>>> KrbAsRep cons in KrbAsReq.getReply HTTP/www.example.com
Added key: 18version: 1
Ordering keys wrt default_tkt_enctypes list
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
Found KeyTab
Found KerberosKey for HTTP/www.example.com@EXAMPLE.COM
Entered Krb5Context.acceptSecContext with state=STATE_NEW
Added key: 18version: 1
Ordering keys wrt default_tkt_enctypes list
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23 1 3.
 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
replay cache for user0001@EXAMPLE.COM is null.
object 0: 1370973475196/196436
 >>> KrbApReq: authenticate succeed.
 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
 >>>Delegated Creds have pname=user0001@EXAMPLE.COM 
sname=krbtgt/EXAMPLE.COM@EXAMPLE.COM authtime=20130611175709Z 
starttime=20130611175755Z endtime=20130612175704ZrenewTill=null
...


>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> Added key: 17version: 1
> Added key: 18version: 1
> Added key: 3version: 1
> Added key: 23version: 1
> Ordering keys wrt default_tkt_enctypes list
> default etypes for default_tkt_enctypes: 18 17.
>>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> Using builtin default etypes for permitted_enctypes
> default etypes for permitted_enctypes: 18 17 16 23 1 3.
>>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> replay cache for user00001@EXAMPLE.COM is null.
> object 0: 1370027872357/357663
>>>> KrbApReq: authenticate succeed.
> Krb5Context setting peerSeqNumber to: 758340766
> Krb5Context setting mySeqNumber to: 758340766
>
> Edward
>
> P.S.: The example server.xml bit from your bugzilla test kit provides for role based authorization. If I can get my very simple example to work, I'll try to use it. On that point, the bit:
>
>       <Realm className="org.apache.catalina.realm.JNDIRealm"
>          connectionURL="ldap://localhost:10389"
>          userBase="ou=users,ou=security,dc=example,dc=com"
>          userSearch="(uid={0})"
>          roleBase="ou=groups,dc=example,dc=com"
>          roleName="cn"
>          roleSearch="(uniqueMember={0})"
>          useDelegatedCredential="false"
>       />
>
> or a similar tidy might be added to the HowTo, right after:
>
> "The SPNEGO authenticator will work with any Realm but if used with the JNDI Realm, by default the JNDI Realm will use the user's delegated credentials to connect to the Active Directory."
That would be a bad example, since I explicitly disabled the delegation 
of the credentials in my case :)

Regards,
  Felix
>
>
>
>
> ________________________________________
> From: Felix Schumacher [felix.schumacher@internetallee.de]
> Sent: Wednesday, June 05, 2013 4:12 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat7 and SPNEGO configuration questions
>
> Am 03.06.2013 20:48, schrieb Edward Siewick:
>> Felix & Friends,
>>
>> I've made a fair amount of progress, though I'm still not able to log in with a domain credential. The domain account ID doesn't appear in the Tomcat7 logging at all, >though it is in tomcat-users.xml. So I might now only be confused as to the syntax of: server.xml for JAAS; the webapp's "realm" bits in web.xml for SPNEGO, or; > tomcat-users.xml. I have tried changing tomcat-users.xml to "OPENIDMDEV/esiewick", "COM.OPENIDMDEV/esiewick" and just "esiewick". And, I've adjusted the Account ID in the Windows Security prompt to match each of these.
> If I read your logs at the end of your mail correctly, I think you
> haven't gotten that far as to have authenticated an user. In my logs you
> could see an user00001 being authenticated. But I can't really tell you,
> why your user was not authenticated.
>
> At https://issues.apache.org/bugzilla/show_bug.cgi?id=53480 I have
> described how I setup a tomcat with apacheds as a kerberos server. You
> might want to try that setup.
>
> Regards
>    Felix
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org