[Freeipa-users] FreeIPA 4.2 on CentOS 7.2 restricts an access to krb* attributes

[Konstantin M. Khankin]

Hi Alexander!

Here's the config (mostly auto-generated by ipa-client-install):
-------------------------------------------------------------------------------------------------------------------------------------
[domain/gsk.loc]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = gsk.loc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = garage.gsk.loc
chpass_provider = ipa
ipa_server = _srv_, drone.gsk.loc
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_search_base = cn=accounts,dc=gsk,dc=loc
ldap_user_extra_attrs = uid, krbLastSuccessfulAuth, krbLastFailedAuth

[sssd]
services = nss, sudo, pam, ssh, ifp
config_file_version = 2

domains = gsk.loc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]
allowed_uids = apache, root
user_attributes = +uid, +krbLastSuccessfulAuth, +krbLastFailedAuth
-------------------------------------------------------------------------------------------------------------------------------------

In debug logs I can see that sssd establishes secure connection using host/
principal:

(Tue Jun  7 18:08:36 2016) [sssd[be[gsk.loc]]] [sasl_bind_send] (0x0100):
Executing sasl bind mech: GSSAPI, user: host/garage.gsk.loc
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [child_sig_handler]
(0x0100): child [2377] finished successfully.
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [fo_set_port_status]
(0x0100): Marking port 389 of server 'drone.gsk.loc' as 'working'
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [set_server_common_status]
(0x0100): Marking server 'drone.gsk.loc' as 'working'
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [fo_set_port_status]
(0x0400): Marking port 389 of duplicate server 'drone.gsk.loc' as 'working'

But this is what happens when I query info via dbus:

...
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sdap_attrs_add_ldap_attr]
(0x2000): Adding uid [hc] to attributes of [hc].
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sdap_attrs_add_ldap_attr]
(0x2000): krbLastSuccessfulAuth is not available for [hc].
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sdap_attrs_add_ldap_attr]
(0x2000): krbLastFailedAuth is not available for [hc].
...
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sysdb_remove_attrs]
(0x2000): Removing attribute [krbLastSuccessfulAuth] from [hc]
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sysdb_remove_attrs]
(0x2000): Removing attribute [krbLastFailedAuth] from [hc]
...

> FreeIPA 4.x has enhanced ACIs but it mostly means there are less
> attributes accessible to non-authenticated (anonymous) connections. Once
> you are authenticated, most of the attributes which were accessed by
> anonymous connections before are now available.

Where can I see and/or control these ACIs?

Thanks!


2016-06-07 16:40 GMT+03:00 Alexander Bokovoy <abokovoy at redhat.com>:

> On Tue, 07 Jun 2016, Konstantin M. Khankin wrote:
>
>> HI!
>>
>> I used to run FreeIPA 3.0 on CentOS 6 but recently upgraded this setup to
>> FreeIPA 4.2 on CentOS 7.2. And I got 2 my applications failing, because
>> they were accessing LDAP fields krb* (one by itself, another through
>> mod_lookup_identity). For the one which makes LDAP requests by its own I
>> created an account and LDAP happily gives an access to krb* fields once
>> that app makes simple bind
>>
> FreeIPA 4.x has enhanced ACIs but it mostly means there are less
> attributes accessible to non-authenticated (anonymous) connections. Once
> you are authenticated, most of the attributes which were accessed by
> anonymous connections before are now available.
>
> But with the one which relies on mod_lookup_identity I'm having troubles.
>> Even though SSSD is being authenticated through GSSAPI, LDAP does not give
>> an access to krb* fields. I tried to create a separate service record for
>> SSSD - no change. And I couldn't make SSSD do simple bind instead of using
>> GSSAPI. I tried to setup FreeIPA so that by default it gives an access to
>> krb* fields, but web interface rejected that change
>>
>> Could you please help me with this issue? How can I control this behavior
>> properly, not with ugly hacks?
>>
> Can you show your SSSD configuration? host/ principals should be just
> fine to access krb* attributes.
>
>
> --
> / Alexander Bokovoy
>



-- 
Konstantin Khankin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160607/50d83470/attachment.htm>