On Mon, 2017-11-13 at 10:34 +0100, Jan Kowalsky wrote: > Hi William, > > 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: > > > > dc=example,dc=com > > ou=foo,dc=example,dc=com > > > > And in the mapping tree these are marked as "parent", then the aci > > of > > dc=example,dc=com should apply to ou=foo too. > > ok. So for me it doesn't work. The databases are completely > separeted. Then you can't share aci's sorry :( This is just a reality of how our aci's operate. > > > Generally, I would look at: > > > > https://research.google.com/pubs/pub43231.html > > > > IP address based security is not a good control: You should be > > using > > 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 > additionally > control beside the firewall. The Directory should not to be > accessible > from public internet at all. But for the case there is any error on > firewalling I want to protect the whole directory. Other access > rights > 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 controls. 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, > > Regards > Jan > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
