If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
"broken"/missing ACL's?
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 |
Ads |
#2
|
|||
|
|||
"broken"/missing ACL's?
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...b;EN-US;180094 --- lmhosts file http://support.microsoft.com/default...b;EN-US;158148 --- nltest "Maury Markowitz" wrote in message ... 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 |
#3
|
|||
|
|||
"broken"/missing ACL's?
I should also mention that there are many security settings that can cause a
problem with a NT4.0 in an Active Directory domain particularly with Windows 2003 domain controllers which by default require SMB signing. The link below explains many of the settings that can cause a problem. --- Steve http://support.microsoft.com/default...b;en-us;823659 "Steven L Umbach" wrote in message news 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...b;EN-US;180094 --- lmhosts file http://support.microsoft.com/default...b;EN-US;158148 --- nltest "Maury Markowitz" wrote in message ... 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 |
#4
|
|||
|
|||
"broken"/missing ACL's?
"Steven L Umbach" wrote:
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. 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 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 |
#5
|
|||
|
|||
"broken"/missing ACL's?
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 |
#6
|
|||
|
|||
"broken"/missing ACL's?
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...en-us%3B291382 --- Active Directory DNS FAQ that must be followed for a domain to function correctly. "Maury Markowitz" wrote in message ... 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 |
#7
|
|||
|
|||
"broken"/missing ACL's? - SOLVED, ANSWER
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 |
#8
|
|||
|
|||
"broken"/missing ACL's? - SOLVED, ANSWER
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 "Maury Markowitz" wrote in message ... 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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
ACL Checker? | Wm. Scott Miller | Security and Administration with Windows XP | 4 | July 26th 05 07:34 PM |
ACL's Security | Sudeep Sachdev | Security and Administration with Windows XP | 1 | November 30th 04 12:38 PM |
XP Local/domain/admin security (NTFS) issues/madness | Chris | General XP issues or comments | 1 | October 12th 04 02:37 AM |