On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote:
> Hi Brendan,
>
> Yes thanks for your great explanation, I have done that indeed. But in
> some strange way, with only a 401 in access_log of apache I get a Non
> valid ticket when I connect through my loadbalancer. I don't go "by"
> my loadbalancer but through it (NAT) or should it go "by/next" to it ?
>
> I think we can get this fixed :)
>
> Thanks!
>
> Matt
>
> 2015-03-31 17:41 GMT+02:00 Brendan Kearney <bpk...@gmail.com>:
> > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote:
> >> On 03/31/2015 10:38 AM, Matt . wrote:
> >> > True, but we have some extra later between which does the cli command
> >> > not usable (at least for the moment)
> >> >
> >> > I already know how to share the key's among all servers, that works
> >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname
> >> > (loadbalancer), or the client doesn't understand it.
> >> >
> >> > So fixing this saves me really much more time than doing the another way.
> >>
> >> Kerberos is not load balancer friendly. It is something that is a known
> >> property of Kerberos.
> >> I remember MIT mentioning something that they did or might do to help
> >> with that so it might make sense to ask this question on the MIT
> >> Kerberos user list.
> >>
> >> >
> >> > Thanks!
> >> >
> >> > Matt
> >> >
> >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
> >> >> On 31.3.2015 16:10, Matt . wrote:
> >> >>> HI Petr,
> >> >>>
> >> >>> We had a several of reasons why we did that. We wanted to use one
> >> >>> language for that, and also have formatted returns. There was also
> >> >>> some security issue which came up.
> >> >> I would be very interested in the security reason. If you see any
> >> >> problem with
> >> >> 'ipa' command or FreeIPA API please send me a private e-mail or contact
> >> >> secal...@redhat.com directly.
> >> >>
> >> >>> I could ask you, why does IPA json itself ? if you see what it posts
> >> >>> and what it gets back as result it makes it much more clear in
> >> >>> development.
> >> >> I do not understand the question, sorry.
> >> >>
> >> >> If you want to see what 'ipa' command does run it with '-vv' parameter:
> >> >> $ ipa -vv user-find
> >> >>
> >> >> It will print JSON request and reply:
> >> >> ipa: INFO: Request: {
> >> >> "id": 0,
> >> >> "method": "user_find",
> >> >> "params": [
> >> >> [
> >> >> null
> >> >> ],
> >> >> {
> >> >> "all": false,
> >> >> "no_members": false,
> >> >> "pkey_only": false,
> >> >> "raw": false,
> >> >> "version": "2.115",
> >> >> "whoami": false
> >> >> }
> >> >> ]
> >> >> }
> >> >> ipa: INFO: Response: {
> >> >> "error": null,
> >> >> "id": 0,
> >> >> "principal": "admin@IPA.EXAMPLE",
> >> >> "result": {
> >> >> "count": 2,
> >> >> "result": [
> >> >> {
> >> >> "dn":
> >> >> "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example",
> >> >> "gidnumber": [
> >> >> "1381000000"
> >> >> ],
> >> >> ...
> >> >>
> >> >>
> >> >>> HTTP loadbalancing is not difficult at all, as we post to the
> >> >>> webserver I need to have that part only auth right. We do more very
> >> >>> specific loadbalancing stuff and this is the most easy one as it's
> >> >>> only webserver forward, but IPA/Kerberos has an issue with the
> >> >>> principal it seems... it cannot be hard to make that accepted I would
> >> >>> say.
> >> >> If you insist on Kerberos servers behind a load balancer... you will
> >> >> need to
> >> >> somehow share the Kerberos key among all servers. I will defer that to
> >> >> Kerberos experts here.
> >> >>
> >> >>> I'm still looking for solutions :)
> >> >> Sure, but you will save a lot of time and nerves if you simply call
> >> >> 'ipa'
> >> >> command :-)
> >> >>
> >> >> Have a nice day!
> >> >>
> >> >> Petr^2 Spacek
> >> >>
> >> >>> Cheers,
> >> >>>
> >> >>> Matt
> >> >>>
> >> >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
> >> >>>> On 31.3.2015 15:23, Matt . wrote:
> >> >>>>> Hi Petr,
> >> >>>>>
> >> >>>>> We discussed that before indeed, but SRV is not usable in this case.
> >> >>>>>
> >> >>>>> My clients are just webservers (apache) doing some executes of CURL
> >> >>>>> commands to ipa/json, actually the same commands as the webgui does
> >> >>>>> using json, but we curl it.
> >> >>>>>
> >> >>>>> Do you have a better view now ?
> >> >>>> Yes. If you have seen the previous discussion then you know that it
> >> >>>> will be
> >> >>>> pretty difficult to do this kind of load balancing.
> >> >>>>
> >> >>>> Why are you not using 'ipa' command or Python API we have instead?
> >> >>>> Why to use
> >> >>>> CURL and make things more complex?
> >> >>>>
> >> >>>> Petr^2 Spacek
> >> >>>>
> >> >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
> >> >>>>>> On 31.3.2015 14:35, Matt . wrote:
> >> >>>>>>> Hi Petr,
> >> >>>>>>>
> >> >>>>>>> As this is not my topic it's for me quite "simple".
> >> >>>>>>>
> >> >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more.
> >> >>>>>>>
> >> >>>>>>> i have
> >> >>>>>>>
> >> >>>>>>> ldap-01.domain.tld (ipa1)
> >> >>>>>>> ldap-01.domain.tld (ipa2)
> >> >>>>>>>
> >> >>>>>>> and my loadbalancer is ldap.domain.tld
> >> >>>>>>>
> >> >>>>>>> ldap requests over a loadbalancer are quite simple and working, but
> >> >>>>>>> the json part is more difficult because of the ticket and the dns
> >> >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there
> >> >>>>>>> is a
> >> >>>>>>> http/ldap.domain.tld service on the ipa server.
> >> >>>>>>>
> >> >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld
> >> >>>>>>> to
> >> >>>>>>> ldap-01.domain.tld, but when I change my script to
> >> >>>>>>> ldap-01.domain.tld
> >> >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works.
> >> >>>>>>>
> >> >>>>>>> Is this enough information for you ?
> >> >>>>>> Well, I still do not understand the use case. What are your
> >> >>>>>> clients? Are you
> >> >>>>>> using 'ipa' command to do something? Or some other clients?
> >> >>>>>>
> >> >>>>>> Usually the best thing is to use DNS SRV records because it works
> >> >>>>>> even with
> >> >>>>>> geographically distributed clusters and does not have single point
> >> >>>>>> of failure
> >> >>>>>> (the load balancer).
> >> >>>>>>
> >> >>>>>> This requires clients with support for DNS SRV but if your machines
> >> >>>>>> are using
> >> >>>>>> SSSD then you do not need to change anything and it should just
> >> >>>>>> work.
> >> >>>>>>
> >> >>>>>> That is why I'm asking for the use case :-)
> >> >>>>>>
> >> >>>>>> Petr^2 Spacek
> >> >>>>>>
> >> >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
> >> >>>>>>>> On 31.3.2015 14:02, Matt . wrote:
> >> >>>>>>>>> HI Phasant,
> >> >>>>>>>>>
> >> >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos
> >> >>>>>>>>> part
> >> >>>>>>>>> not, SRV records are used for that normally.
> >> >>>>>>>>>
> >> >>>>>>>>> Are you talking about the webgui or the ldap part ?
> >> >>>>>>>> I would recommend you to step back and describe use-case you have
> >> >>>>>>>> in mind. It
> >> >>>>>>>> is important for us to understand to your use-case to propose
> >> >>>>>>>> optimal solution.
> >> >>>>>>>>
> >> >>>>>>>> Petr^2 Spacek
> >> >>>>>>>>
> >> >>>>>>>>> Cheers,
> >> >>>>>>>>>
> >> >>>>>>>>> Matt
> >> >>>>>>>>>
> >> >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat <prash...@apigee.com>:
> >> >>>>>>>>>> Hi,
> >> >>>>>>>>>>
> >> >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind
> >> >>>>>>>>>> a load
> >> >>>>>>>>>> balancer, specifically Amazon ELB.
> >> >>>>>>>>>>
> >> >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf
> >> >>>>>>>>>> but looks like
> >> >>>>>>>>>> there is more to it than just this file.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Any suggestions ?
> >> >>>>>>>>>>
> >> >>>>>>>>>> Thanks.
> >> >>>>>>>>>> --Prashant
> >>
> >>
> >> --
> >> Thank you,
> >> Dmitri Pal
> >>
> >> Sr. Engineering Manager IdM portfolio
> >> Red Hat, Inc.
> >>
> >
> > kerberos is load balancer friendly, if you pet it nicely.
> >
> > you generate a principal for the VIP. you then create a keytab for the
> > VIP. you distribute the keytab via SCP (or other secure method) to all
> > load balanced pool members. you must distribute the same exact keytab
> > to all devices. the KVNO for the VIP principal must match in all copies
> > put on the pool members. use "klist -Kket /path/to/file.keytab" to
> > validate this on all pool members.
> >
> > there are additional steps you may want to take, in order to add the
> > individual principal(s) to the same keytab, so that you can access the
> > pool members themselves (not via the VIP). this requires that you
> > distribute the keytab as above, and then add the individual principals
> > to the local copy of the keytab file.
> >
> > example:
> >
> > you have created the principal ldap/ldap.domain.tld for your VIP
> > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab
> > you have copied the keytab file ~/ldap.keytab to server1, server2 and
> > server3 as /etc/ldap.keytab
> >
> > you ssh to server1 and run kadmin.
> > you then add a principal ldap/server1.domain.tld
> > you then add the principal ldap/server1.domain.tld to the already
> > existing keytab /etc/ldap.keytab.
> > quit kadmin
> >
> > when you run "klist -Kket /etc/ldap.keytab" you should see two
> > principals in it. the VIP name and the hostname.
> >
> > lather, rinse, repeat for all servers.
> >
> > keep in mind the administrative overhead of changing names of servers or
> > VIPs.
> >
> > there are other tricks for doing kerberos stuff. i use the same VIP,
> > but different ports in order to access an individual host/service behind
> > the load balancer. this works because the name (of the VIP) stays the
> > same and i just point a different front end port to an individual
> > backend device/port.
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
wireshark/tcpdump are your friends. run an unfiltered capture on the
client and attempt the access. review the capture and see what is not
working (hint, filter for "kerberos || ldap" in wireshark during your
review).
ldapwhoami should return info about your ID. klist after running the
ldapwhoami should have an ldap ticket listed, along with your TGT and
possibly others.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
