________________________________
From: [email protected]
[mailto:[email protected]] On Behalf Of Pepin, Martin
AVAYA (CAR:9D80)
Sent: Thursday, January 14, 2010 12:55 PM
To: [email protected]
Subject: [sipX-dev] Adding new LDAP import options for sipXecs
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.
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.
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.
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.
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.
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.
Thank you.
Martin
I should be able to take care of #5 on your list using the existing
jira issue XX-7381.
Dave.
_______________________________________________
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/
