Восстановление контроллера домена windows 2008 r2 - Windowsa.top

ipmanyak

Цитата:

repadmin /showrepl

[more]
Repadmin: running command /showrepl against full DC localhost

DIS\MZ3

DSA Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL

Site Options: (none)

DSA object GUID: 79a0e382-2465-4c23-b4ef-2e00a1561207

DSA invocationID: 3fd1401b-f09c-46b6-a9dc-e2b5076b7129

==== INBOUND NEIGHBORS ======================================

DC=mz,DC=intra

DIS\DC1 via RPC

DSA object GUID: ed40e239-a588-4281-88d7-2194e8c5016a

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 07:24:35.

DIS\MZ2 via RPC

DSA object GUID: eee91c6c-a3ff-41f2-835b-be2784b6eb4e

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 07:24:40.

CN=Configuration,DC=mz,DC=intra

DIS\DC1 via RPC

DSA object GUID: ed40e239-a588-4281-88d7-2194e8c5016a

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

87 consecutive failure(s).

Last success @ 2015-04-01 06:57:42.

DIS\MZ2 via RPC

DSA object GUID: eee91c6c-a3ff-41f2-835b-be2784b6eb4e

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 06:57:42.

CN=Schema,CN=Configuration,DC=mz,DC=intra

DIS\DC1 via RPC

DSA object GUID: ed40e239-a588-4281-88d7-2194e8c5016a

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 06:57:42.

DIS\MZ2 via RPC

DSA object GUID: eee91c6c-a3ff-41f2-835b-be2784b6eb4e

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 06:57:42.

DC=DomainDnsZones,DC=mz,DC=intra

DIS\DC1 via RPC

DSA object GUID: ed40e239-a588-4281-88d7-2194e8c5016a

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 07:24:06.

DIS\MZ2 via RPC

DSA object GUID: eee91c6c-a3ff-41f2-835b-be2784b6eb4e

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 07:24:27.

DC=ForestDnsZones,DC=mz,DC=intra

DIS\DC1 via RPC

DSA object GUID: ed40e239-a588-4281-88d7-2194e8c5016a

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 06:57:42.

DIS\MZ2 via RPC

DSA object GUID: eee91c6c-a3ff-41f2-835b-be2784b6eb4e

Last attempt @ 2015-04-24 07:48:43 failed, result 8457 (0x2109):

The destination server is currently rejecting replication requests.

88 consecutive failure(s).

Last success @ 2015-04-01 06:57:42.

Source: DIS\MZ2

******* 88 CONSECUTIVE FAILURES since 2015-04-01 07:24:40

Last error: 8457 (0x2109):

The destination server is currently rejecting replication requests.

Source: DIS\DC1

******* 88 CONSECUTIVE FAILURES since 2015-04-01 07:24:35

Last error: 8457 (0x2109):

The destination server is currently rejecting replication requests.
[/more]

Цитата:

dcdiag /v

[more]

Directory Server Diagnosis

Performing initial setup:

Trying to find home server…

* Verifying that the local machine MZ3, is a Directory Server.
Home Server = MZ3

* Connecting to directory service on server MZ3.

* Identified AD Forest.
Collecting AD specific global data
* Collecting site info.

Calling ldap_search_init_page(hld,CN=Sites,CN=Configuration,DC=mz,DC=intra,LDAP_SCOPE_SUBTREE,(objectCategory=ntDSSiteSettings),…….
The previous call succeeded
Iterating through the sites
Looking at base site object: CN=NTDS Site Settings,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
Getting ISTG and options for the site
* Identifying all servers.

Calling ldap_search_init_page(hld,CN=Sites,CN=Configuration,DC=mz,DC=intra,LDAP_SCOPE_SUBTREE,(objectClass=ntDSDsa),…….
The previous call succeeded….
The previous call succeeded
Iterating through the list of servers
Getting information for the server CN=NTDS Settings,CN=DC1,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
objectGuid obtained
InvocationID obtained
dnsHostname obtained
site info obtained
All the info for the server collected
Getting information for the server CN=NTDS Settings,CN=MZ2,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
objectGuid obtained
InvocationID obtained
dnsHostname obtained
site info obtained
All the info for the server collected
Getting information for the server CN=NTDS Settings,CN=MZ3,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
objectGuid obtained
InvocationID obtained
dnsHostname obtained
site info obtained
All the info for the server collected
* Identifying all NC cross-refs.

* Found 3 DC(s). Testing 1 of them.

Done gathering initial info.

Doing initial required tests

Testing server: DIS\MZ3

Starting test: Connectivity

* Active Directory LDAP Services Check
Determining IP4 connectivity
* Active Directory RPC Services Check
……………………. MZ3 passed test Connectivity

Doing primary tests

Testing server: DIS\MZ3

Starting test: Advertising

Warning: DsGetDcName returned information for \\MZ2.mz.intra, when we

were trying to reach MZ3.

SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.

……………………. MZ3 failed test Advertising

Test omitted by user request: CheckSecurityError

Test omitted by user request: CutoffServers

Starting test: FrsEvent

* The File Replication Service Event log test
There are warning or error events within the last 24 hours after the

SYSVOL has been shared. Failing SYSVOL replication problems may cause

Group Policy problems.
A warning event occurred. EventID: 0x800034FA

Time Generated: 04/23/2015 23:19:34

Event String:

Following is the summary of warnings and errors encountered by File Replication Service while polling the Domain Controller MZ3.mz.intra for FRS replica set configuration information.

Could not find computer object for this computer. Will try again at next polling cycle.

A warning event occurred. EventID: 0x800034FA

Time Generated: 04/23/2015 23:28:09

Event String:

Following is the summary of warnings and errors encountered by File Replication Service while polling the Domain Controller MZ3.mz.intra for FRS replica set configuration information.

Could not bind to a Domain Controller. Will try again at next polling cycle.

……………………. MZ3 passed test FrsEvent

Starting test: DFSREvent

The DFS Replication Event Log.
Skip the test because the server is running FRS.

……………………. MZ3 passed test DFSREvent

Starting test: SysVolCheck

* The File Replication Service SYSVOL ready test
File Replication Service’s SYSVOL is ready
……………………. MZ3 passed test SysVolCheck

Starting test: KccEvent

* The KCC Event log test
Found no KCC errors in «Directory Service» Event log in the last 15 minutes.
……………………. MZ3 passed test KccEvent

Starting test: KnowsOfRoleHolders

Role Schema Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
[DC1] DsBindWithSpnEx() failed with error -2146893022,

The target principal name is incorrect..
Warning: DC1 is the Schema Owner, but is not responding to DS RPC

Bind.

[DC1] LDAP bind failed with error 8341,

A directory service error has occurred..
Warning: DC1 is the Schema Owner, but is not responding to LDAP Bind.

Role Domain Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
Warning: DC1 is the Domain Owner, but is not responding to DS RPC

Bind.

Warning: DC1 is the Domain Owner, but is not responding to LDAP Bind.

Role PDC Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
Warning: DC1 is the PDC Owner, but is not responding to DS RPC Bind.

Warning: DC1 is the PDC Owner, but is not responding to LDAP Bind.

Role Rid Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
Warning: DC1 is the Rid Owner, but is not responding to DS RPC Bind.

Warning: DC1 is the Rid Owner, but is not responding to LDAP Bind.

Role Infrastructure Update Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra
Warning: DC1 is the Infrastructure Update Owner, but is not responding

to DS RPC Bind.

Warning: DC1 is the Infrastructure Update Owner, but is not responding

to LDAP Bind.

……………………. MZ3 failed test KnowsOfRoleHolders

Starting test: MachineAccount

Checking machine account for DC MZ3 on DC MZ3.
* SPN found :LDAP/MZ3.mz.intra/mz.intra
* SPN found :LDAP/MZ3.mz.intra
* SPN found :LDAP/MZ3
* SPN found :LDAP/MZ3.mz.intra/MZ
* SPN found :LDAP/79a0e382-2465-4c23-b4ef-2e00a1561207._msdcs.mz.intra
* SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/79a0e382-2465-4c23-b4ef-2e00a1561207/mz.intra
* SPN found :HOST/MZ3.mz.intra/mz.intra
* SPN found :HOST/MZ3.mz.intra
* SPN found :HOST/MZ3
* SPN found :HOST/MZ3.mz.intra/MZ
* SPN found :GC/MZ3.mz.intra/mz.intra
……………………. MZ3 passed test MachineAccount

Starting test: NCSecDesc

* Security Permissions check for all NC’s on DC MZ3.
The forest is not ready for RODC. Will skip checking ERODC ACEs.
* Security Permissions Check for

DC=ForestDnsZones,DC=mz,DC=intra
(NDNC,Version 3)
* Security Permissions Check for

DC=DomainDnsZones,DC=mz,DC=intra
(NDNC,Version 3)
* Security Permissions Check for

CN=Schema,CN=Configuration,DC=mz,DC=intra
(Schema,Version 3)
* Security Permissions Check for

CN=Configuration,DC=mz,DC=intra
(Configuration,Version 3)
* Security Permissions Check for

DC=mz,DC=intra
(Domain,Version 3)
……………………. MZ3 passed test NCSecDesc

Starting test: NetLogons

* Network Logons Privileges Check
Verified share \\MZ3\netlogon
Verified share \\MZ3\sysvol
……………………. MZ3 passed test NetLogons

Starting test: ObjectsReplicated

MZ3 is in domain DC=mz,DC=intra
Checking for CN=MZ3,OU=Domain Controllers,DC=mz,DC=intra in domain DC=mz,DC=intra on 1 servers
Object is up-to-date on all servers.
Checking for CN=NTDS Settings,CN=MZ3,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra in domain CN=Configuration,DC=mz,DC=intra on 1 servers
Object is up-to-date on all servers.
……………………. MZ3 passed test ObjectsReplicated

Test omitted by user request: OutboundSecureChannels

Starting test: Replications

* Replications Check
[Replications Check,Replications Check] Inbound replication is

disabled.

To correct, run «repadmin /options MZ3 -DISABLE_INBOUND_REPL»

[Replications Check,MZ3] Outbound replication is disabled.

To correct, run «repadmin /options MZ3 -DISABLE_OUTBOUND_REPL»

……………………. MZ3 failed test Replications

Starting test: RidManager

* Available RID Pool for the Domain is 33607 to 1073741823
* DC1.mz.intra is the RID Master
……………………. MZ3 failed test RidManager

Starting test: Services

* Checking Service: EventSystem
* Checking Service: RpcSs
* Checking Service: NTDS
* Checking Service: DnsCache
* Checking Service: NtFrs
* Checking Service: IsmServ
* Checking Service: kdc
* Checking Service: SamSs
* Checking Service: LanmanServer
* Checking Service: LanmanWorkstation
* Checking Service: w32time
w32time Service is stopped on [MZ3]

* Checking Service: NETLOGON
NETLOGON Service is paused on [MZ3]

……………………. MZ3 failed test Services

Starting test: SystemLog

* The System Event log test
An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:16:36

Event String:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

An error event occurred. EventID: 0xC00038D6

Time Generated: 04/24/2015 07:18:55

Event String:

The DFS Namespace service could not initialize cross forest trust information on this domain controller, but it will periodically retry the operation. The return code is in the record data.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:21:19

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc1$. The target name used was ldap/DC1.mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:21:36

Event String:

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:26:35

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc1$. The target name used was E3514235-4B06-11D1-AB04-00C04FC2DCD2/ed40e239-a588-4281-88d7-2194e8c5016a/mz.intra@mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:26:37

Event String:

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:26:50

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz2$. The target name used was E3514235-4B06-11D1-AB04-00C04FC2DCD2/eee91c6c-a3ff-41f2-835b-be2784b6eb4e/mz.intra@mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:28:27

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz3$. The target name used was cifs/MZ3.mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:29:12

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz2$. The target name used was LDAP/MZ2.mz.intra/mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:29:12

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz2$. The target name used was LDAP/MZ2.mz.intra/MZ. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:31:38

Event String:

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:34:28

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz3$. The target name used was LDAP/MZ3. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 07:34:28

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc1$. The target name used was DNS/dc1.mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:36:39

Event String:

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:41:40

Event String:

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:46:40

Event String:

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:51:42

Event String:

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 07:56:43

Event String:

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 08:01:44

Event String:

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 08:03:13

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz3$. The target name used was ldap/MZ3.mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 08:04:19

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz2$. The target name used was cifs/MZ2.mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 08:06:44

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz2$. The target name used was LDAP/MZ2.mz.intra/mz.intra@MZ.INTRA. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 08:06:45

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server mz2$. The target name used was ldap/MZ2.mz.intra/mz.intra@MZ.INTRA. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 08:06:45

Event String:

An error event occurred. EventID: 0x000003EE

Time Generated: 04/24/2015 08:11:46

Event String:

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 08:15:36

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc1$. The target name used was LDAP/ed40e239-a588-4281-88d7-2194e8c5016a._msdcs.mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

An error event occurred. EventID: 0x40000004

Time Generated: 04/24/2015 08:15:36

Event String:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc1$. The target name used was ldap/dc1.mz.intra. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (MZ.INTRA) is different from the client domain (MZ.INTRA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

……………………. MZ3 failed test SystemLog

Test omitted by user request: Topology

Test omitted by user request: VerifyEnterpriseReferences

Starting test: VerifyReferences

The system object reference (serverReference)

CN=MZ3,OU=Domain Controllers,DC=mz,DC=intra and backlink on

CN=MZ3,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra are

correct.
The system object reference (serverReferenceBL)

CN=MZ3,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=mz,DC=intra

and backlink on

CN=NTDS Settings,CN=MZ3,CN=Servers,CN=DIS,CN=Sites,CN=Configuration,DC=mz,DC=intra

are correct.
The system object reference (frsComputerReferenceBL)

CN=MZ3,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=mz,DC=intra

and backlink on CN=MZ3,OU=Domain Controllers,DC=mz,DC=intra are

correct.
……………………. MZ3 passed test VerifyReferences

Test omitted by user request: VerifyReplicas

Test omitted by user request: DNS

Running partition tests on : ForestDnsZones

Starting test: CheckSDRefDom

……………………. ForestDnsZones passed test CheckSDRefDom

Starting test: CrossRefValidation

……………………. ForestDnsZones passed test

CrossRefValidation

Running partition tests on : DomainDnsZones

Starting test: CheckSDRefDom

……………………. DomainDnsZones passed test CheckSDRefDom

Starting test: CrossRefValidation

……………………. DomainDnsZones passed test

CrossRefValidation

Running partition tests on : Schema

Starting test: CheckSDRefDom

……………………. Schema passed test CheckSDRefDom

Starting test: CrossRefValidation

……………………. Schema passed test CrossRefValidation

Running partition tests on : Configuration

Starting test: CheckSDRefDom

……………………. Configuration passed test CheckSDRefDom

Starting test: CrossRefValidation

……………………. Configuration passed test CrossRefValidation

Running partition tests on : mz

Starting test: CheckSDRefDom

……………………. mz passed test CheckSDRefDom

Starting test: CrossRefValidation

……………………. mz passed test CrossRefValidation

Running enterprise tests on : mz.intra

Test omitted by user request: DNS

Starting test: LocatorCheck

[MZ2] LDAP bind failed with error 8341,

A directory service error has occurred..
Warning: Couldn’t verify this server as a GC in this servers AD.
GC Name: \\MZ2.mz.intra

Locator Flags: 0xe00071fd
Error: The server returned by DsGetDcName() did not match

DsListRoles() for the PDC

PDC Name: \\MZ2.mz.intra
Locator Flags: 0xe00071fd
Time Server Name: \\MZ2.mz.intra
Locator Flags: 0xe00071fd
Preferred Time Server Name: \\MZ2.mz.intra
Locator Flags: 0xe00071fd
KDC Name: \\MZ2.mz.intra
Locator Flags: 0xe00071fd
……………………. mz.intra passed test LocatorCheck

Starting test: Intersite

Skipping site DIS, this site is outside the scope provided by the

command line arguments provided.
……………………. mz.intra passed test Intersite
[/more]

Цитата:

dcdiag /test:replications

[more]

Directory Server Diagnosis

Performing initial setup:

Trying to find home server…

Home Server = MZ3

* Identified AD Forest.
Done gathering initial info.

Doing initial required tests

Testing server: DIS\MZ3

Starting test: Connectivity

……………………. MZ3 passed test Connectivity

Doing primary tests

Testing server: DIS\MZ3

Starting test: Replications

[Replications Check,Replications Check] Inbound replication is

disabled.

To correct, run «repadmin /options MZ3 -DISABLE_INBOUND_REPL»

[Replications Check,MZ3] Outbound replication is disabled.

To correct, run «repadmin /options MZ3 -DISABLE_OUTBOUND_REPL»

……………………. MZ3 failed test Replications

Running partition tests on : ForestDnsZones

Running partition tests on : DomainDnsZones

Running partition tests on : Schema

Running partition tests on : Configuration

Running partition tests on : mz

Running enterprise tests on : mz.intra
[/more]

Цитата:

Если на серваке ничего ценного нет, то проще и быстрее вывести его из доменконтроллеров и поднять заново. Но без репликации может не дать вывести нормально и придется принудительно выводить

На серваке нет ничего ценного. Принудительно DC я выводил не раз, не привыкать.

Цитата:

How to temporarily stabilize the domain SYSVOL tree ?

Нет, не пробовал. Показалось рискованным.

Источник

В этой статье мы покажем, как восстановить контроллер домена Active Directory из резервной копии System State (см. статью Резервное копирование Active Directory) и рассмотрим типы и принципы восстановления DC в AD.

Содержание:

Развертывание нового контроллера домена AD через репликацию
Полномочное и неполномочное восстановление Active Directory
Восстановление контроллера домена AD из system state бэкапа
Восстановление отдельных объектов в Active Directory

При выходе из строя контроллера домена, даже если у вас актуальный бэкап, нужно выбрать сценарий восстановления, который вы будете использовать. Это зависит от того, есть ли у вас в сети другие исправные контроллеры домена, доступны ли они по сети с площадки со сломанным DC и цела ли база Active Directory на них.

Развертывание нового контроллера домена AD через репликацию

Если у вас развернуто несколько контроллеров домена (а это рекомендуемая конфигурация для Active Directory), вместо восстановления неисправного сервера с ролью DC из бэкапа, бывает проще развернуть на площадке новый контроллер домена.

Если размер базы ADDS небольшой и другой DC доступен по скоростному каналу, это намного быстрее, чем восстанавливать DC из бэкапа. Старый контроллер нужно просто удалить из AD (если на вышедшем из строя DC были запущены роли FSMO, нужно их предварительно передать на другой сервер).

После повышения сервера до DC, новый контроллера домена синхронизирует (реплицирует) базу данных ntds.dit, объекты GPO, содержимое папки SYSVOL и другие объекты AD с других DC, оставшихся доступными онлайн. Это самый простой способ восстановления работоспособности DC, который гарантирует что вы не внесете непоправимых изменений в AD.

Полномочное и неполномочное восстановление Active Directory

Есть два типа восстановления службы каталогов Active Directory Domain Services из резервной копии, в которых нужно четко разобраться перед началом восстановления:

Authoritative Restore (полномочное или авторитетно восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Такие восстановленные объекты будут считаться более новыми другими DC, и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно!!!
При полномочном восстановлении вы потеряете все изменения в AD, произошедших с момента создания бэкапа (членство в группах AD, атрибуты Exchange и т.д.).
Non-Authoritative Restore (неполномочное или не-авторитиативное восстановление) – способ используется при выходе из строя физического/виртуального сервера, на котором развернут DC. Восстановленный контроллер домена после развертывания из бэкапа сообщает другим DC, что он восстановлен из резервной копии и ему нужны последние изменения в AD (для DC создается новый DSA Invocation ID). Этот способ восстановления можно использовать на удаленных площадках, когда сложно сразу реплицировать большую базу AD по медленному WAN каналу; или когда на сервере имелись какие-то важные данные или приложения.

Восстановление контроллера домена AD из system state бэкапа

Предположим, что в домене имелся только один DC, который стал недоступен вследствие выхода из строя физического сервера. У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.

Подготовьте новый сервер (физический или виртуальный) для развертывания DC из бэкапа:

На новом сервере должна быть установлена та же самая версия Windows Server, что на неисправном DC
Выполните чистую установку Windows Server. Не нужно пока задавать ему имя компьютера (hostname) старого DC и IP адрес.
Установите роль Active Directory Domain Services (не настраивая ее) и компонент Windows Server Backup. Можно установить эти компоненты из Server Manager или с помощью PowerShell:
Install-WindowsFeature -Name AD-Domain-Services, Windows-Server-Backup

Чтобы приступить к восстановлению Active Directory, нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите
msconfig
и на вкладе Boot выберите Safe Boot -> Active Directory repair. Или выполните команды:

bcdedit /set safeboot dsrepair shutdown /r /t 0

Картинка с сайта: winitpro.ru

После перезагрузки сервер перейдет в безопасный режим DSRM. Запустите консоль управления Windows Server Backup (
wbadmin.msc
) и в правом меню выберите Recover.

В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).

Выберите диск, на котором находится резервная копия DC, или укажите UNC путь к сетевой папке, содержащей WindowsImageBackup. Например
\\FileServer1\Backup\DC1
.

UNC сетевой путь к каталогу с резевной копией DC

Если вы хотите использовать для восстановления резервную копию с локального диска, нужно поместить каталог

WindowsImageBackup

в корень диска. Проверить наличие резервных копий на диске с помощью команды:

wbadmin get versions -backupTarget:D:

Выберите дату, на которую нужно восстановить резервную копию.

выберите дату создания резевной копии состояния контроллера домена AD

Укажите, что вы восстанавливаете состояние System State.

Выберите для восстановления «Исходное размещение» (Original location) и обязательно установите галочку «Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files). (напоминаю что мы рассматриваем сценарий авторитативного восстановления AD, когда в сети единственный DC, других исправных контроллеров домена нет!!).

Если эта опция отключена, будет выполнено non-authoritative восстановление.

авторитативное восстановление Perform an authoritative restore of Active Directory files

Система покажет предупреждение, что эта резервная копия другого сервера, и что при восстановлении на другом сервере может не завестись. Продолжаем.

бэкап от другого сервера контроллера домена

Согласитесь с еще одним предупреждением:

Windows Server Backup

Note: This recovery option will cause replicated content on the local server to re-synchronize after recovery. This may cause potential latency or outage issues.

This recovery option will cause replicated content on the local server to re-synchronize after recovery

После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет автоматически изменено на имя DC в бэкапе).

После перезагрузки, войдите на сервер с локальной учтённой записью администратора DSRM. Указав имя пользователя в формате
.\administrator

wbadmin - восстановление контроллера домена AD

Теперь можно загрузить DC в обычном режиме, отключив загрузку DSRM из
msconfig
или командой:

bcdedit /deletevalue safeboot

Авторизуйтесь на сервере под учетной записью с правами администратора домена. (если не знаете пароль администратора домена, его можно сбросить).

На данный момент служба ADDS еще не работает. При попытке запустить оснастку ADUC, появится ошибка:

Active Directory Domain Services
Naming information cannot be located for the following reason:
The server is not operational.

Выводит список опубликованных общих папок на сервере командой:

net share

Как вы видите, отсутствуют сетевые сетевых папки SYSVOL и NETLOGON.

Чтобы исправить ошибку:

Запустите regedit.exe;
Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Измените значение параметра SysvolReady с 0 на 1;

Картинка с сайта: winitpro.ru
Потом перезапустите службу NetLogon:
net stop netlogon & net start netlogon

Картинка с сайта: winitpro.ru

Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.

консоль aduc на восстановленном контроллере домена

Итак, вы успешно восстановили свой контроллер домен AD в режиме Authoritative Restore. Теперь все объекты в Active Directory будут автоматически реплицированы на другие контроллеры домена.

Восстановление отдельных объектов в Active Directory

Если вы случайно удалили какой-то объект в AD, не обязательно восстанавливать его из резервной копии. В Active Directory можно настроить корзину AD, из которой в течении 180 дней (значение по умолчанию для tombstoneLifetime) можно восстановить удаленный объект домена с помощью командлета
Restore-ADObject
или из оснастки Active Directory Administrative Center.

Если время захоронения уже просрочено, или ActiveDirectory RecycleBin не включена, вы можете восстановить отдельные объекты AD в режиме авторитетного восстановления. Для этого в режиме DSRM после восстановления DC из бэкапа нужно воспользоваться утилитой
ntdsutil
.

Выведите список доступных резервных копий:
wbadmin get versions
Запустите восстановление выбранной резервной копии:
wbadmin start systemstaterecovery –version:[your_version]
Подтвердите восстановление DC (в не-авторитативном режиме);
После перезагрузки запустите:
ntdsutil
activate instance ntds
authoritative restore

Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:

restore subtree "OU=Users,DC=winitpro,DC=ru"

Или один объект:

restore object "cn=Test,OU=Users,DC=winitpro,DC=ru"

Данная команда запретит репликацию указанных объектов с других контроллеров домена и увеличит USN объекта на 100000.

Выйдите из ntdsutil:
quit

Загрузите контроллер домена в обычном режиме и убедитесь, что удаленный объект AD был восстановлен.

Источник

Архив номеров / 2009 / Выпуск №6 (79) / Резервирование и восстановление объектов Active Directory в Windows Server 2008/2008 R2

Рубрика:

Администрирование /
Продукты и решения

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

Сергей Яремчук

Резервирование и восстановление объектов
Active Directory в Windows Server 2008/2008 R2

Служба Active Directory является стандартом в корпоративных сетях, работающих под управлением Windows. Обеспечивая администратора эффективными инструментами, внешне простая в использовании, она является тем не менее довольно сложной по своей структуре и составу. К тому же никто не застрахован от сбоев в работе операционной системы, программ, отказа «железа» или ошибки человека. Поэтому нужно быть всегда готовым к тому, что придется предпринять меры по восстановлению работы в целом или отдельных элементов.

О необходимости резервного копирования

В каждой новой версии Windows Server появляются новые инструменты, упрощающие и автоматизирующие процесс управления, с которыми может справиться даже начинающий администратор. Одним из распространенных мнений среди таких «специалистов» является вообще отказ от резервирования контроллеров доменов. Аргумент простой. В организациях среднего и крупного размеров используется несколько контроллеров доменов, это аксиома. Вероятность того, что в один день выйдут из строя все, практически равна нулю. Если только их не вынесут по постановлению прокурора или воспользовавшись ошибкой в организации охраны, но этот случай, согласитесь, из ряда вон выходящий. Поэтому если выходит из строя один контроллер домена, все остальные работают в штатном режиме, а ему на замену подготавливается новый сервер. Отчасти они правы, но резервирование хотя бы двух контроллеров (на случай ошибки), имеющих роли FSMO (Flexible single-master operations, операции с одним исполнителем), все же обязательно. Так рекомендуют Microsoft и здравый смысл. Причем есть еще один главный довод в пользу резервирования. Простота управления приводит к росту процента ошибок. Удалить случайно объект Active Directory довольно просто. И необязательно это может быть умышленное действие, это может произойти, например, в результате ошибки при выполнении скрипта. И чтобы восстановить все настройки, потребуется приложить некоторые усилия.

Если ошибка обнаружена не сразу и изменение уже реплицировалось на другие контроллеры, в этой ситуации вам и понадобится резервная копия. Я уже не говорю о небольших организациях с одним контроллером домена.

Документом, показывающим возможности по резервированию и восстановлению данных в Windows Server 2008, является статья Джила Киркпатрика (Gil Kirkpatrick) «Резервное копирование и восстановление Active Directory в Windows Server 2008» в [1], которую и рекомендую к прочтению. Но если вопросы резервирования расписаны полностью, то восстановление показано, на мой взгляд, несколько поверхностно и не дает полной картины. Эта статья, собственно, и появилась из заметок, составленных на тот крайний случай.

Система архивации данных Windows Server

В Windows Server 2008 на замену NT Backup пришел абсолютно новый компонент «Система архивации данных Windows Server» (Windows Server Backup, WBS), основанный на VSS (Volume Shadow Copy Service, сервис теневого копирования тома). WBS – довольно мощное приложение, позволяющее восстанавливать систему, в том числе и на другой комьютер, поддерживающее некоторые сервисы, в списке которых значится и AD.

Установить WBS просто, следует лишь активировать компонент «Возможности системы архивации данных в Windows Server» плюс подпункт «Система архивации данных Windows Server». Последний включает MMC-консоль управления и новое средство командной строки Wbadmin. Дополнительно доступен пункт «Программы командной строки», который включает сценарии PowerShell, позволяющие создавать и управлять резервными копиями.

В командной строке установка выглядит еще проще:

> servermanagercmd -install Backup-Features

Или в Server Core:

> ocsetup WindowsServerBackup

Управлять резервированием можно из MMC-консоли или в командной строке. Так, чтобы создать резервную копию критичных томов, следует ввести:

> wbadmin Start Backup -backupTarget:E: -allCritical

С полной копией, думаю, все понятно. В контексте статьи нас больше интересует резервное копирование состояния системы при помощи параметра SystemStateBackup. Кстати, в первых сборках Windows Server 2008 этой функции не было, а через MMC она недоступна:

> wbadmin Start SystemStateBackup -backupTarget:E:

В этом случае производится пофайловое копирование состояния системы и некоторых сервисов, в числе которых есть и AD. Самое неудобное в этом случае, что каждый раз приходится создавать полную копию (свежеустановленная система приблизительно 7 Гб), а процесс происходит несколько медленнее, чем обычное резервирование. Но зато восстановить такую копию можно на другой компьютер с идентичной конфигурацией.

В команде копирование производится на другой том. Но в KB944530 [2] рассказано, как разрешить возможность резервного копирования на любой том. Для этого нужно добавить параметр типа DWORD с именем AllowSSBTo AnyVolume и значением 1 в ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup.

С резервированием обычно здесь проблем не возникает, все просто и понятно, трудности начинаются, когда необходимо восстановить работоспособность AD или случайно удаленных объектов. Использование SystemState-копий позволяет обойтись без восстановления всей системы, а просто вернуть предыдущее состояние служб AD. Графическая консоль, предназначенная для восстановления данных, копий SystemState не видит (находятся на диске в другом каталоге SystemStateBackup). Если попробовать запустить процесс восстановления в рабочей системе, получаем сообщение о том, что так как архив содержит службу доменов Active Directory, операцию необходимо производить в режиме восстановления службы каталогов (Directory Services Restore Mode, DSRM). Это один из минусов, так как контроллер домена в это время будет недоступен.

Восстановление состояния системы из SystemState-копии

Новый механизм загрузки BCD, появившийся в Windows, начиная с Vista, в котором убран старый добрый boot.ini, заставляет нас произвести еще ряд действий, чтобы попасть в DSRM. В составе ОС имеется специальная утилита, предназначенная для редактирования параметров загрузчика (в Интернете можно найти графические утилиты, но я считаю им не место на сервере). Создаем новую копию записи:

> bcdedit /copy {default} /d «Directory Service Repair Mode»

Запись успешно скопирована в {df127c16-2ec7-11de-bc25-000c2971dfb5}

Теперь устанавливаем ее, указав в качестве параметра полученный ID:

> bcdedit /set «{df127c16-2ec7-11de-bc25-000c2971dfb5}» safeboot dsrepair

Если команды вводятся с использованием PowerShell, то {ID} следует вводить в скобках «{ID}», иначе получаем ошибку:

The set command specified is not valid

По окончании проверяем:

> bcdedit /enum

В списке должен появиться новый пункт.

Перезагружаемся, выбираем пункт Directory Service Repair Mode и, нажав <F8>, отмечаем «Режим восстановления службы каталогов». Обратите внимание, что в этом режиме следует для входа использовать данные администратора локальной системы, а не доменную учетную запись.

Далее все просто. Получаем список резервных копий (команда wbadmin «видит» копии SystemState).

> wbadmin get versions

Время архивации: 22.05.2009 1:02

Идентификатор версии: 05/21/2009-21:02

Можно восстановить: Приложение(ия), Состояние системы

И восстанавливаем, использовав к качестве параметра полученный идентификатор версии:

> wbadmin start systemstaterecovery –version:05/21/2009-21:02

Если восстановление производится с локального диска, параметр BackupTarget, показывающий wbadmin, где взять резервную копию, указывать необязательно. Если копия находится на сетевом ресурсе, его прописываем так:

-BackupTarget:\\computer\backup -machine:server-ad

Несмотря на предупреждение о том, что:

Операция восстановления приводит к повторной синхронизации всего

реплицированного содержимого на локальном компьютере после завершения

восстановления. Возможно, это приведет к задержке и ошибкам.

Восстановление службы каталогов происходит обычно без проблем. После перезагрузки встречаем сообщение о том, что начатая операция по восстановлению успешно завершена.

Перейдя в консоль управления Active Directory, обнаруживаем, что все находится на своих местах… кроме новых объектов, созданных уже после того, как было произведено резервирование. В принципе такой результат ожидаем. А для восстановления отдельных объектов есть совсем другой путь (даже несколько).

Принудительное восстановление объектов при помощи NTDSUTIL

В состав Windows Server входит утилита командной строки NTDSUTIL, предназначенная для обслуживания, управления и контроля Active Directory Domain Services (AD DS) и Active Directory Lightweight Directory Services (AD LDS). В системе утилита становится доступной после установки роли AD DS. В Windows Server 2008 ее функциональность несколько изменилась. Так, в Windows Server 2003 с ее помощью можно было восстановить всю базу данных, но в 2008 с этим отлично справляется wbadmin, наверное, поэтому ее возможности по восстановлению чуть подсократили. Теперь, используя NTDSUTIL, можно восстановить организационное подразделение со всем содержимым и отдельный объект.

Ее работа основана на мгновенных снимках Active Directory, сделанных при помощи службы VSS. Снимок представляет собой компактную резервную копию работающей службы Active Directory со всеми каталогами и файлами. Создание такой копии в отличие от SystemState происходит очень быстро и занимает несколько секунд.

> ntdsutil

Переходим в контекст snapshot:

ntdsutil: snapshot

Запускаем команду создания снимка (краткая форма – «ac i ntds»):

снимок: activate instance ntds

Активный экземпляр «ntds».

снимок: create

Через некоторое время получаем информацию о созданном снимке, выходим:

снимок: quit

ntdsutil: quit

Теперь, чтобы восстановить базу Active Directory, достаточно ввести «ntdsutil files repair» в командной строке режима DSRM, но нас интересует отдельный объект.

Просмотреть список удаленных объектов можно при помощи LDP.exe, воспользовавшись командлетами PowerShell Get-ADObject и Restore-ADObject (есть и другие варианты).

В LDP, например, следует подключить к серверу, выбрать «Параметры (Options) -> Элементы управления (Controls)» и в раскрывающемся списке «Предопределенная загрузка» (Load Predefined) установить параметр Return deleted objects. Затем переходим в «Вид -> Дерево», выбираем контекст домена. В итоге в дереве справа появится объект CN=Deleted Object, где и находим все удаленные объекты.

Теперь важное – при удалении объект теряет большую и важную часть своих свойств (в частности, пароль, managedBy, memberOf), поэтому после его восстановления он будет не совсем в том виде, как нам хотелось. Это все хорошо видно в LDP. Но здесь есть несколько вариантов:

увеличить количество атрибутов, которые не будут затерты при удалении объекта в хранилище удаленных объектов;
восстановить объект и вернуть ему атрибуты;
и самый лучший – заблокировать объект от случайного удаления.

Восстановить удаленный объект можно несколькими способами. Самый удобный – утилита AdRestore Марка Руссиновича (Mark Russinovich) [3]. Скачиваем и вводим:

> adrestore -r user

Получаем объект с частью атрибутов.

Остальные методы расписаны в KB840001 [4], они не так просты, поэтому останавливаться на них не буду.

Восстанавливаем атрибуты объектов

В снимке, полученном при помощи ntdsutil, есть объект и его атрибуты. Образ можно монтировать и подключать в качестве виртуального LDAP-сервера, экспортирующего объекты. Вызываем ntdsutil:

> ntdsutil

ntdsutil: snapshot

Смотрим список доступных снимков:

снимок: list all

1: 2009/04/22:23:18 {8378f4fe-94c2-4479-b0e6-ab46b2d88225}

2: C: {732fdf7f-9133-4e62-a7e2-2362227a8c8e}

3: 2009/04/23:00:19 {6f7aca49-8959-4bdf-a668-6172d28ddde6}

4: C: {cd17412a-387b-47d1-9d67-1972f49d6706}

Монтируем командой mount c указанием номера или {ID}:

снимок: mount 4

Снимок {cd17412a-387b-47d1-9d67-1972f49d6706} установлен как C:\$SNAP_200904230019_VOLUMEC$\

Снимок смонтирован. Теперь можно перейти при помощи Проводника в указанный каталог и просмотреть, что находится внутри. Выходим из ntdsutil, введя дважды quit, образ по-прежнему будет смонтирован. Теперь, используя утилиту dsamain, создаем виртуальный LDAP-сервер, указав в качестве параметра путь к файлу ntds.dit, который находится в смонтированном снимке. В качестве порта LDAP-сервера я выбрал 10000:

> dsamain -dbpath C:\$SNAP_200904230019_VOLUMEC$\Windows\NT DS\ntds.dit -ldapPort 10000

EVENTLOG (Informational): NTDS General / Управление службой : 1000

Завершен запуск доменных служб Active Directory (Майкрософт) версии 6.0.6001.18000

Можно подключиться к виртуальному LDAP-серверу при помощи консоли «Active Directory – пользователи и компьютеры», указав в качестве параметра номер порта 10000, и просмотреть находящиеся внутри объекты.

Экспортируем параметры нужного объекта в ldf-файл, подробнее об ldifde написано в KB237677 [5].

> ldifde -r «(name=user)» -f export.ldf -t 10000

Установка связи с «testcomp.domain.ru»

Вход от имени текущего пользователя с помощью SSPI

Экспорт каталога в файл export.ldf

Поиск элементов…

Записываются элементы.

1 элементов экспортировано

В полученном ldf-файле следует изменить параметр changetype: add на changetype: modify и затем новый файл импортировать в каталог:

> ldifde -i -z -f import.ldf

Созданный ldf-файл необходимо подправить

Есть и другие варианты импорта/экспорта с использованием DSGET/DSMOD, PowerShell и так далее.

> dsget user cn=user,ou=ou1,dc=domain,ds=ru -s localhost:10000 -memberof | dsmod group -c -addmbr cn=user,ou=ou1,dc=domain,ds=ru

Другой метод основан на том, что каждый объект Active Directory имеет номер версии. При различии номеров версии на двух контролерах домена новым и правильным считается тот объект, у которого номер версии выше. Это и использует механизм «принудительного восстановления» (authoritative restore), когда восстановленному при помощи ntdsutil объекту присваивается номер выше и он принимается AD как новый. Для работы механизма принудительного восстановления сервер также перезагружается в DSRM.

> ntdsutil «authoritative restore» «restore object cn=user,ou=group,dc=domain,dc=ru» q q

Аналогично восстанавливается подразделение:

> ntdsutil «authoritative restore» «restore subtree ou=group,dc=domain,dc=ru» q q

Защита объектов от удаления

Начну с того, что вместе с Windows Server 2008 R2 [6] администраторы получили еще один функциональный уровень домена, и в итоге такой сервер может быть настроен в одном из четырех уровней – Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2. Его можно указать на этапе установки при помощи dcpromo или повысить, если был выбран меньший уровень, используя меню Reise the domain (forest) functional level в Active Directory Admin Center, о котором чуть дальше. Причем возможна и обратная операция – понижение функционального уровня домена и леса, если они находятся на уровне Windows Server 2008 R2, его можно вернуть на уровень Windows Server 2008, ниже – на 2003 или 2000 – нельзя. Большинство из новых возможностей будут доступны только в том случае, если домен находится на уровне R2. Так, начиная с Windows Server 2008 в свойстве объекта появился дополнительный пункт, позволяющий его защитить от случайного удаления. Точнее, он был и раньше, но здесь его уже не приходится искать.

В Windows Server 2008 он доступен при создании подразделения (OU, Organizational Unit) и называется «Защитить объект (контейнер) от случайного удаления» (Protect object from accidental deletion). Такой флажок появляется только при создании нового OU. Для уже имеющихся OU, а также вновь создаваемых групп, компьютеров и учетных записей его можно активировать во вкладке «Объект» окна свойств (видно при активном «Вид -> Дополнительные компоненты (Advanced)»).

Установка searchFlags для нужного атрибута позволит сохранить его при удалении

В R2 нужный пункт Protect from accidental deletion имеется в свойствах отдельной учетной записи, компьютера, группы и подразделения, на самом видном месте. Достаточно установить здесь флажок и при попытке удалить объект, администратор получает предупреждение о невозможности произвести требуемую операцию. При этом нужно помнить, что флажок защищает от удаления лишь тот объект, в котором он установлен. То есть если он активирован для группы, на отдельные элементы, входящие в ее состав, эта установка никак не распространяется. То есть по-прежнему можно будет удалить любой объект внутри, если он не защищен персональным флажком. Чуть другая ситуация при удалении незащищенного OU. Если в его составе нет защищенных объектов, OU будет полностью удален. Но если такие объекты есть, то следует установить в появившемся окне флажок «Использовать элемент управления сервера «Удалить поддерево» (Use delete subtree server control). Иначе вместо удаления самого OU со всеми элементами будет фактически произведена попытка очистки OU от объектов, не имеющих защиты. Причем, как показывают эксперименты, очистка эта будет неполной, так как, столкнувшись с первым же защищенным объектом, программа прекращает работу, выдав предупреждение. Это характерно и для Windows Server 2008, и для R2 RC.

Две консоли, подключенные к AD и виртуальному LDAP-серверу

В Windows Server 2003 защитить объект от удаления можно, лишь установив в разрешениях запрет на «Удаление», «Удалить поддерево» и «Удалить все дочерние объекты» (Deny для Delete, Delete subtree, Delete All Child Objects). Такой подход не очень удобен, особенно если администрированием системы занимаются несколько человек и объекты все же нужно удалять.

Защищаем объект от случайного удаления в Windows Server 2008

Объект защищен от случайного удаления

Защищаем объект от случайного удаления в Windows Server 2008 R2

При удалении дерева нужно подтвердить удаление всех объектов

Active Directory Recycle Bin

В Windows Server 2008 R2 появилась новая функция Active Directory Recycle Bin (AD RB), автоматически активируемая, когда домен находится на уровне Windows Server 2008 R2. По своей сути она схожа с корзиной, используемой в Windows, в которую помещаются удаленные файлы, и случайно удаленный объект может быть быстро и без проблем восстановлен. Причем восстановленный из AD RB объект сразу же получает и все свои аттрибуты. По умолчанию время «жизни» удаленного объекта в AD RB составляет 180 дней, после этого переходит в состояние Recycle Bin Lifetime, теряет атрибуты и через некоторое время полностью удаляется. Изменить эти значения можно при помощи параметра msDS-deletedObjectLifetime. Если при установке AD был выбран уровень ниже R2, а затем был поднят командой:

PS C:\> Set-ADForestMode –Identity domain.ru -ForestMode Windows2008R2Forest

то AD RB следует активировать отдельно. Для этого используется командлет Enable-ADOptionalFeature PowerShell:

PS C:\> Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service, /

CN=Windows NT,CN=Services,CN=Configuration, DC=domain,DC=ru’ –Scope Forest –Target ‘domain.ru’

Восстановить удаленный объект теперь очень просто:

PS C:\> Get-ADObject -Filter {displayName -eq «user»} -IncludeDeletedObjects | Restore-ADObject

Командлеты Get-ADObject и Restore-ADObject имеют большое количество параметров, например, позволяя найти OU, к которой принадлежала удаленная учетная запись, и затем восстановить весь OU. В документе Restore a Deleted Active Directory Object [7] все очень подробно изложено.

Заключение

Несмотря на возможности новых серверных ОС от Microsoft, резервное копирование контроллеров Active Directory должно проводиться планомерно и постоянно, без этого невозможно восстановление отдельных объектов или OU. Причем помимо Windows Server Backup следует создавать снимки при помощи ntdsutil. Процесс резервирования упрощается, а объемы данных уменьшаются, если контроллер домена не выполняет других функций.

Джил Киркпатрик. Резервное копирование и восстановление Active Directory в Windows Server 2008 – http://technet.microsoft.com/ru-ru/magazine/cc462796.aspx.
Статья KB944530. Error message when you try to perform a system state backup in Windows Server 2008 – http://support.microsoft.com/kb/944530.
Утилита AdRestore – http://technet.microsoft.com/ru-ru/sysinternals/bb963906.aspx.
Документ KB840001. How to restore deleted user accounts and their group memberships in Active Directory – http://support.microsoft.com/kb/840001.
Документ KB237677. «Использование средства LDIFDE для импорта и экспорта объектов каталогов в Active Directory» – http://support.microsoft.com/kb/237677/ru.
Страница, посвященная Windows Server 2008 R2 – http://www.microsoft.com/windowsserver2008/ru/ru/default.aspx.
Документ Step 2: Restore a Deleted Active Directory Object –http://technet.microsoft.com/en-us/library/dd379509.aspx.

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

Источник

Довольно часто администраторы, не знакомые с предметом, восстанавливают контроллеры домена из снимка или из старого бекапа. Контроллеры их за это не любят, а администраторы приходят жаловаться в технеты. Сегодня мы посмотрим, как быстро и точно побороть эту проблему.

Статья относится к Windows 2008 R2 и всем предыдущим ОС- в Windows server 2012 нам, наконец-то, нечего бояться.

Дисклеймер: Если вы принимаете решение, воспользоваться ли решением данной статьи, помните, что это должен быть последний метод- использование его может повредить Active Directory и не поддерживается Microsoft.

1) Выполняйте следующие шаги на проблемном «клоне»

2) Отключите сетевой адаптер сервера

3) Запишите значение Invocation Id

a. В командной строке выполните:

i. Repadmin /showrepl

4) Перезагрузите контроллер домена в режим восстановления службы каталогов Directory Services Restore Mode (DSRM)

5) Остановите службу NTFRS

6) Запустите редактор реестра regEdit

a. Перейдите к разделу HKLM\System\CurrentControlSet\Services\NTDS\Parameters

i. Измените параметр “Database restored from backup” = 1. Если такой ключ не существует, создайте его: значение DWORD, равное 1

ii..Если существует предыдущее значение реестра DSA Previous Restore Count, запишите его значение. Если параметра нет, его необходимо создать вручную и установить значение параметра равным 1

b. Перейдите к разделу HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process

i. Измените ключ BurFlags, установите его равным D2

7) Перезагрузите сервер

Войдите на контроллер домена.

a. Проверьте, что Invocation Id изменился

b. В журнале есть событие с кодом Event Id 1109 (AD restored from backup)

9) Если пункт 8 успешно выполнен, включите сетевой адаптер контроллера домена.

Ресурсы для самостоятельного изучения.

http://technet.microsoft.com/ru-ru/library/dd348479(v=ws.10)

http://support.microsoft.com/kb/290762

http://support.microsoft.com/kb/875495/en-us

http://technet.microsoft.com/ru-ru/library/hh994618.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/cc507518(v=vs.85).aspx#performing_nonauthoritative_restore

Источник

Written on 23 Марта 2009. Posted in Windows Server 2008

Страница 10 из 14

Восстановление состояния системы контроллера домена

Если восстановление требуется из-за того, что возникла какая-то проблема в работе Active Directory, к примеру нужно восстановить удаленное подразделение (OU), лучше восстановить предыдущее состояние доменных служб Active Directory, а не восстанавливать систему целиком. Несмотря на то что службы ADDS в Windows Server 2008 можно остановить, для восстановления состояния системы контроллера домена все равно придется загрузить сервер в режиме восстановления служб каталога.

Выбор режима загрузки в Windows Server 2008 стал несколько сложнее, чем раньше. Среда загрузки Windows полностью перестроена: теперь она поддерживает интерфейс EFI, файлы boot.ini не используются. Вместо них для контроля процесса загрузки в Windows Server 2008 применяются данные настройки загрузки (BCD).

Самый простой способ управления данными BCD предлагает программа командной строки BCDEDIT. Чтобы рассказать обо всех командах и параметрах программы BCDEDIT, потребовалась бы целая статья, так что здесь мы приведем лишь несколько полезных примеров.

Для перезагрузки контроллера домена под управлением Windows Server 2008 в режиме восстановления службы каталога используется следующая команда:

C:\> bcdedit /set safeboot dsrepair

Таким образом в записи начального загрузчика, используемой по умолчанию, указывается параметр safeboot. Если Windows Server 2008 устанавливается в первый раз, в нем есть только одна запись начального загрузчика, WINLOAD.EXE. Чтобы удалить параметр safeboot и загрузить систему в обычном режиме, используйте следующую команду:

C:\> bcdedit /deletevalue safeboot

Можно несколько упростить работу: настроить для контроллера домена две записи начального загрузчика, одну для обычной загрузки, а другую для загрузки в режиме восстановления службы каталога. После этого режим загрузки можно будет менять в диалоговом окне параметров загрузки и восстановления, доступ к которому можно получить через параметры системы. Для добавления новой записи начального загрузчика применяется следующая команда:

C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"

В этом случает новая запись создается путем копирования записи начального загрузчика, исопльзуемой по умолчанию. Программа BCDEDIT выдаст примерно такое сообщение:

The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.

Выведенный идентификатор GUID присваивается новой записи. Чтобы включить в созданную запись параметр safeboot, используется следующая команда:

C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair

После этого режим загрузки (обычный режим или режим восстановления службы каталога) можно будет выбирать в параметрах загрузки и восстановления (см. рис. 10).

Figure 10 Disable incremental backups on busy volumes

Прежде чем запускать восстановление состояния системы при помощи WBADMIN, необходимо указать, на основании какой резервной копии оно будет проводиться. Программа WBADMIN позволяет выполнить восстановление состояния либо на основании полной резервной копии системы, либо на основании копии, содержащей основные тома, либо на основании резервной копии состояния. В каждом из этих случаев необходимо указать версию той резервной копии, которую вы намерены использовать. Версию копии проще всего узнать при помощи следующей команды программы WBADMIN:

C:\> wbadmin get versions

Программа WBADMIN отобразит список версий резервных копий примерно так, как показано на рис. 11. Для каждой копии указывается время создания, носитель назначения, идентификатор версии (представляющий собой, собственно говоря, дату и время начала процедуры копирования по универсальному среднему времени), а также список поддерживаемых типов операций восстановления.

Figure 11 Идентификация резервных копий, пригодных для восстановления

wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State

Мы выбрали последнюю по времени создания резервную копию и запустили восстановление состояния системы при помощи следующей команды WBADMIN:

C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25

В этом случае происходит неполномочное восстановление. Если вы хотите выполнить принудительное восстановление каталога SYSVOL, нужно пометить восстановленную копию SYSVOL как доверенную, добавив параметр authsysvol в команду WBADMIN. Дополнительные сведения по этой процедуре приведены на странице go.microsoft.com/fwlink/?LinkId=113152.

Источник