"broken"/missing ACL's?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have been tracking down a problem for a few days now, and I finally
understand what's going on...

On one machine in our office running NT4, any attempt to add ACLs for any
reason fails. The user/group/etc. can be added as you would expect -- you
select the user/group/etc from the "pick list" for the domain, and then click
Add, at which point it appears in the ACL list. However when you immediately
open the list again, that entry has been replaced with the "unknown user"
icon and the ACL name itself is a long string of alphanums.

I have seen this behaviour in the past when you delete a user, at which
point the account goes "unknown". However the ones I am attempting to apply
are valid, and in widespread use. The problem effects both file ACL's as well
as DCOM settings, which is where I saw it the first time.

It _seems_ like the machine is having problems talking to the domain
controller. The reason I say this is that I notice if I open an ACL list on
my machine, the list will show these same sort of unknown icons for a second
or two before being replaced by the correct name and icon. I assume this
happens as the local machine communicates with the domain server and updates
its display. On the problem machine, this update never occurs.

It can't be that simple though, because the machine can still work on the
network fine, and seems to have credentials.

Anyone seen this before?

Maury
 
I think you are right in that the computer is having problems contacting the
domain controller consistently. Look in the logs via Event Viewer to see if
anything helpful is recorded there. Since NT4.0 uses only netbios over
tcp/ip name resolution you need to make sure that wins is set up correctly
on the network, that the NT4.0 computer is a wins client, and the domain
controller is a wins client. You might be able to get by without using wins
but wins would be more reliable. Another possibility is to try lmhosts file
entries for the domain controller as shown in the link below. If problems
persist I would suspect a bad network adapter, flaky drivers for the network
adapter, bad CAT5 cable, or even a problem with the switch port. Nltest
/query can be used to check the secure channel to the domain
ontroller. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;180094 --- lmhosts
file
http://support.microsoft.com/default.aspx?scid=kb;EN-US;158148 --- nltest
 
Steven L Umbach said:
anything helpful is recorded there. Since NT4.0 uses only netbios over
tcp/ip name resolution you need to make sure that wins is set up correctly
on the network, that the NT4.0 computer is a wins client, and the domain
controller is a wins client.
Click to expand...

I'm not sure this is something I know how to do. But before we go there...
adapter, bad CAT5 cable, or even a problem with the switch port. Nltest
/query can be used to check the secure channel to the domain
ontroller. --- Steve
Click to expand...

I ran this and got "ERROR_ACCESS_DENIED". The nltest readme (the one you
pointed me to) claims this happens after a computer account has been reset.
This HAS happened, but it happened several days ago. How do we clear this?

Just for fun I restated netlogin and the tcphelper services, but neither had
any effect.

Maury
 
Ok, here's some much more useful information: Event Viewer is showing a
continued stream of errors from NetLogin, "failed to authenticate with xxx",
where xxx is one of the domain controllers on our network.

So what exactly does this mean, or is this another one of the infamous "one
of a million" error messages?

Just to make things more interesting (and me look dumber), the machine in
question is not NT4, but 2k. Yes, it was always 2k. no, I don't know how I
could have possibly confused the two.

Maury
 
OK. In that case I would run the support tool netdiag on it to see what it
finds and I suspect some problems. Probably the easiest fix would be to make
sure that the computer is using ONLY domain controllers as it's preferred
dns servers in tcp/ip properties and as shown with ipconfig /all, verify
that it can ping the domain controllers at least by IP address, and then
logon as a local administrator, unjoin the computer from the domain, reboot
it, join it to the domain again, reboot again and then see if things get
better. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 ---
Active Directory DNS FAQ that must be followed for a domain to function
correctly.
 
Ok, I got this to work...

Basically the ACL's are looked up on the domain controller (DC) via a hidden
private network channel. The computer logs into the DC over this channel
using a private password, which the DC and client exchange/resync every so
often (30 days typically). If the DC is upgraded, it can sometimes fail to
sync up the clients on the next sync.

In this case the client was just about to have to change when the DC was
upgraded to 2003. So either end expected different passwords and could not
log in. The only real solution to this is to remove the client from the
domain (put it into a workgroup) and reboot. Then you remove that machine
from the DC's machine list, and then have the client re-join the domain. This
resets the passwords, and presto.

Phew!

Maury
 
That is pretty much what I thought. Netdiag would have shown that right
away. Glad you got it resolved. You probably could have used netdom to do
the same but unless you are familiar with netdom often it is just easier to
remove from domain and rejoin. The secure channel is used for pass through
authentication in a domain. --- Steve
 
Back
Top