I'm back on my occasional task of trying to get the OpenLDAP backend to Samba4 going again, and was hoping to simply test out the fine work done on the vernum module. (which I should have tested at the time it was developed).
Anyway, Samba has moved on, and things have broken. Part of the changes relate to these additional DN types (found in AD), of:
#define DSDB_SYNTAX_BINARY_DN "1.2.840.113556.1.4.903" http://msdn.microsoft.com/en-us/library/ms684429%28VS.85%29.aspx
#define DSDB_SYNTAX_STRING_DN "1.2.840.113556.1.4.904" http://msdn.microsoft.com/en-us/library/ms684430%28VS.85%29.aspx
#define DSDB_SYNTAX_OR_NAME "1.2.840.113556.1.4.1221" http://archives.free.net.ph/message/20091211.162430.74b43d9e.en.html
These are quite odd in their behaivour, but in short they are both a string or binary blob and a DN, all in one. Only the DN portion is relevant for attribute matching rules.
Currently, I map these to strings, but they are not strings - and need proper DN match rules, as I need to be able to use the 'deref' module on them (and to correctly handle the case sensitive/insensitive nature of DNs).
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
(Additionally, even when just use deref with normal DNs, I'm not getting a the control response, but I need to get more info before I can pin the details down)
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
I'm back on my occasional task of trying to get the OpenLDAP backend to Samba4 going again, and was hoping to simply test out the fine work done on the vernum module. (which I should have tested at the time it was developed).
Anyway, Samba has moved on, and things have broken. Part of the changes relate to these additional DN types (found in AD), of:
#define DSDB_SYNTAX_BINARY_DN "1.2.840.113556.1.4.903" http://msdn.microsoft.com/en-us/library/ms684429%28VS.85%29.aspx
#define DSDB_SYNTAX_STRING_DN "1.2.840.113556.1.4.904" http://msdn.microsoft.com/en-us/library/ms684430%28VS.85%29.aspx
#define DSDB_SYNTAX_OR_NAME "1.2.840.113556.1.4.1221" http://archives.free.net.ph/message/20091211.162430.74b43d9e.en.html
These are quite odd in their behaivour, but in short they are both a string or binary blob and a DN, all in one. Only the DN portion is relevant for attribute matching rules.
Currently, I map these to strings, but they are not strings - and need proper DN match rules, as I need to be able to use the 'deref' module on them (and to correctly handle the case sensitive/insensitive nature of DNs).
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
(Additionally, even when just use deref with normal DNs, I'm not getting a the control response, but I need to get more info before I can pin the details down)
Thanks,
Andrew Bartlett
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
I'm back on my occasional task of trying to get the OpenLDAP backend to Samba4 going again, and was hoping to simply test out the fine work done on the vernum module. (which I should have tested at the time it was developed).
Anyway, Samba has moved on, and things have broken. Part of the changes relate to these additional DN types (found in AD), of:
#define DSDB_SYNTAX_BINARY_DN "1.2.840.113556.1.4.903" http://msdn.microsoft.com/en-us/library/ms684429%28VS.85%29.aspx
#define DSDB_SYNTAX_STRING_DN "1.2.840.113556.1.4.904" http://msdn.microsoft.com/en-us/library/ms684430%28VS.85%29.aspx
#define DSDB_SYNTAX_OR_NAME "1.2.840.113556.1.4.1221" http://archives.free.net.ph/message/20091211.162430.74b43d9e.en.html
These are quite odd in their behaivour, but in short they are both a string or binary blob and a DN, all in one. Only the DN portion is relevant for attribute matching rules.
Currently, I map these to strings, but they are not strings - and need proper DN match rules, as I need to be able to use the 'deref' module on them (and to correctly handle the case sensitive/insensitive nature of DNs).
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Andrew Bartlett
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead.
If as you say, the blob portion is irrelevant for matching, then you would just store the normalized DN portion as the attribute's normalized values, and most things that work with DNs will Just Work.
Howard Chu wrote:
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead.
I've added a SLAP_SYNTAX_DN syntax flag for this purpose. Also updated the deref overlay to use this flag instead of only checking for distinguishedName syntax.
If as you say, the blob portion is irrelevant for matching, then you would just store the normalized DN portion as the attribute's normalized values, and most things that work with DNs will Just Work.
Howard Chu wrote:
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead.
The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute.
On Sun, 2010-07-11 at 18:25 -0700, Howard Chu wrote:
Howard Chu wrote:
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead.
The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute.
So, how do I define a new syntax for this?
Andrew Bartlett
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 18:25 -0700, Howard Chu wrote:
Howard Chu wrote:
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead.
The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute.
So, how do I define a new syntax for this?
Have a look at the contributed code in ITS#6247 for an example.
http://www.openldap.org/its/index.cgi/Contrib?id=6247
Howard Chu wrote:
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead.
The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute.
This would probably be the caller's business; for example, slapo-rwm and back-meta where DN-valued (or SLAP_SYNTAX_DN_LIKE-valued) attributes are rewritten. Probably, each syntax normalizer's duty would be to isolate the DN portion and feed it to dnNormalize().
p.
p.
masarati@aero.polimi.it wrote:
Howard Chu wrote:
Andrew Bartlett wrote:
On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values?
Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted.
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits.
Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead.
The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute.
This would probably be the caller's business; for example, slapo-rwm and back-meta where DN-valued (or SLAP_SYNTAX_DN_LIKE-valued) attributes are rewritten. Probably, each syntax normalizer's duty would be to isolate the DN portion and feed it to dnNormalize().
Yes, but that's only part of it. We also need to back that into the Pretty'd value without losing the blob.
Andrew Bartlett writes:
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression...
Worse, check its usual matching rule uniqueMemberMatch: Noncommutative in X.520, pre-rfc4517 LDAP, and optionally in RFC 4517 implementations. Then filter "(uniqueMember=cn=foo)" matches "cn=foo#<any bitstring>" as well as "cn=foo", but not vice versa: "(uniqueMember=cn=foo#'10'B)" does not match "cn=foo". Unless I got that backwards, i don't remember.
So yeah, I'd say you need a new syntax or at least a new matching rule. Or revitalization of the Component Matching stuff, but I'm not volunteering...
On Mon, 2010-07-12 at 11:28 +0200, Hallvard B Furuseth wrote:
Andrew Bartlett writes:
Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression...
Worse, check its usual matching rule uniqueMemberMatch: Noncommutative in X.520, pre-rfc4517 LDAP, and optionally in RFC 4517 implementations. Then filter "(uniqueMember=cn=foo)" matches "cn=foo#<any bitstring>" as well as "cn=foo", but not vice versa: "(uniqueMember=cn=foo#'10'B)" does not match "cn=foo". Unless I got that backwards, i don't remember.
That's exactly the same semantics as DN+binary and DN+string, so it would work for me.
So yeah, I'd say you need a new syntax or at least a new matching rule. Or revitalization of the Component Matching stuff, but I'm not volunteering...
:-) I don't think I'll need that fortunately.
Andrew Bartlett
openldap-technical@openldap.org
-
Andrew Bartlett -
Hallvard B Furuseth -
Howard Chu -
masarati＠aero.polimi.it