Hi all,
after reading post on the lists regarding acis I was wondering what will be the preferred way to only grant access to the directory for hosts in the own network.
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.
Does this apply to ip address based access too?
My approach would be just someting like:
aci: (targetattr = "*") (version 3.0;acl "Bind from special IPs only";deny (all) (ip != "192.168.100.*" and ip != "10.0.0.*);)
do allow only from 192.168.100.* networks or from 10.0.0.*.
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?
Thanks and Regards Jan
On Sun, 2017-11-12 at 23:06 +0100, Jan Kowalsky wrote:
Hi all,
after reading post on the lists regarding acis I was wondering what will be the preferred way to only grant access to the directory for hosts in the own network.
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 :)
Does this apply to ip address based access too?
My approach would be just someting like:
aci: (targetattr = "*") (version 3.0;acl "Bind from special IPs only";deny (all) (ip != "192.168.100.*" and ip != "10.0.0.*);)
do allow only from 192.168.100.* networks or from 10.0.0.*.
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.
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.
Hope that helps,
Hi William,
thanks a lot for clearing.
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.
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.
Regards Jan
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
389-users@lists.fedoraproject.org
-
Jan Kowalsky -
William Brown