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?..
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@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"
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"
Input fn="insert-filter" method="POST" filter="sed-request"
###### Don't ask why not the correct way like so:
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.
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!
How have you defined the domain/domain aliases in LDAP? In particular, it is not enough to decorate just user entries with addresses with other domain names; you have to define a domain alias at the domain level in LDAP. Depending upon which Schema you're using (Schema 1 or Schema 2), domain aliases are set up a bit differently.
Also, it is possible to have "plain" domain aliases (another domain name which is totally synonymous), it is possible to have domain "up level" automatic aliasing, and it is possible to have overlappingly defined domains, where some users have addresses in both domains but other users don't.
Anyhow, if you don't have your domain aliasing (fully) set up, then it is possible to get mixed results, where sometimes, some lookups "work" (depending upon which
direction, from user to domain, or from domain to user, needs to happen, and depending upon caching of previously found results), but other lookups don't work.
The imsimta test -domain_map utility's "verify" and "enumerate" commands are one way to do a quick check of some basics of your domain definitions:
# imsimta test -domain_map
DOMAIN_MAP> enumerate -aliases
If you have a domain defined, you can also see some of its attributes via
DOMAIN_MAP> locate domain <domain-name>
though if it looks like you don't have your domain aliases fully setup, seeing the full LDIF for your domain entries may be more informative.
P.S. Just checked your version: the -aliases switch of enumerate was added for MS 7.4,
so you won't be able to use that particular command switch in your version.
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
%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 -aliases
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
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|^$'
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 firstname.lastname@example.org, whereas email@example.com would be routed by all internet hosts, according to published DNS, to the legacy server which is still active now).
looks to be due to the presence in the
dn: o=domain.com, dc=domain,dc=local
entry of both:
You should remove the associatedDomain: domain.com from this entry:
domain.com *is* the actual domain name, and you only should list
as aliases (associatedDomain values) the other, domain alias, names.
This is quite likely to cause problems.
The errors saying
are complaining that you have entries, apparently the o=CommsHosting ones,
that appear to Messaging Server's domain finding code (what test -domain_map
tests) that they "ought" to be actual domain entries; more precisely, you have
entries that have objectClass value(s) suitable for being actual domain entries,
but which then don't have a sunPreferredDomain attribute set. Note: This is not
a case where for your purposes you would or should set sunPreferredDomain on
those entries; rather, this is a case where I question what the purpose of those
entries is, and if you in fact really need to have them, then some objectClass
adjustment needs to happen.
I would like to see the full LDIF for these domain and domain-like entries, in
particular including just what objectClasses are (or aren't) present on them.
Now I'm not clear what this whole o=CommsHosting setup is supposed to be doing,
or where it "came from" in your setup. In particular, I don't work with
Delegated Admin: maybe Delegated Admin needs entries along these lines, or maybe
I would suspect there is something a bit off about the entries -- as in perhaps
some unnecessary-to-DA-and-causing-problems-for-other-components structuring
of the entries and/or setting of objectClasses -- since sites use DA without the
problems you're encountering. (By the way, note that I'm not concerned about the
sunAssignableDomains and sunAvailableDomains attributes you mentioned, as those
are not attributes that the MTA or authentication code care about -- that's
almost certainly the DA-specific stuff that DA cares about.)
However, if it does turn out that DA really "needs" the entries more or less as
is, there is a way to tell Messaging Server's domain-finding code (used by the
MTA and the authentication code for address/user resolution) to ignore
extraneous, "bogus" domain entries by doing some additional objectClass filtering
of the apparent domain entries. If necessary, that can be an approach.
But first it would be good to know: what is there (full LDIF), and does DA
really "need" it to be the way it is? If this is a test setup (?) then maybe
starting over with DA and defining the main domain name as domain.com, and adding
domain.local as an alias, instead of doing a conversion of the domain names, would
be a good idea to get "cleaner" directory entries.
For later: once you have the domain entries in good shape, note that you'll likely want
to take a look at the MTA's DOMAIN_UPLEVEL option, to see if it's of interest for
your needs. (Depending on whether you want all users to be able to use addresses
with all the domain aliases WITHOUT you having to explicitly set each as a user-level
alias, or whether you intend for only some of the users to be able to use some
of the domain aliases in addresses, DOMAIN_UPLEVEL can be helpful.) But
DOMAIN_UPLEVEL is a convenient help once domain entries are good: the domain
entries need to be clean first.