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

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy