On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote: > 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....@example.com and > >>>>>>>it's OK whereas the second one is on > >>>>>>>HTTP/olmo.example....@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....@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....@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}, ad...@example.com for krbtgt/example....@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}, ad...@example.com for > >>>ldap/olmo.example....@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....@example.com for krbtgt/example....@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....@example.com for > >>>krbtgt/example....@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....@example.com for > >>>HTTP/olmo.example....@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.
I think you can use earlier Java versions but tell them to use the native GSSAPI library (and perhaps sprinkle a little bit of GSS-Proxy in the back for fun. > 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. > > -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel