[Freeipa-users] MinSSF suggestions?

[Erinn Looney-Triggs]

On Wednesday, August 13, 2014 08:57:19 PM Rob Crittenden wrote:
> 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

Yeah I understand that, the stuff that you folks are doing I was not too 
concerned about. This whole thought process started because I was looking at 
the IDM manual and under the disabling anonymous bind section it had an 
ldapmodify command using the directory manager's credentials that were being 
sent in the clear. I filed a bug, it'll be fixed, but it got me thinking about 
how to protect folks from themselves and thus minssf.

Anyway, there seem to be good reasons that things are as they are, maybe in 
you know, five years, when RHEL 5 goes away, this can be revisited.

-Erinn 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140814/68501d60/attachment.sig>