Recover from log on locally domain setting

[MTNL]

Accidentally we enforced the log on locally option on the
domain security policy without any user .
Now no one is allowed to log in to the system
Kindly help us to come out of this.
thanks

 

[Diana Smith [MSFT]]

Hello,

To resolve this behavior, perform the following steps:



1. Connect to the problem Windows 2000-based computer's C$ share from
another network computer using the administrator account.

2. Open the %Systemroot%\Security\Database folder.

3. Rename the Secedit.sdb file.

4.

a. If the computer has Microsoft Windows 2000 Professional installed, a
Secedit.sdb file has to be copied from an operational Windows 2000
Professional-based computer.

b. If the computer has Microsoft Windows 2000 Server installed, a
Secedit.sdb file has to be copied from an operational Windows 2000
Server-based computer.NOTE: Another Secedit.sdb file from a similar Windows
2000-based, Windows 2000 Professional-based, or Windows 2000 Server-based
computer, is required. This file can be copied from another computer which
has a similar version.

5. Copy the new Secedit.sdb file to the %Systemroot%\Security\Database.

6. Restart the computer. You should now be able to log on locally.

If this does not work or you do not have a copy of secedit.sdb to copy, here
is an article that talks about ntrights that should assist you with this
problem:
279664 How to Set Logon User Rights with the Ntrights.exe Utility
http://support.microsoft.com/?id=279664

315276 How to Set Logon User Rights by Using the NTRights Utility
http://support.microsoft.com/?id=315276

Thank You.

Diana

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks Diana ,I will try that and come back to you

 

[Steven L Umbach]

You should still be able to logon to your domain controller since domain policy
should not override domain controller policy for user rights and change the setting
back. --- Steve

 

[MTNL]

Dear Diana,
I had renamed that file Secedit.sdb in the %Systemroot%
\Security\Database folder and copied a similar file to
that folder.but still the deadlock is persisting.

we dont have that Ntrights.exe Utility.Is there any other
way to come out of this deadlock.Please advice and help.
Thanks
MTNL

 

[MTNL]

Dear Steve,
The problem is we had not set the Domain Controller
Security Policies.
So the system is taking the domain security policies.
Is there any way to come out of it?

Thanks
MTNL

 

[Andrew Mitchell]

Dear Steve,
The problem is we had not set the Domain Controller
Security Policies.
So the system is taking the domain security policies.
Is there any way to come out of it?

I'm assuming you have done this via a group policy.
Can't you install the server tools on a client PC and remove the group policy
setting from there?

 

[Steven L Umbach]

By default user rights are assigned to domain controllers via Domain
Controller Security Policy which exempts them from changes to user rights in
domain policy. You should be able to logon to a domain controller to change
the domain policy. Did you try to logon to a domain controller?? If you can
not, see the KB link below on how to manually change user rights for Domain
Controller Security Policy which will allow you to logon to a domain
controller assuming they are still in the default domain controller
container. Be sure to read the whole article. --- Steve

http://support.microsoft.com/?kbid=267553

 

[MTNL]

Dear Andrew,
Please tell us how to install server toools and remove
group policy..
Thanks
MTNL

 

[Steven L Umbach]

Can you log onto a domain controller?? If you can you should be able to
reverse the policy setting that has you locked out for domain users.
Changing the domain policy for logon locally should NOT affect domain
controllers in a default installation.

If that does not work for some reason. Logon to a computer with a local
account that has domain administrator priviliges. You may need to create
that account first. The go to Network Places and find your domain
controller - preferrably the pdc fsmp role holder. Go to the sysvol share.
Find the domain name, go to policies, select the first one which should be
default domain policy and then go to machine/Microsoft/Windows Nt/secedit
and open the GptTmpl.inf file. Go down to the end where there is a heading
for [Privilige Rights]. Make sure you have a line that looks exactly like
this [ SeInteractiveLogonRight = *S-1-5-11 ] without the brackets. That
allows authenticated users to logon locally. If you have a line for [
SeDenyInteractiveLogonRight = ] with a sid number in it then delete the
whole line. After finishing that and saving it, hit the back button four
times and you should find the gpt.ini file for the domain GPO. Open it and
bump up the serial number by 10 and save it. Wait a few minutes nad try
rebooting one of your domain computers to see if you can logon. If that does
not work you will also have to do the same for the other GptTmpl.inf and
gpt.ini files for the other GPO's as they may be overriding the domain GPO.
Good luck. --- Steve

 

[MTNL]

Thanks Steve,
I ll try this and come back to you

-----Original Message-----
Can you log onto a domain controller?? If you can you should be able to
reverse the policy setting that has you locked out for domain users.
Changing the domain policy for logon locally should NOT affect domain
controllers in a default installation.

If that does not work for some reason. Logon to a computer with a local
account that has domain administrator priviliges. You may need to create
that account first. The go to Network Places and find your domain
controller - preferrably the pdc fsmp role holder. Go to the sysvol share.
Find the domain name, go to policies, select the first one which should be
default domain policy and then go to

machine/Microsoft/Windows Nt/secedit

and open the GptTmpl.inf file. Go down to the end where there is a heading
for [Privilige Rights]. Make sure you have a line that looks exactly like
this [ SeInteractiveLogonRight = *S-1-5-11 ] without the brackets. That
allows authenticated users to logon locally. If you have a line for [
SeDenyInteractiveLogonRight = ] with a sid number in it then delete the
whole line. After finishing that and saving it, hit the back button four
times and you should find the gpt.ini file for the domain GPO. Open it and
bump up the serial number by 10 and save it. Wait a few minutes nad try
rebooting one of your domain computers to see if you can logon. If that does
not work you will also have to do the same for the other GptTmpl.inf and
gpt.ini files for the other GPO's as they may be overriding the domain GPO.
Good luck. --- Steve

Dear Steve,
The problem is we had not set the Domain Controller
Security Policies.
So the system is taking the domain security policies.
Is there any way to come out of it?

Thanks
MTNL

.