Re: [Freeipa-users] Cockpit integration part I - Single Sign On

[Alexander Bokovoy]

On Mon, 04 Jan 2016, Alexander Bokovoy wrote:

On Mon, 04 Jan 2016, Marius Vollmer wrote:

Alexander Bokovoy  writes:


Thanks. I think we actually could do better by using gss-proxy -- if
only cockpit-ws would cooperate[1]. I'll file a bug


Thanks!


-- when cockpit-ws launches cockpit-session it doesn't pass anything
from the environment cockpit-ws was launched with.


It uses NULL as the envp argument, which means that cockpit-session
inherits the environment from cockpit-ws, no?

You're right.


cockpit-session itself calls clearenv() very early, and that is probably
the reason why GSS_USE_PROXY doesn't work.

https://github.com/cockpit-project/cockpit/blob/master/src/ws/session.c#L955

In that case adding GSS_USE_PROXY to env_names and moving restore of the
environment before the PAM processing would probably be a solution?

I've filed an issue to cockpit:
https://github.com/cockpit-project/cockpit/issues/3407

It is a bit more complicated due to cockpit-session fiddling with
setuid().
--
/ 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

Re: [Freeipa-users] Cockpit integration part I - Single Sign On

[Alexander Bokovoy]

On Mon, 04 Jan 2016, Marius Vollmer wrote:

Alexander Bokovoy  writes:


Thanks. I think we actually could do better by using gss-proxy -- if
only cockpit-ws would cooperate[1]. I'll file a bug


Thanks!


-- when cockpit-ws launches cockpit-session it doesn't pass anything
from the environment cockpit-ws was launched with.


It uses NULL as the envp argument, which means that cockpit-session
inherits the environment from cockpit-ws, no?

You're right.


cockpit-session itself calls clearenv() very early, and that is probably
the reason why GSS_USE_PROXY doesn't work.

https://github.com/cockpit-project/cockpit/blob/master/src/ws/session.c#L955

In that case adding GSS_USE_PROXY to env_names and moving restore of the
environment before the PAM processing would probably be a solution?

--
/ 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

Re: [Freeipa-users] Cockpit integration part I - Single Sign On

[Marius Vollmer]

Alexander Bokovoy  writes:

> Thanks. I think we actually could do better by using gss-proxy -- if
> only cockpit-ws would cooperate[1]. I'll file a bug

Thanks!

> -- when cockpit-ws launches cockpit-session it doesn't pass anything
> from the environment cockpit-ws was launched with.

It uses NULL as the envp argument, which means that cockpit-session
inherits the environment from cockpit-ws, no?

cockpit-session itself calls clearenv() very early, and that is probably
the reason why GSS_USE_PROXY doesn't work.

https://github.com/cockpit-project/cockpit/blob/master/src/ws/session.c#L955

-- 
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

Re: [Freeipa-users] Cockpit integration part I - Single Sign On

[Alexander Bokovoy]

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[1]. 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.

[1] 
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

[Freeipa-users] Cockpit integration part I - Single Sign On

[Jochen Hein]

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.

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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