[Freeipa-users] subjectAlternitiveName for webservice

Thu Mar 19 10:30:56 UTC 2015

Isn't this documented well (yet) ?

The RH docs are always very detailed about it, but I'm not sure
here... I see solutions but not 100% from A to Z to make sure we do it
the proper way.

2015-03-12 16:59 GMT+01:00 Matt . <yamakasi.014 at gmail.com>:
> Not worried, I need to try.
>
> I think it's not an issue as we use persistance for the connection. We
> only do some user adding/chaging stuff, nothing really fancy but it
> needs to be decent. As persistence comes in I think we don't have to
> worry about it, we discussed that here earlier as I remember.
>
> Or do I ?
>
> Something else; did you had a nice PTO ?
>
> 2015-03-12 15:54 GMT+01:00 Rob Crittenden <rcritten at redhat.com>:
>> Matt . wrote:
>>> Hi,
>>>
>>> Security wise I can understand that.
>>>
>>> Yes I have read about that... but that would let me use the
>>> loadbalancer to connect ? I was not sure if the SAN would "connect" as
>>> "other" host.
>>
>> Kerberos through a load balancer can be a problem. Is this what you're
>> worried about?
>>
>> rob
>>
>>>
>>> 2015-03-12 15:07 GMT+01:00 Rob Crittenden <rcritten at redhat.com>:
>>>> Matt . wrote:
>>>>> Hi Guys,
>>>>>
>>>>> Is Rob able to look at this ? I hope he has some sparetime as I'm
>>>>> kinda stuck with this issue.
>>>>
>>>> Wildcard certs are not supported.
>>>>
>>>> You can request a SAN with certmonger using -D <FQDN>. That will work
>>>> with IPA 4.x for sure, maybe 3.3.5.
>>>>
>>>> rob
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> 2015-03-08 12:30 GMT+01:00 Matt . <yamakasi.014 at gmail.com>:
>>>>>> I'm reviewing some things.
>>>>>>
>>>>>> When I'm using a loadbalancer, which I prefer in this setup I need to
>>>>>> have the same certificates on both servers. Maybe a wildcard for my
>>>>>> domain could do instead of having only both fqdn's of the servers
>>>>>> including the loadbalancer's fqdn.
>>>>>>
>>>>>> But the question remains, how?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-03-07 10:37 GMT+01:00 Matt . <yamakasi.014 at gmail.com>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I will balance with IP persistance so I think there won't be any
>>>>>>> mixing as long as that "used" server is online.
>>>>>>>
>>>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal <dpal at redhat.com>:
>>>>>>>> On 03/06/2015 11:05 AM, Matt . wrote:
>>>>>>>>>
>>>>>>>>> OK, understood.
>>>>>>>>>
>>>>>>>>> But when a webservice does execute a command (from scripting) to a SVR
>>>>>>>>> record and the first is not reacable, would it try to do it again or
>>>>>>>>> will handle DNS this in front of it ?
>>>>>>>>>
>>>>>>>>> I do a kinit against an IPA server using a keytab after I first
>>>>>>>>> checked if the user was able to auth himself using his ldap
>>>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff
>>>>>>>>> to the IPA server.
>>>>>>>>>
>>>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server
>>>>>>>>> is down and doesn't even try to direct any of the commands to it...
>>>>>>>>> I'm not sure if the SRV will handle this well when doing these command
>>>>>>>>> from PHP for an example. Building in extra checks in front could be
>>>>>>>>> done but it not ideal as a loadbalancer can handle such things much
>>>>>>>>> better.
>>>>>>>>
>>>>>>>>
>>>>>>>> OK, this makes things much more clear. Thanks for the explanation.
>>>>>>>> Rob. What is our failover logic for API?
>>>>>>>>
>>>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the
>>>>>>>> whole conversation goes to the same server you should be fine. I do not
>>>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a
>>>>>>>> cert there then if you can enforce the use of the same server in this case.
>>>>>>>>
>>>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance
>>>>>>>> the Kerberos traffic, only the API commands starting with the negotiation.
>>>>>>>>
>>>>>>>> Rob does that make sense for you?
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal <dpal at redhat.com>:
>>>>>>>>>>
>>>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers,
>>>>>>>>>>> SRV won't fit here sorry to say.
>>>>>>>>>>>
>>>>>>>>>>> I auth users, so their keytab should be the same between two masters I
>>>>>>>>>>> believe ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Each entity in Kerberos exchange has its own identity and key.
>>>>>>>>>> If you send a ticket that is destined to service A instead to service B
>>>>>>>>>> it
>>>>>>>>>> would not work unless they share the same keys and identity. Sharinf same
>>>>>>>>>> keys and identities between the servers just would not work with IPA.
>>>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if
>>>>>>>>>> you
>>>>>>>>>> do not have any load balancers and this is the common case. You are
>>>>>>>>>> trying
>>>>>>>>>> to add one where it is really not needed creating overhead for yourself.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not
>>>>>>>>>>> 100% there in step 6
>>>>>>>>>>>
>>>>>>>>>>> Thanks again!
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Matthijs
>>>>>>>>>>>
>>>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek <pspacek at redhat.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using
>>>>>>>>>>>>> curl/json.
>>>>>>>>>>>>
>>>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API.
>>>>>>>>>>>> It
>>>>>>>>>>>> will
>>>>>>>>>>>> handle fail over for you even without any load balancer. That would be
>>>>>>>>>>>> easiest
>>>>>>>>>>>> way.
>>>>>>>>>>>>
>>>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one
>>>>>>>>>>>>> central point where I can tal to I use a loadbalancer.
>>>>>>>>>>>>
>>>>>>>>>>>> Well, if you can control clients then the easiest and most universal
>>>>>>>>>>>> way
>>>>>>>>>>>> is to
>>>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution
>>>>>>>>>>>> works
>>>>>>>>>>>> even when servers are geographically distributed/in different networks
>>>>>>>>>>>> and
>>>>>>>>>>>> does not have single point of failure (the load balancer).
>>>>>>>>>>>>
>>>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known
>>>>>>>>>>>>> on the IPA server because this is needed for the http service
>>>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server
>>>>>>>>>>>>> and make it as an ALT name to it's Certificate.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As the users are the same on both servers I would asume i can use a
>>>>>>>>>>>>> keytab for a user against both servers from my clients.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on
>>>>>>>>>>>> IPA
>>>>>>>>>>>> server have their own keytabs too. Every service on every server has
>>>>>>>>>>>> own
>>>>>>>>>>>> keytab with different key.
>>>>>>>>>>>>
>>>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about
>>>>>>>>>>>> possibility
>>>>>>>>>>>> of
>>>>>>>>>>>> sharing keytabs between IPA services.
>>>>>>>>>>>>
>>>>>>>>>>>>> Does this make it more clear ?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm still not sure if you want to have human users too or just API
>>>>>>>>>>>> clients.
>>>>>>>>>>>>
>>>>>>>>>>>> Petr^2 Spacek
>>>>>>>>>>>>
>>>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek <pspacek at redhat.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each
>>>>>>>>>>>>>>> ipa
>>>>>>>>>>>>>>> server ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any other options ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I do not really understand your use case. Could you describe it in
>>>>>>>>>>>>>> detail, please?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Petr^2 Spacek
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek <pspacek at redhat.com>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically
>>>>>>>>>>>>>>>> possible to use
>>>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve
>>>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect
>>>>>>>>>>>>>>>> to ipa
>>>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using
>>>>>>>>>>>>>>>> classical load
>>>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force
>>>>>>>>>>>>>>>> you to mess
>>>>>>>>>>>>>>>> with certs and keytabs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Petr^2 Spacek
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Petr Spacek  @  Red Hat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Thank you,
>>>>>>>>>> Dmitri Pal
>>>>>>>>>>
>>>>>>>>>> Sr. Engineering Manager IdM portfolio
>>>>>>>>>> Red Hat, Inc.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thank you,
>>>>>>>> Dmitri Pal
>>>>>>>>
>>>>>>>> Sr. Engineering Manager IdM portfolio
>>>>>>>> Red Hat, Inc.
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>
>>