On Thu, 2010-01-14 at 12:55 -0500, Martin Pepin wrote: > I would like to suggest improving the existing LDAP import > capabilities to add more flexibility get closer to what a spreadsheet > import can support. At the same time, this enhancement request would > provide better alignment with the enhancements introduced in XX-7381. > Your feedback is appreciated. I'll open a JIRA based on your input.
Not 'a JIRA' - one tracker issue per item. Bundle issues are evil. > More specifically I suggest the following improvements to the LDAP > import feature: > > 1) Add SSL/TLS support to LDAP import. > > In the "LDAP / Active Directory Server" screen a new SSL/TLS checkbox > can be added to suggest that "ldaps://" is going to be used as opposed > to "ldap://";. The user will need to manually change the default port > number from 389 to 636. In some deployments LDAP database access over > TLS is the only option and this enhancement makes it possible given > the relevant certificates have been installed in sipXecs. Supporting secure access seems like an obviously good feature (despite all the certificate management headaches it will doubtlessly entail). You're kidding about having to manually change the port number, right? (Say yes, Martin) > 2) Add a template list to preselect the LDAP attributes to user > account field mapping. > > In the "LDAP / Active Directory Server" screen, once the administrator > clicks on the "continue" button, a fairly long list of LDAP components > can show up. It can be difficult to figure out which components should > be selected in some well known scenarios for which a template can be > provided. This template could at the same time set the LDAP attribute > to user account field mapping in the next screen once the admin clicks > on the "continue" button. Seems like a good idea, if such common cases actually exist. > 3) Add optional string prefix to some user account fields. > > When configuring LDAP attribute to user account field mapping it is in > some cases desirable to prefix the "user ID attribute" field with a > string or number to avoid collisions with existing user IDs or for > example adding a "location code" number to a base extension number. > The "alias attribute" field which could also be presented as an > extension number can also benefit from a string prefix to interoperate > with legacy PBXes for example. The optional string entry for those two > fields would be entered by enabling a separate checkbox per field each > with a corresponding input text box. The default is no string prefix. I don't think I understand this one... perhaps an example or two would help. In particular, the question of "existing user IDs" is, I think, moot - since if we are using LDAP as the authoritative source of user information, there are no user IDs that don't come from LDAP. > 4) Avoid using a hardcoded group name. > > When configuring LDAP attribute to user account field mapping, there > is a field for "user group attribute". If left empty a default > hardcoded group name of "ldap_import" is added. And if the user > selects an LDAP attribute, each user will belong to two groups. The > proposal is to allow either a custom group name to be entered as a > free-form text entry or to use an LDAP attribute if not custom type. > The default would be custom type that shows "ldap_import". If custom > is used, then this group name must not be an empty string. This way > grouping is enforced such that imported LDAP users can be viewed or > deleted easily by their group names. This sounds like something I agree with, even if I'm a bit vague on the details. I suspect that if we're seriously going to manage via LDAP, that it will need to be possible to have expressions that define groups. For example, "all users above personel grade 2 whose location is New York". But not just automatically assigning a fixed group name seems like an excellent start. > 5) Existing group settings are not applied to newly imported users. > > When an LDAP import is triggered either by polling or by manual > intervention in the user interface if the group name for newly added > users exists already, then default group settings should be applied to > those newly added users. It is the case for users imported by > spreadsheet but it does not work for user imported by LDAP. This > should be fixed as well. Clearly a bug (and a fairly serious one). _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
