Perry Myers wrote:
adding sct
On 01/20/2011 08:27 PM, Dmitri Pal wrote:
> Perry Myers wrote:
>
>> The first pass at Matahari right now has zero auth on it, just a
>> username field to connect to a broker but no password. :)
>>
>> Adam is working to add simple password auth to Matahari so that we have
>> some semblance of security.
>>
>> But as Dmitri will point out, the real deal here is to get kerberos
>> integrated via IPA. Of course, qpid supports auth via kerberos, but
>> there are some practical matters we need to figure out.
>>
>> Ignoring for a minute the issue of getting a machine its identity (which
>> Dmitri already covered separately), let's assume that the machine
>> already has a keytab file in place on the filesystem.
>>
>> Ok, now we've got a keytab, but...
>>
>> * How do we do the equivalent of kinit to load the identity and
>> authenticate to the KDC in an automated fashion? Kerberos tickets
>> generally have an expiration, so the 'kinit' would need to happen on
>> some sort of schedule? How is this done? (Note: crontab/at are not
>> good answers)
>>
>>
> First I had to dig how it works in MRG/QPID/AMQP.
> Here is the link:
>
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Messagi...
>
> If you look at item 3 :
>
> 1.
> Make sure that each Qpid user is registered in the Kerberos
> database, and that Kerberos is correctly configured on the client
> machine. The Qpid user is the account from which a Qpid messaging
> client is run. If it is correctly configured, the following
> command should succeed:
>
> $ kinit user(a)REALM.COM
>
> So this implies that the machine is configured to be a member of the
> Kerberos realm and user can authenticate with kinit.
> In the sequence I am working on for bootstrapping we will have (my
> script will provide) a machine kerberos principal, keytab and as a
> result a TGT ticket. We do not need to renew since it is a one time
> operation. But I do not have a clue on how to (or even if it is
> possible) to tell the QPID client to use a specific principal other then
> the current user.
> Tedd can you please help with this?
>
Hm it might be even more simpler than I thought. If we need to connect
as user we do not need to enroll the system as a whole.
I really need to setup QPID client and server. I will give it a try.
> For Matahari it is different since it would have to kinit
internally
> every time the GSSAPI failed becuase the ticket go expired. This is how
> all applications do it. It looks like it should be something on top of
> QPID becuase based on what I read on the page QPID client just assumes
> that there is a ticket, so Matahari will have to implement this logic
> itself. Fortunately it is a usual case for any client service and I
> would be able to dig some example code quire easily. SSSD has to do it
> for itself from time to time so we should have code there.
> But before we even look into this we need to find answer to the question
> above.
>
>
>
>
>
>
>> * Can/should we use keytab/identities that do not require a password to
>> create a ticket? Since we need automation here, adding a password is
>> sort of self-defeating anyhow
>>
>>
> Correct we should be using keytabs and host or service identities rather
> than user identities. The challenge is to make qpid client respect that.
>
>
>> * What about Windows? If we're going to rely on Kerberos on Windows as
>> well, that means we need to preinstall some MIT kerb software on
>> Windows which means we need to pull it into Fedora and cross compile
>> it along with mingw32-matahari? Or do we just say "if you want to
>> use Matahari/Kerberos on Windows, here go download this MIT kerberos
>> windows installer from http://...."?
>>
>>
> Yes in the following ways:
> a) We would have to port out ipa-join code to windows (not scheduled
> right now)
> b) This effort will automatically require kerberos libraries so we would
> have to so it out and make sure we port all pieces needed, thus porting
> this to windows would release you headache but add mine... I suspect
> that QPID client on windows would leverage same libraries. If not then
> we both got a problem to share :-)
>
>
>
>> * Aside from installing either ipa RPMS on Fedora or MIT kerberos
>> software on Windows, there's the issue of configuring your OS to use
>> a KDC. Do we just declare that that is outside the scope of Matahari
>> install and state "if you want to use Kerberos auth, first make sure
>> your OS has the proper software and configuration to connect to a
>> KDC"?
>>
>>
> My thought is the following:
> The first boot sequence will be Kerberized and will allow an newly born
> VM to connect to the config server and pull first boot puppet script and
> may be other bits of configuration . This puppet script or the
> additional config info will have enough information to configure
> Matahari to be a part of the IPA domain. Now here is an interesting
> part. Which domain? It is not a bootstrapping domain. It should be a
> part of the Cloud engine domain (or for the sake of security a separate
> domain controlled by cloud engine but this does not matter for now). But
> this domain is behind the firewall... So what you need to do? Right,
> execute the VPN sequence first, get on the VPN and then using the data
> provided by the bootstrapping server enroll with the right IPA using
> pretty much the same client script that was used to enroll it in the
> first place.
> As alternative to VPN sequence we can use IEKERB - a special Kerberos
> server that can be put into DNZ for access by clients outside the
> firewall but we never tried it yet. It is a fairly new technology and it
> is unclear whether it is fully baked or not. Implementing VPN sequence
> IMO would be easier at least for now but I will drill down more on
> IEKERB too.
> Keep in mind that VPN sequence should be a part of every restart of the
> machine to make it a part of the corporate infrastructure.
>
> The problems to solve now are:
> 1) The client script I am working on with the subproblem of how to make
> qpid client understand which principal to use. If we can tell it what
> principal to use we might actually not need to rename a machine while
> doing the enrollment magic.
> 2) VPN sequence - slides are on the list, we can talk about it next week.
>
> Once these two things solved the problems of enrollment you rise above
> will be solved.
>
>
>
>
>> Dmitri, thoughts? Just trying to figure out the practicalities of
>> making this easy to deploy and use for end-users on both Fedora and
>> Windows platforms.
>>
>> Perry
>>
>>
>
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/