On Sun, 27 Dec 2015, Jochen Hein wrote:
Hi, here is what I did on my system - may be helpful to others as well. Cockpit: enable Single-Sign-On with FreeIPA =========================================== I wanted to use SSO to access the Cockpit already installed on my freeipa server. Upstream documentation is on http://cockpit-project.org/guide/latest/sso.html, so we only add some remarks here. Upstream: ,---- | There must be a valid Kerberos host key for the server in the | /etc/krb5.keytab file. It may be necessary to create a kerberos | service principal and update the keytab if it is not | present. Depending on your domain type different service names are | required: | | Active Directory HOST/server.example....@example.com | IPA and MIT HTTP/server.example....@example.com `---- This has already happened - apache on my server uses the service HTTP/server.example....@example.com, but the service is not present in the server keytab. So we need to add the service principal there. If we just generate a new keytab, we invalidate the keytab used by apache. So we need to only retrieve the keytab, not regenerate it. This is only possible after we allowed the retrieval of the keytab for either the admin principal, the host principal or some users/host groups. Here we go for the host principal: # kinit admin # ipa service-allow-retrieve-keytab HTTP/freeipa.jochen....@jochen.org --hosts=freeipa.jochen.org Finally we retrieve the service keytab into /etc/krb5.keytab: # ipa-getkeytab -r -s freeipa.jochen.org -p HTTP/freeipa.jochen....@jochen.org -k /etc/krb5.keytab After that Single Sign On works as expected.
Thanks. I think we actually could do better by using gss-proxy -- if only cockpit-ws would cooperate. I'll file a bug -- when cockpit-ws launches cockpit-session it doesn't pass anything from the environment cockpit-ws was launched with. This prevents use of gss-proxy, unfortunately. With gss-proxy you would not need to retrieve and maintain separate keytabs or give cockpit any access to the keytab at all. When this would be fixed, a config section for /etc/gssproxy/gssproxy.conf like this would allow the gss-proxy interposer would kick in and obtain the ticket: [service/cockpit-ws] mechs = krb5 cred_store = keytab:/etc/httpd/conf/ipa.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab # uid of cockpit-ws euid = 981 You also would need to add Environment=GSS_USE_PROXY=yes to the cockpit.service, so that GSSAPI library would start using gss-proxy. I've CC:ed Marius to make Cockpit guys aware of the issue.  https://github.com/cockpit-project/cockpit/blob/master/src/ws/cockpitauth.c#L391 -- / Alexander Bokovoy -- 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