Using custom attribute instead of mail
Hi,
We are implementing Sun Messaging server with an existing LDAP. Our ldap already has a mail attribute which is currently used by a lot of legacy system and changing that would be an hassle. I have changed the mapping.locale file to search for "mailAlternateAddress" and that works fine in Messaging Express. But now UWC is not allowing me to login. It gives error "Invalid user/ password"
Are there any other property file which needs to be changed for UWC to not look of mail attrbute.
Thanks
[522 byte] By [
HellFirea] at [2007-11-26 12:41:32]
# 1
Hi,
Rather then modifying messaging server to use a non-standard attribute for the mail property I would recommend an alternate approach. The directory proxy server software provided by sun allows for the rewriting of attribute names. So if you point your messaging server at a directory proxy server instance, you can have it rewrite an attribute in your existing LDAP, say sunmail: to the mail: attribute and the mail: attribute to legacymail:. Then you don't need to make numerous changes within the messaging server product. Also if you hit another 'legacy' attribute you can just rewrite that.
Otherwise you will most likely hit problems in the future when for some reason there is no way to re-map mail: within messaging server/uwc or some other product.
You can download the directory proxy software from here:
http://www.sun.com/download/products.xml?id=3ee7aed1
Regards,
Shane.
# 2
Hi Shane,Thanks for your reply, but it would be difficult for us to change the ldap infrastructure as it is serving a huge ebusiness environment. Is there any way I can change the configs of the MTA, UWC, Messaging Express, MEM to not use mail attribute.
# 3
Hi,
I think you misunderstand what is being proposed. The directory proxy software is a separate piece of software that operates between your existing LDAP server and messaging server translating/rewriting LDAP commands as appropriate. So you could have it running completely independently of your existing LDAP environment, the only applications that would be affected would be those applications you pointed at it (i.e. messaging server/uwc). The existing LDAP infrastructure would remain as-is.
We had a similar 'legacy' issue for which we used the directory proxy to solve. In this case the application was requesting the version: attribute from the directory (cn=config). If the version string didn't contain the word 'netscape' the application would refuse to start. This prevented us upgrading our master LDAP server from unsupported 4.X to supported 5.X (where the version string now had the word iPlanet). To change the LDAP server's version: string would require a code rewrite -- not something we had the ability or access of the code to do.
To solve this we installed a copy of the directory proxy software on the same system as the application (listening on localhost port 6389 so only the application could use it). We then added a custom attribute 'oldversion:' to the directory server in cn=config which had the version string from a 4.X install. The directory proxy server was then configured to rewrite version: with oldversion: and vice versa. When we pointed the application at the local directory proxy software install for LDAP operations. When the application requested the version: attribute, it was given the value of oldversion: So voila, problem solved. All other directory requests were passed through to our existing LDAP infrastructure unchanged.
Regards,
Shane.
