realmd should have a method for setting up a service (with SPN) and a return a keytab for that service.
Cockpit needs this for setting up an HTTP/computer@realm service, since the host/computer@REALM does not work with HTTP Negotiate in IPA, as it does in AD.
FreeIPA has no client side command to setup a service from the client side. One can use the server side tool which is in the freeipa-admintools package. In lieu of a client side tool one can access the JSON-RPC API directly: $ kinit admin $ curl --negotiate -u : https://f0.cockpit.lan/ipa/json --header 'Referer: https://f0.cockpit.lan/ipa' --header "Content-Type: application/json" --header "Accept: application/json" --data '{"params": [["HTTP2/stef.cockpit.lan"], {"raw": false, "all": false, "version": "2.101", "force": true, "no_members": false}], "method": "service_add", "id": 0}'
freeipa-admintools can be installed on a client, and called out, it's just a matter of making it a dependency. We used to avoid making it a dependency of freeipa-client to minimize the amount of stuff installed, but it can be installed.
(In reply to Stef Walter from comment #1) > Cockpit needs this for setting up an HTTP/computer@realm service, since the > host/computer@REALM does not work with HTTP Negotiate in IPA, as it does in > AD. Should we add a HTTP/fqdn service by dafault at join time, so all you need is to invoke ipa-get-keytab to get a key ?
(In reply to Simo Sorce from comment #4) > Should we add a HTTP/fqdn service by dafault at join time, so all you need > is to invoke ipa-get-keytab to get a key ? That would be awesome and fit the use case really well. If Cockpit is to be a our server UI, then having HTTP/fqdn there by default makes complete sense.
(In reply to Simo Sorce from comment #4) > > Should we add a HTTP/fqdn service by dafault at join time, so all you need > is to invoke ipa-get-keytab to get a key ? Could we have this dependent on a class (?) of the host? While adding HTTP/ is a natural option, I wonder if in some environments, other services might be preferred.
(In reply to Jan Pazdziora from comment #6) > (In reply to Simo Sorce from comment #4) > > > > Should we add a HTTP/fqdn service by dafault at join time, so all you need > > is to invoke ipa-get-keytab to get a key ? > > Could we have this dependent on a class (?) of the host? While adding HTTP/ > is a natural option, I wonder if in some environments, other services might > be preferred. I guess so. I really wish we could just use the HOST/fqdn@REALM SPN. Logically, Cockpit is providing access to the host, just like ssh does. I wonder why Firefox can can get HTTP/fqdn@REALM tickets against Active Directory for a computer account and keytab without an HTTP service principal: $ klist Ticket cache: KEYRING:persistent:1000:krb_ccache_Pt3dMeM Default principal: Fry Valid starting Expires Service principal 09/24/2014 15:52:17 09/25/2014 01:52:14 HTTP/falcon.thewalter.lan renew until 10/01/2014 15:52:14 09/24/2014 15:52:17 09/25/2014 01:52:14 HTTP/falcon.thewalter.lan@ renew until 10/01/2014 15:52:14 09/24/2014 15:52:14 09/25/2014 01:52:14 krbtgt/BORG.LAN renew until 10/01/2014 15:52:14 [stef@falcon cockpit]$ ldapsearch -Y GSSAPI -s base -b CN=falcon,CN=Computers,DC=BORG,DC=LAN -H ldap://dc.borg.lan SASL/GSSAPI authentication started SASL username: Fry SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <CN=falcon,CN=Computers,DC=BORG,DC=LAN> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # falcon, Computers, BORG.LAN dn: CN=falcon,CN=Computers,DC=BORG,DC=LAN objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user objectClass: computer cn: falcon distinguishedName: CN=falcon,CN=Computers,DC=borg,DC=lan instanceType: 4 whenCreated: 20140924080821.0Z whenChanged: 20140924082725.0Z uSNCreated: 16409 uSNChanged: 16428 name: falcon objectGUID:: i/YJSFIynUG59avUnB4jgw== userAccountControl: 69632 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 130560401623125000 localPolicyFlags: 0 pwdLastSet: 130560208456562500 primaryGroupID: 515 objectSid:: AQUAAAAAAAUVAAAA2MkECpaRByiBT/qiUQQAAA== accountExpires: 9223372036854775807 logonCount: 22 sAMAccountName: falcon$ sAMAccountType: 805306369 dNSHostName: falcon.thewalter.lan servicePrincipalName: HOST/falcon.thewalter.lan servicePrincipalName: HOST/FALCON objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=borg,DC=lan isCriticalSystemObject: FALSE dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130560197028750000 # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 $ sudo klist -k [sudo] password for stef: Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon.thewalter.lan 3 host/falcon 3 host/falcon 3 host/falcon 3 host/falcon 3 host/falcon 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN 3 FALCON$@BORG.LAN
I think we need to go two ways: a) Figure out why HOST does not work. I am not sure whose action item is. b) Implement a way to create services in IPA automatically when host is created. https://fedorahosted.org/freeipa/ticket/4568
(In reply to Dmitri Pal from comment #8) > I think we need to go two ways: > > a) Figure out why HOST does not work. I am not sure whose action item is. Simo said on IRC that Active Directory adds a HTTP/fqdn@REALM SPN with the same key as the host/fqdn@REALM SPN automatically. He noted that they can get away with this due to the use of a gss-proxy equivalent (ie: services don't get their hands on the key material). > b) Implement a way to create services in IPA automatically when host is > created. > https://fedorahosted.org/freeipa/ticket/4568 Yes that would be great. If implemented in IPA server, we also need a work around in IPA client and/or realmd.
(In reply to Dmitri Pal from comment #8) > > a) Figure out why HOST does not work. I am not sure whose action item is. RFC 4559 (SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows) mandates that: When the Kerberos Version 5 GSSAPI mechanism [RFC4121] is being used, the HTTP server will be using a principal name of the form of "HTTP/hostname".
(In reply to Jan Pazdziora from comment #10) > (In reply to Dmitri Pal from comment #8) > > > > a) Figure out why HOST does not work. I am not sure whose action item is. > > RFC 4559 (SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft > Windows) mandates that: > > When the Kerberos Version 5 GSSAPI mechanism [RFC4121] is being used, > the HTTP server will be using a principal name of the form of > "HTTP/hostname". Which it does, as you can see from my "klist" output above. The key difference is HTTP/fqdn is provisioned automatically and has the same key as host/fqdn
(In reply to Stef Walter from comment #11) > Which it does, as you can see from my "klist" output above. The key > difference is HTTP/fqdn is provisioned automatically and has the same key as > host/fqdn It's more subtle than that, in windows there is a concept of a "machine password" and those crdentials can be used by any program though assistance of the OS. On top of that in AD a ton of service names are Aliased on the host SPN by default, you do not even need to do anything special at provisioning time, asking a ticket for HTTP/ FTP/ host/ ... works because they are all aliases for the computer key.
Idea: IPA will give host key access to add a service (at least ones on the whitelist). The initial cockpit setup 'remotectl' command can set up HTTP service in this case.
* Could do some checks before adding the service whether it exists or not by getting a ticket for HTTP/ and if it's already in active use by something else (ie: apache mod_auth_gsssapi|kerb)
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I believe this request is still valid on Fedora 23.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
> FreeIPA has no client side command to setup a service from the client side. This does exist now: ipa service-add It would still be nice to not have to do this manually of course. ipa-getkeytab could just automatically create a missing SPN, as discussed in https://pagure.io/freeipa/issue/4568 .
https://github.com/cockpit-project/cockpit/pull/8956 implements this in Cockpit with the FreeIPA client side tools (ipa service-add and ipa-getkeytab). It's not literally in realmd, but I suppose it's "good enough"? As discussed in https://pagure.io/freeipa/issue/4568 there won't be much further change in FreeIPA wrt. this, so I figure this bug can be closed now?
Yes, I'll close the ticket. While it would be possible to add a new command family to realmd to manage services I think it would be better and more flexible to use the more specific tools like 'net ads', 'adcli' or the ipa client commands for this.