aaronburro Sup, B 53065 Posts user info edit post |
I've got a Win2K server environment that I am tinkering with at home that is having a problem. I made a user whose sole purpose was to log onto the domain controller server and perform one task. I set him to be able to log on only to the domain controller in Active Directory. here's the next stuff I did:
I set him to be able logon locally on all three of the security profiles : Domain Controller, Local, and Domain. I also set him to be denied network access on all three of the above. Then I logged into two other Win2K server machines and set them to deny that user local logon and network access as well, only in the local policy (since its the only one, duh).
The last step was apparently fairly stupid, as it locked all users out of the other two servers locally. I could access all the network resources, but noone could logon locally, not even the domain and local administrators.
So, I went back and undid all of the security settings on the domain controller and one of the afflicted servers freed up. The other seems to have freed up, but not completely. When I restart the server, I don't get the ability to logon, as the little "Press Ctl-Alt-Del" window never shows up. All the services that are supposed to run on that server are running, but I just can't get that prompt.
Any ideas as to what is fucked up? 8/10/2005 1:54:09 PM |
esgargs Suspended 97470 Posts user info edit post |
how about we switch jobs and I'll do my work without asking for help on TWW? 8/10/2005 1:59:12 PM |
Noen All American 31346 Posts user info edit post |
he asked an informed question douchebag
I'll do some research on it and get back to ya 8/10/2005 2:06:19 PM |
aaronburro Sup, B 53065 Posts user info edit post |
just because I think its worth mentioning, safe mode w/ networking works fine... 8/10/2005 2:07:10 PM |
aaronburro Sup, B 53065 Posts user info edit post |
btw, it appears to be a problem w/ the APC PowerChute software. Here' s a link to the related issue
http://nam-en.apc.com/cgi-bin/nam_en.cfg/php/enduser/std_adp.php?p_sid=q2ApQmKh&p_lva=&p_faqid=7202 8/10/2005 5:33:55 PM |
smoothcrim Universal Magnetic! 18966 Posts user info edit post |
that was worded not so clearly (terminology maybe?) but, are you saying you created him as a user in AD and then locked him out of the domain? is the guy supposed to physically use the domain controller? are you setting him up so he can only log into the DC locally (via a local admin account) and not putting his user in the domain admins group?
I'm sure I'm not the only one confused 8/10/2005 5:38:54 PM |
aaronburro Sup, B 53065 Posts user info edit post |
well, initially I set the user up as a domain user in AD but limited his logon via AD to only the domain controller.
That didn't let him log onto the server, so I tinkered w/ the local security policy on the domain controller, and that didn't work either. So I also changed the Domain Security Policy and the Domain Controller Security Policy as well, setting him to have local logon ability. That did the trick. But, like an idiot, I went over to the other two servers and set their local security policies to deny that user local logon abilities. I'm not 100% sure what that locked everyone else out, too, but... It did.
The APC software bug seems to explain it quite well, though, as it is likely that the APC service is getting run before the workstation / interactive logon service. The APC service is likely stalling and not completely starting, or at least taking an assload of time to finish starting. Somehow that keeps any service scheduled to run after the APC service from starting. The glitch only occurred on one server because I rebooted that server to get into safe mode to try and fix the local logon problem in there. The other server never got rebooted, so the logon problem was fixed when I simply restored the Domain Controller Security policy and Domain Security policy back to their original condition by removing the added entries.
But yeah, I was prolly a bit confusing up there for a second or two. Thankfully this problem occurred on my company's play servers instead of the real damn things Of course, those servers have the same potential problem, so... I gotta fix that tomorrow. Testing on the play servers first, though
Out of curiosity, as I toyed with the idea of overwriting the security policy manually (probably not a good idea, but it was going to be used as a last resort before re-imaging the servers), the local security policy is stored in WinNT\Security\Database, right? Cause I used the logs in Security\Logs to try and diagnose the problem from a local security policy standpoint beforfe I logged in via safe mode. In case you were wondering, even though I couldn't log onto the workstations, I could access their shared folders, so I was fishing around through there to see if I could find the solution in a fucked up or missing file. 8/10/2005 5:55:14 PM |
smoothcrim Universal Magnetic! 18966 Posts user info edit post |
it sounds like you want to setup a flex profile for this user. you want him to be able to login and do stuff from his workstation and at the dc's physical console, but you don't want him to be able mess with the DC at all, right? In general it's a bad thing to have anyone but domain and forest admins be able to login to the DC directly. you could give him a local non-admin account on the DC and he could remote desktop or login remotely and at the dc's console without a large threat if you really lock down his account, but I wouldn't trust any end user not to do something stupid and crash the DC. 8/11/2005 12:52:50 AM |
aaronburro Sup, B 53065 Posts user info edit post |
well, i was thinking that as long as he is a limited user he shouldn't be able mess w/ the AD at all. Locking down only the directories that he needs read access to shouldn't be a problem, but still...
you think I should not have him logging on locally to the DC, even if he is sufficiently crippled so as to prevent him from changing everything? 8/11/2005 1:10:37 PM |