On Fri, 2009-04-03 at 11:16 +0100, Sam Liddicott wrote: > In control-panel/Mail when I get the failure, it replaces the mapi-proxy > name I inserted and replaces it with NOVA, the real mail server. [How > did it know to do this?] > > BUT, if I tell mapiproxy that the next-hop binding should be star > (returned by RfrGetNewDSA from nova) instead of nova (the real mail > server) then I don't get the kerberos error and everything works > absolutely fine! > > > So I think one conclusion is that mapiproxy could perhaps follow the > RfrGetNewDSA result for the binding? > My network seemed to get this way because I moved the domain exchange > server from one DC to another DC.
Sam,
The RfrGetNewDSA function is part of the NSPIReferral API and is used
to locate the NSPI server. Following unconditionally this binding string
for any other services but NSPI one would be wrong.
However I think you pointed an interesting issue. How bad does mapiproxy
work within a clustered Exchange environment? That is obviously one
configuration I didn't have the opportunity to test extensively/at all
so far.
Mapiproxy uses a unique binding string for all exchange services and for
all auth mechanisms it supplies (specified/delegated/machine account) -
or should supply properly. That is obviously technically wrong when we
deal with clustered Exchange environments.
Let's take a real clustered Exchange use case:
- Server A: main Exchange server
- Server B: second Exchange server where a mailbox has been
moved
- Server C: third Exchange server with a replication of NSPI
server
- mapiproxy points on server A
RFR/NSPI case:
==============
When Outlook sends the RFRGetNewDSA call to mapiproxy:
1. mapiproxy relays the call to the real Exchange server A.
2. Server A replies and fill the network name of server C
3. mapiproxy receives the reply, then replace the real server
with its own FQDN name.
4. It forwards the reply to the client.
== Outlook think the real NSPI server IS mapiproxy ==
Case 1:
=======
If Outlook initiates a NEW connection, then the hack
needs to be much deeper. We would need to associate
accounts/usernames with the different servers
(NSPI/EMSMDB) we need to contact in order to serve users
requests.
Case 2:
=======
If Outlook alters the dcerpc context, then maybe
replacing the binding string within dcesrv_auth
structure samba is providing mapiproxy could do the
trick. I'm however yet unsure about potential side
effects when Outlook tries to alter the context once
again from NSPI session to open an EMSMDB connection.
From past experience - single remote server - Exchange
just fails to alter the context for different services
and Outlook needs to open a new connection (epmapper,
auth3, bind).
I can probably test case 2 pretty quickly to get sure whether it
works or not. However I'd be tempted to focus right now - maybe
I'm wrong - on case 1.
EMSMDB case:
============
I'm currently not 100% sure of what I states below. It is just
based on strong assumptions.
Now, let's say we have implemented case 1 and we have a database
linking the username to the servers its account and mailbox are
associated to. We could imagine something like:
User A:
NSPI location: Server C
Mailbox location: Server B
mapiproxy would still initially points to Server A in smb.conf
Knowing where the user's mailbox is physically located can -
afaik - only be known from Outlook once it has opened the
message store (Logon IDL call). The exchange server would reply
the server is not here and fill a "Redirect Response Buffer".
This IDL is not yet handled in exchange.idl, mostly because it
requires to hack ndr_mapi.c to write manual OpenMsgStore NDR
pull code for mapi_response. Furthermore I didn't have any test
case I could play with so far.
So Server A returns this redirect response buffer to Outlook and
tells its mailbox is located on Server B.
mapiproxy changes the server address in the reply so it points
to mapiproxy, then update its local database and associate
Server B to the mailbox location.
So far - and if all the above statements are correct -
everything is perfect ;-)
Two questions - which I couldn't find the answer for within MS
specs:
1. Does Outlook automatically connects Server B for any
further connections or does it contact Server A and wait
for the redirect response buffer?
2. If it directly contacts Server B, what would happen
if you move the mailbox once again and how mapiproxy
should behave?
>
> The other question is how did Control-panel/Mail know to fallback to
> Nova (and why not star?) when the krb bind was failing?
I'd need a pcap capture for this, but it may be related to mapiproxy not
handling properly what is detailed in the first part of the email.
---
Julien Kerihuel
j.kerih...@openchange.org
OpenChange Project Manager
GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list devel@lists.openchange.org http://mailman.openchange.org/listinfo/devel
