HP/Microsoft support came through. Apparently, this
problem is related to a known issue with TS and Winlogon.exe in Windows 2003.
To fix it one needs a hotfix version of Winlogon.exe
(http://support.microsoft.com/?id=821929)
and a reg hack to make the winlogon process ignore errors when attempting
to read the user's AD TS configuration data (http://support.microsoft.com/?id=815266).
-Stuart
From: Fuller, Stuart [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 10:51 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Windows 2003 Server, Firewalls, Terminal Services , and AD Trusts
Guido,
Thanks for reply and the link to the article - very
useful.
However, the TS port really isn't the issue. I can TS
to the member server with no problems. The problem is that when I log into
the member server via TS with a trusted account I get rejected. With
Windows 2000 TS, the trusted account logon request gets passed through the
firewall via the member server DC's and the holes open between the member server
DC's and the trusted DC's. With 2003 TS, it looks like the member server
needs to contact the trusted DC's directly. I don't really want to
open the ports on the firewall to allow traffic from the member server to
the trusted DC. I would prefer that 2003 like 2000 is able to "proxy"
the logon request via the member server DC's.
The odd thing about this is that the problem only occurs
with a TS logon. If I use a trusted account and logon at the physical
console I don't have any problems. Also, any shares and other security bits
seem to work just find. I am stumped on this so that's why the query to
the list. I do have a ticket in with our Microsoft support provider HP but
so far no solution or explanation.
-Stuart
From: GRILLENMEIER,GUIDO (HP-Germany,ex1) [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 11, 2003 2:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Windows 2003 Server, Firewalls, Terminal Services , and AD Trusts
Stuart - I haven't run into this myself and am not really
aware of particular changes in 2003 that would make this happen as
described. However, the new MS KB on port requirements for the various
services used on the system may give some insight (http://support.microsoft.com/default.aspx?scid=kb;en-us;832017).
For Terminal Services the following port is
required:
System
service name: TermService
|
Application
protocol |
Protocol |
Ports |
|
Terminal
Services |
TCP |
3389 |
Not sure, if this is of any help to you, but I would simply
check if the authentication works correctly after opening that port on your
firewall configuration.
/Guido
From: Fuller, Stuart [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 11. Dezember 2003 17:08
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Windows 2003 Server, Firewalls, Terminal Services, and AD Trusts
We are moving
ahead with deploying Windows 2003 servers and I have run into an issue with Terminal Services
logons, trusts, and firewalls. From
what I can tell Windows 2003 needs to directly contact a trusted DC for
authorization when processing a TS logon (remote admin mode). This bites
when that trusted DC is behind a firewall and your logon attempt
bounces. Let me
explain the setup a bit
more then I'll go into the problem. (Apologies in advance for the long
email...)
Setup:
Domain A in
Forest A has a one-way external trust with Domain B in Forest B where B
trusts domain A. Domain B is separated
from A by a stateful-aware firewall. The firewall is configured to
allow all traffic to pass "out" from A to B and to generally deny all
traffic from B to A. The exception to this rule is that the DC's
in Domain B have port access to all of the DC's in Domain A.
Domain B DNS is configured for
forward lookup to Domain A DNS. Domain B DNS zone information is also
configured as a secondary zone in Domain A DNS (e.g. domain A and
B can lookup each others DNS information).
A member server in
Domain B is Windows 2000 or Windows 2003. The administrators group for
that server is configured to contain Domain Local groups from Domain B.
Those domain local groups contain selected administrator user accounts
from domain A. All Domain A and B DC's are Windows 2000 SP4 and both
domains are in native mode.
Issue:
To administer the member server in Domain B, a domain A
account is used. This works
great with Windows 2000 member servers and an admin can successfully log in at the console or TS to the
box.
The problem is that on the new Windows
2003 servers, the TS bit no
longer work with Domain A admin
accounts. The Domain A admin can logon via the console just fine,
but when attempting a TS logon the admin will get a "The specified
domain either does not exist or could not be contacted" error message. The
TS logon attempt also generates an event log message on the 2003
server. The event that is recorded is eventID 1219 with a message of
"Logon rejected for <domain>\<userID>. Unable to obtain
Terminal Server User Configuration. Error: the specified domain either
does not exist or could not be contacted."
Attempts at resolution:
I have played around with the system policy setting to
see if it was some odd 2003 signed security problem with no luck. I have
also talked with HP/Microsoft support and so far they have had no enlightened
response to the issue. I have also looked
at KB822142 but that seems to only apply to 2000 and not 2003.
I have have captured NetMon traces for the 2003 server
and found some interesting stuff. For the console logon, the server
will attempt LDAP (port 389) connections but then fail over to NTLM
and succeed with the logon via the trust via the domain B DC. For TS
logons, the server keeps banging away with a direct LDAP connection to the
domain A DC's and never fails over to NTLM. From all appearances, TS logon
seems to require direct LDAP connection back to the trusted DC's instead of
proxying the logon via the domain B DC's.
Questions for the group
mind:
1. Has anyone else run into this
yet?
2. Why would the TS logon method be different than a
regular console logon? Why shouldn't TS on 2003 also fail over to NTLM
like it does on 2000?
3. Any speculation or
WAGS on a possible fix?
4. Given that the
strategic goal of the organization is to reduce the number of user accounts and
consolidate, how does one manage servers and distributed security in a cross
forest / firewall scenario?
Thanks in advance,
Stuart
Fuller
AD
wannabee
State of
Montana
