Joseph Fry via FreeIPA-users wrote:
> On ti, 20 heinä 2021, Joseph Fry via FreeIPA-users wrote:
>
> Regardless what compatibility plugin represents, the resulting entries
> are processed by 389-ds LDAP server core. They have to follow the logic
> and rules defined in 389-ds.
>
> As Rob said, defining an object class for 'computer' is the only option.
> There is another one, of course, to relax schema checks in the whole
> 389-ds, but it would mean eventually breaking the consistency of this
> deployment as other schema violations would not be detected.
>
> Filing a feature request to 389-ds will not help. They have spent
> several years going into the opposite direction and enforcing the schema
> everywhere.
Thank you Alexander.
Can anyone provide an example of an update file that adds an objectclass to the schema.
I find tons of examples using .ldif files, but I am hoping to make this a one file
solution.
I would really rather not define the attributes for the new objectclasses, I assume there
is a way to make it an extensible objectclass or something similar?
I didn't search particularly hard for what the AD Computers objectclass
is supposed to look like but I think I found the OID anyway. Something
like this is a bare-bones representation that *might* work. It's
basically untested other than it didn't burn down my IPA install:
dn: cn=schema
add: objectClasses: (1.2.840.113556.1.3.30 NAME 'Computers' DESC 'AD
Computers' SUP top MAY (cn))