[389-devel] [PATCH] Add require secure binds switch.

[Nathan Kinder]

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
>