[Freeipa-devel] Talking json/rpc with java client

[Rob Crittenden]

Alexander Bokovoy wrote:
> On Thu, 20 Mar 2014, Massimiliano Perrone (tirasa.net) wrote:
>> On 03/18/2014 05:26 PM, Alexander Bokovoy wrote:
>>> On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote:
>>>>>> The difference between the two calls is on the last TGS_REQ;
>>>>>> because the first one is on ldap/olmo.example.com at EXAMPLE.COM and
>>>>>> it's OK whereas the second one is on
>>>>>> HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose).
>>>>>>
>>>>>> Where's the error?
>>>>> Am I correct that you have a user connecting to HTTP/ebano.example.com
>>>>> and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com
>>>>> using credentials of the user?
>>>>>
>>>>> FreeIPA uses constraint delegation of the credentials, with the
>>>>> help of
>>>>> S4U2Proxy extension. You need to allow HTTP/ebano.example.com to
>>>>> delegate
>>>>> credentials to HTTP/olmo.example.com.
>>>>>
>>>>> I have written an article how to do that:
>>>>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Hi Alexander, thanks for your reply.
>>>> I read carefully your interesting post and I follow it to delegate
>>>> HTTP/ebano.example.com credentials to HTTP/olmo.example.com.
>>>>
>>>> Now, two questions:
>>>> 1) How can I check that my configuration, now is ok? Because this
>>>> ldapsearch returns result: 0
>>>>
>>>> ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b
>>>> "cn=s4u2proxy,cn=etc,dc=example,dc=com"
>>>> "cn=ipa-http-delegation-targets" dn
>>> You need to create these delegation entries yourself, like the article
>>> says. Note that your app talks to IPA server's HTTP service, so create
>>>
>>> dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com
>>> objectClass: ipaKrb5DelegationACL
>>> objectClass: groupOfPrincipals
>>> objectClass: top
>>> cn: ebano-http-delegation
>>> memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM
>>> ipaAllowedTarget:
>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
>>>
>>> This entry says: "HTTP/ebano.example.com is allowed to delegate users'
>>> credentials to whatever Kerberos principal is a member of
>>> cn=ebano-http-delegation-targets group"
>>>
>>> Now, this is the group:
>>> dn:
>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
>>> objectClass: groupOfPrincipals
>>> objectClass: top
>>> cn: ebano-http-delegation-targets
>>> memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM
>>>
>>> With these two entries we would have HTTP/ebano.example.com allowed to
>>> delegate users' credentials to HTTP/olomo.example.com
>>
>> Hi Alexander, thanks for your patience.
>> I followed your suggestions but the result is always the same.
>>
>> Trying with curl, of course, it works.
>>
>> My doubt now is why curl generates this log on kerberos server
>>
>> mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1
>> etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18
>> tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM
>> mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
>> etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975,
>> etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for
>> ldap/olmo.example.com at EXAMPLE.COM
> This is effect of S4U extension working correctly.
>
>> whereas java generates this other one
>>
>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes
>> {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH:
>> HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM,
>> Additional pre-authentication required
>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes
>> {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes
>> {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for
>> krbtgt/EXAMPLE.COM at EXAMPLE.COM
>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
>> etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449,
>> etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for
>> HTTP/olmo.example.com at EXAMPLE.COM
>>
>> As you can see, the first one uses admin on ldap service, the second
>> one uses HTTP/ebano.example.com on HTTP service.
> This means your Java application doesn't use S4U extension or doesn't
> know about that.
>
>> Can I do the same call with Java?
> At this point we need to set clear what Java are you using.
>
> http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html
>
> tells that S4U extensions (we use S4U2Proxy here) was added in Java SE 8.
>

The client doesn't do the S4U2Proxy work though, so this shouldn't 
matter, right?

I think what I'd suggest is to use the keytab you're using in java in 
the curl test:

$ kinit -kt /path/to/keytab HTTP/ebano.example.com
$ curl ...

Then you'll be comparing apples to apples.

rob