Description of problem: Similar to the F17 bug #834798 that was resolved, but F18 evolution seems to have regressed and doesn't do Kerberos MAPI, I see bug #913554 but I can't tell if they are getting further as they had an existing setup upgraded. Also still no dependency on KrbAuthDialog which would be I think helpful. Version-Release number of selected component (if applicable): 3.6.3-2 Exchange 2010 How reproducible: Every time Steps to Reproduce: 1. Using a new clean homedir 2. Starting evolution gives the Evolution Account Assistant 3. Type in details 4. When "Exchange MAPI" and all details are entered appropriately hit "Authenticate" 5. Evolution seems to permanently sit there with "Connecting to server, please wait" Actual results: Sits permanently at "Connecting to server, please wait" Expected results: Account gets authenticated and configured correctly. Additional info: Running with LIBMAPI_DEBUG=15 evolution &>log.txt ,generates no meaningful output just a few: (evolution:30632): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed Also Kerberos tickets for MAPI are appearing in the output of klist so it must be doing (or have done) something.
Thanks for a bug report. Could you try with this [1] test package, please? I hope it'll help. It contains also a patch which makes the LIBMAPI_DEBUG work for account Authentication phase too, thus you might see actual communication between server and the client. Please make sure you'll have installed latest samba too. With respect of KrbAuthDialog, it's rather hidden/soft dependency, probably not used by most of the evolution-mapi users, which is a reason for it not being pulled in as a hard dependency. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5054372
That's looking much better and I can now get in. Though I now have bug #913554 as my contacts, calendar and tasks are local ones only. We have a wrinkle with this too. We use a third party AD authentication system, that places it's Ticket Cache in /tmp/krb5cc_uid. If we have a running krb5-auth-dialog (which finds the Ticket Cache in /tmp/krb5cc_uid) then evolution finds the ticket cache. If krb5-auth-dialog isn't running and I run evolution from a shell which list valid tickets in the output of a klist, evolution doesn't connect and krb5-auth-dialog (spawned by Evolution) says tickets have expired. Does evolution have hard coded or attempt to drop back to the 'DIR::' style krb5 ticket caches? Any thoughts on this.
evolution-mapi uses D-Bus interface to talk to KrbAuthDialog, by passing the Realm as set in preferences (it's the only purpose of the realm, to have something to be passed into KrbAuthDialog). The passed-in value is simply username@realm. All the rest is led by samba, which is responsible for connecting to the server. I do not know how to help more here, I'm sorry.
I just got a confirmation from bug #913554 about that being working with Kerberos only, which makes me wonder whether it's related to something else. It seems to me that some samba version can have issues with Kerberos. I currently use samba 4.0.1, which seems to behave properly.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.