On Tue, 2015-03-31 at 18:18 +0200, Matt . wrote: > OK, that makes it even more clear. > > an ldapwhoami might be an issue. As this client is known on a > different ldap server and I kinit to another ldap server. There is a > reason for this as we have out office network and our deployment > network. Users that manage are in the office ldap, user that are in > deployment are in the deployment ldap. I do my kinit > username@deployment.domain which works ok when I run my commands at > ipa-01.deployment.domain. > > But when I want to do a ldapwhoami it tries to connect to the office > ldap server which is not working of course. (I get a connection error > atm, need to investigate as that server is running fine). > > Get the idea ? > > Thanks again! > > Matt > > 2015-03-31 17:58 GMT+02:00 Brendan Kearney <bpk...@gmail.com>: > > 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. > >
looks like trusts between the kerberos realms and/or ldap domains are not setup, are not setup correctly or are not bi-directional. you seem to be getting a referral for the ticket, but cannot get the ticket from where you are being referred to. dig into a netowrk capture with wireshark and look through it very carefully. -- 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