Another bit of info: I've tried Pidgin for remote XMPP tests - it works with all the different combinations of user identifier (uid, employeenumber, base for a mail address) and a valid domain name (we have a few linked to the test organization) that I've tried. It refuses to work without a domain name. It even worked for a user identifier which only exists in employeeNumber and a domain name, so the resulting combination is not a value of any mail attribute nor of uid.

Now testing more with this account identifier which has no direct mail alias (employeeNumber=jim for account with uid=jimklimov and aliases for jimklimov@* and eklimov@*).

Convergence did log in by the value of employeeNumber without a domain, but refused to connect the messenger and calendar. Shows the mails, attachments and address books ok. Same for login with jim@recentdomainname, where the domain alias was added recently (but from what I see, it is enabled in all the layers of LDAP organizations along with the old domain name) and for jim@olderdomainname which was an alias added several months ago.

Everything works for jim@primarydomainname (which, as I now see, is explicitly defined in iim.conf.xml in the "domain" tag... I wonder if aliases can be defined here, or would it be full-fledged multi-domain hosting?)

For logins with jimklimov (value of uid), and jimklimov@recentdomainname and jimklimov@olderdomainname, which are both defined as email aliases, the Calendar works along with other modules, messenger does not.

Everything works for jimklimov@primarydomainname.

Finally, login with eklimov (base of email address, including the primary mail attribute, but not a complete value of any attribute), eklimov@recentdomainname and eklimov@olderdomainname, all of these do not connect both calendar and messenger.

Login with eklimov@primarydomainname, which happens to be the value of the mail attribute as well, shows all applications correctly.

Hope these clues show something

I'll tinker a bit with other values of the mail attribute (varying users and domains) and see if behavior of logins with such values differ... or if the users should login only with anythingvalid@primarydomainname?..

Thanks,

//Jim

And a few more bits of info. I changed this test account's mailAlternateAddress aliases, adding jimalias@primarydomain and jimalias@olderdomain and jimalias@recentdomain (jimalias is not a value present in any other attribute), as well as replaced eklimov@olderdomain with eklimov@randomdomain, and replaced the mail attribute from eklimov@primarydomain to eklimov@olderdomain. Then I restarted all the messaging-related services to clear any caches. Hope this makes sense

Trying these changed logins now...

jimalias@primarydomain - all works in Convergence.

eklimov@olderdomain (current value of the mail attribute), jimalias@olderdomain, jimalias@recentdomain - no calendar, no messenger. Mail, addresses, attachments work.

eklimov@randomdomain (present among aliases) - does not log in at all. Makes sense, no organizations match this domain.

eklimov@primarydomain (value not present in any mail or alias attributes now, eklimov is not an uid nor employeeNumber) - all works in Convergence. Probably goes subject to those filters which separate $U and $D, and then $U@* matches an address in the LDAP. This is my guess, I don't have evidence from logs.

So, basically, ALL things work only for logins anythingvalid@primarydomainname... "You can have any car of any color, as long as it is a black Ford"

What is then the proper way of handling fully aliased domains (where $U@primarydomain should automatically - or even explicitly as in our case - match $U@anyothersupporteddomain)?

Thanks again,

//Jim Klimov

While I am interested in opinions and information about the under-the-hood cause of the problem, I am happy to report a workaround. It seems to be good in this form, as long as this server only hosts one actual email domain (no competing organizations).

I prefaced the Convergence server and other appservers in the messaging installation with a Sun Web Server which does reverse-proxying to the different web-services and makes them look like one site for the users. This is a nice spot to do analysis and rewriting of the HTTP streams, including HTTPS (served and deciphered by this webserver). The workaround block is this:

    <If $uri = "/iwc/svc/iwcp/login.iwc">

        Input fn="insert-filter" method="POST" filter="sed-request"

            sed="s/(@|%40)[^&]*&/&/"

        Input fn="insert-filter" method="POST" filter="sed-request"

            sed="s/&passw/%40domain.com&/"

            ###### Don't ask why not the correct way like so:

            ### sed="s/&passw/%40domain.com&passw/"

This is a bit ugly, unfortunately I did not find a way to use backreferences in sed-requests to make it a simple nice filter. So part one chops off the mail domain part from the request (%40 is @). Part two attaches the primary domain. This is all ad-hoc, based on the fact that in the current implementation, the &password= field is present at all (think cert auth) and directly follows the username=... field. Also, I have no idea about NOT needing to add the passwd in the substitution; may have to do with & being a special character?

At least, this works for us and is within acceptable limitations (one predefined primary domain). And this can break when web-interface forms change, for example. So proper solutions are still welcome, but nonetheless... something

Interestingly, I've also tried proxyauth logins - everything works for them in Convergence with and without this hack. Even if the administrative user and the end-user were both given without a domain (and this hack was disabled), messaging and calendar still work.

HTH,

//Jim Klimov

PS: On a side note, if people use Web Server to be a face for the Messaging farm, and they use the Trim Filter plugin to reduce traffic - for the /iwc/svc path don't use it, some clients like Outlook Connector rely on particular markup layout, such as standard presence of CRLF in the CalDAV queries!

Thanks for the suggestions, here's the test result (note that MS7.4 is indeed part of OUCS7u2, so I happen to have the aliases command as well):

#  imsimta test -domain_map

DOMAIN_MAP> verify

%DMAP-E-NODOMAINNAME, Domain entry with DN 'o=CommsHostingDomainsRoot,dc=domain,dc=local' does not have a domain name

%DMAP-E-DOMAINMULTDEF, Domain 'domain.com' multiply defined by entries with DNs 'o=domain.com,dc=domain,dc=local' and 'o=domain.com,dc=domain,dc=local'

%DMAP-E-NODOMAINNAME, Domain entry with DN 'o=CommsHosting,o=domain.com,dc=domain,dc=local' does not have a domain name

%DMAP-E-NODOMAINNAME, Domain entry with DN 'o=CommsHostingOps,o=CommsHosting,o=domain.com,dc=domain,dc=local' does not have a domain name

%DMAP-E-NODOMAINNAME, Domain entry with DN 'o=oucs-org,o=CommsHosting,o=domain.com,dc=domain,dc=local' does not have a domain name

%DMAP-E-NODOMAINNAME, Domain entry with DN 'o=msad-org,o=CommsHosting,o=domain.com,dc=domain,dc=local' does not have a domain name

DOMAIN_MAP> enumerate

  domain.com

DOMAIN_MAP> enumerate -aliases

  domain.com

  domain.local

  domain.com

  ucs.domain.com

  ucs.domain.local

DOMAIN_MAP>

I believe this would benefit from a bit of clarification. The LDAP was initially set up with a single organization (o=domain.com,dc=domain,dc=local) which housed several OUs - with ordinary users, and with users replicated from MSAD by IdSyncWin (component of DSEE LDAP server). Later we found that the Delegated Admin requires that users are strictly under ou=People,o=org,... in their organization, in order to be able to edit them. So we remade the LDAP catalog for the existing system into hosted-domains-support scheme.

This is supposed to host one domain (and its aliases), defining the different user containers as sub-organizations sharing the common domain, with MSAD-replicated users in one org, and OUCS-defined "local" users in another. The LDAP branches with "CommsHosting" in the names are pieces of that structure. I am not sure if they (all or some) should also mention the domains; some of them do have sunAssignableDomains and/or sunAvailableDomains set, though.

Except for hiccups with Convergence described in this thread, this works quite well as far as messaging, calendaring and other subsystems are concerned, at least while the setup is still a POC demo waiting to become the master server

Interesting about that double-definition... it seems that the o=domain root org does have both sunPreferredDomain and associatedDomain set both to the domain.com value. Should one be removed, or does this not matter much?
Thanks,

//Jim

Just in case it helps, here are all organizations in the tree, alogn with attributes which mention the domain name:

# ldapsearch-dsee 'o=*' | egrep "$domain"'|dn|^$'
dn: o=cosTemplates,dc=domain,dc=local

dn: o=mailuser,o=cosTemplates,dc=domain,dc=local

dn: o=calendaruser,o=cosTemplates,dc=domain,dc=local

dn: o=imuser,o=cosTemplates,dc=domain,dc=local

dn: o=mailcalendaruser,o=cosTemplates,dc=domain,dc=local

dn: o=mailcalendarimuser,o=cosTemplates,dc=domain,dc=local

dn: o=mailimuser,o=cosTemplates,dc=domain,dc=local

dn: o=calendarimuser,o=cosTemplates,dc=domain,dc=local

dn: o=mailgroup,o=cosTemplates,dc=domain,dc=local

dn: o=calendargroup,o=cosTemplates,dc=domain,dc=local

dn: o=mailcalendargroup,o=cosTemplates,dc=domain,dc=local

dn: o=CommsHostingDomainsRoot,dc=domain,dc=local

dn: o=domain.com,dc=domain,dc=local
associatedDomain: domain.local
associatedDomain: domain.com
associatedDomain: ucs.domain.com
associatedDomain: ucs.domain.local
icsDWPBackEndHosts: cal.ucs.domain.com
preferredMailHost: imap.ucs.domain.com
mailRoutingHosts: imap.ucs.domain.com
sunPreferredDomain: domain.com
o: domain.com

dn: o=CommsHosting,o=domain.com,dc=domain,dc=local
sunAssignableDomains: domain.com
sunAssignableDomains: domain.local
sunAssignableDomains: ucs.domain.com
sunAssignableDomains: ucs.domain.local
sunBusinessOrgBase: o=CommsHostingdomainsroot,dc=domain,dc=local
sunProviderOrgDN: o=CommsHostingOps,o=CommsHosting,o=domain.com,dc=domain,dc=loca

dn: o=CommsHostingOps,o=CommsHosting,o=domain.com,dc=domain,dc=local
sunAvailableDomainNames: domain.com
sunAvailableDomainNames: domain.local
sunAvailableDomainNames: ucs.domain.com
sunAvailableDomainNames: ucs.domain.local
preferredMailHost: imap.ucs.domain.com

dn: o=oucs-org,o=CommsHosting,o=domain.com,dc=domain,dc=local
sunAvailableDomainNames: domain.com
sunAvailableDomainNames: domain.local
sunAvailableDomainNames: ucs.domain.com
sunAvailableDomainNames: ucs.domain.local
icsDWPBackEndHosts: cal.ucs.domain.com
o: oucs-org
preferredMailHost: imap.ucs.domain.com

dn: o=msad-org,o=CommsHosting,o=domain.com,dc=domain,dc=local
sunAvailableDomainNames: domain.com
sunAvailableDomainNames: domain.local
sunAvailableDomainNames: ucs.domain.com
sunAvailableDomainNames: ucs.domain.local
icsDWPBackEndHosts: cal.ucs.domain.com
preferredMailHost: imap.ucs.domain.com
o: msad-org

The aliases are as follows:

domain.com - the customer's domain name as the system will be in the internet in the future

domain.local - the LAN domain

ucs.domain.com / ucs.domain.local - current name of the OUCS user-facing node; support for these names was added to be able to post test messages from LAN and internet so that they would find way to the OUCS box rather than the original server which it would replace eventually (i.e. posting to user@ucs.domain.com, whereas user@domain.com would be routed by all internet hosts, according to published DNS, to the legacy server which is still active now).