On 11/13/18 10:20 PM, Rob Crittenden via FreeIPA-devel wrote:
> Petr Vobornik via FreeIPA-devel wrote:
>> On Mon, Nov 12, 2018 at 6:28 PM François Cami via FreeIPA-devel
>> <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> While investigating why non-admin users having access to a shared
>>> vault got an error that stemmed from them not being able to find the
>>> KRA server to query (*), I found out that by changing the ldapsearch
>>> query normal users could, in fact, get the list of KRA servers.
>>>
>>> (*) https://pagure.io/freeipa/issue/7691
>>>
>>> E.g. the query built from select_any_master(ldap2, service='CA') does
>>> not return any server when run by a non-admin user:
>>> ##############
>>> # ldapsearch -Y GSSAPI -b
>>> cn=masters,cn=ipa,cn=etc,dc=laptop,dc=example,dc=org
>>> '(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=KRA))'
>>> (...)
>>> ##############
>>>
>>> but removing (ipaConfigString=enabledService) from the query works:
>>> ##############
>>> # ldapsearch -Y GSSAPI -b
>>> cn=masters,cn=ipa,cn=etc,dc=laptop,dc=example,dc=org
>>> '(&(objectClass=ipaConfigObject)(cn=KRA))'
>>> # KRA, idm0.laptop.example.org, masters, ipa, etc, laptop.example.org
>>> dn:
cn=KRA,cn=idm0.laptop.example.org,cn=masters,cn=ipa,cn=etc,dc=laptop,dc=ex
>>> ample,dc=org
>>> objectClass: nsContainer
>>> objectClass: ipaConfigObject
>>> objectClass: top
>>> cn: KRA
>>> ##############
>>>
>>> So it looks like once we're past logging an exception when we can't
>>> find a KRA master ( https://github.com/freeipa/freeipa/pull/2553 ), we
>>> have to decide what to do:
>>> * should users be able to see more data in LDAP by default - it looks
>>> like by using ldapsearch they already can find the information they
>>> need anyway - so allow all users to read status of services
>>
>> After the ping on IRC I gave it bit more thought
>>
>> I'd actually prefer to allow reading of ipaconfig string attr to all
>> authenticated users as I don't think we are revealing any new
>> information and it would make logic simpler and would support possible
>> RFE of standby replica.
>>
>> Some thinking behind it, maybe I have missed something:
>>
>> If a service is present is visible by the presence of the container,
>> e.g. KRA(as pointed out by Francois) - this is done via permission
>> "Read access to masters" bind to all.
>>
>> For values which are stored in ipaConfigString:
>> * enabledService - IPA doesn't support uninstallation, so except for
>> interim state in install this will be mostly present in each service
>> container and can be mostly read from SRV records + it's the point of
>> all this.
>> * startOrder - this information is not interesting and all servers
>> should have the same value
>> * dnssecVersion 1 - I think it can be inferred from DNS
>> * caRenewalMaster - I don't know exactly how this attr is being
>> consumed by a consumer but we also announce all CA servers and it is
>> clear that it is one of them. Also readable by all IPA managed hosts
>> (as any ipaConfigString in masters tree).
>> * kdcProxyEnabled - enabled by default
>> * pkinitEnabled - is obtainable via another way
>
> Seems well-reasoned to me, +1.
>
> rob
Also agree, we can make ipaconfigstring readable by all authenticated users.
flo
