Dear all,
I'm currently experimenting with (MIT) Kerberos and got to the point where I need to add the Kerberos definitions to LDAP (krb5-kdc.ldif). (This is on Rocky Linux 9 with symas-openldap-servers-2.6.6-1.el9.x86_64.)
First question: is this the correct schema file or should I use the one provided by MIT Kerberos 1.20.1 (/usr/share/doc/krb5-server-ldap/kerberos.ldif) ?
If I use krb5-kdc.ldif I get the following:
[root@gateway ~]# cd /opt/symas/etc/openldap/schema/ [root@gateway schema]# ldapadd -Y EXTERNAL -H ldapi:/// -f krb5-kdc.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=krb5-kdc,cn=schema,cn=config" ldap_add: Constraint violation (19) additional info: structuralObjectClass: no user modification allowed
Is this a permission issue or does the provided LDIF file contain lines that prevent the addition of the schema?
If I use the file provided by MIT Kerberos I get:
[root@gateway ~]# cd /usr/share/doc/krb5-server-ldap [root@gateway krb5-server-ldap]# ldapadd -Y EXTERNAL -H ldapi:/// -f kerberos.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=schema" ldap_modify: Invalid syntax (21) additional info: attributetypes: value #0 invalid per syntax
The book I'm following still uses Symas' LDAP 2.4 and thus needs to convert the .schema file to .ldif provided by MIT Kerberos. The procedure is:
#### start instructions #### # echo 'include /usr/share/doc/krb5-server-ldap/kerberos.schema' > /tmp/slapd.conf # mkdir /tmp/slapd.d # slaptest -f /tmp/slapd.conf -F /tmp/slapd.d # cp '/tmp/slapd.conf/cn=config/cn=schema/cn={0}kerberos.ldif' /tmp/kerberos.conf
Further instructions say: - remove '{0}' in /tmp/kerberos.conf in lines startig with 'dn:' and 'cn:' - add 'cn=schema,cn=config' to the DN - remove the lines containing 'structuralObjectClass', 'entryUUID', 'creatorsName', 'createTimestamp', 'modifiersName', 'modifyTimestamp' and 'entryCSN' at the end of the file
After the modifications, there should be only lines containing 'objectClass', 'olcAttributeTypes', 'olcObjectClasses', 'cn' or 'dn'. #### end instructions ####
If I follow these instructions and use the converted LDIF file the command succeeds:
[root@gateway tmp]# ldapadd -Y EXTERNAL -H ldapi:/// -f kerberos.ldif.converted SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=kerberos,cn=schema,cn=config"
Is there an explanation for this behavior? Do the files provided by Symas and MIT contain errors? (For convenience I attached all three files to this mail.)
Thank you,
Uwe
I'm currently experimenting with (MIT) Kerberos and got to the point where I need to add the Kerberos definitions to LDAP (krb5-kdc.ldif). (This is on Rocky Linux 9 with symas-openldap- servers-2.6.6-1.el9.x86_64.)
First question: is this the correct schema file or should I use the one provided by MIT Kerberos 1.20.1 (/usr/share/doc/krb5-server-ldap/kerberos.ldif) ?
If I use krb5-kdc.ldif I get the following:
[root@gateway ~]# cd /opt/symas/etc/openldap/schema/ [root@gateway schema]# ldapadd -Y EXTERNAL -H ldapi:/// -f krb5-kdc.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=krb5-kdc,cn=schema,cn=config" ldap_add: Constraint violation (19) additional info: structuralObjectClass: no user modification allowed
This is what works (recently tested) when I create containers, see if this one works (this is everything on one line)
ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f sendmail.ldif
dn: cn=sendmail,cn=schema,cn=config objectClass: olcSchemaConfig cn: sendmail olcAttributeTypes: {0}( 1.3.6.1.4.1.6152.10.3.1.10 NAME 'sendmailMTACluster' DESC 'cluster name associated with a set of MTAs' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: {1}( 1.3.6.1.4.1.6152.10.3.1.11 NAME 'sendmailMTAHost' DESC 'host name associated with a MTA cluster' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: {2}( 1.3.6.1.4.1.6152.10.3.1.13 NAME 'sendmailMTAKey' DESC 'key (left hand side) of an aliases or map entry' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {3}( 1.3.6.1.4.1.6152.10.3.1.14 NAME 'sendmailMTAMapName' DESC 'identifier for the particular map' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE ) olcAttributeTypes: {4}( 1.3.6.1.4.1.6152.10.3.1.16 NAME 'sendmailMTAMapValue' DESC 'value (right hand side) of a map entry' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {5}( 1.3.6.1.4.1.6152.10.3.1.24 NAME 'sendmailMTAMapSearch' DESC 'recursive search for values of a map entry' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {6}( 1.3.6.1.4.1.6152.10.3.1.25 NAME 'sendmailMTAMapURL' DESC 'recursive search URL for values of a map entry' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {7}( 1.3.6.1.4.1.6152.10.3.1.18 NAME 'sendmailMTAAliasGrouping' DESC 'name that identifies a particular aliases grouping' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: {8}( 1.3.6.1.4.1.6152.10.3.1.20 NAME 'sendmailMTAAliasValue' DESC 'value (right hand side) of an alias' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {9}( 1.3.6.1.4.1.6152.10.3.1.26 NAME 'sendmailMTAAliasSearch' DESC 'recursive search for values of an alias' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {10}( 1.3.6.1.4.1.6152.10.3.1.27 NAME 'sendmailMTAAliasURL' DESC 'recursive search URL for values of an alias' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {11}( 1.3.6.1.4.1.6152.10.3.1.22 NAME 'sendmailMTAClassName' DESC 'identifier for the class' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE ) olcAttributeTypes: {12}( 1.3.6.1.4.1.6152.10.3.1.23 NAME 'sendmailMTAClassValue' DESC 'member of a class' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {13}( 1.3.6.1.4.1.6152.10.3.1.28 NAME 'sendmailMTAClassSearch' DESC 'recursive search for members of a class' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {14}( 1.3.6.1.4.1.6152.10.3.1.29 NAME 'sendmailMTAClassURL' DESC 'recursive search URL for members of a class' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcObjectClasses: {0}( 1.3.6.1.4.1.6152.10.3.2.10 NAME 'sendmailMTA' DESC 'Sendmail MTA definition' SUP top STRUCTURAL MAY ( sendmailMTACluster $ sendmailMTAHost $ Description ) ) olcObjectClasses: {1}( 1.3.6.1.4.1.6152.10.3.2.11 NAME 'sendmailMTAMap' DESC 'Sendmail MTA map definition' SUP sendmailMTA STRUCTURAL MUST sendmailMTAMapName MAY ( sendmailMTACluster $ sendmailMTAHost $ Description ) ) olcObjectClasses: {2}( 1.3.6.1.4.1.6152.10.3.2.12 NAME 'sendmailMTAMapObject' DESC 'Sendmail MTA map object' SUP sendmailMTAMap STRUCTURAL MUST ( sendmailMTAMapName $ sendmailMTAKey ) MAY ( sendmailMTACluster $ sendmailMTAHost $ sendmailMTAMapValue $ sendmailMTAMapSearch $ sendmailMTAMapURL $ Description ) ) olcObjectClasses: {3}( 1.3.6.1.4.1.6152.10.3.2.13 NAME 'sendmailMTAAlias' DESC 'Sendmail MTA alias definition' SUP sendmailMTA STRUCTURAL MAY ( sendmailMTAAliasGrouping $ sendmailMTACluster $ sendmailMTAHost $ Description ) ) olcObjectClasses: {4}( 1.3.6.1.4.1.6152.10.3.2.14 NAME 'sendmailMTAAliasObject' DESC 'Sendmail MTA alias object' SUP sendmailMTAAlias STRUCTURAL MUST sendmailMTAKey MAY ( sendmailMTAAliasGrouping $ sendmailMTACluster $ sendmailMTAHost $ sendmailMTAAliasValue $ sendmailMTAAliasSearch $ sendmailMTAAliasURL $ Description ) ) olcObjectClasses: {5}( 1.3.6.1.4.1.6152.10.3.2.15 NAME 'sendmailMTAClass' DESC 'Sendmail MTA class definition' SUP sendmailMTA STRUCTURAL MUST sendmailMTAClassName MAY ( sendmailMTACluster $ sendmailMTAHost $ sendmailMTAClassValue $ sendmailMTAClassSearch $ sendmailMTAClassURL $ Description ) ) ~
Am 26.09.23 um 15:38 schrieb Marc:
I'm currently experimenting with (MIT) Kerberos and got to the point where I need to add the Kerberos definitions to LDAP (krb5-kdc.ldif). (This is on Rocky Linux 9 with symas-openldap- servers-2.6.6-1.el9.x86_64.)
First question: is this the correct schema file or should I use the one provided by MIT Kerberos 1.20.1 (/usr/share/doc/krb5-server-ldap/kerberos.ldif) ?
If I use krb5-kdc.ldif I get the following:
[root@gateway ~]# cd /opt/symas/etc/openldap/schema/ [root@gateway schema]# ldapadd -Y EXTERNAL -H ldapi:/// -f krb5-kdc.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=krb5-kdc,cn=schema,cn=config" ldap_add: Constraint violation (19) additional info: structuralObjectClass: no user modification allowed
This is what works (recently tested) when I create containers, see if this one works (this is everything on one line)
ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f sendmail.ldif
This worked but your sendmail.ldif doesn't contain 'structuralObjectClass' like krb5-kdc.ldif does. krb5-kdc.ldif also contains lines with 'structuralObjectClass', 'entryUUID', 'creatorsName', 'createTimestamp', 'modifiersName', 'modifyTimestamp' and 'entryCSN'.
Is my fundamental error here, that krb5-kdc.ldif needs to be added by slapadd instead of lapadd?
Having a closer look at kerberos.ldif I see that there are no lines containing 'olc'. It seems that this is still in the old 'schema' format although kerberos.ldif and kerberos.schema provided by MIT differ… I'm getting the impression that both files are still for the old 'slapd.conf' configuration style, one to be used with slapadd, the other with ldapadd.
Am 26.09.23 um 16:23 schrieb Uwe Sauter:
Am 26.09.23 um 15:38 schrieb Marc:
I'm currently experimenting with (MIT) Kerberos and got to the point where I need to add the Kerberos definitions to LDAP (krb5-kdc.ldif). (This is on Rocky Linux 9 with symas-openldap- servers-2.6.6-1.el9.x86_64.)
First question: is this the correct schema file or should I use the one provided by MIT Kerberos 1.20.1 (/usr/share/doc/krb5-server-ldap/kerberos.ldif) ?
If I use krb5-kdc.ldif I get the following:
[root@gateway ~]# cd /opt/symas/etc/openldap/schema/ [root@gateway schema]# ldapadd -Y EXTERNAL -H ldapi:/// -f krb5-kdc.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=krb5-kdc,cn=schema,cn=config" ldap_add: Constraint violation (19) additional info: structuralObjectClass: no user modification allowed
This is what works (recently tested) when I create containers, see if this one works (this is everything on one line)
ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f sendmail.ldif
This worked but your sendmail.ldif doesn't contain 'structuralObjectClass' like krb5-kdc.ldif does. krb5-kdc.ldif also contains lines with 'structuralObjectClass', 'entryUUID', 'creatorsName', 'createTimestamp', 'modifiersName', 'modifyTimestamp' and 'entryCSN'.
Is my fundamental error here, that krb5-kdc.ldif needs to be added by slapadd instead of lapadd?
Having a closer look at kerberos.ldif I see that there are no lines containing 'olc'. It seems that this is still in the old 'schema' format although kerberos.ldif and kerberos.schema provided by MIT differ… I'm getting the impression that both files are still for the old 'slapd.conf' configuration style, one to be used with slapadd, the other with ldapadd.
Further investigation showed that there is a working 'slapd.d' style file provided by MIT at https://raw.githubusercontent.com/krb5/krb5/master/src/plugins/kdb/ldap/libk...
This one works both with slapadd and ldapadd.
So some questions still remain: which file should be used? Symas' krb5-kdc.ldif or MIT's kerberos.openldap.ldif? Are the equivalent? Is krb5-kdc.ldif an schema definition independent of the Kerberos server implementation (MIT/Heimdal/…)?
On 26.09.23 16:23, Uwe Sauter wrote:
This worked but your sendmail.ldif doesn't contain 'structuralObjectClass' like krb5-kdc.ldif does. krb5-kdc.ldif also contains lines with 'structuralObjectClass', 'entryUUID', 'creatorsName', 'createTimestamp', 'modifiersName', 'modifyTimestamp' and 'entryCSN'.
If I compare the krb5-kdc.ldif from the symas debian package, there is no line with structuralObjectClass.
So looks like, the el9 package is different.
I would say, edit the file, go to the end and removed all lines from structuralObjectClass to the end of the file.
Best regards Ulf
openldap-technical@openldap.org
-
Marc -
Ulf Volmer -
Uwe Sauter