Multi domain LDAP authentication and user import support

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.4
  • Fix Version/s: 4.6
  • Component/s: None
  • Labels:
    None
  • Team:
    Unspecified

Description

Given discussion with Mike, the following is required:

4.4, 4.6 releases: user-portal:
-introduce username concept apart from extension
-accept multiple domains network ids like: joe@sipfoundry.org, mirceac@example.com, joe@middle.eee.com
-ensure multi-domain LDAP authentication
-new UI field with structure: Username:[text field for username]@[text field for domain name]

Fields joe@sipfoundry.org, mirceac@example.com, joe@middle.eee.com will be saved as aliases in sipxecs backend, and in addition, we will save joe, mirceac as aliases.
The last joe (joe@middle.eee.com) is in conflict, so we will automatically save joe1 as alias for him. Admin will be informed (an alarm raise) about this potential conflict and automated resolution.
Admin will be free to change joe1 in something more suggestive

4.4, 4.6 releases: LDAP/AD setup page:
-ensure multi-domain LDAP setup (enhance sipxecs to configure many LDAP instances at once)
example: LDAP instance 1 with suffix: dc=sipfoundry, dc=org, LDAP instance 2 with suffix dc=example, dc=com, LDAP instance 3 with suffix dc=middle., dc=eee, dc=com
-ability to import users belonging on these instances

XMPP
4.4 release: currently the proposed user id is the extension - this will be changed to propose as an im id the username (joe, mirceac, joe1)
4.6 release: joe, mirceac, joe1 will automatically be used as im ids - the im configuration page will dissapear in 4.6

Issue Links

also reported as

New Feature - A new feature of the product, which has yet to be developed. XX-9700 Support multiple LDAP / AD Domains

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Don McIlvin added a comment -
Just some thoughts; Multiple AD domain instances should be identifiable and searchable by the AD domain name and a sipXecs admin should be able to list all and select an AD domain from the list for administrative purposes. If a User-ID can be associated with a designated AD domain, that would optimize authentication attempting such against only the one designated AD domain.
Show
Don McIlvin added a comment - Just some thoughts; Multiple AD domain instances should be identifiable and searchable by the AD domain name and a sipXecs admin should be able to list all and select an AD domain from the list for administrative purposes. If a User-ID can be associated with a designated AD domain, that would optimize authentication attempting such against only the one designated AD domain.
Hide
Permalink
Mircea Carasel added a comment -
I think that A LDAP instance runs on a dedicated port - each LDAP instance has its own port, so in order to find the domain (LDAP sufix - like dc=example,dc=com represents the domain example.com) we need to connect to that port first...

At least this is how 389-ds ldap server, available on fedora repository, configures multiple instances. each runs on its own port
Show
Mircea Carasel added a comment - I think that A LDAP instance runs on a dedicated port - each LDAP instance has its own port, so in order to find the domain (LDAP sufix - like dc=example,dc=com represents the domain example.com) we need to connect to that port first... At least this is how 389-ds ldap server, available on fedora repository, configures multiple instances. each runs on its own port
Hide
Permalink
Mircea Carasel added a comment -
As I read more, a true multi domain LDAP server should open one single port (389 for instance) and configure there multiple sufixes (dc=example, dc=com for example.com and dc=sipfoundry, dc=org for sipfoundry.org), and the
sipxecs admin should be able to list all configured sufixes and select one to configure
Show
Mircea Carasel added a comment - As I read more, a true multi domain LDAP server should open one single port (389 for instance) and configure there multiple sufixes (dc=example, dc=com for example.com and dc=sipfoundry, dc=org for sipfoundry.org), and the sipxecs admin should be able to list all configured sufixes and select one to configure
Hide
Permalink
Michael Picher added a comment -
As part of the change with domain as part of login for LDAP, we should have a check box on the login page to enable writing a browser cookie to remember the username...
Show
Michael Picher added a comment - As part of the change with domain as part of login for LDAP, we should have a check box on the login page to enable writing a browser cookie to remember the username...
Hide
Permalink
Michael Picher added a comment -
Have a single ‘logon’ field and not fields for both username and domain separately.
 
If possible consider the following (please don't let it add time to development effort):
 
Many Windows network users are used to using the old-school (legacy) DOMAIN\username rather than username@DOMAIN. This is unfortunate in that the legacy domain is a netbios domain name and fqdn is the new domain naming. This could be done (as a work-around for now) by keeping a field in the LDAP setup that is ‘Legacy Domain’ or something, so we would have (a very rough idea):
 
FQDN: SOME.DOMAIN.COM
LEGACY: SOMEDOM
LDAP SERVER: X.Y.Z.A
LDAP ACCOUNT: <domain account with read access>
PASSWORD: <password>
BASE DN: DC=SOME,DC=DOMAIN,DC=COM
 
That way a user could log in with either user@SOME.DOMAIN.COM or SOMEDOM\user – breaking the string into its separate components and adding a bit of logic in there is a simple enough thing that you could then compare that to the LDAP setup and go to login from there.
Show
Michael Picher added a comment - Have a single ‘logon’ field and not fields for both username and domain separately.   If possible consider the following (please don't let it add time to development effort):   Many Windows network users are used to using the old-school (legacy) DOMAIN\username rather than username@DOMAIN. This is unfortunate in that the legacy domain is a netbios domain name and fqdn is the new domain naming. This could be done (as a work-around for now) by keeping a field in the LDAP setup that is ‘Legacy Domain’ or something, so we would have (a very rough idea):   FQDN: SOME.DOMAIN.COM LEGACY: SOMEDOM LDAP SERVER: X.Y.Z.A LDAP ACCOUNT: <domain account with read access> PASSWORD: <password> BASE DN: DC=SOME,DC=DOMAIN,DC=COM   That way a user could log in with either user@SOME.DOMAIN.COM or SOMEDOM\user – breaking the string into its separate components and adding a bit of logic in there is a simple enough thing that you could then compare that to the LDAP setup and go to login from there.
Hide
Permalink
Michael Picher added a comment -
Netbios name will be needed...
Show
Michael Picher added a comment - Netbios name will be needed...
Hide
Permalink
Michael Picher added a comment -
If a user is removed from Active Directory, the user's mailbox should be moved to a holding location & marked for deletion after XX days. Where XX is configurable. If a user is re-instated within XX days, their mailbox is copied back.
Show
Michael Picher added a comment - If a user is removed from Active Directory, the user's mailbox should be moved to a holding location & marked for deletion after XX days. Where XX is configurable. If a user is re-instated within XX days, their mailbox is copied back.
Hide
Permalink
Michael Picher added a comment -
There should be the a enable / disable to allow LDAP/AD imports to overwrite any user configured information in sipXecs user profile.
Show
Michael Picher added a comment - There should be the a enable / disable to allow LDAP/AD imports to overwrite any user configured information in sipXecs user profile.
Hide
Permalink
Michael Picher added a comment -
Can we allow login with email address & have that mapped back to a user's domain? If not, this would be good to have in 4.6.
Show
Michael Picher added a comment - Can we allow login with email address & have that mapped back to a user's domain? If not, this would be good to have in 4.6.
Hide
Permalink
Mircea Carasel added a comment - - edited
commit phase 1:
https://github.com/dhubler/sipxecs/commit/0a151f3bea8b87b5d8007c9f402e0e81b0bdc19c
https://github.com/dhubler/sipxecs/commit/7e9bb2f1a1551e8282b8c5b07d83255fb6dc11f8

- implement multiple ldap connection configuration
- implement LDAP authentication across multiple ldap instances
- implement import scheduling for each ldap instance separately
- fixed, improved tests
Show
Mircea Carasel added a comment - - edited commit phase 1: https://github.com/dhubler/sipxecs/commit/0a151f3bea8b87b5d8007c9f402e0e81b0bdc19c https://github.com/dhubler/sipxecs/commit/7e9bb2f1a1551e8282b8c5b07d83255fb6dc11f8 - implement multiple ldap connection configuration - implement LDAP authentication across multiple ldap instances - implement import scheduling for each ldap instance separately - fixed, improved tests
Hide
Permalink
Mircea Carasel added a comment -
commited phase 2
https://github.com/dhubler/sipxecs/commit/6e0a0674c9e3d1b0443395be33603488c6316fc0
-added domain field in LDAP configuration page
-added domain setting in edit user page
-pick ldap authenticator that belongs to user domain
-parsing mechanism of login user@domain domain\user entries
-fix ldap import to be able to corectly save aliases
-if alias collision, do not save alias for that user, show warning in status page, log warning
-fixed/improved tests
Show
Mircea Carasel added a comment - commited phase 2 https://github.com/dhubler/sipxecs/commit/6e0a0674c9e3d1b0443395be33603488c6316fc0 -added domain field in LDAP configuration page -added domain setting in edit user page -pick ldap authenticator that belongs to user domain -parsing mechanism of login user@domain domain\user entries -fix ldap import to be able to corectly save aliases -if alias collision, do not save alias for that user, show warning in status page, log warning -fixed/improved tests
Hide
Permalink
Mircea Carasel added a comment -
I keep this opeend, until we have a decision whether this needs to be backported to 4.4 or not
Show
Mircea Carasel added a comment - I keep this opeend, until we have a decision whether this needs to be backported to 4.4 or not
Hide
Permalink
MuthyaChitra added a comment -
Worked on ldap on 12th July sipxecs build and these are the verifications we did:
a.Importing of users from two search bases from the same ldap server
b.Importing of users with users having same alias (from two search bases)
c.Logging in users who has same alias as mentioned in the document sent by you with user@domain, authentication, domain\user, etc.. works fine.
Hence discussed with Mircea and closing the issue.
Show
MuthyaChitra added a comment - Worked on ldap on 12th July sipxecs build and these are the verifications we did: a.Importing of users from two search bases from the same ldap server b.Importing of users with users having same alias (from two search bases) c.Logging in users who has same alias as mentioned in the document sent by you with user@domain, authentication, domain\user, etc.. works fine. Hence discussed with Mircea and closing the issue.

People

  • Assignee:
    Unassigned
    Reporter:
    Mircea Carasel
Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: