On Tue, 2015-03-31 at 12:53 -0400, Simo Sorce wrote: > On Tue, 2015-03-31 at 11:41 -0400, Brendan Kearney wrote: > > 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. > > > > This is all true if you just accept connections. > > (Un?)fortunately we use delegation within IPA, which requires to use a > local key to contact the KDC. This action "fixates" what key we are > going to use to accept incoming context establishment requests. If a > principal name is not specified then the selected key is usually the > first in the keytab. > > In an IPA setup that will usually be the server's specific key. > > In order to use multiple keys in conjunction with IPA we'd have to > explicitly support. I am not sure if the SSL layer records which name > was used (perhaps it does if SNI is used, but almost certainly not is > SAN are used), or if multiple virtual hosts need to be used. > If we can know what name the client used then we could modify > mod_auth_gssapi to select a specific name to acquire creds and then > accept the connection with the correct keys. (Another option would be to > explicitly retry with each available key if something fails). > > I am afraid I won't try to coerce mod_auth_kerb to do that, so this > option is probably something we can do only post 4.2 and only if we can > make appropriate modifications. > > Simo. > the below works for me on apache2.4, with mod_auth_kerb, MIT Kerberos V and OpenLDAP. I run HAProxy, which holds the A/PTR records for www.bpk2.com, and load balances to each of the instances i have running behind it. Fedora 20 with latest everything...
AuthType Kerberos AuthName "Enter your credentials" KrbMethodNegotiate On KrbMethodK5Passwd On KrbSaveCredentials On KrbAuthRealms BPK2.COM Krb5KeyTab /etc/httpd/conf.d/httpd.keytab KrbServiceName "HTTP/www.bpk2....@bpk2.com" KrbLocalUserMapping On KrbDelegateBasic Off KrbAuthoritative Off KrbServiceName explicitly sets the principal to be used. because of this, i use the front end trick with port on the VIP to access a specific pool memeber (www:80 --> load balanced via least connections to all pool members, www:81 --> server1:80, www:82 --> server2:80) -- 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