9 Replies Latest reply on Jul 23, 2013 5:48 PM by user12611146

    Convergence SSO fails for some logins


      Hello, a new problem with an OUCS 7u2 (unpatched) installation.


      This may be a case of "my bad", or may be a known issue (perhaps fixed in a later release) and would ring a bell?


      Our test users have several LDAP attributes by which they can be identified for login, including uid, employeenumber, mail, mailEquivalentAddress, mailAlternateAddress, and as far as I see, I did configure all programs with web-interfaced access (IWC, davserver, jiss, iim) to accept these as part of ugldap search filter. For the mail attributes we match the user-provided string as a full mail address or as a "base" for the mail addresses at our domains, i.e. "%s@*" or %s@domain.name).


      While these users can login properly into Convergence with any of these login strings, some functionality (messenger widget coming online, attachment folder not displaying) only seems to work, reliably and repeatably at least, when the login string is either the value of mail attribute, or is uid@domain.name - this does not even have to be the value of the mail attribute (although this string is one of the aliases, and by chance matches the icsCalendar LDAP attribute value - it is not in the login filter, and the WCAP logins often show the default "mail" value as the calendar account name). Any other valid strings, from the short UID to other mail aliases to the user identifiers in the mail addresses (characters before the "@" even if they are not a value of any other attribute), usually lead to the messenger remaining in the "Connecting..." stage forever, and sometimes to errors contacting the JISS server for attachments (though after last night's reconfiguration of LDAP filters across the test server, I can't reproduce this one issue anymore).


      Off the top of my head, it seems that Convergence may pass the originally provided user identifier (instead of determined uid or some other attribute) to SSO-login into other components. Apparently, (maybe due to my typos, or not) some components don't like these strings as login identifiers... I didn't see any complaints in the appserver or convergence or component logs, however.


      Perhaps I'm just missing something simple...


      Any ideas?


        • 1. Re: Convergence SSO fails for some logins

          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?..




          • 2. Re: Convergence SSO fails for some logins

            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

            • 3. Re: Convergence SSO fails for some logins

              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:

                          ### 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.



              //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!

              1 person found this helpful
              • 4. Re: Convergence SSO fails for some logins

                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> verify

                DOMAIN_MAP> enumerate

                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>

                DOMAIN_MAP> show


                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.






                • 5. Re: Convergence SSO fails for some logins

                  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.






                  1 person found this helpful
                  • 6. Re: Convergence SSO fails for some logins

                    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_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

                    • 7. Re: Convergence SSO fails for some logins

                      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?


                      • 8. Re: Convergence SSO fails for some logins

                        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).

                        • 9. Re: Convergence SSO fails for some logins

                          The error




                          looks to be due to the presence in the


                          dn: o=domain.com, dc=domain,dc=local


                          entry of both:


                          associatedDomain: domain.com

                          sunPreferredDomain: domain.com


                          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

                          it doesn't.


                          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.