|
Hi Jorge, That seems to be the crux of the problem:
we are expecting the NTLM behaviour, but Kerberos is the first try and failing.
The specific action that was failing was an attempt to add credentials from Domain_A
in your example to a member server in Domain_B. It failed using the GUI
(adding member to group) but then succeeded with a “net localgroup add”
command. Am still seeking permission to sniff the
DMZ belonging to Domain/Company B… Thanks everyone for your input! AL Al Maurer From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Almeida Pinto, Jorge de lets say the structure
is: CLIENT-DOMAIN_A
..... DC-DOMAIN_A
...... DC-DOMAIN_B
...... MEMBERSRV-DOMAIN_B if NTLM is used the order of authentication is: (1) CLIENT-DOMAIN_A wants to access MEMBERSRV-DOMAIN_B (2) CLIENT-DOMAIN_A connects
to MEMBERSRV-DOMAIN_B (3) MEMBERSRV-DOMAIN_B connects to DC-DOMAIN_B and asks do
you know: CLIENT-DOMAIN_A (4) DC-DOMAIN_B says NO, but I do trust DOMAIN_A. Let me
check. (5) DC-DOMAIN_B connects to DC-DOMAIN_A and asks do
you know: CLIENT-DOMAIN_A (6) DC-DOMAIN_A says: yes, it's OK (7) DC-DOMAIN_B sets up an access token for domain B for
CLIENT-DOMAIN_A. (8) CLIENT-DOMAIN_A accesses MEMBERSRV-DOMAIN_B if KERBEROS is used the order of authentication is: (1) CLIENT-DOMAIN_A wants to access MEMBERSRV-DOMAIN_B (2) CLIENT-DOMAIN_A connects to DC-DOMAIN_A and
asks for a ticket to access MEMBERSRV-DOMAIN_B (3) DC-DOMAIN_A says: let me check, just a sec. (4) DC-DOMAIN_A says: that server does not exist within
the domain or the forest. However I do have a trust with DOMAIN_B. Go to
DC-DOMAIN_B (5) CLIENT-DOMAIN_A connects to DC-DOMAIN_B
and asks for a ticket to access MEMBERSRV-DOMAIN_B (6) DC-DOMAIN_B says: let me check, just a sec. (7) DC-DOMAIN_B says: here's your ticket and access token.
have fun (8) CLIENT-DOMAIN_A accesses MEMBERSRV-DOMAIN_B the problem is that only DC-DOMAIN_A and DC-DOMAIN_B can
communicate through the firewall with each other. Other communication paths are
not available or possible because of the firewall configuration. Or did I miss something? Met vriendelijke
groeten / Kind regards, Ing. Jorge de Almeida
Pinto Senior Infrastructure
Consultant MVP Windows
Server - Directory Services LogicaCMG
Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : [EMAIL PROTECTED] From: [EMAIL PROTECTED]
on behalf of [EMAIL PROTECTED] Within a domain, when a user’s credentials are
presented to a member server, that member server communicates with the domain
controller to validate the creds. We have a cross-forest (cross–company; a divestiture)
trust set up that we are testing. A member server in the other
forest/domain and across the firewall is having trouble authenticating
credentials from our domain. Their DC works fine. Ports on the
firewall are only opened for the two domain controllers (one on each side). Here’s the question: in order to validate the
“foreign” credentials, should the member server be looking first to
its own DC, or is it trying to cross the firewall to find our DC? Based
in the preliminary traffic sampling so far, I think that’s what is
happening. Is that normal/expected behavior? TIA, AL Al Maurer
|
- RE: [ActiveDir] Communication across a ... Almeida Pinto, Jorge de
- RE: [ActiveDir] Communication acro... Myrick, Todd \(NIH/CC/DNA\) [E]
- RE: [ActiveDir] Communication ... Rocky Habeeb
- RE: [ActiveDir] Communicat... Simon Bembridge
- Re: [ActiveDir] Communicat... Al Mulnick
- RE: [ActiveDir] Communication acro... Jeff Salisbury
- RE: [ActiveDir] Communication acro... Olivarez, Sergio J Mr CTNOSC/GD-NS
- RE: [ActiveDir] Communication acro... al_maurer
- RE: [ActiveDir] Communication acro... Arthur Freyman
- RE: [ActiveDir] Communication acro... Myrick, Todd \(NIH/CC/DNA\) [E]
