Over the past few days or weeks, I've asked a number of questions related to schemas as I move my LDAP directory to a newer OS and newer version of OpenLDAP. As has happened in the past, I have run into schema issues when importing the database (LDIF file) into the new directory with slapadd.
This time I got the following errors: 1. Kerberos attributes in "new" kerberos schema start with 'krb' instead of 'krb5' 2. I got a schema structural error because user accounts have both objectclasses "account" and "krbPrincipal", which is not good. 3. We were using solaris.schema on the old system, which CentOS 6 doesn't provide, but it does provide duaconf.schema, which seemed be be similar if not identical to solaris.schema.
Both of these are easy to fix - just use sed to change 'krb5' to 'krb', and then change 'krbPrincipal' to 'krbPrincipalAux', but is this really the best/safest way to make these changes. Also, what happens to apps that are looking for the 'krb5' instead of 'krb' and vice-versa?
I think many system admins would say just copy the schemas from the old server to the new server and forget about it, but I don't think this is a good approach. After doing that several times, I imagine the newer applications on the newer OS versions will be looking for different objectclass or attribute names (like krb instead of krb5), and things will eventually break, anyway.
So my questions are this:
1. How do the rest of you handle situations like this? 2. Who/what is the authoritative source for current schema definitions? Are they all defined in RFCs?
In an earlier e-mail, regarding my kerberos schema issues, Michael Ströder wrote
You should use the current schema file shipped with your particular Kerberos installation.
That's exactly what I'm trying to do, which led to the kerberos schema issues. And in the past there have been times when the current version of the OS didn't provide the same schemas as the old version, and I was left searching the Internet to find the modern equivalent of the schema from the old system.
On Tue, May 16, 2017 at 03:23:59PM -0400, Prentice Bisbal wrote:
- Kerberos attributes in "new" kerberos schema start with 'krb'
instead of 'krb5'
Are you sure they are only older/newer versions of the same schema? That sounds to me like one of them is the MIT schema and the other is Heimdal. AFAIK the data formats are not really compatible despite the similar names for things.
MIT schema: https://github.com/krb5/krb5/blob/master/src/plugins/kdb/ldap/libkdb_ldap/ke... Heimdal schema: https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb.schema
Worth noting is that MIT has 'krbPrincipal' and 'krbPrincipalAux' but in Heimdal, 'krb5Principal' itself is already AUXILIARY.
Both of these are easy to fix - just use sed to change 'krb5' to 'krb', and then change 'krbPrincipal' to 'krbPrincipalAux', but is this really the best/safest way to make these changes. Also, what happens to apps that are looking for the 'krb5' instead of 'krb' and vice-versa?
Right, you can't just go modifying schema without also modifying the applications that have the names and expectations baked into them. Generally the correct schema to use is the one supplied with the software itself - in this case, whichever KDC you are using should have a copy of the appropriate schema shipped with it.
On 05/16/2017 05:05 PM, Ryan Tandy wrote:
On Tue, May 16, 2017 at 03:23:59PM -0400, Prentice Bisbal wrote:
- Kerberos attributes in "new" kerberos schema start with 'krb'
instead of 'krb5'
Are you sure they are only older/newer versions of the same schema? That sounds to me like one of them is the MIT schema and the other is Heimdal. AFAIK the data formats are not really compatible despite the similar names for things.
MIT schema: https://github.com/krb5/krb5/blob/master/src/plugins/kdb/ldap/libkdb_ldap/ke... Heimdal schema: https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb.schema
No, I can't be 100% sure they're newer/older versions of the same schema. The system admins I inherited this directory from are no longer working here, and they didn't document any of their work, so I have no idea where the older kerberos.schema file originated from.
The newer one that I am using now, the one with 'krb' instead of 'krb5' is provided by CentOS 6 as part of the krb5-server-ldap RPM. Querying this package indicates that it's from MIT's kerberos. We're actually using AD for our KDC, so I should use whatever is compatible with that. A quick Google search seems to indicate that AD is compatible with MIT kerberos, but I couldn't find any conclusive statements to that fact.
I'll compare both schemas above to what I'm using now.
Worth noting is that MIT has 'krbPrincipal' and 'krbPrincipalAux' but in Heimdal, 'krb5Principal' itself is already AUXILIARY.
Hmmm... that would indicate that the old Kerberos schema was Heimdal Kerberos.
Both of these are easy to fix - just use sed to change 'krb5' to 'krb', and then change 'krbPrincipal' to 'krbPrincipalAux', but is this really the best/safest way to make these changes. Also, what happens to apps that are looking for the 'krb5' instead of 'krb' and vice-versa?
Right, you can't just go modifying schema without also modifying the applications that have the names and expectations baked into them. Generally the correct schema to use is the one supplied with the software itself - in this case, whichever KDC you are using should have a copy of the appropriate schema shipped with it.
That's what scares me. Sure, my changes allowed me to import the directory data with slapadd, but what happens when a critical application like SSSD is actually looking for the other attribute name?
It looks like I've got some work to do to make sure I'm using the correct schemas.
Prentice
On 16 May 2017, at 20:23, Prentice Bisbal pbisbal@pppl.gov wrote:
I think many system admins would say just copy the schemas from the old server to the new server and forget about it, but I don't think this is a good approach.
That’s what I do. I agree, on a theoretical level, that that might not be the best way to do it, but it sure is the simplest :). I have way to much to do anyway, so if I can take the easy way for once, I’ll take it.
As far as other applications using LDAP and any attribute in there, they are (should be!) configurable. For example, LibNSS-LDAP and LibPAM-LDAP all let you configure what attributes to use for what..
I’m sure there’s a reason for changing 'krbPrincipal' to ‘krbPrincipalAux’, but personally I don’t care. The former works for me.
- Who/what is the authoritative source for current schema definitions? Are they all defined in RFCs?
Probably not all. MINE isn’t. But I do have a registered IANA, so from the schemas attribute or objectless OID, it should be “reasonably” easy to match the two and find out who wrote it and from there you might be able to get a later version.
On 05/17/2017 05:03 AM, Turbo Fredriksson wrote:
On 16 May 2017, at 20:23, Prentice Bisbal pbisbal@pppl.gov wrote:
I think many system admins would say just copy the schemas from the old server to the new server and forget about it, but I don't think this is a good approach.
That’s what I do. I agree, on a theoretical level, that that might not be the best way to do it, but it sure is the simplest :). I have way to much to do anyway, so if I can take the easy way for once, I’ll take it.
The way I look at it, it's better to address this problem head-on and fix it now (if it in fact needs fixing), than wait until my schemas are so old that when I upgrade my directory clients something breaks because my schemas are old and obsolete that they're no longer compatible with the client applications like SSSD, etc. In that scenario, I see bosses and users screaming at me, asking why the upgrade lead to problems...
Although to be honest, I don't think schemas really change very often.
As far as other applications using LDAP and any attribute in there, they are (should be!) configurable. For example, LibNSS-LDAP and LibPAM-LDAP all let you configure what attributes to use for what..
Very true, but I'd rather fix the schema in one place, rather than fix all my applications, which could have config files with various syntaxes all over /etc.
I’m sure there’s a reason for changing 'krbPrincipal' to ‘krbPrincipalAux’, but personally I don’t care. The former works for me.
I think Ryan Tandy nailed it - one's for Heimdal Kerberos, the other is for MIT kerberos. I need to dig into this further to confirm for myself, though,
- Who/what is the authoritative source for current schema definitions? Are they all defined in RFCs?
Probably not all. MINE isn’t. But I do have a registered IANA, so from the schemas attribute or objectless OID, it should be “reasonably” easy to match the two and find out who wrote it and from there you might be able to get a later version.
openldap-technical@openldap.org
-
Prentice Bisbal -
Ryan Tandy -
Turbo Fredriksson