Есть домен domainOne.ru. Есть два контроллера домена:
dc1.domainOne.ru — в питере AD+DNS+DHCP
dc3.tver.domainOne.ru — в твери. AD+DNS+DHCP
Работало всё хорошо после установки всей системы уже месяца 4, и тут в пятницу ещё ухожу домой — всё ОК. в субботу утром, то бишь 1 ноября получаю:
пользователи с тверского домена не авторизуються на питерском терминальном сервере. Смотрю дальше. по логам не идёт репликация dc1 c dc3.
с dc1 не могу попасть на dc3 через AD Users and Computers — нет доступа, не прошёл аутентификацию.
вот логи с netdiag и dcdiag с обоих контроллер домена + перекрёстый опрос (вывел только ошибки, что бы не заграмождать):
На DC3:
Netdiag
Computer Name: DC3
DNS Host Name: dc3.tver.domainOne.ru
Host Name. . . . . . . . . : dc3
IP Address . . . . . . . . : 10.2.0.31
Subnet Mask. . . . . . . . : 255.255.0.0
Default Gateway. . . . . . : 10.2.0.1
Dns Servers. . . . . . . . : 10.2.0.31
Winsock test . . . . . . . . . . . : Passed
DNS test . . . . . . . . . . . . . : Passed
PASS — All the DNS entries for DC are registered on DNS server ‘10.2.0.31’ a
nd other DCs also have some of the names registered.
Redir and Browser test . . . . . . : Failed
List of NetBt transports currently bound to the Redir
NetBT_Tcpip_{FBC5505E-9A1E-459F-A6E7-92E000FB66B6}
The redir is bound to 1 NetBt transport.
List of NetBt transports currently bound to the browser
NetBT_Tcpip_{FBC5505E-9A1E-459F-A6E7-92E000FB66B6}
The browser is bound to 1 NetBt transport.
[FATAL] Cannot send mailslot message to ‘\DOMAINONE*MAILSLOTNETNETLO
GON’ via redir. [ERROR_BAD_NETPATH]
DC list test . . . . . . . . . . . : Failed
Failed to enumerate DCs by using the browser. [ERROR_NO_BROWSER_SERVERS_
FOUND]
Dcdiag
Starting test: NCSecDesc
[DC3] LDAP bind failed with error 8341,
Win32 Error 8341.
……………………. DC3 failed test NCSecDesc
Starting test: KnowsOfRoleHolders
[DC1] DsBindWithSpnEx() failed with error -2146892976,
Win32 Error -2146892976.
Warning: DC1 is the Schema Owner, but is not responding to DS RPC Bind.
[DC1] LDAP bind failed with error 8341,
Win32 Error 8341.
Warning: DC1 is the Schema Owner, but is not responding to LDAP Bind.
[DC2] DsBindWithSpnEx() failed with error -2146892976,
Win32 Error -2146892976.
Warning: DC2 is the Domain Owner, but is not responding to DS RPC Bind.
[DC2] LDAP bind failed with error 8341,
Win32 Error 8341.
Warning: DC2 is the Domain Owner, but is not responding to LDAP Bind.
……………………. DC3 failed test KnowsOfRoleHolders
На DC1
netdiag
Computer Name: DC1
DNS Host Name: dc1.domainOne.ru
Host Name. . . . . . . . . : dc1
IP Address . . . . . . . . : 10.1.0.31
Subnet Mask. . . . . . . . : 255.255.0.0
Default Gateway. . . . . . : 10.1.0.1
Dns Servers. . . . . . . . : 10.1.0.31
10.1.0.32
Прошёл без ошибок
Dcdiag
Прошёл без ошибок
Хотя ранее выдавал:
Testing server: Spb-SiteDC1
Starting test: Replications
что тут ошибка, не может сделать репликацию с dc3
Далее перекрестную провёрку решил попробовать:
На DC3:
dcdiag /sc1
Testing server: Spb-SiteDC1
Starting test: Replications
[DC2] DsBindWithSpnEx() failed with error -2146892976,
Win32 Error -2146892976.
……………………. DC1 passed test Replications
Starting test: NCSecDesc
[DC1] LDAP bind failed with error 8341,
Win32 Error 8341.
……………………. DC1 failed test NCSecDesc
Starting test: NetLogons
……………………. DC1 passed test NetLogons
Starting test: Advertising
……………………. DC1 passed test Advertising
Starting test: KnowsOfRoleHolders
Warning: DC2 is the Domain Owner, but is not responding to DS RPC Bind.
[DC2] LDAP bind failed with error 8341,
Win32 Error 8341.
Warning: DC2 is the Domain Owner, but is not responding to LDAP Bind.
Warning: DC2 is the Infrastructure Update Owner, but is not responding
to DS RPC Bind.
Warning: DC2 is the Infrastructure Update Owner, but is not responding
to LDAP Bind.
……………………. DC1 failed test KnowsOfRoleHolders
На DC1:
dcdiag /sc3
Domain Controller Diagnosis
Performing initial setup:
Done gathering initial info.
Doing initial required tests
Testing server: Tver-SiteDC3
Starting test: Connectivity
……………………. DC3 passed test Connectivity
Doing primary tests
Testing server: Tver-SiteDC3
Starting test: Replications
……………………. DC3 passed test Replications
Starting test: NCSecDesc
……………………. DC3 passed test NCSecDesc
Starting test: NetLogons
……………………. DC3 passed test NetLogons
Starting test: Advertising
……………………. DC3 passed test Advertising
Starting test: KnowsOfRoleHolders
……………………. DC3 passed test KnowsOfRoleHolders
Starting test: RidManager
……………………. DC3 passed test RidManager
Starting test: MachineAccount
……………………. DC3 passed test MachineAccount
Starting test: Services
……………………. DC3 passed test Services
Starting test: ObjectsReplicated
……………………. DC3 passed test ObjectsReplicated
Starting test: frssysvol
……………………. DC3 passed test frssysvol
Starting test: frsevent
……………………. DC3 passed test frsevent
Starting test: kccevent
……………………. DC3 passed test kccevent
Starting test: systemlog
……………………. DC3 passed test systemlog
Starting test: VerifyReferences
……………………. DC3 passed test VerifyReferences
Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
……………………. DomainDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
……………………. DomainDnsZones passed test CheckSDRefDom
Running partition tests on : tver
Starting test: CrossRefValidation
……………………. tver passed test CrossRefValidation
Starting test: CheckSDRefDom
……………………. tver passed test CheckSDRefDom
Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
……………………. ForestDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
……………………. ForestDnsZones passed test CheckSDRefDom
Running partition tests on : Schema
Starting test: CrossRefValidation
……………………. Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
……………………. Schema passed test CheckSDRefDom
Running partition tests on : Configuration
Starting test: CrossRefValidation
……………………. Configuration passed test CrossRefValidation
Starting test: CheckSDRefDom
……………………. Configuration passed test CheckSDRefDom
Running enterprise tests on : domainOne.ru
Starting test: Intersite
……………………. domainOne.ru passed test Intersite
Starting test: FsmoCheck
……………………. domainOne.ru passed test FsmoCheck
Получается проблемный контроллер DC3, но не могу понять в чём проблема
Что смотрел:
часовые зоны, время проверил — совпадают.
ДНС и там и там вроде работает, ошибок в логах ДНС нету.
попробовал dcdiag /fix and netdiag /fix на обоих серверах, результата никакого не дала.
Подскажите советом, где искать…
- Remove From My Forums
AD Replication Failure Between Server 2008 R2 and Server 2003 — LDAP bind failed with error 8341
-
Question
-
Hello,
I adopted a rather messy network from a previous engineer. We have a 2008 r2 domain controller that cannot replicate from a 2003 domain controller. The 2003 is PDCe, holding all FSMO roles. Both servers are DNS servers.
As you can see from the below, replication has not occurred in almost 3 months. This has become a large issue for workstations on the network, as well as the Exchange server.
Please note that I believe I have done a good job of making sure there are not duplicate DNS entries for either DC2003 or DC2008R2 on
either server.Thank you for any help you can give.
Issues encountered while running commands from DC2008R2:
— When I browse \DC2003 from DC2008R2 I receive the error: Logon Failure: The account name is incorrect.
— When I run dcdiag /test:dns
I receive the following initial error:
- Performing initial setup:
Trying to find home server…
Home Server = DC2008R2
* Identified AD Forest.
[DC2003] LDAP bind failed with error 8341,
A directory service error has occurred..
Got error while checking if the DC is using FRS or DFSR. Error:
A directory service error has occurred.The VerifyReferences, FrsEvent and
DfsrEvent tests might fail because of this error.
Done gathering initial info.
— The following event shows up in the System event viewer:
- Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 8/7/2012 5:02:48 PM
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DC2008R2.contoso.com
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/DC2003.contoso.com. The target name used was LDAP/3d3f03ae-eadc-4080-888f-4b765fd5e0ea._msdcs.contoso.com. 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. Please ensure that the target SPN is registered on, and only registered on, the account used by the server.
This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC
are both updated to use the current password. If the server name is not fully qualified, and the target domain (contoso.COM) is different from the client domain (contoso.COM), check if there are identically named server accounts in these two domains, or use
the fully-qualified name to identify the server.
Event Xml:
<Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event»>
<System>
<Provider Name=»Microsoft-Windows-Security-Kerberos» Guid=»{98E6CFCB-EE0A-41E0-A57B-622D4E1B30B1}» EventSourceName=»Kerberos» />
<EventID Qualifiers=»16384″>4</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime=»2012-08-08T00:02:48.000000000Z» />
<EventRecordID>182676</EventRecordID>
<Correlation />
<Execution ProcessID=»0″ ThreadID=»0″ />
<Channel>System</Channel>
<Computer>DC2008R2.contoso.com</Computer>
<Security />
</System>
<EventData>
<Data Name=»Server»>host/DC2003.contoso.com</Data>
<Data Name=»TargetRealm»>contoso.COM</Data>
<Data Name=»Targetname»>LDAP/3d3f03ae-eadc-4080-888f-4b765fd5e0ea._msdcs.contoso.com</Data>
<Data Name=»ClientRealm»>contoso.COM</Data>
<Binary>
</Binary>
</EventData>
</Event>
— When I run repadmin /showreps I receive the following:
- Default-First-Site-NameDC2008R2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 9653ed10-c0b2-4a8d-be12-051ba20d71ba
DSA invocationID: 529bd905-ccfb-43f6-bec9-888e7449c173==== INBOUND NEIGHBORS ======================================
DC=contoso,DC=com
Default-First-Site-NameDC2003 via RPC
DSA object GUID: 3d3f03ae-eadc-4080-888f-4b765fd5e0ea
Last attempt @ 2012-08-07 18:58:43 failed, result -2146893022 (0x80090322):
The target principal name is incorrect.
2673 consecutive failure(s).
Last success @ 2012-05-13 04:27:38.CN=Configuration,DC=contoso,DC=com
Default-First-Site-NameDC2003 via RPC
DSA object GUID: 3d3f03ae-eadc-4080-888f-4b765fd5e0ea
Last attempt @ 2012-08-07 18:58:43 failed, result -2146893022 (0x80090322):
The target principal name is incorrect.
3426 consecutive failure(s).
Last success @ 2012-05-13 03:54:46.CN=Schema,CN=Configuration,DC=contoso,DC=com
Default-First-Site-NameDC2003 via RPC
DSA object GUID: 3d3f03ae-eadc-4080-888f-4b765fd5e0ea
Last attempt @ 2012-08-07 18:58:43 failed, result -2146893022 (0x80090322):
The target principal name is incorrect.
2079 consecutive failure(s).
Last success @ 2012-05-13 03:54:46.DC=DomainDnsZones,DC=contoso,DC=com
Default-First-Site-NameDC2003 via RPC
DSA object GUID: 3d3f03ae-eadc-4080-888f-4b765fd5e0ea
Last attempt @ 2012-08-07 18:58:43 failed, result 1256 (0x4e8):
The remote system is not available. For information about network troubleshooting, see Windows Help.
2081 consecutive failure(s).
Last success @ 2012-05-13 03:54:46.DC=ForestDnsZones,DC=contoso,DC=com
Default-First-Site-NameDC2003 via RPC
DSA object GUID: 3d3f03ae-eadc-4080-888f-4b765fd5e0ea
Last attempt @ 2012-08-07 18:58:43 failed, result 1256 (0x4e8):
The remote system is not available. For information about network troubleshooting, see Windows Help.
2079 consecutive failure(s).
Last success @ 2012-05-13 03:54:46.Source: Default-First-Site-NameDC2003
******* 3425 CONSECUTIVE FAILURES since 2012-05-13 04:27:38
Last error: -2146893022 (0x80090322):
The target principal name is incorrect.
-
Edited by
Wednesday, August 8, 2012 3:22 AM
- Performing initial setup:
Answers
-
I agree with Awinish. The easiest course of action is to simply run dcpromo /forceremoval, clean out AD with a metadata cleanup process, then re-promote it.
Complete Step by Step to Remove an Orphaned Domain Controller
http://msmvps.com/blogs/acefekay/archive/2010/10/05/complete-step-by-step-to-remove-an-orphaned-domain-controller.aspx.
However, if you are up to it and have plenty of time on your hands, look at the following link, scroll down to «To reinitialize replication due to lingering objects, which is due to replication failing far beyond the Tombstone AD limit,» and follow the lengthy
suggestions to reinitialize the DC.Active Directory Lingering Objects, Journal Wraps, USN Rollbacks, Tombstone
Lifetime, and Event IDs 13568, 13508, 1388, 1988, 2042, 2023, 2095, 1113, 1115,
2103, and more …
http://msmvps.com/blogs/acefekay/archive/2011/12/27/active-directory-lingering-objects-journal-wraps-tombstone-lifetime-and-event-ids-13568-13508-1388-1988-2042-2023.aspx.
I also suggest to find out the root cause, such as if firewall ports are blocking DC to DC communications.
Active Directory Firewall Ports — Let’s Try To Make This Simple
http://msmvps.com/blogs/acefekay/archive/2011/11/01/active-directory-firewall-ports-let-s-try-to-make-this-simple.aspx.
We haven’t seen any ipconfigs, but just in case, I suggest that if any of the DCs are multihomed (more than one NIC, IP RRAS, iSCSI interface, etc), to single home them. Multihomed DCs are problematic.
.
Another suggestion is to change the AD tombstone time to 180 from 60 days. Apparently the very first DC installed was based on a Windows 2000 or Windows 2003 pre-SP1 installation, whiich is why the tombstone is 60 days.
Changing the Tombstone Lifetime Attribute in Active Directory
http://www.petri.co.il/changing_the_tombstone_lifetime_windows_ad.htm.
And glad to hear so far you’re doing your best to clean up an inherited mess from a previous admin.
.
Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & Exchange 2010, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP — Directory Services
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.phpThis post is provided AS-IS with no warranties or guarantees and confers no rights.
-
Proposed as answer by
Sandesh Dubey
Wednesday, August 8, 2012 5:10 PM -
Marked as answer by
MikeHSB
Tuesday, August 14, 2012 5:29 AM
-
Proposed as answer by
This topic has been deleted. Only users with topic management privileges can see it.
-
Having an issue with Active Directory failing when a new device attempts to join the domain. Here is the error that I get when running a dcdiag /v against the main domain controller (to-win-ad1.)
-
One obvious issue here is the DNS one. If I ping to-win-ad1 it resolves correctly and can be reached. But when running dcdiag it is attempting to use the 10.x.x.x subnet which is not available to the clients over the VPN.
-
Did you setup the Pertino settings with the DNS info, etc?
-
Yes, like I said the DNS resolution and pings work fine. It only has the issue when running the diags.
-
@scottalanmiller said:
Yes, like I said the DNS resolution and pings work fine. It only has the issue when running the diags.
Ok, what about forcing it to use the Pertino address for that hostname? Try adding that hostname with the Pertino address to the hosts file.
-
It’s not an ideal solution but at least for the sake of troubleshooting, might be worth a shot.
-
I wonder if Pertino has tried this at all in their labs?
-
@Dashrender said:
I wonder if Pertino has tried this at all in their labs?
Considering Scott is the one who created the initial method for connecting to AD over Pertino, it’s a craps shoot.
-
@ajstringham said:
@Dashrender said:
I wonder if Pertino has tried this at all in their labs?
Considering Scott is the one who created the initial method for connecting to AD over Pertino, it’s a craps shoot.
Method?
-
@Dashrender said:
@ajstringham said:
@Dashrender said:
I wonder if Pertino has tried this at all in their labs?
Considering Scott is the one who created the initial method for connecting to AD over Pertino, it’s a craps shoot.
Method?
You put Pertino on your DC/DCs and the client machine. On the client machine, you go the the IP settings of the Pertino adapter and set the DNS statically to your DC or DCs. That was the initial process. It may still be the standard.
-
Tested with a new desktop that is also on Windows 10 and it too has the same failure to join the domain without any further information to tell us what might be wrong.
-
Have you tried a point to point VPN source for connectivity with the Domain to see if that works (instead of Pertino)?
-
@Dashrender said:
Have you tried a point to point VPN source for connectivity with the Domain to see if that works (instead of Pertino)?
It’s OpenVPN and IPSec, I’ve used both a ton. No concerns there at all. But it doesn’t do what Pertino does. While both are VPNs, they are completely different things. Pertino is a hosted full mesh. Ubiquiti, like any hardware VPN, is a site to site VPN. There are very few times that both would be an option for the same network.
-
@scottalanmiller said:
@Dashrender said:
Have you tried a point to point VPN source for connectivity with the Domain to see if that works (instead of Pertino)?
It’s OpenVPN and IPSec, I’ve used both a ton. No concerns there at all. But it doesn’t do what Pertino does. While both are VPNs, they are completely different things. Pertino is a hosted full mesh. Ubiquiti, like any hardware VPN, is a site to site VPN. There are very few times that both would be an option for the same network.
I was suggesting that you try to join the domain using another connection method instead of Pertino to see if it is Pertino that is causing the problem of joining the domain. Setup a Site to Site VPN from your home to NTG’s network, etc. If that works, you (and hopefully) Pertino now know that Pertino has some work to do to get this working for Windows 10.
-
@scottalanmiller said:
It’s OpenVPN and IPSec, I’ve used both a ton. No concerns there at all. But it doesn’t do what Pertino does. While both are VPNs, they are completely different things. Pertino is a hosted full mesh. Ubiquiti, like any hardware VPN, is a site to site VPN. ** There are very few times that both would be an option for the same network.**
Really? I could see this being useful in my case where I have 4 remote locations using Site to Site, and for my mobile users they could use Pertino.