Support of Kerberos authentication in ccm-fetch

[StephaneGerardVUB]

LWP::UserAgent needs the plugin LWP::Authen::Negotiate in order to enable Kerberos authentication in case the profiles are in an Apache with mod_auth_kerb. This plugin is provided by the package perl-LWP-Authen-Negotiate. I suggest that this package is added in the "external" repositories, and it becomes a dependency of the ccm package.

[stdweird]

@StephaneGerardVUB what else is needed to make this work? if it is only a matter of adding the package, it could make it in 15.4 imho (the rpm exists in el5 EPEL); if more is needed, it will be 15.6.
@ned21 @gombasg any feedback (i was under the impression that MS used ccm with krb5)

[jrha]

It would be good to know! We plan migrate to kerberised ccm this year.

[stdweird]

now that i remember, i think this is related to quattor/CAF#62 and the earlier discussion in quattor/aii#81

[StephaneGerardVUB]

@stdweird You need something else for it to work : a valid kerberos ticket for root. root can always create a ticket using the keytab of the machine by doing "kinit -k -t /etc/krb5.keytab". So, what is missing is implementing ticket creation in ccm-fetch.

[jrha]

Ok, lets leave this for 15.6.

[stdweird]

tickets should be obtainable from perl, there's Authen::Krb5 to help with that
@StephaneGerardVUB if you can live manually creating the tickets, maybe you can also add the dependency in the templates for now? I agree with @jrha that this can't be achieved for 15.4

[StephaneGerardVUB]

@stdweird Sure we can survive without that. You can postpone it to 15.6.

[ned21]

We don't use mod_auth_kerb but instead encrypt the profile such that only the intended recipient can decrypt it.

[jrha]

Did you patch ccm to do the decryption?

[ned21]

We don't have any local patches, if that's what you are asking. I believe this code in CCM originated from us.

[stdweird]

@ned21 any specific reason why you use that way of working instead of mod_auth_kerb?

[ned21]

Yes, several. One of them was that this provides encryption and authorisation via the same trust infrastructure. mod_auth_kerb requires SSL to ensure the data is not transmitted in the clear, plus management of appropriate ACLs on all the profile servers (of which we have many). Might be a good presentation at the next workshop if you are interested?

[jrha]

Yes please. What is doing the encryption?

[stdweird]

👍 on the presentation
but aside from managing the trusts, no real technical reason? i think some sites are looking at a single realm setup, managed with freeipa; so if there's a technical drawback, that would be very interesting to know.

[ned21]

@jrha - a CGI script on the web server

@stdweird - depends on your definition of "technical". I don't think we considered mod_auth_kerb because it didn't (alone) meet the requirements we had, while kerberos encryption did.

[jrha]

Is this issue just a matter of documentation now?

[stdweird]

@jrha no, not really, i plan to fix this via quattor/CAF#110. we need it end of january, so i'll work on it next month.

[stdweird]

@ned21 @gombasg what are the odds of MS accepting dependency on LWP::Authen::Negotiate in CAF or CCM? it is in epel, but even for el7 not in main repos. i could reimplement the code ofcourse (it's not that hard), but i'd prefer to avoid this kind of duplication.

[jnovy]

Hi Stijn,

it's ok as we can use EPEL now. perl-LWP-Authen-Negotiate is in all EPELs (version 0.08) so we should be good if you use this one.

Cheers,
Jindrich

[stdweird]

@jnovy thx!