Julien; there are some interesting conclusions in this message.
I'm looking at why mapiproxy gives me a DCERPC bind failure when I fill
in the realm of the specified credentials.
Part of the reason is that when I fill in the realm, kerberos can be used.
The other part of the reason is that kerberos fails; and I think the
answer is in these two packets:
Internet Protocol, Src: 10.42.0.139 (10.42.0.139), Dst: 10.42.0.1
(10.42.0.1)
Transmission Control Protocol, Src Port: 14992 (14992), Dst Port:
indigo-server (1176), Seq: 1449, Ack: 1, Len: 1178
DCE RPC Bind, Fragment: Single, FragLen: 2626, Call: 1
Version: 5
Version (minor): 0
Packet type: Bind (11)
Packet Flags: 0x03
0... .... = Object: Not set
.0.. .... = Maybe: Not set
..0. .... = Did Not Execute: Not set
...0 .... = Multiplex: Not set
.... 0... = Reserved: Not set
.... .0.. = Cancel Pending: Not set
.... ..1. = Last Frag: Set
.... ...1 = First Frag: Set
Data Representation: 10000000
Byte order: Little-endian (1)
Character: ASCII (0)
Floating-point: IEEE (0)
Frag Length: 2626
Auth Length: 2546
Call ID: 1
Max Xmit Frag: 5840
Max Recv Frag: 5840
Assoc Group: 0x00000000
Num Ctx Items: 1
Ctx Item[1]: ID:0
Context ID: 0
Num Trans Items: 1
Abstract Syntax: NSPI V56.0
Interface: NSPI UUID: f5cc5a18-4264-101a-8c59-08002b2f8426
Interface Ver: 56
Interface Ver Minor: 0
Transfer Syntax[1]: 8a885d04-1ceb-11c9-9fe8-08002b104860 V2
Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860
ver: 2
Auth type: SPNEGO (9)
Auth level: Connect (2)
Auth pad len: 0
Auth Rsrvd: 0
Auth Context ID: 1804289383
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
SPNEGO
negTokenInit
mechTypes: 3 items
Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft
Kerberos 5)
Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft
NTLM Security Support Provider)
mechToken:
6E8209AC308209A8A003020105A10302010EA20703050020...
krb5_blob:
6E8209AC308209A8A003020105A10302010EA20703050020...
Kerberos AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 20000000 (Mutual required)
.0.. .... .... .... .... .... .... .... =
Use Session Key: Do NOT use the session key to encrypt the ticket
..1. .... .... .... .... .... .... .... =
Mutual required: MUTUAL authentication is REQUIRED
Ticket
Tkt-vno: 5
Realm: GALAXY.TEST.DBAMSYSTEMS.LOCAL
Server Name (Service and Host): host/NOVA
Name-type: Service and Host (3)
Name: host
Name: NOVA
enc-part rc4-hmac
Encryption type: rc4-hmac (23)
Kvno: 3
enc-part:
698584C26468DF341CAB69BEDD44716634A2828C8BFEC2E0...
Authenticator rc4-hmac
Encryption type: rc4-hmac (23)
Authenticator data:
27942591FDA2996D02B4D1947120C01EC6ED15E0295861C9...
NOTE: that for kerberos it is trying to talk to NOVA which is the main
DC and real mail server; but also note that theRfrGetNewDSA call returns
machine "star.galaxy.test.dbamsystems.local" which is also a DC and used
to be the mail server.
Now in the response below note the failure:
error_code: KRB5KRB_AP_ERR_MODIFIED (41)
which (according to google) relates to the kerberos name in the response
packet being for star.galaxy.dbamsystems.local
Internet Protocol, Src: 10.42.0.1 (10.42.0.1), Dst: 10.42.0.139
(10.42.0.139)
Transmission Control Protocol, Src Port: indigo-server (1176), Dst Port:
14992 (14992), Seq: 1, Ack: 2627, Len: 249
DCE RPC Bind_ack, Fragment: Single, FragLen: 249, Call: 1
Version: 5
Version (minor): 0
Packet type: Bind_ack (12)
Packet Flags: 0x03
0... .... = Object: Not set
.0.. .... = Maybe: Not set
..0. .... = Did Not Execute: Not set
...0 .... = Multiplex: Not set
.... 0... = Reserved: Not set
.... .0.. = Cancel Pending: Not set
.... ..1. = Last Frag: Set
.... ...1 = First Frag: Set
Data Representation: 10000000
Byte order: Little-endian (1)rela
Character: ASCII (0)
Floating-point: IEEE (0)
Frag Length: 249
Auth Length: 181
Call ID: 1
Max Xmit Frag: 5840
Max Recv Frag: 5840
Assoc Group: 0x00018a5e
Scndry Addr len: 5
Scndry Addr: 1025
Num results: 1
Context ID[1]
Ack result: Acceptance (0)
Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860
Syntax ver: 2
Auth type: SPNEGO (9)rela
Auth level: Connect (2)
Auth pad len: 0
Auth Rsrvd: 0
Auth Context ID: 1804289383
GSS-API Generic Security Service Application Program Interface
SPNEGO
negTokenTarg
negResult: accept-incomplete (1)
supportedMech: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft
Kerberos 5)
responseToken:
60819406092A864886F71201020203007E8184308181A003...
krb5_blob:
60819406092A864886F71201020203007E8184308181A003...
KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_tok_id: KRB5_ERROR (0x0003)
Kerberos KRB-ERROR
Pvno: 5
MSG Type: KRB-ERROR (30)
stime: 2009-04-02 15:46:49 (UTC)
susec: 664879
error_code: KRB5KRB_AP_ERR_MODIFIED (41)
Realm: GALAXY.TEST.DBAMSYSTEMS.LOCAL
Server Name (Service and Host):
host/star.galaxy.test.dbamsystems.local
Name-type: Service and Host (3)
Name: host
Name: star.galaxy.test.dbamsystems.local
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.
The other question is how did Control-panel/Mail know to fallback to
Nova (and why not star?) when the krb bind was failing?
Sam
_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel
