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
--
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
