[Freeipa-users] subjectAlternitiveName for webservice

Dmitri Pal dpal at redhat.com
Fri Mar 6 18:16:39 UTC 2015


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.




More information about the Freeipa-users mailing list