Re: Assigning Security through W2k3 to W2k Trusted Domains

Thanks for the resolution info - sort of goes back to the first post, ey?
Glad you are whole, but I sit scratching my head at the resolution and
W2k only impact in non-Kerberos situation.


"DevGD" <DevGD@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5D67D07A-9305-4893-A840-0EED6FCF6EA1@xxxxxxxxxxxxxxxx
FIXED!..
Thanks for the help Roger.

Here is what finally fixed the issue.

I had to remove and reload DNS zone for DomainB on DNS server in DomainA.
Even though it looked like all the records were there. Apparently, there
was
a SRV record either missing or corupt. And that record is only needed by
W2K.
Once I did the remove and reload, I validated the trust again and now I
can
assign NTFS security on all machines, including W2k.

Thanks again for the responses.

DEVGD

"Roger Abell [MVP]" wrote:

So it is just always that character of message.
That certainly indicates to me that there is a failure to form SChannel
with the foreign domain, or failure otherwise in the authentication (of
who you are, that you should be allowed to pull down usr/grp info)
and its communications (SSP negotiation, packet signing characteristics).

That goes back to the policies I have indicated, to ability to locate the
needed SRV records in DNS, or otherwise resolve location.

(thinking aloud . . .)
Given that use of the same account in the same scenario except logged
into W2k tells us it is not issue with the domains or their trusts, with
location resolution, with grants to the account being used, etc. and
tends to indicate something about the W2k in that domain.
Those W2k would not have their schannel or some aspects of their
SSP negotiations set if that is being done by group policy, while the
W2k3/XP of the domain would. Other than that and the encryption
algorithms available to W2k being more limited that for W2k3/XP

Now, the trusts in play must be NTLM based given the level of
the forests, and there is one of the policies new to W2k3 that does
control the NTLM SSPI minimum security levels - so that could
be a prime suspect.

As FYI, the following article lists out the usual suspects for the
no logon servers issues when there is no trust involved, most of
which get at having valid Kerberos support, which should not
be in play here in you case, and what is not Kerberos tied is
ruled out by the success of the same actions by the same account
on a non-W2k of the same domain.
http://support.microsoft.com/kb/837513/en-us

So, it sounds like the SSPI negotiation attempt is ending with
a SEC_E_NO_AUTHENTICATING_AUTHORITY return
code, and the only available SSP is NTLM.
The question is, how to get more info out from the failure sequence
to see where is the fix. I only pull up dev MSDN info trying to
search down those lines, but your issue is not in what is being
done but in how the W2k server's config fails to support it.





"DevGD" <DevGD@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:646F808F-CC12-4FCA-9357-99014660BD4D@xxxxxxxxxxxxxxxx
When I am in DomainA, I try to assign NTFS permissions on a folder
located
on
a member server. I want to add a user from DomainB.

Example:
On the file server running windows 2000 in DomainA (2003) I do the
following:
Right-click on folder
select security tab
click location and select DomainB
I get the following error:
"Could not display objects from this location because of the following
error:
No authority could be contacted for authentication. "

I can browse and assign NTFS security for a user/group from DomainB on
all
windows 2003 servers and the one DC that is Windows2000 in DomainA. The
issue
only seems to reside on Windows 2000 Member servers; two to be exact.

I can not browse the trusted domain to assign NTFS security.

Does that help? Any ideas?

Thanks,

DevGD

"Roger Abell [MVP]" wrote:

I cannot see how a member reboot would matter, but then I also
do not see what is the issue :-)
When you attempt to, say, add a user to a local group on the
W2k member, just what is it that you experience and refer to
as not being able to do it?.

"DevGD" <DevGD@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6998644E-7FF0-4874-B0EE-F75CB03391AD@xxxxxxxxxxxxxxxx
Third time must be the charm. On DomainA (2003), I went to the w2k
DC
and
validated the trust for a third time. This time, after validating
fine,
it
allowed me to assign security on that domain controller. But I still
can
not
assign security on member servers running windows 2000. Can you
think
of
anything else I can try? Would I have to reboot the member server?

Thanks,
DevGD

"Roger Abell [MVP]" wrote:

I named the specific ones, about 2/3s of which are not understood
by
W2k and would not affect them. If you know that you have not
altered
the settings then these are not it. However, if someone has these
could
be involved (again, difficult to think through the asymmetry
however)
as
these control the ability to communicate for
authentication/control.

"DevGD" <DevGD@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D7A318E3-201C-4FAF-97CC-1D87D7BD7FB9@xxxxxxxxxxxxxxxx
Could it really be a policy issue? One thing I failed to mention
is
that
the
trust was orginally in place before the upgrade to 2003 domain on
domanA.
Assigning security worked before that upgrade and where the
security
is
assigned, before the upgrade, seems to still be working. I will
double
check
that though. Is there something in particular in a security
policy
that
you
might this would be causing the issue? I am amazed that it works
on
the
w2k3
servers but not the w2k servers.

Thanks
DevGD

"Roger Abell [MVP]" wrote:

Hmmm . . . while I do not see how the following could account
to the observed asymmetry I would still check the effective
group
policy settings in the Security Options part of Computer
policies.
Specifically I would be looking at policies understood by W2k3
but not by W2k, and in particular I would be looking at the
Domain
Member policies regarding secure channel signing and encryption,
and also at the Network client and server policies for digital
signing
and the Network security policies for minimum session security
for
NTLM SSP

"DevGD" <DevGD@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6F48EF3F-F4C1-49BE-8856-50CD2507AE88@xxxxxxxxxxxxxxxx
Each domain has a DNS zone for the other trusted domain. The
trust
can
be
validated and I can assign security on any pc or server on
DomainB
from
DomainA. In DomainA(2003 domain), I can assign security on all
pcs
and
server
except for servers or pcs running windows 2000.

Example:

I have a windows 2003 file server and a windows 2000 file
server
in
DomainA.
On the windows 2003 file server, I can assign all the
security I
want
from
DomainB. But on the windows 2000 server I can not assign
anything.

Does Windows 2000 browse or check authentication differently
then
W2K3
or
XP?

Thanks

DevGD

"Roger Abell [MVP]" wrote:

Make sure that the DNS zones for all involved domains are
available for name resolution, such as by conditional
forwarders
or zone transfers between the DNS servers supporting the two
forests.

--
Roger Abell
Microsoft MVP (Windows Server : Security)

"DevGD" <DevGD@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BA74DE88-7770-4844-BB2D-D390A986C1B8@xxxxxxxxxxxxxxxx
Situation:
I have created a trust between two domains in two different
forests.
DomainA
is a mixed Windows 2003 domain. DomainB is native Windows
2000.
The
trust
can
be validated and seems to be working in every way. I have
validated
on
both
ends of the trust. There is no firewall blocking the
servers.

Problem:
When I try to add access for a user or security group from
DomainB
to a
folder on a server running w2K on DomainA, I get the
following
error:

"Could not display objects from this location because of
the
following
error:
No authority could be contacted for authentication. "

I can do the same steps on a windows 2003 server and it
browses
the
domain
and adds the security just fine.

Also, I can assign security on any server or PC on DomainB
with
groups
or
users from DomainA. OS does not seem to matter.

Process I am using to assign security
Right-click on folder, select security tab, click location
and
select
DomainB. This is when I get the error.

Please help.

Thanks
DevGD




















.

Relevant Pages

  • SecurityFocus Microsoft Newsletter #164
    ... Got Storage Security Risks? ... MICROSOFT VULNERABILITY SUMMARY ... Chat Client FTP Server Default Username Credential Weak... ... NetServe Web Server is a compact web server for Microsoft Windows ...
    (Focus-Microsoft)
  • Re: im being held in memory
    ... How can I harden my computer or server to secure it from hackers? ... Use firewall software and hardware and antivirus software that is ... Follow the instructions for hardening Windows and IIS at ... Install all service packs and security fixes from Microsoft and otherwise ...
    (microsoft.public.security)
  • 2003 to NT Domain Trust not working.
    ... the Windows 2000 domain. ... PDC tries to create a trust. ... The domain contains an NT Server 4.0 PDC, ... dom2K domain controllers. ...
    (microsoft.public.win2000.networking)
  • MS and security: good effort but no cigar
    ... build upon the progress it's already made in security. ... The low-hanging fruit of millions of insecure Windows machines ... Then there's the issue of poorly secured server applications. ... and execute external virus and filtering ...
    (microsoft.public.windowsxp.general)
  • SecurityFocus Microsoft Newsletter #167
    ... MICROSOFT VULNERABILITY SUMMARY ... Multiple Vendor XML Parser SOAP Server Denial Of Service Vul... ... Proactive Windows Security Explorer ...
    (Focus-Microsoft)