Windows Server 2003 Security Guide issue

[Guest]

I've a windows 2003 domain with N.1 Domain Controller machine.
I've noted that when I apply the Enterprise Client Domain Controller Policy
defined in the Windwos Server 2003 Security Guide it is impossible to connect
to any share on a workstation machine that is no joined to the domain
(standalone machine) and it is impossible too connect to any share on the
Domain Controller Machine from the same workstation.
If I remove the policy all issues are removed an I can connect from and to
the standalone workstation.
The question is: wich setting is responsible of this behaviour?
Thanks in advance.
Cosimo MERCURO

 

[Steven L Umbach]

What is the client?? More than likely it is due to forcing SMB signing
[digitally] sign communications for client and server or lan manager
authentication level security options. Since kerberos can not be used
outside the domain the computers must use a common authentication method
such as lm/ntlm/ntlmv2. If you enable auditing of logon events on both
computers you may be able to get more information from information in failed
logon attempts. --- Steve

 

[Guest]

I've noted the same beaviour even if I attempt to connect from the DC1
machine to any other client joined to domain (and not only to standalone
machine).
In other words if I attempt to connect from DC1 (with enterprise policy
enabled) to any other machine (joined or not to domain) it is impossible and
a message says: "...the user may not have the request authorizzations...."
Instead if I wont to connect to DC1 machine from any other domain client
machine this is possible, but if I wont to connect to DC1 from a standalone
machine with Windows 2000 Pro (not joined to domain) this is impossible.
At last if I wont to connect from standalone windows 2000 Pro workstatio to
another client in the domain, this is possible.
I've enabled the account logon event policy but when the issues occours, no
events are logged not on the server (DC1) nor on the clients.

 

[Roger Abell]

Have you yet examined behavors when loosening/adjusting the
polices Steve has indicated, or the SChannel security level policy?
The behavior seems to indicate that server is requiring a level of
schannel or communication signing that other machines are not
configured to allow, hence communications never get as far as
attempting login authentication

 

[Steven L Umbach]

First off when you connect if you are not successful with the computer name,
try the computer IP address as in \\xxx.xxx.xxx.xxx\share and make sure you
can ping the server to establish network connectivity. If you can connect
with IP address but not with name you have a name resolution problem.
Otherwise my guess is still that the problem is related to incompatible
security options. What you could do is run the Security Configuration and
Analysis mmc snapin tool to analyze the servers security policy using the
setup security.inf template as the comparison template and then view
security options after the analysis to find which settings differ from the
setup security.inf template. Those settings would be suspect as to the
connectivity problem. A domain controllers default security policy consists
of the setup security.inf template and then the dcsecurity.inf template is
applied during the dcpromo process. However the dcsecurity.inf template does
not have any security options defined so it would not be necessary to import
it into the database for the analysis. The link below shows how to use the
SCA mmc tool and note that with Windows 2003 you can AND should create a
"rollback" template with the secedit command to implement if you need to
rollback a security template application though it will not include settings
for file system, registry, restricted groups, or services. The rollback
template needs to be created BEFORE you change security policy. --- Steve

http://www.lokbox.net/SecureXP/secAnalysis.asp -- how to use SCA mmc tool.
http://support.microsoft.com/default.aspx?scid=kb;en-us;823659 -- problems
related to incompatible security settings.