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

[Alexander Bokovoy]

On Thu, 20 Mar 2014, Rob Crittenden wrote:
>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?
My point is that the client will not do what he expects unless S4U2Proxy
is used in Java and that requires Java 8 platform, released on March
18th 2014. That is, if there is a user talking to the Java client and
then Java client turning to IPA LDAP or web server with constraint
delegation.

This is something I tried to get clarification for in the original
discussion.


-- 
/ Alexander Bokovoy