openldap - different sets of schemas on different servers?

[justanotheruser]

If I want to tie in Zimbra to our existing openldap servers, do i have to modify the zimbra slapd.conf to contain the same set of schema files? We use the nis.schema and a custom schema.

Based on some googling and thinking it over, it looks like you don't have to - that you could have a setup like this:

- zimbra machine (with zimbra schema)
- openldap server A (with nis.schema)
- oepnldap server B (with custom.schema)


...is my understanding correct?

[zaf]

Right, You can have Zimbra authenticate against any existing LDAP server, without modifying the schemas. When you configure a domain in Zimbra, you tell it how you want it to do LDAP lookups to authenticate its users.

[dijichi2]

if you use external auth on a domain to chain the user auth against another ldap server, then you have to 'synch' the accounts manually, in that you have to run some script to create accounts on both ldap servers as they're not linked.

altering the zimbra ldap to deal with custom schema is not recommended, there's no guarantee it will be preserved or understood across upgrades - the upgrade scripts are quite complex and likely will break if they come across unexpected constraints.

[justanotheruser]

Let me check if I understood you right or if you explained what you meant clearly - are you saying that I can have this scenario:

- custom schema on SERVER1 but NOT on SERVER2
- sync accounts between SERVER1 and SERVER2

Then if I were to do an LDAP search on SERVER2 it will be smart enough to join across to find data out of SERVER1's custom schema?

So, I'm not modifying the zimbra.schema, just adding into the mix, my own custom schema.

if you use external auth on a domain to chain the user auth against another ldap server, then you have to 'synch' the accounts manually, in that you have to run some script to create accounts on both ldap servers as they're not linked.

altering the zimbra ldap to deal with custom schema is not recommended, there's no guarantee it will be preserved or understood across upgrades - the upgrade scripts are quite complex and likely will break if they come across unexpected constraints.