Proper Approach to Extending LDAP Schema for GPC Storage in FreeIPA

[Sam Morris]

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.

[Alexander Bokovoy]

On Пан, 10 сак 2025, Данила Скачедубов via FreeIPA-users wrote:
> 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?

organizationalUnit is part of RFC 4519 (section 3.11).

You should never modify existing object classes, especially if they
are part of the LDAP specification and created well before your
solution. So the approach (2) is what should be used, in my opinion.

If FreeIPA ever starts using organizationalUnit itself, we definitely
will not be modifying its object class as well.