Thank you for your response. I would like to clarify my approach. My goal is to extend the organizationalUnit class by adding custom attributes, such as customAttribute and a few others, as follows:
objectclasses: ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou MAY ( businessCategory $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationalISDNNumber $ l $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ searchGuide $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ userPassword $ x121Address $ customAttribute ) X-ORIGIN ( 'Custom Modification' 'user defined' ) )
I am not expecting FreeIPA to interact with or recognize these modifications. Instead, I am developing a separate application that will work directly with this structure in the LDAP database.
However, my main concern is whether FreeIPA might, under certain circumstances, reset the schema to its defaults, potentially removing my custom attributes. Additionally, I am wondering if the organizationalUnit class is used in critical FreeIPA operations, such as trust relationships with Active Directory (AD) or other built-in functions.
Given these concerns, would it be more architecturally sound to:
1. Extend the existing organizationalUnit class as I have done above, or
2. Create a new object class with SUP organizationalUnit to avoid interfering with the standard schema?
I would greatly appreciate any insights or best practices regarding this approach.
Best regards,
Daniel
----------------
Кому: [email protected] ([email protected]);
Копия: Sam Morris ([email protected]);
Тема: [Freeipa-users] Re: Proper Approach to Extending LDAP Schema for GPC Storage in FreeIPA;
05.03.2025, 19:24, "Sam Morris via FreeIPA-users" <[email protected]>:
On 05/03/2025 12:47, Данила Скачедубов via FreeIPA-users wrote:
I am trying to replicate the Organizational Unit (OU) structure similar
to Samba in my LDAP database by adding attributes such as
distinguishedName, gPLink, and others. Using ldapmodify, I was able to
add these attributes to the organizationalUnit object class, and with
ldapadd, I successfully created instances of this class.
However, I would like to ask what potential consequences I might have
overlooked after modifying this object class. Could someone advise on
whether this approach is appropriate, or suggest a more architecturally
sound way to extend the LDAP schema for storing Group Policy Container
(GPC) information?--
FreeIPA doesn't use the organizationalUnit object class. It uses the
nsContainer object class. These are created in a fixed structure, each
of which will contain all the entries of a particular class in a flat list.
e.g., all users live exactly one level beneath the
"cn=users,cn=accounts,dc=example,dc=com" entry.
I don't follow exactly what modifications you made to your directory
(did you modify the schema, to add additional required or optional
attributes to the objectClasses attribute for organizationalUnit?) - but
I would guess that FreeIPA will ignore them, since it doesn't create any
organizationalUnit classes itself.
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
