How to export user contact/details to LDAP

[Josh Bonczkowski, modificado hace 13 años.]

I have LDAP configured in my environment. Ok, it's actually Active Directory. I am able to log in using this LDAP server for authentication. I have checked the box to export changes back to LDAP and set the proper LDAP path to where the users are.

I found a page on the wiki which talks about LDAP export module (LDAP Wiki Page). On that page, it mentions that only a few pieces of data are currently exported back to LDAP; screenName, password, emailAddress, firstName and lastName.

As part of our portal, I would like changes to the users address and phone numbers to also be exported to LDAP. I am walking through some of the source code to see if I can determine how the user information is exported back to LDAP.

I appears that a Contact object is used for exporting. The ldap.user.mapping property is then retrieved (as a Properties object). Then the Liferay property is copied into a Modification object (for LDAP modifications) for each property that can be copied. (see PortalLDAPExporterImpl.exportToLDAP)

I had hoped that I could update the ldap.user.mapping setting to include mappings for the other information I wanted to export to LDAP, but those properties do not exist on the Contact object. Looks like I need to hook or extend Liferay to do this.

For this type of change, is there a hook or extension that I can created to perform the additional logic to copy the rest of the user information to LDAP using Modification objects? I can write the code to do it, but I'm just not sure how to cleanly extend Liferay so that my code is executed every time that the user information is changed.

Suggestions? Pointers?

[Josh Bonczkowski, modificado hace 13 años.]

I forgot to mention, I am using Liferay 6 which has the ext plugins; if that helps.

[Jerry Niu, modificado hace 13 años.]

I haven't tried it but from looking at the code, it looks like you can also use the sig for the User object vs the Contact object. I think its easier to follow the User object.

As for the exporter, have you tried to create the custom attributes in the the control panel and than insert it in the properties file. In this case, you do not have to rely on the Contact object.

[Josh Bonczkowski, modificado hace 13 años.]

I have not tried to use custom attributes. Unfortunately, that would also result in the best experience for the user. Right now, if they edit their address from the normal UI, the region (State in US) drop down is pre-populated once the country is selected.

Thanks for mentioning the User object can be used as well. I am currently trying to extend the method with the User object and pulling out the List<Address> and List<Phone> for the user.


As a side note. The *LocalService objects should have a method to retrieve a list of the objects from the user ID. To get around this, I've been just pulling the entire set and filtering to the ones used by the user. My approach probably won't scale to very large sites, but should handle a few thousand users.

[Josh Bonczkowski, modificado hace 13 años.]

I have most of my solution in place now, but I ran into an interesting problem. When the user is exported to LDAP, the Address and Phone fields in the Liferay DB have not been updated yet. So I am pulling the old values from the DB and pushing them to LDAP. An additional press of the Save button on the user details is required to force the most recent change to go to the server.

I would suggest that the order for persisting data is probably backwards. If the calls to the LDAP server fail, the Liferay DB is still updated correctly. To me, that means there is little probably with persisting to Liferay DB first, then exporting to LDAP.

I think my next step is to figure out where the code which persists and exports to LDAP lives and try and order it through my extension.

Any other thoughts?

[amit doshi, modificado hace 13 años.]

Hi Josh,

I am getting the same issue as you have mentioned.

Have you found the solution for it?