Erinn Looney-Triggs wrote:
> On 08/12/2014 09:21 AM, Alexander Bokovoy wrote:
>> On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> On 08/11/2014 09:08 AM, Martin Kosek wrote:
>>>> On 08/11/2014 04:24 PM, Jakub Hrozek wrote:
>>>>> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy 
>>>>> wrote:
>>>>>> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote:
>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>>
>>>>>>> It would seem to be prudent to set the minssf setting for
>>>>>>> 389 to 56, however I am wondering why this isn't done by
>>>>>>> default, and if there is any reason why I shouldn't do
>>>>>>> it?
>>>>>> Anonymous connection to LDAP wouldn't work. I think we use
>>>>>> it for rootdse access when enrolling IPA clients where we
>>>>>> don't yet have a CA certificate.
>>>>>>
>>>>>> I may be wrong, though.
>>>>>
>>>>> Also old (RHEL-5) SSSD versions rely on anonymous access to
>>>>> be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are
>>>>> able to re-try fetching rootDSE once the authenticated
>>>>> connection is established.
>>>>>
>>>>
>>>> Also, older FreeIPA clients were not able to join those severs
>>>> due to bug in ipa-client-install:
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/4459
>>>>
>>>> This will be fixed in FreeIPA 4.0.2. Note that this only
>>>> affects if you are changing MinSSF for whole DS by
>>>> nsslapd-minssf.
>>>>
>>>> Martin
>>>>
>>>
>>> I guess the part I don't get here, is that this setting does not 
>>> disable anonymous access to rootdse it just requires, as far as
>>> I understand, that TLS or some security be used for the
>>> connection.
>>>
>>> I currently have minssf set to 56 and am able to anonymously bind
>>> and obtain the rootdse.
>> This assumes you have CA certificate available so that you can 
>> successfully verify TLS handshake. When you are enrolling a client,
>> you don't have the certificate yet.
> 
> 
> However, this does bring up one more question in mind, why would the
> initial installer care?
> 
> I mean that if the intial connection for ipa-client-install is going
> to be cleartext to what is basically an untrusted source at that point
> why not just ignore CA issues and use a TLS connection anyway? Kind of
> in the vein of the first ssh connection to a new host, the host
> presents its keys and you can choose whether to trust them or not. In
> the installers case trusting them for an anonymous bind would be just
> as safe as doing an anonymous bind without tls.
> 
> Does that make sense?

Yeah, but the stuff we're doing isn't all that critical anyway and
should be seemlessly skipped. What doesn't happen is the validation that
the remote LDAP server is an IPA server. This would only be an issue for
manual enrollments or if DNS returns the wrong records.

rob

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

Reply via email to