I’m not too concerned on the default as long as the user is warned (or even
maybe asked) at install time.
Kind regards,
Will Sheldon
+1.778-689-1244
On Monday, January 6, 2014 at 1:57 PM, Sigbjorn Lie wrote:
On 03/01/14 20:33, Stephen Ingram wrote:
On Fri, Jan 3, 2014 at 10:29 AM,
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
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
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,
On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal d...@redhat.com wrote:
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
On 01/03/2014 02:33 PM, Stephen Ingram wrote:
On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
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
On Fri, Jan 3, 2014 at 11:37 AM, Dmitri Pal d...@redhat.com wrote:
On 01/03/2014 02:33 PM, Stephen Ingram wrote:
On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal d...@redhat.com wrote:
On 01/03/2014 12:50 PM, Will Sheldon wrote:
Thanks Petr, that certainly makes sense from the point of view
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
Hi,
IPA has really been a great Project.
But, I was really concerned about the security of IPA
I have been testing it on RHEL 7 Beta for some time.
ldapsearch is able to fetch the details from the IPA Server without
Authentication.
I would appreciate if IPA team could work on securing the IPA
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
- Jitse
On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote:
It exposes the details of all the users/admins in the
10 matches
Mail list logo
