[389-devel] [PATCH] Add require secure binds switch.
Nathan Kinder
nkinder at redhat.com
Fri May 29 18:15:01 UTC 2009
Rich Megginson wrote:
> Nathan Kinder wrote:
>> Nathan Kinder wrote:
>>> Nathan Kinder wrote:
>>>> Andrey Ivanov wrote:
>>>>>
>>>>> Does it mean that when "nsslapd-require-secure-binds" is "on" then
>>>>> even the anonymous binds should be made by SSL? Maybe there is
>>>>> some sense in leaving a possibility to have anonymous binds
>>>>> non-SSL and frocing non-anonymous ones to be secure?
>>>> Sorry for the late response, but I was on vacation the last week.
>>>>
>>>> The current patch does force all simple binds, including anonymous,
>>>> to use a secure connection. I can see value in allowing anonymous
>>>> simple binds over an unencrypted connection, as the main reason for
>>>> this new setting is to prevent clear text transmission of
>>>> passwords. I will revise the patch to ignore anonymous binds when
>>>> nsslapd-require-secure-binds is on unless anyone else has arguments
>>>> otherwise.
>>> A new patch with the above change is attached.
>> After some discussion with Rich, we determined that a change to the
>> patch was necessary with regards to the way unauthenticated binds are
>> treated. The attached patch treats unauthenticated binds the same as
>> anonymous binds (assuming that they are allowed in the config). This
>> means that the new setting to require secure binds will not affect
>> unauthenticated binds or anonymous binds.
>>
>> The patch also fixed a typo in one of the new log messages.
> Ok.
Pushed to master.
>>>>
>>>> There are a number of other security related configuration settings
>>>> that I plan to add soon, which will provide other ways of dealing
>>>> with restricting anonymous operations. One of these features are a
>>>> switch to disable any anonymous operations completely. Another is
>>>> to have a minimum SSF setting on the server. The only operation we
>>>> would allow after first connecting over plain LDAP would be
>>>> startTLS. If the SSF then meets the minimum requirement, other
>>>> operations would be allowed.
>>>>>
>>>>> 2009/5/15 Rich Megginson <rmeggins at redhat.com
>>>>> <mailto:rmeggins at redhat.com>>
>>>>>
>>>>> Nathan Kinder wrote:
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> --
>>>>> Fedora-directory-devel mailing list
>>>>> Fedora-directory-devel at redhat.com
>>>>> <mailto:Fedora-directory-devel at redhat.com>
>>>>>
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>>>
>>>>> Looks good.
>>>>>
>>>>> --
>>>>> Fedora-directory-devel mailing list
>>>>> Fedora-directory-devel at redhat.com
>>>>> <mailto:Fedora-directory-devel at redhat.com>
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> --
>>>>> Fedora-directory-devel mailing list
>>>>> Fedora-directory-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>>>
>>>>
>>>> --
>>>> Fedora-directory-devel mailing list
>>>> Fedora-directory-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> --
>>> Fedora-directory-devel mailing list
>>> Fedora-directory-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>
>> ------------------------------------------------------------------------
>>
>> --
>> Fedora-directory-devel mailing list
>> Fedora-directory-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-devel mailing list
> Fedora-directory-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
More information about the 389-devel
mailing list