Hi,
On 6/11/19 5:06 PM, Emmanuel Lécharny wrote:
For those of you who are not aware of those AD "peculiarities", AD
provides an somehow-standard LDAP-like schema definition. But this
leaves a lot to be desired.
Indeed. Like 'userPassword' is single-valued in AD, while it's
expected to be MultiValued per the RFCs, and many other atrocities
(aka "*Embrace, extend, and extinguish*").
In fact, userPassword is pretty much useless in AD. There is this
marvelous unicodePwd thing instead.
I would be interested about having an exhaustive description of the
differences.
E.g. AD objectclass definition for 'person' looks like this:
dn: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=evolveum,DC=com
objectClass: top
objectClass: classSchema
cn: Person
...
subClassOf: top
governsID: 2.5.6.6
mayContain: attributeCertificateAttribute
rDNAttID: cn
showInAdvancedViewOnly: TRUE
adminDisplayName: Person
adminDescription: Person
objectClassCategory: 0
lDAPDisplayName: person
name: Person
objectGUID:: /uA5AkzcX0W3/FG/QH8AFg==
schemaIDGUID:: p3qWv+YN0BGihQCqADBJ4g==
systemOnly: FALSE
systemPossSuperiors: organizationalUnit
systemPossSuperiors: container
systemMayContain: userPassword
systemMayContain: telephoneNumber
systemMayContain: sn
systemMayContain: serialNumber
systemMayContain: seeAlso
systemMustContain: cn
systemFlags: 16
defaultHidingValue: TRUE
objectCategory:
CN=Class-Schema,CN=Schema,CN=Configuration,DC=ad,DC=evolveum,D
C=com
defaultObjectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=evolveum,
DC=com
....
Completely different form. Part of the data is equivalent. But there are
extensions (e.g. showInAdvancedViewOnly). Syntaxes are all different.
Auxiliary object classes are handled in a different way (they can be
"included" in structural object class definition). Lots of subtle
differences there.
But the most annoying is objectCategory. AD obviously cannot properly
index objectClass. Therefore they have invented single-valued
objectCategory. That is the primary reason that I have bothered with this.
To be completely honest, all of this leaves quite a bad taste. I do not
want to go into all the gory details. I think I will keep the
implementation to the bare minimum to be able to survive with AD.
AFAICT, you are working in a branch, which is just fine. I don't think
the LDAP API base code will move a lot in the coming weeks, now that
we have cut a release, so you have time to do what you need and be
safe merging all of it back in master.
For now the code is in my AD connector for midPoint. That's where it is
easiest for me to have quick trial-and-error cycles, that are so
necessary whenever one works with AD. Once I'm OK with the code I'll
move it to Directory API. But that will take several weeks/months.
Current structure of Directory API, especially the schema-processing
parts (SchemaLoader, SchemaManager) is not ideal for this particular
kind of abominations.
trudat. I saw that you made it extensible, which is a sane decision.
May be creating an abstract classin the middle would make sense, I
don't know. Or a factory ?
I do not know yet. Honestly, I'm not sure that I completely understand
current purpose of SchemaLoader/SchemaManager and how the
responsibilities are split between them. E.g. it looks like the design
is based on assumption that all the schemas will be in RFC4512 format
(or something very similar). Which obviously does not fit AD schemas.
But I'm not sure. I think I need more experience with the code to
understand it. Maybe more experiments. And I also have almost zero
understanding how all of that fits into the server. That is also the
reason why I've done only a very minimal changes. I do not want to ruin
original design just because I do not understand it yet.
I think that rethinking the design after you are done would benefit
from your experience.
Maybe later. Now I feel that my experience is not sufficient for this.
Actually, decoupling the API from MINA will be quite difficult. We can
discuss that further, but the main issues are :
Yes. That is something we need to discuss later. The primary problem
with MINA is its complexity. E.g. it makes it very inconvenient to use
Directory API in simple apps, because even the basic usage of the API
creates a lot of threads. And then it is a complete nightmare to
diagnose and fix issues, e.g. the recent issue with the bind. Such
things should be easy on the client. But they are not. I understand,
that there is a need for some of that complexity on server side. But
maybe, if we can make the "networking underside" pluggable, then we can
have MINA on the server and something simpler on the client. But that is
also something that needs to wait a bit. One problem at a time ...
--
Radovan Semancik
Software Architect
evolveum.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
