On Mon, 2017-11-13 at 10:34 +0100, Jan Kowalsky wrote:
thanks a lot for clearing.
Sorry for the very late response! I have been quite busy :(
Am 13.11.2017 um 00:42 schrieb William Brown:
> On Sun, 2017-11-12 at 23:06 +0100, Jan Kowalsky wrote:
> > On some comments I read that it's generally discouraged to use
> > aci's
> > with a "not" logic like:
> > ip != 10.0.0.*
> > or something like this.
> The != is only an issue for targetattr, because if you do:
> targetattr != sn
> Then this includes all system attributes like nsACcountlock and
> resource limit types etc.
> IP addr != is fine :)
> > As long as I understood, I have to define aci's for every base dn
> > separately if I running multiple databases. Is there any way to
> > define
> > this for the whole server?
> If you have the databases nested IE:
> And in the mapping tree these are marked as "parent", then the aci
> dc=example,dc=com should apply to ou=foo too.
ok. So for me it doesn't work. The databases are completely
Then you can't share aci's sorry :( This is just a reality of how our
> Generally, I would look at:
> IP address based security is not a good control: You should be
> other factors and information to provide access I think. You could
> limit admins to using TLS user certs for identity rather than
> passwords, using minssf rules, longer password policy, etc.
The ip based access control in my setting is only to give a
control beside the firewall. The Directory should not to be
from public internet at all. But for the case there is any error on
firewalling I want to protect the whole directory. Other access
are more granular.
Why not limit this based on iptables *and* your routers instead? That
would be a more effective control I think than ip based access
Additionally, another option is remove anonymous binds (or heavily
limit anonymous access), and use service accounts for applications to
read attributes that they require? This could be more effective than IP
controls, because when you think about an attacker, they don't just go
"from internet to ldap". They'll have poped a box on your network
internally, so the exfiltration route is:
ds -> poped internal box -> internet.
So your internet controls won't help here, because your ds is talking
*internally*. Better option is limit based on service accounts and
privilege than IP.
I really hope this advice helps,
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
Red Hat, Australia/Brisbane