On 01/03/2014 12:50 PM, Will Sheldon wrote: > Thanks Petr, that certainly makes sense from the point of view of > functionality. > > I do think the default is sane, but there are a lot of possible > deployment scenarios and my concern is that a junior or time poor > admin looking to implement a trusted, secure solution should be made > aware of any potential data leakage during configuration, (preferably > in big red letters in the documentation, or better still, the install > script). > > Though I am reluctant to draw comparisons between IPA and MS AD they > do seem inevitable. AD restricts anonymous binds to the rootDSE entry > by default and as such this may be considered by many to be the > expected default. Extra care should therefore be made to point out > this difference. To do otherwise risks undermining the confidence of > users in the security of the solution.
It is a double edge sword. We compared IPA to LDAP based solutions and with those you have (had) anonymous bind enabled by default. IMO it is the question of a migration. The field of centralized authentication is crowded with all sorts of different solutions, though not that integrated as AD or IdM. It seems that migrating and then tightening security to the level you need is the way to go. The default you suggest might be a barrier to migration as people usually tackle problems one step at a time. I am not against changing the default eventually but I am not sure it is the time to. But may be I am wrong. Are there any opinions on the matter? > > > > On Fri, Jan 3, 2014 at 4:53 AM, Petr Viktorin <pvikt...@redhat.com > <mailto:pvikt...@redhat.com>> wrote: > > On 01/03/2014 02:23 AM, Will Sheldon wrote: > > > This is cause for concern. Is there a hardening / best > practices for > production guide anywhere, did I miss a section of the > documentation? > > What else do I need to secure? > > I understand that there is a tradeoff between security and > compatibility, but maybe there should be a ipa-secure script > somewhere? > > > We are working on making the read permissions granular, so you can > make your own tradeoffs if IPA defaults aren't appropriate for > your use. > > The work is tracked in > https://fedorahosted.org/freeipa/ticket/3566 and linked tickets > 4032-4034. > > On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp > <jitsekl...@gmail.com <mailto:jitsekl...@gmail.com> > <mailto:jitsekl...@gmail.com <mailto:jitsekl...@gmail.com>>> > wrote: > > It is possible to disable anonymous binds to the directory > server. > Take a look at > > > https://docs.fedoraproject.__org/en-US/Fedora/18/html/__FreeIPA_Guide/disabling-anon-__binds.html > > > > > <https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html> > > - Jitse > > > > On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: > > It exposes the details of all the users/admins in the > environment. > There should be a user that the IPA should use to > fetch the > details from > the IPA Servers. Without Authentication , no one > should be able > to fetch > any information from the IPA Server. > > > > -- > Petr³ > > > _______________________________________________ > Freeipa-users mailing list > Freeipaemail@example.com <mailto:Freeipafirstname.lastname@example.org> > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > > Kind regards, > > Will Sheldon > +1.(778)-689-4144 > > > _______________________________________________ > Freeipa-users mailing list > Freeipaemail@example.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users