Ldap error 82 local error win32 err 8341

Есть домен domainOne.ru. Есть два контроллера домена:

Есть домен 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 /sBig Smilec1

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 /sBig Smilec3

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

 locked

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

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.php

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook
    Twitter
    LinkedIn

    • 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

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.)

    binderror.png

  • 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.

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Ld roller reset error
  • Lcd init arduino ошибка
  • Latex error illegal character in array arg
  • Last day on earth ошибка синхронизации
  • Last boot speed type ошибка

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии