Alternatively, could the missing service be auto-added only at ipa-get-keytab time?

Replying to [comment:1 adelton]:

Alternatively, could the missing service be auto-added only at ipa-get-keytab time?

May be but it seems to be something we should consider as a part of #4567

automember only controls membership, I do not think it should also create entries - looks like overengineering to me. The route via #4567 looks more promising to me.

Replying to [comment:3 mkosek]:

automember only controls membership, I do not think it should also create entries - looks like overengineering to me. The route via #4567 looks more promising to me.

I did not imply automember should be governing this.

My argument for making the services auto-created is that it would be server-only change, client would not need to make the (service-add?) call, so any scripts that now rely on admin adding the services manually on the server would continue working without any change, just could be called without admin doing anything.

For real-life example, take http://theforeman.org/manuals/1.6/index.html#5.7ExternalAuthentication -- it states in prerequisites that you should {{{ipa-client-install}}} and then {{{ipa service-add HTTP/...}}}. If the {{{ipa-getkeytab}}} (that {{{--foreman-ipa-authentication=true}}} calls internally) would cause the service to be autocreated if not yet present, the Foreman installer code would not need to be changed at all, just the {{{ipa service-add}}} step would become optional in the docs.

But now clients that do run ipa service-add will start getting an error because the entry already exists ?

Replying to [comment:6 simo]:

But now clients that do run ipa service-add will start getting an error because the entry already exists ?

This is why I said that there should be rules on the server that are "similar" to automember.
Same concept - scripts that were adding groups manually would start failing if the member is already there. It is up to the deployment to decide. BTW I have not heard any complains that with introduction of the automember feature someone was not happy that the existing scripts started to fail. IMO using a similar mechanism to automember will be the way to go. For example one can have a "Nova-Keystone" host and that would mean that when the host is created and the type of the host is passed the new autoservice creation plugin will create all the services for this type.
I also do not see a problem with creating entries. Is there a significant problem with creation that is different from the update?

Duplicate: #4862.

Rob should have some cycles to help with this one.

Closed, as #4862 was fixed.

#4682 was not really fixed, it was just closed as a duplicate of this; so the previous comment and the closing are confusing. Auto-adding missing services at ipa-get-keytab time would greatly simplify things indeed. Right now, setting up cockpit still requires doing

ipa service-add --ok-as-delegate=true --force HTTP/x0.cockpit.lan@COCKPIT.LAN

before the ipa-getkeytab command.

Whoops, sorry for the mis-formatting; seems I can't edit my own comment :-(

I think you mean #4862 and yes, looks like this was closed by accident.

One problem is what you are proposing already adds new flags to ipa-getkeytab:

--add (or it could be implicit)
--ok-as-delegate
--force

There are a number of others that service-add provides as well.

If you already have to invoke one command, ipa-getkeytab, what is the issue with invoking two?

Oh, it would need to duplicate the flags, I see. I only really started to look into this issue today (I sent https://github.com/cockpit-project/cockpit/pull/8949 for an initial cleanup). I stumbled over this bug and mostly just noticed that it was closed without a real explanation. I suppose cockpit-ws could first check if the SPN already exists and if not create it, then run ipa-getkeytab. This will take a few more roundtrips (and take some time), but I guess it's not a big deal.

So if you think this should be a "wontfix", please feel free to close again.

cockpit-ws could first check if the SPN already exists ...

Actually it would not be the web server that does it, as that does not have an admin ticket and thus is not privileged to do this operation. I figure Cockpit would do that right after realm join, and there a few extra seconds don't matter at all.

Does that make sense? I. e. is it kosher for Cockpit's "Join a domain" page to always create a HTTP/<host> SPN (if it does not exist), create a new keytab for that, and let the web server use that keytab from then on instead of the default /etc/krb5.keytab? In other words, is it best practice for services to genenerate their own SPN by itself, or is that something an admin wants/needs to have control over?

I figure it is okay as the option of letting ipa-getkeytab auto-create missing SPNs was seriously considered, but as I'm fairly new to krb I better ask twice..

Thank you!

Martin, I think letting Cockpit's 'Join a domian' page to perform that is OK. After all, you are configuring secured HTTP access to Cockpit web application and by custom all browsers will use HTTP/.. service principal for the target service name.

It is, however, not OK to extend ipa-getkeytab to create services because it is simply a wrong place to do that job. ipa-getkeytab by design is a tool to request a generation of a key for a service principal that exists or to retrieve existing key in case there are enough privileges to allow it. Coupling it with ability to create the principals would violate privilege separation design.

Also, unlike Active Directory, a generic Kerberos does not necessary has SPNs the same way. For example, for FreeIPA host/<host> and HTTP/<host> are two different service principals. In general, they are fully unrelated, there is no shared key (unlike Active Directory where HTTP/<host> is merely an alias for a machine account), no shared access control and shared management rules. in FreeIPA we set by default a machine to be a manager of Kerberos services created on that machine, so that host principal (host/<host>) gains access rights to generate a key for HTTP/<host> but this, for example, does not allow host/<host> to retrieve an existing key for HTTP/<host>. For doing that, one needs to assign additional privileges to host/<host>.

In the machinery we have around Kerberos principal management we aren't really willing to conflate different roles (create principals - generate keys - retrieve keys) by default.

Thanks @abbra for the confirmation and explanation! So it sounds like Cockpit doing ipa service-add for HTTP/ (if not already present) and ipa-getkeytab for cockpit's web server (again, if not already present) is the way to go, and doesn't require changes to IPA itself. I have a first working version here. So I figure this should be closed then, as "wont fix"?

Let us keep the ticket for the original purpose, just 'wont fix' for cockpit.

Recently we wanted to add a simple notification system which would allow to use it for audit purposes. A plugin that listens to that and reacts by creating additional objects in IPA would be a good answer for the original request.

So I'd keep this ticket open for the purpose of making such a plugin (external to IPA itself) available.