Trying to use the krb5-kdc.schema included with app-crypt/heimdal-0.6.3-r1 with openldap-2.2.14 causes slapd to error on start. Reproducible: Always Steps to Reproduce: 1.emerge openldap 2.emerge heimdal 3.include /etc/openldap/schema/krb5-kdc.schema in /etc/openldap/slapd.conf 4./etc/init.d/slapd start Actual Results: /etc/openldap/schema/krb5-kdc.schema: line 80: AttributeType inappropriate matching rule: "generalizedTimeOrderingMatch" [ !! ] Expected Results: the schema should work with the version of openldap http://www.openldap.org/lists/openldap-software/200402/msg00134.html
Created attachment 52944 [details] A working krb5-kdc.schema
this schema is bundled with heimdal NOT openldap. passing to correct maintainers.
Take a look at http://www.stacken.kth.se/lists/heimdal-discuss/2005-04/msg00067.html and corresponding thread.
audience? :)
(In reply to comment #4) > audience? :) Mabey it would be a good idee to include the krb5-kdc.schema in the mit-krb5 ebuild?
(In reply to comment #5) > > Mabey it would be a good idee to include the krb5-kdc.schema in the mit-krb5 ebuild? I see no reason to do that... as long as I know, MIT Kerberos has no support for storing principal information in LDAP, so it makes no sense to include this schema in the mit-krb5 ebuild. This schema is only suitable for Heimdal.
(In reply to comment #6) > (In reply to comment #5) > > > > Mabey it would be a good idee to include the krb5-kdc.schema in the mit-krb5 > ebuild? > > I see no reason to do that... as long as I know, MIT Kerberos has no support for > storing principal information in LDAP, so it makes no sense to include this > schema in the mit-krb5 ebuild. This schema is only suitable for Heimdal. But ldap has support for gssapi/kerberos authentication whit sasl. To bind as a ldap uid, there is a sasl-regex to look up the kerberosprincipal in the ldap database. Normaly the krb5Principal attr of the uid. This can not be done whit out the schema. So for a ldap v3 environment whit MIT Kerberos, the schema is nessesary, but onley to register the user principal whit the uid.
(In reply to comment #7) > But ldap has support for gssapi/kerberos authentication whit sasl. > To bind as a ldap uid, there is a sasl-regex to look up the kerberosprincipal in > the ldap database. Normaly the krb5Principal attr of the uid. This can not be > done whit out the schema. So for a ldap v3 environment whit MIT Kerberos, the > schema is nessesary, but onley to register the user principal whit the uid. I think you're wrong... when you use sasl-regexp to map your authentication identities, you map the Kerberos authentication identity to an entry in LDAP. The Kerberos authentication identity is in the form: uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth with maybe cn=realm missing if the mechanism doesn't understand the concept of realms or you're using the default realm. Nothing to do with LDAP schemas in this part. You must map that identity to an entry in LDAP, and you can do it for example in the following way: sasl-regexp uid=(.+),cn=(.+),cn=.+,cn=auth ldap:///dc=$2,dc=com??sub?(|(uid=$1)(cn=$1@$2)) Here we're using a ldap search to map the corresponing LDAP entry, and we're searching just using uid and cn: there is no krb5PrincipalName involved nor needed, so there is no need for the Kerberos schema. The only place where you DO need to do a search based on the krb5PrincipalName attribute is when you are storing your Kerberos entries in the LDAP directory. For example: sasl-regexp uid=(.+),cn=.+,cn=auth ldap:///dc=example,dc=com??sub?(|(uid=$1)(krb5PrincipalName=$1@EXAMPLE.COM)) Here we're searching for a matching uid or krb5PrincipalName, but just because we're already storing our Kerberos principals in LDAP, and we have the krb5PrincipalName attribute available. Even in this case you could map the identities using just the uid and not using the krb5PrincipalName attribute at all if you use the same uid in LDAP and Kerberos. So I still think there's no sense in including the Kerberos schema with MIT Kerberos because it isn't needed. I even think that including it and letting somebody use krb5PrincipalName as an attribute of an LDAP entry just to map authentication identities could lead to confusion, as you could think that Kerberos principals would be stored in LDAP instead of MIT Kerberos own database, where they really are. Best regards Jose P.D: I think we're getting a bit off topic... maybe we could continue this discussion privately?
so what do you all want me to do with this? Please reopen when you comment.
