OK, but as I say, without the loadbalancer, same domain it works.
My IPA server also sees the client name and ptr as I do nat.
So you create a keytab for your host you are doing the commands from ?
I was using a user keytab and run my commands as that user, that works
to ipa-01
It's getting something more clear.
2015-03-31 19:29 GMT+02:00 Brendan Kearney <bpk...@gmail.com>:
> 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
