Avoid Exchange login dialog

[Bernie]

Is there any way to authenticate to an Exchange server without any user
interaction?

The exact situation is as follows:
I have an XP machine with Outlook 2003 that is connected to an Exchange
2003 server, and my program is supposed to enumerate the user's Exchange
folders as well as use the GetSharedDefaultFolder method to access another
user's inbox. The code works fine, except that Outlook requires the user
to enter the Exchange password manually, and I can't for the life of me
figure out how to avoid that. The Save Password checkbox on the dialog has
no effect either.
Both user name and password are known to my application, I just can't
figure out what to do with them.
My current approach is to create a separate thread that looks for login
windows and enters the Exchange password by simulating user input.
However, this is somewhat error-prone and doesn't work at all when the
workstation is locked (I assume it's because the login window can't get
the focus which is required to receive keyboard input).

I'm somewhat of a newbie in this area, so apologies if I'm posting this to
the wrong place. I'll also gladly accept an RTFM-style reply, as long as
it's accompanied by a hint where to find an FM that actually answers my
question (neither Google nor MSDN have proved too helpful on this
particular subject, or maybe I just didn't look in the right place).
Anyways, all help would be *much* appreciated.

 

[Dan Mitchell]

Both user name and password are known to my application, I just can't
figure out what to do with them.

In that case, you should be able to use LogonUser/ImpersonateLoggedOnUser
to give your thread the identity of that other person. However, that's not
recommended; see

http://blogs.msdn.com/stephen_griffin/archive/2005/04/13/407925.aspx

for more on that. (note: the MSDN blog server seems particularly flaky
today, but that link should work given a bit of persistence)

-- dan

 

[Bernie]

Thank you, but that's not exactly what I'm looking for. The Exchange login
is different from the Windows login, in fact the client and the server
aren't even on the same domain. Hence, I don't think there's any way to
avoid explicitly passing the username/password combination to the Exchange
server via Outlook.

Still, thanks for your time

 

[Dan Mitchell]

Thank you, but that's not exactly what I'm looking for. The Exchange
login is different from the Windows login, in fact the client and the
server aren't even on the same domain.

Oh, I see. Maybe this is one of the cases where the profilePassword
argument to CDO1.21's Session.Logon() / lpszPassword to MAPILogonEx would
be useful -- it would certainly be worth a try, at least.

-- dan

 

[Dmitry Streblechenko]

No, that password is only used by the PST provider.
There is no way to bypass the login dialog if the current user and Exchange
are on different domains with no trust, at least not when using the Outlook
Object Model.
You can use LogonUser/ImpersonateLoggedOnUser in case of CDO 1.21 or
Extended MAPI, but that won't work with OOM as it runs in a separate process
space (outlook.exe), not in-proc. Plus it needs to see the profile to be
able to log in; and the profiles are stored on a per Windows user basis.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

 

[Dan Mitchell]

No, that password is only used by the PST provider.

Oh, right, now I remember. Sorry, I was confused there.

You can use LogonUser/ImpersonateLoggedOnUser in case of CDO 1.21 or
Extended MAPI, but that won't work with OOM as it runs in a separate
process space (outlook.exe), not in-proc. Plus it needs to see the
profile to be able to log in; and the profiles are stored on a per
Windows user basis.

That's the sort of nasty stuff that Steve Griffin's blog entry is talking
about.. Somewhere I have a post saved away by a guy who does all sorts of
grim things copying tokens around and tweaking ACLs on bits of the
registry, which seems like more trouble than it's worth.

-- dan

 

[Bernie]

Oh dear. I start to think there simply is no way to do what I want. Well,
thanks for your time anyway! I guess it's time to try some less
recommended approaches.

- Off to play with DLL injection