Hi Brian,
On 07/11/2019 06:01, Brian Burch wrote:
On 6/11/19 8:03 pm, Emmanuel Lécharny wrote:
Hi Brian,
Hi Emmanuel. I thought you would be too busy for more than a one-line
response. It's really nice to know my question interested you
sufficiently to be a bit chatty. Please forgive me for taking this
opportunity to continue the discussion...
just FTR, the ads-contextentry configuration element contains the
partition context entry (doh !) :
Yes, I thought you realised I knew that from the way I framed my
question.
Sure I did. The 'doh' was just me sounding like 'doctor obvious'.
ads-contextentry::
ZG46IGRjPWV4YW1wbGUsZGM9Y29tCmRjOiBleGFtcGxlCm9iamVjdGNsY
XNzOiBkb21haW4Kb2JqZWN0Y2xhc3M6IHRvcAoK
translates to :
dn: dc=example,dc=com
dc: example
objectclass: domain
objectclass: top
when you decode the base64 value.
My cribs work the example partition hash backwards, forwards, via
strings and files, just to prove I am deeply paranoid!
Just to be clear: base64 is not a hash, it's a 6 bits encoding of a 8
bits byte array. That makes the string acceptable by limiting the used
characters to [a-zA-Z0-9+/=], which is 26 + 26 + 10 + 2 ascii chars. '='
is used as a padding.
So the deal here is really to *convert* the contextEntry LDIF to a
single line of base64 encoded String that can be injected in the LDIF
configuration file. Just wanted to be clear for the users list members.
Note that regardless of the change, the server will accept both
entries and will work fine.
I had not realised that!
I was obsessed with matching the auto-generated hash, rather than
making any "grand circuit" of possible failure conditions.
Without having time to dig into the code, I'm somewhat intrigued by
your comment. I guess it de-hashes the four elements and then compares
them separately in order of occurrence. (Maybe a StringTokenizer with
NL tokens fed into a small hash table?)
Actually, we use a LDIF reader to process the decoded base64 value. So
the process is :
configurationReader : read the ads-contextentry value (ZG46IGRjPWV...)
- decode the value into a string ("ZG46IGRjPWV..." -> "dn:
dc=example,dc..." )
- parse the decoded value
- add it in the server if it's nor already present.
The LDIF parser accepts pretty much anything that is LDIF compliant, and
there are a few constraints :
- the DN always has to come first
- all the following attributes are considered as a set of
<attributeType, value>, there is no order requirement. You can have
something like :
dn: dc=example,dc=com
objectclass: domain
dc: example
objectclass: top
it will be accepted and processed the exact same way as
dn: dc=example,dc=com
dc: example
objectclass: domain
objectclass: top
Internally, we do lookups on the attributes ("fetch the 'objectClass'
attribute's values" -> 'top', 'domain' ) because those attributes are
stored in a java Map.
Now, if you want to generate the proper Base64 encoding from a LDIF
entry, I suggest you use a tool like https://www.base64encode.org/,
where you can copy/paste the entry and encode it (be aware that
spaces or NL at the end of the file will also be translated). You
will then just have to copy/paste the result into the
ads-contextentry attribute.
I hit issues with base64 because it is limited to a length of 64 byes
and this messed up the output hashes.
I switched to openssl with the -A parameter, which happily encodes
longer strings. It works fine (and is available to windoze users), so
I prefer to stick with it.
That's fine. Whatever works.
The reason we store the entry base 64 encoded is because it will
contain NL, and that will not fit well with the containing LDIF file.
For instance, using that :
ads-contextentry: dn: dc=example,dc=com
dc: example
objectclass: top
objectclass: domain
will simply not work, as the configuration reader will not be able to
understand what these "dc" and "ObjectClass" lines are good for...
I hope I clarified this part of the configuration...
I sort-of understand what you mean, but probably have enough other
headaches to let that issue slip slightly hazily past me!
HOWEVER...
I /still/ don't know which elements of my "old school" directory root
need to be hashed to generate an acceptable ads-contextentry value!
The top level entry is the one to encode (not hash).
On 06/11/2019 10:36, Brian Burch wrote:
Emmanuel helped me a lot when I added the new section to the wiki
more than 2 years ago. The users mailing list thread carried the
subject "ApacheDS 2.0.0-M23 non-gui adding a partition".
<snip/>
The top entry looks like this:
dn: O=PingToo.com
objectclass: top
objectclass: organization
o: PingToo.com
Obviously, the order of these attributes and also the exact use of
letter case (and any white space ) will alter the resultant
ads-contextentry hash.
Q1: I guess I can use the dn and objectclass top lines as-is.
DN first. Otherwise, everything the comes after, at your convenience. We
usually put the ObjectClass first like we put java declaration first in
a class: it's candy to the eye, but irrelevant for the computer - unlike
in Pascal ! -
Q2: Can I use the o value for my ads-partitionid (I think the answer
is yes).
Yes, the answer is yes. But be aware that you need to use an ObjectClass
that has this 'o' attributeType in its MUST or MAY requirements. The
'domain' ObjectClass meets this requirement :
objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain'
SUP top
STRUCTURAL
MUST dc
MAY ( associatedName $ o $ description $ businessCategory $ seeAlso
$ searchGuide $ userPassword $ l $ st $ street $
physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox
$ facsimileTelephoneNumber $ internationaliSDNNumber $ telephoneNumber $
teletexTerminalIdentifier $ telexNumber $ preferredDeliveryMethod $
destinationIndicator $ registeredAddress $ x121Address ) )
Note that you outgh to add a 'dc' as it's mandatory. Last, not least, if
you decide to go with a DN like "o=acme, dc=com", then you must have the
"o: acme" in the list of attributes.
dn: o=acme,dc=com
objectclass: top
objectclass: domain
dc: whatever
o: acme
works but :
dn: o=acme,dc=com
objectclass: top
objectclass: domain
dc: whatever
will not (missing o: acme). Not will :
dn: o=acme,dc=com
objectclass: top
objectclass: domain
o: acme
because the mandatory ('MUST') 'dc' attribute is missing.
Q3: [Your previous advice implied all 4 lines were required to have
the example partition created]. What should I do with my objectclass
organization line? Should it be changed to "domain", left as-is, or
simply eliminated?
So that is a different things. Would you decide to use 'organization'
objectClass instead of 'domain', then your context entry would have to
look like :
dn: o=acme,dc=com
objectclass: top
objectclass: organization
o: acme
No 'dc', because the 'Organization' objectClass does not require it :
objectclass ( 2.5.6.4 NAME 'organization'
DESC 'RFC2256: an organization'
SUP top
STRUCTURAL
MUST o
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description ) )
As you can see, an attributeType (like 'o') can be used by many
ObjectClasses (here, 'domain' and 'organization', but many oithers too -
'account', 'i,nterOrgPerson', etc...)
Any enlightenment would be very welcome!
Merci d'avance (sorry, that sounds less polite to me than the English
"Thanks in anticipation"),
'Merci d'avance' is perfect. It means exactly what it it is : I need
assistance, and I thank you for providing some, regardless of the delay
to do so!
That's always a pleasure to have such a nice technical conversation with
you, Brian. You are a gentleman !
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
