| Title: | Windows NT |
| Notice: | See note 15.0 for HCL location |
| Moderator: | TARKIN::LIN .com::FOLEY |
| Created: | Thu Oct 31 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6086 |
| Total number of notes: | 31449 |
Hi folks,
We have hit a problem with logging on to one of our NT 4.0 Servers.
The only users who can log in interactively, or access the server
over the network, are those who are in the "administrators" or
"Domain Admins" groups. The error messages depend on the attempted
access method as follows:
Local log-in:
"The local policy of this system does not permit you to logon
interactively"
Double click on server in Network Neighborhood on a Workstation:
"\\servername is not accessible
The user is not allowed to log on from this workstation"
NET VIEW \\servername from a Workstation
"The user is not allowed to log on from this workstation
More help is available by typing NET HELPMSG 2240."
I've already checked all of the following potential causes, and
none of them seem to be at fault:
1) In User Manager for Domains, all users are enabled to log in to
any computer
2) The "log on locally" User Rights Policy is enabled for the
"Everyone" group
3) For any given user, adding them to the "administrators" or
"Domain Admins" group makes everything work just fine.
4) None of the security settings on the Server file system or in the
registry are obviously strange. (Basically "Everybody" has access).
We are running NT 4.0 Server with Service Pack 1; a TCP/IP network
(that is physically isolated from the rest of the world); DHCP,
WINS and DNS; SQL Server 6.5 and SMS 1.2.
The only "abnormal" thing that we have done is use the System
Policy Editor. I suspect that this may be part of the problem,
but I have no hard evidence. I've spent a good two days checking
through all the policy editor settings, as well as all the stuff
above, and I can't see any that should affect the system in this way.
Any help, hints or pointers will be highly appreciated. I know that
the last resort is to trash the system and re-install, but I need to
be sure of what went wrong so that it doesn't happen when we build
the deliverable system while the customer watches!
Thanks in advance,
Dave Wylie
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5770.1 | CANING::MTEAM | Tue Mar 04 1997 20:54 | 8 | ||
When you added "everyone" was it the "everyone" from your Machine or
"everyone" from the Domain that they are trying to log in from..
Even though it does not say servername\everyone.. I think that is
different than if you add digital1\everyone.
Jim Radziewicz
| |||||
| 5770.2 | It's a single Domain | 16.42.1.40::WylieD | Generic Specialist | Wed Mar 05 1997 01:46 | 25 |
Thanks for the suggestion Jim, but there is only the one domain! It's a very simple test setup, one Primary Domain Controller and two NT Workstation 4.0 client machines, both of which are members of the Domain. The fact that new users created in the domain on the PDC cannot log into that very same machine (unless they are put into one of the Admin groups) implies that something is very wrong with the security on the PDC. I even explicitly granted a brand new user the "log on locally" right, but this made no difference. We really do need to work out what caused this problem so that we don't hit it again - I probably only have time for one more trash/re-install cycle before the client gets to see it. Regards, Dave Wylie PS. I'm still very unhappy about the policy editor; I'm sure it did something strange to the system in addition to applying the policy! | |||||
| 5770.3 | Time to re-install NT | 16.42.1.40::WylieD | Generic Specialist | Thu Mar 06 1997 00:35 | 12 |
No progress on this problem, so we're going for the trash/re-install option. I'll be careful this time to check at each stage of our installation procedure that normal users have access to the server. If the same problem happens again at least I'll know what it was that triggered it. Wish me luck... Dave Wylie | |||||
| 5770.4 | Found It! | 16.42.1.40::WylieD | Generic Specialist | Fri Mar 07 1997 03:05 | 43 |
Ok, I've found it. After re-installing the system (which took most of Thursday), all worked fine. This morning, while accessing the machine from the network, the server crashed with a blue screen informing us that the security log was full and that it could not log an auditable event. After the automatic re-boot, I found that the situation described in .0 had come back. Armed with this "audit failure" clue, a search of the Microsoft Knowledge Base web-site revealed article Q140058, which provided the pointer that I needed. First time round, the audit crash must have happened when nobody was looking (perhaps overnight), so I didn't have this vital clue. In fact, the system should have been set NOT to automatically restart. Our system is set up with various security features, including having the system "CrashOnAuditFail". This is an entry that has to be manually added to the registry under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ and set to have the REG_DWORD value 1. When an audit fails, this causes the machine to crash as described above. However, what is not documented anywhere that I had previously seen is that after the re-boot, the value is changed to be 2. This indicates that auditing is not working, so normal users should not be allowed access. Administrators CAN access the system, otherwise it would not be possible to sort the problem out. Clearing the event log, using the registry editor to change the above value back to 1 then re-booting sorted out the problem. So now we know. Hope this info helps anybody else who is using the above security feature, and may therefore end up in the same situation. Dave Wylie. | |||||
| 5770.5 | Neat! | TARKIN::LIN | Bill Lin | Fri Mar 07 1997 04:14 | 0 |
| 5770.6 | User Rights may be an issue | PGREEN::SACKMANJ | Pedalo'ing the Internet | Tue Mar 11 1997 00:15 | 6 |
Another reason for being unable to login interactively is also in User
Maanager for Domains.
Under User Rights, one of the options is 'logon locally'. Note that
only the Administrators and xxx Operators groups have this right by
default.
Jon.
| |||||