Hello
As far as I know, it is not possible to match an IP subnet. For instance, if I have an object like this:
dn: cn=foo,o=example managedAddr: 192.0.2.0/24
And this kind of thing does not seems available: ldapsearch 'managedAddr:addressInSubnetMatch:=192.0.2.1'
I can think of a few useful matching rules: addressInSubnetMatch subnetInSubnetMatch subnetContainsSubnetMatch subnetContainsAddressMatch subnetExactMatch (192.0.2.5/24 and 192.0.2.10/24 are the same)
Questions: - can someone confirm this cannot be done yet? - is there a RFC to implement that does this? Or should I start with what I have though about and presented above? - is this functionnality welcome? - where do I start to implement it? The thing happen in schema_init.c and schema_prep.c, but I need to select an OID. How?
The motivation is DNS configuration stored in LDAP. That feature could enable the delegation of subnet management to different administrators, the access being enforced by slapd ACL.
Emmanuel Dreyfus writes:
As far as I know, it is not possible to match an IP subnet. For instance, if I have an object like this: dn: cn=foo,o=example managedAddr: 192.0.2.0/24
And this kind of thing does not seems available: ldapsearch 'managedAddr:addressInSubnetMatch:=192.0.2.1'
Remember that even if it were, OpenLDAP does not support indexing for such filters. So each search would have to inspect every IP-subnet entry in scope.
That's another thing which would be quite nice if someone implemented someday: Indexing for extended filters. Not me though...
- can someone confirm this cannot be done yet?
It can't.
- is there a RFC to implement that does this? Or should I start with
what I have though about and presented above?
I would google around for ldap ip ranges and also look for Microsoft syntax/mathing rules first. No need to be different from them if they already have sensible definitions. (Except it might still be best to use our own OIDs; proprietary syntaxes/rules may be changed at any time.)
RFC 2307 has some IP address attributes, but not useful to search for ranges and subnets.
- is this functionnality welcome?
Well, we'd use it at our site - at least what supports indexing.
- where do I start to implement it? The thing happen in schema_init.c
and schema_prep.c, but I need to select an OID. How?
OpenLDAP has an experimental OID arc, but I don't know where to see which ones are used.
The motivation is DNS configuration stored in LDAP. That feature could enable the delegation of subnet management to different administrators, the access being enforced by slapd ACL.
At our site we store IP ranges as two integer attributes (start, end), and put an equality index on these attributes. In 2.4, equality index for integers also supports inequality filters <= and >=, so we can do an indexed search for (&(ipRangeStart<=value)(ipRangeEnd>=value)).
That doesn't allow us to have two IP ranges in the same LDAP entry though.
An alternative would be to use binary representation and substring match, but this strikes me as somewhat suboptimal:-)
BTW, one point to keep in mind: What do IP ranges look like in IPv6?
Hallvard B Furuseth wrote:
Emmanuel Dreyfus writes:
As far as I know, it is not possible to match an IP subnet. For instance, if I have an object like this: dn: cn=foo,o=example managedAddr: 192.0.2.0/24
And this kind of thing does not seems available: ldapsearch 'managedAddr:addressInSubnetMatch:=192.0.2.1'
Remember that even if it were, OpenLDAP does not support indexing for such filters. So each search would have to inspect every IP-subnet entry in scope.
That's another thing which would be quite nice if someone implemented someday: Indexing for extended filters. Not me though...
Ugh...
- where do I start to implement it? The thing happen in schema_init.c
and schema_prep.c, but I need to select an OID. How?
OpenLDAP has an experimental OID arc, but I don't know where to see which ones are used.
http://www.openldap.org/faq/data/cache/197.html
But I'm not convinced this is useful core functionality, which is why I suggested using your own registry for now.
Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:
Remember that even if it were, OpenLDAP does not support indexing for such filters. So each search would have to inspect every IP-subnet entry in scope.
Even if indexing is not available, the feature would still be useful for ACL.
BTW, one point to keep in mind: What do IP ranges look like in IPv6?
Same look: address "/" prefix IPv6 addresses contain ":", prefixes are from 0 to 128 IPv4 addresses contain ".", prefixes are from 0 to 32.
Emmanuel Dreyfus wrote:
Hello
As far as I know, it is not possible to match an IP subnet. For instance, if I have an object like this:
dn: cn=foo,o=example managedAddr: 192.0.2.0/24
And this kind of thing does not seems available: ldapsearch 'managedAddr:addressInSubnetMatch:=192.0.2.1'
I can think of a few useful matching rules: addressInSubnetMatch subnetInSubnetMatch subnetContainsSubnetMatch subnetContainsAddressMatch subnetExactMatch (192.0.2.5/24 and 192.0.2.10/24 are the same)
Questions:
- can someone confirm this cannot be done yet?
- is there a RFC to implement that does this? Or should I start with
what I have though about and presented above?
- is this functionnality welcome?
- where do I start to implement it? The thing happen in schema_init.c
and schema_prep.c,
No, just write it as a loadable module.
but I need to select an OID. How?
Same way anyone else does. Register an OID for your organization and manage it as you see fit.
The motivation is DNS configuration stored in LDAP. That feature could enable the delegation of subnet management to different administrators, the access being enforced by slapd ACL.
Subnets and DNS domains are quite distinct and don't map directly onto each other. I don't think you've presented a clear case for (or even a clear description of) this functionality yet.
In my own domain-based directories I simply use the DN hierarchy:
dc=doubleclick,dc=net,ou=spam,dc=highlandsun,dc=com dc=73,dc=216,dc=in-addr,dc=arpa,ou=spam,dc=highlandsun,dc=com
etc...
A lookup for 216.73.86.10 will return NoSuchObject with MatchedDN = dc=73,dc=216,... and a lookup of that MatchedDN gives me the info I need.
Howard Chu hyc@symas.com wrote:
In my own domain-based directories I simply use the DN hierarchy:
dc=doubleclick,dc=net,ou=spam,dc=highlandsun,dc=com dc=73,dc=216,dc=in-addr,dc=arpa,ou=spam,dc=highlandsun,dc=com
How do you get that working with BIND, for instance? The schema is there: http://www.venaas.no/ldap/bind-sdb/dnszone-schema.txt
Exemple: dn: relativeDomainName=host,o=home objectClass: dNSZone relativeDomainName: host zoneName: example.net dNSClass: IN aRecord: 192.0.2.3
dn: relativeDomainName=3,zoneName=2.0.192.in-addr.arpa,o=home objectClass: dNSZone relativeDomainName: 3 zoneName: 2.0.192.in-addr.arpa dNSClass: IN pTRRecord: host.example.net.
Currently, we have everything needed to setup an ACL so that John Doe can only set a pTRRecord within *.sales.example.net. One just have to setup a val.regex ACL.
But there is no way to tell that he can only set a pTRRecord within 192.0.2.128/25, therefore my inquiry on that topic.
Emmanuel Dreyfus manu@netbsd.org wrote:
dn: relativeDomainName=host,o=home objectClass: dNSZone relativeDomainName: host zoneName: example.net dNSClass: IN aRecord: 192.0.2.3
The DN was wrong (but that does not change the overall picture):
dn: relativeDomainName=host,zoneName=example.net,o=home objectClass: dNSZone relativeDomainName: host zoneName: example.net dNSClass: IN aRecord: 192.0.2.3
Emmanuel Dreyfus wrote:
Howard Chuhyc@symas.com wrote:
In my own domain-based directories I simply use the DN hierarchy:
dc=doubleclick,dc=net,ou=spam,dc=highlandsun,dc=com dc=73,dc=216,dc=in-addr,dc=arpa,ou=spam,dc=highlandsun,dc=comHow do you get that working with BIND, for instance? The schema is there: http://www.venaas.no/ldap/bind-sdb/dnszone-schema.txt
I use my own schema and adapter code. Anything that maps hierarchical data onto LDAP without taking advantage of LDAP's hierarchy is inherently broken, IMO...
Exemple: dn: relativeDomainName=host,o=home objectClass: dNSZone relativeDomainName: host zoneName: example.net dNSClass: IN aRecord: 192.0.2.3
dn: relativeDomainName=3,zoneName=2.0.192.in-addr.arpa,o=home objectClass: dNSZone relativeDomainName: 3 zoneName: 2.0.192.in-addr.arpa dNSClass: IN pTRRecord: host.example.net.
This would instead look something like
dn: dc=host,dc=example,dc=net,o=home objectClass: dnsZone dc: host dnsClass: IN aRecord: 192.0.2.3
dn: dc=3,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa,o=home objectClass: dnsZone dc: 3 dnsClass: IN ptrRecord: host.example.net
Currently, we have everything needed to setup an ACL so that John Doe can only set a pTRRecord within *.sales.example.net. One just have to setup a val.regex ACL.
value-based ACLs are fairly expensive. This should just be access to dn.sub="dc=sales,dc=example,dc=net,o=home" by foo ... which is cheap...
But there is no way to tell that he can only set a pTRRecord within 192.0.2.128/25, therefore my inquiry on that topic.
And as I said before, subnets and domains are orthogonal. There is nothing in DNS to accommodate subnet notation, so you're still on your own here. A regex would probably be the best bet. Using hexadecimal RDNs would simplify things too.
dn: dc=03,dc=02,dc=00,dc=c0,dc=in-addr,dc=arpa,o=home
access to dn.regex="dc=[89abcdef].,dc=02,dc=00,dc=c0,dc=in-addr,dc=arpa,o=home" by foo ...
Howard Chu hyc@symas.com wrote:
I use my own schema and adapter code.
Is that published somewhere?
On Sun, 16 Nov 2008, Howard Chu wrote:
But there is no way to tell that he can only set a pTRRecord within 192.0.2.128/25, therefore my inquiry on that topic.
And as I said before, subnets and domains are orthogonal. There is nothing in DNS to accommodate subnet notation, so you're still on your own here. A regex would probably be the best bet. Using hexadecimal RDNs would simplify things too.
dn: dc=03,dc=02,dc=00,dc=c0,dc=in-addr,dc=arpa,o=home
access to dn.regex="dc=[89abcdef].,dc=02,dc=00,dc=c0,dc=in-addr,dc=arpa,o=home" by foo
This might be a situation where you could steal some of the ideas from RFC2317 so as to avoid the expensive ACL. Consider the example:
$ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) ;... ; <<0-127>> /25 0/25 NS ldap1-name.server. 0/25 NS ldap2-name.server. ; 1 CNAME 1.0/25.2.0.192.in-addr.arpa.
then just configure ldap{1,2}-name.server with a comparatively cheap
access to dn.subtree="dc=0/25,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa,o=home" ...
The downfall (to my reading) is that you won't actually *stop* somebody from writing, say, 195.2.0.192.in-addr.arpa. to that subtree. But there's only so many stupid user tricks you can avoid, and it's got to be a lot easier on administration than the long regexps.
-
Aaron Richton -
Hallvard B Furuseth -
Howard Chu -
manu＠netbsd.org