Hi Dmitri,

On Sun, Mar 18, 2012 at 5:41 PM, Dmitri Pal <d...@redhat.com> wrote:

> **
> On 03/18/2012 08:59 AM, Marco Pizzoli wrote:
>
> Hi Simo,
>
> On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce <s...@redhat.com> wrote:
>
>>  On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote:
>> > Hi guys,
>> >
>> > I extended my set of LDAP objectClasses associated to users by adding
>> > my new objectClass to my cn=ipaConfig LDAP entry, the
>> > ipaUserObjectClasses attribute.
>> > Then, I created a new user with the web ui and I see the new
>> > objectClass associated with that user, but as structural instead of
>> > auxiliary. I don't know why, could you help me?
>> >
>> > Same thing happened for my groups. I added 3 objectClasses and now I
>> > see all of them as structural. I would understand an answer: all
>> > objectClasses eventually result as structural, but so why, for
>> > example, the ipaObject is still an auxiliary objectClass?
>>
>>  The objectClass type depends on the schema. It is not something that
>> changes after you assign it to an object.
>>
>
> Yes, your answer surely does make sense.
>
> My question was triggered by the fact that, AFAICS, not all objectClasses
> are structural as well.
> In fact I can see that, for my group object, the objectClass "ipaobject"
> has been defined as auxiliary, while others structural.
> For users, I see that *only my objectClass* is defined as structural. All
> others as auxiliary.
>
> In attachment you can see 2 images that immediately represent what I'm
> trying to explain.
>
> If this was the intended behaviour, I would be really interested in
> knowing what is the rationale behind this.
> Only curiousity, as usual :-)
>
> Thanks again for your patience!
>
>
> AFAIU the object classes that are added to users and groups need to be
> first defined in the schema.
> I assume you have done so otherwise all sorts of errors would have shown
> up. Am I correct?
>

Exact. I followed the instructions on extending the schema on 389-ds, by
inserting a file in my /etc/dirsrv/<instance>/schema dir.
Everything went ok, and I can see from phpldapadmin that the DSA correctly
present my objectClasses as available to use for extending objects.


> I do not recognize the object classes as standard object classes. But
> might knowledge might be limited.
>

Exact, they are "mine" objects, under a reserved OID number.


>  Can you put show how you defined these new object classes in schema? You
> might have not specified the type and it defaulted to structural.
>

This was a schema file created for OpenLDAP and which is currently in
production.
I used the script posted on the 389-ds HowTo for the migration from
OpenLDAP schema files to 389-ds format.
Here you can find it. A little camouflated, of course.

[root@freeipa01 ~]# cat
/etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif
dn: cn=schema
attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.4 NAME 'xxxUfficio' DESC 'Ufficio
di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' SUP
top AUXILIARY DESC 'Definizione di attributi specifici per gli utenti XXX'
MAY (  xxxUfficio ))
attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.1 NAME 'xxxProgetto' DESC 'Nome
del macro-progetto associato a questo gruppo LDAP' EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.2 NAME 'xxxAmbiente' DESC 'Nome
di ambiente SVIL-TEST-VALID-PROD associato al progetto' EQUALITY
caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications
)
attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.5 NAME 'xxxTipoGruppo' DESC
'Tipologia di gruppo' EQUALITY caseIgnoreMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' SUP
top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi XXX'
MAY (  xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ))
attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.6 NAME 'xxxWebminAmbiente' DESC
'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' SUP
top AUXILIARY DESC 'Definizione di attributi specifici per gli oggetti
Webmin' MAY (  xxxWebminAmbiente ))
attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.3 NAME 'xxxDB2GruppiPrivilegi'
DESC 'Tipologia di gruppo creato per accesso al DB2' EQUALITY
caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications
)
objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME 'xxxDB2GroupsAttributes'
SUP top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi
DB2' MAY (  xxxDB2GruppiPrivilegi ))
objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' SUP top
AUXILIARY DESC 'Definizione di attributi specifici per utilizzo interno'
MAY (  xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ xxxDB2GruppiPrivilegi ))

As you can see, they are explicitly declared as AUXILIARY.

Thanks again
Marco
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to