Системная ошибка 1396

Есть домен Windows 2008, в нативном режиме. Два контроллера домена.

В домене несколько серверов под Windows 2000 server и несколько сотен рабочих станций под управлением Windows 2000/XP.

На одной рабочей станции под Windows XP (SP3) наблюдается такая ситуация: при попытке подключиться к шаре на одном из Win2K серверов выдаётся ошибка:

C:>net use * \SERVER1SHARE
Системная ошибка 1396.

Вход в систему не произведен: конечная учетная запись указана не верно.

Это для всех пользователей, кто залогинился на этой рабочей станции. Эти же пользователи с другой рабочей станции свободно получают доступ к этой шаре на этом сервере. Кроме того, все пользователи, залогинившиеся на этой рабочей станции, свободно получают доступ к шарам на других серверах под Windows 2000 Server.

То есть, получается какая-то «нелюбовь» одной РС под Windows XP к одному серверу под Windows 2000 Server. В eventlog’ах ни на рабочей станции, ни на сервере. ни на контроллерах домена ничего про эту попытку подключения нет.

Пытался гуглить на тему System error 1396 — ничего вразумительного не нашёл.

Как понять, чем именно этому серверу не приглянулась эта рабочая станция?

PS. Иногда, всё-таки подключения с этой рабочей станции к шарам на этом сервере начинают работать. Но с чем это связано — понять не могу… Да, и ещё: при попытке посмотреть доступные шары с этой рабочей станции (по net view \server1) получаю «Ошибка 5. Отказано в доступе». Шары на других серверах просматриваются нормально.

  • Перемещено

    22 апреля 2012 г. 18:04
    (От:Windows Server 2008)

title description ms.date author ms.author manager audience ms.topic ms.prod localization_priority ms.reviewer ms.custom ms.technology

Troubleshoot AD replication error 1396

Provides help to troubleshoot Active Directory replication error 1396.

04/28/2023

Deland-Han

delhan

dcscontentpm

itpro

troubleshooting

windows-server

medium

kaushika, Justinha

sap:active-directory-replication, csstroubleshoot

windows-server-active-directory

Active Directory replication error 1396: Logon Failure: The target account name is incorrect

This article describes the symptoms, cause, and resolution for resolving Active Directory replication failing with Win32 error 1396.

Applies to:   Windows Server 2012 R2
Original KB number:   2183411

Symptoms

This article describes the symptoms, cause, and resolution for resolving Active Directory replication failing with Win32 error 1396:

Logon failure: The target account name is incorrect.

  1. DCDIAG reports that the Active Directory Replications has failed with error 1396:

    Logon failure: The target account name is incorrect.

    Testing server: <Site name><DC Name>
    Starting test: Replications
    [Replications Check,<DC Name>] A recent replication attempt failed:
    From <source DC> to <destination DC>
    Naming Context: CN=<DN path of naming context>
    The replication generated an error (1396):
    Logon Failure: The target account name is incorrect.
    The failure occurred at <date> <time>.
    The last success occurred at <date> <time>.
    XX failures have occurred since the last success

  2. REPADMIN.EXE reports that replication attempt has failed with status 1396.

    REPADMIN commands that commonly cite the 1396 status include but are not limited to:

    • REPADMIN /ADD
    • REPADMIN /REPLSUM*
    • REPADMIN /REHOST
    • REPADMIN /SHOWVECTOR /LATENCY
    • REPADMIN /SHOWREPS
    • REPADMIN /SHOWREPL
    • REPADMIN /SYNCALL

    Sample output from REPADMIN /SHOWREPS depicting inbound replication from CONTOSO-DC2 to CONTOSO-DC1 failing with the Logon Failure: The target account name is incorrect error is shown below:

    Default-First-Site-NameCONTOSO-DC1
    DSA Options: IS_GC
    Site Options: (none)
    DSA object GUID: <GUID>
    DSA invocationID: <invocationID>

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

    DC=contoso,DC=com
    Default-First-Site-NameCONTOSO-DC2 via RPC
    DSA object GUID: <GUID>
    Last attempt @ <date> <time> failed, result 1396 (0x574):
    Logon Failure: The target account name is incorrect.
    <#> consecutive failure(s).
    Last success @ <date> <time>.

  3. The replicate now command in Active Directory Sites and Services returns Logon Failure: The target account name is incorrect.

    Right-clicking on the connection object from a source DC and choosing replicate now fails with Logon Failure: The target account name is incorrect. The on-screen error message is shown below:

    Dialog title text: Replicate Now

    Dialog message text: The following error occurred during the attempt to synchronize naming context <partition DNS path> from domain controller <source DC> to domain controller <destination DC>:

    Logon Failure: The target account name is incorrect.
    This operation will not continue.

    Buttons in Dialog: OK

  4. NTDS KCC, NTDS General or Microsoft-Windows-ActiveDirectory_DomainService events with the 1396 status are logged in the directory service event log.

    Active Directory events that commonly cite the 1396 status include but are not limited to:

    Event Source Event ID Event String
    Microsoft-Windows-ActiveDirectory_DomainService 1125 The Active Directory Domain Services Installation Wizard (Dcpromo) was unable to establish connection with the following domain controller.
    NTDS Replication (This event lists the 3-part SPN) 1645 Active Directory did not perform an authenticated remote procedure call (RPC) to another domain controller because the desired service principal name (SPN) for the destination domain controller is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
    Microsoft-Windows-ActiveDirectory_DomainService 1655 Active Directory Domain Services attempted to communicate with the following global catalog and the attempts were unsuccessful.
    Microsoft-Windows-ActiveDirectory_DomainService 2847 The Knowledge Consistency Checker located a replication connection for the local read-only directory service and attempted to update it remotely on the following directory service instance. The operation failed. It will be retried.
    NTDS KCC 1925 The attempt to establish a replication link for the following writable directory partition failed.
    NTDS KCC 1926 The attempt to establish a replication link to a read-only directory partition with the following parameters failed.
    NETLOGON 5781 Server cannot register its name in DNS
  5. Dcpromo fails with an onscreen error:

    Active Directory Installation Failed

    The operation failed because:
    The Directory Service failed to create the server object for CN=NTDS Settings,CN=ServerBeingPromoted,CN=Servers,CN=Site,CN=Sites,CN=Configuration,DC=contoso,DC=com on server ReplicationSourceDC.contoso.com. Please ensure
    the network credentials provided have sufficient access to add a replica.
    «Logon Failure: The target account name is incorrect.»

    OK

    In this case, Event ID 1645, 1168, and 1125 are logged on the server that is being promoted.

  6. Map a drive using net use

    C:>net use z: \<server_name>c$

    System error 1396 has occurred.
    Logon Failure: The target account name is incorrect.

    In this case, the server was also logging Event ID 333 in the system event log and using SQL Server was using a high amount of virtual memory.

  7. The DC time is incorrect.

  8. The KDC will not start on an RODC after a restore of the krbtgt account for the RODC, which had been deleted. After the restore using third-party restore tools, error 1396 appears.

    Event ID 1645 is logged on the RODC.
    Dcdiag also reports an error that it cannot update the RODC krbtgt account.

Cause

Multiple root causes exist. Known root causes include:

  1. The SPN does not exist on the global catalog searched by the KDC on behalf of the client attempting to authenticate using Kerberos.

    In the context of Active Directory replication, the Kerberos client is the destination DC, the KDC performing the SPN lookup is likely the destination DC itself but could be a remote DC.

  2. The user or service account that should contain the service principal name being looked up does not exist on the global catalog searched by the KDC on behalf of destination DC attempting to replicate.

    In the context of Active Directory replication, the source DC computer account does not exist on the global catalog searched by the DC on behalf of the destination DC performing inbound replication.

  3. The destination DC lacks an LSA secret for the source DCs domain.

  4. The SPN being looked up exists on a different computer account than the source DC.

  5. For issues where replication is failing to an RODC, the RODC-specific KRBTGT account may have been deleted.

Resolution

  1. Check the Directory Service event log on the destination DC for NTDS Replication event 1645 and note the following:

    The name of the destination DC
    The SPN being looked up (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<object guid for source DCs NTDS Settings object>/<target domain>.<tld>@<target domain>.<tld>
    The KDC being used by the destination DC

  2. From the console of the KDC identified in step 1, type nltest /dsgetdc:<forest root DNS domain name > /gc.

    Run the NLTEST locator test immediately following a replication attempt that fails with the 1396 error on the destination DC.

    This should identify that GC that the KDC is performing SPN lookups against.

    The GC being searched by the KDC may also be captued in Microsoft-Windows-ActiveDirectory_DomainService event 1655.

  3. Search for the SPN discovered in step 1 on the the global catalog discovered in step 2.

    C:>repadmin /showattrServer_NameDC=corp,DC=contoso,dc=com <GC used by KDC> <DN path of forest root domain> /filter:"(serviceprincipalname=<SPN cited in the NTDS Replication event 1645>)" /gc /subtree /atts:cn,serviceprincipalname

    Or

    C:>dsquery * forestroot -scope subtree -filter "(serviceprincipalname=E3514235-4B06-11D1-AB04-00C04FC2DCD2/65cead9f-4949-46a3-a49a-f1fbfe13d2b3*)" -attr * -sServer_Name.europe.corp.microsoft.com

    Verify that the host object for the SPN exists.

    Verify the DN path for the host object including whether the object is CNF/conflict mangled or resides in the lost and found container.

    Verify that the source DCs AD Replication SPN is registered only on the source DCs computer account.

    If the replication SPN is missing, determine if the source DC has registered its SPN with itself, and whether the SPN is missing on the GC used by the KDC due to simple replication latency or a replication failure

  4. Check the secure channel health and trust health.

This table lists other symptoms, causes, and resolutions:

Symptom Cause Resolution
The DC is not functioning and logs Event ID 1925 and 1411 on Windows Server 2008 domain controllers and Windows Server 2003 domain controllers in the same domain that have been authoritatively restored. These problems occur because the version number of the KRBTGT account increases when you perform an authoritative restoration. The KRBTGT account is a service account that is used by the Kerberos Key Distribution Center (KDC) service. In this case, you might need to apply the hotfix in KB939820.
Map a drive using net use
C:Documents and Settingswschong>net use z: <server_name>c$ System error 1396 has occurred.
Logon Failure: The target account name is incorrect.
In this case, the server was logging Event ID 333 and using high memory, with SQL Server using highest.
If the error appears while mapping a drive using net use, the cause could be that the Non Paged Memory or the Paged Pool Memory is temporarily insufficient. The system keeps recording such events until the computer is restarted, or the related hive is unloaded, even though the temporary memory insufficiency stops. For more information about SQL Server performance problems, see Troubleshooting Performance Problems in SQL Server 2005. To prevent the system logging the event 333 continually in future, please apply the hotfix 970054 on the server and set the following registry value to 1:

  • Location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager
  • Name: RegistryFlushErrorSubside
  • Type: REG_DWORD
  • Value: 1 or 2
The DC time is incorrect. The DC is a virtual machine that was set to sync time with the VMware host, caused events 1925, 1645. unchecked the option to sync time for virtual DC from VMWare host, so that it can sync time with the PDC.
Dcpromo fails with an onscreen error: Active Directory Installation Failed. The operation failed because:
The Directory Service failed to create the server object for CN=NTDS Settings,CN=ServerBeingPromoted, CN=Servers,CN=Site, CN=Sites,CN=Configuration,DC=contoso, DC=com on server ReplicationSourceDC.contoso.com. Ensure the network credentials provided have sufficient access to add a replica.
Logon Failure: The target account name is incorrect.

In this case, Event ID 1645, 1168, and 1125 are logged on the server that is being promoted.

During dcpromo, the SPN on the helper DC (the replication source DC) is not valid. For dcpromo error where helper DC SPN is not valid, use SetSPN to create new SPN on helper DC, in format GC/serverName.contoso.com

More information

Other causes include:

  1. Event ID 1925 can occur on Windows Server 2008 domain controllers and Windows Server 2003 domain controllers in the same domain that have been authoritatively restored. In this case, you might need to apply the hotfix 939820.

  2. During dcpromo, the SPN on the helper DC (the replication source DC) is not valid.

  3. If the error appears while mapping a drive using net use, the cause could be that the Non Paged Memory or the Paged Pool Memory is temporarily insufficient. The system keeps recording such events until the computer is restarted, or the related hive is unloaded, even though the temporary memory insufficiency stops. For more information about SQL Server performance problems, see Troubleshooting Performance Problems in SQL Server 2005.

  4. The DC is a virtual machine that was set to sync time with the VMware host, caused events 1925, 1645.

  5. For the RODC specific scenario where the KRBTGT account is deleted: authoritatively restore the KRBTGT_##### account using NTDSUTIL and then import the LDIFDE file to correct backlinks. At minimum, the msDS-KrbTgtLink attribute on the RODC’s computer object will need to be updated to point to the DN of the restored account.

Data collection

If you need assistance from Microsoft support, we recommend you collect the information by following the steps mentioned in Gather information by using TSSv2 for Active Directory replication issues.

Есть домен Windows 2008, в нативном режиме. Два контроллера домена.

В домене несколько серверов под Windows 2000 server и несколько сотен рабочих станций под управлением Windows 2000/XP.

На одной рабочей станции под Windows XP (SP3) наблюдается такая ситуация: при попытке подключиться к шаре на одном из Win2K серверов выдаётся ошибка:

C:>net use * SERVER1SHARE
Системная ошибка 1396.

Вход в систему не произведен: конечная учетная запись указана не верно.

Это для всех пользователей, кто залогинился на этой рабочей станции. Эти же пользователи с другой рабочей станции свободно получают доступ к этой шаре на этом сервере. Кроме того, все пользователи, залогинившиеся на этой рабочей станции, свободно получают доступ к шарам на других серверах под Windows 2000 Server.

То есть, получается какая-то «нелюбовь» одной РС под Windows XP к одному серверу под Windows 2000 Server. В eventlog’ах ни на рабочей станции, ни на сервере. ни на контроллерах домена ничего про эту попытку подключения нет.

Пытался гуглить на тему System error 1396 — ничего вразумительного не нашёл.

Как понять, чем именно этому серверу не приглянулась эта рабочая станция?

PS. Иногда, всё-таки подключения с этой рабочей станции к шарам на этом сервере начинают работать. Но с чем это связано — понять не могу… Да, и ещё: при попытке посмотреть доступные шары с этой рабочей станции (по net view server1) получаю «Ошибка 5. Отказано в доступе». Шары на других серверах просматриваются нормально.

  • Перемещено

    22 апреля 2012 г. 18:04
    (От:Windows Server 2008)

Страницы

  • Друзья
  • Карта сайта
  • О сайте

Промо

Вход в систему не произведен: конечная учетная запись указана неверно.

Вход в систему не произведен: конечная учетная запись указана неверно.

Однажды на работе произошла «жопа». После установки новых компьютеров в учебный отдел, вбивания их в домен, прописывания принтеров при обращении некоторых компов к сети вылетала ошибка «Вход в систему не произведен: конечная учетная запись указана неверно.» (Картинки кликабельны).

11 - Вход в систему не произведен: конечная учетная запись указана неверно.

Поначалу я думаю проблемы с доменом или настройками. На всех 5 машинах перевбил в домен, с нуля настроил всю сеть, но проблема не прошла. И именно на тех двух злосчастных компах.

Я сразу заметил, что при обращении по IP адресу к машине все прекрасно работало.

192.168.0.1

А при обращении по NETBIOS и DNS имени к компу выскакивала такая ошибка.

2 - Вход в систему не произведен: конечная учетная запись указана неверно.

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

Поскольку проблема возникала именно при обращении к DNS серверу, начал копать его.

3 - Вход в систему не произведен: конечная учетная запись указана неверно.

В nslookup начал пробивать эти имена и тут смотрю, что-то не то. Адреса не те, что у компов. В общем DNS сервер хранил не те записи о компьютерах. Короче имя компа не соответствовало DNS имени в сети.

4 - Вход в систему не произведен: конечная учетная запись указана неверно.

Полезли в домен. А тут раз и адреса не совпадают. Сразу вспомнил, что по адресам 192.168.0.61 у меня был Учебный отдел. А поскольку к нам добавилась еще одна кафедра и в это же время в Учебный отдел привезли компы, я решил навести порядок в распределении IP адресов, которое красиво смотрится у нас в серверной на сетке.

5 - Вход в систему не произведен: конечная учетная запись указана неверно.

DNS сервер за 2 суток не обновился и хранил старые записи. Поэтому набирая

umo-1.sfmgapi.local

я обращался не к компу по адресу 192.168.0.61, а к компу на новой кафедре. Отсюда и ошибка с именем пользователя.

Решается проблема 2 кликами.

6 - Вход в систему не произведен: конечная учетная запись указана неверно.

В настройках нашего DNS сервера dnsmgtm.msc Открывает меню. GATEWAY (У нас так сервер называется). Меню Properties (Настройки). Там находим вкладку Advanced (Дополнительно) и включаем очистку устаревших записей DNS сервера. «Enable automatic scavenging of state records». Я поставил раз в сутки. И проблема решена. Если сразу не решится, то просто удаляем записи о глючных компах из DNS оснастки. Они сами появятся заново, при перезагрузке тех рабочих машин.

7 - Вход в систему не произведен: конечная учетная запись указана неверно.

Не за что…

Комментарии

Комментарий от Настя
[ 6 апреля, 2012, 08:36 ]

Благодарю автора за идею. Очень полезная информация.
Удачи, и новых отличных идей

Комментарий от Татарин
[ 7 сентября, 2012, 14:48 ]

Большое спасибо была таже проблема не печатал принтер перенастроил обращение с имён на ip адреса теперь всё супер))))

Комментарий от Vadim
[ 3 октября, 2012, 09:50 ]

СПАСИБО, помогло

Комментарий от Михаил
[ 27 ноября, 2012, 14:14 ]

Спасибо !!!

Комментарий от yurvasya
[ 11 февраля, 2013, 15:14 ]

Спасибо!

Комментарий от Игорь
[ 21 февраля, 2013, 09:57 ]

Вот спасибо так спасибо! Тоже голову ломали сегодня :)

Комментарий от Akill
[ 7 ноября, 2013, 03:31 ]

Где тут лайк оставить?

Комментарий от Евгений
[ 7 марта, 2014, 10:38 ]

Огромное спасибо!

Комментарий от Андрей
[ 19 июня, 2014, 16:10 ]

Наконец-то наткнулся на толковое решение, а то везде какую-то билиберду пишут и просят логи с найстроками сети :) Спасибо!

Комментарий от Леонид
[ 13 августа, 2014, 14:11 ]

А мне не помагло :((
Галочку потавил, по ИП обращение проходит, а по имени нет. Nslookup возвращает все корректно.

Комментарий от Auger
[ 2 сентября, 2014, 10:34 ]

Спасибо! Всё логично, но всего знать невозможно… СПАСИБО!

Комментарий от Евгений
[ 11 марта, 2016, 06:36 ]

Спасибо бро! Очень выручил!

Поиск по сайту

Статистика

Мета

  • Админ
  • RSS записей
  • RSS комментариев

При выделении одной подсети (основной домен) в другой поддомен (новый домен) в этом же лесу произошла странная ошибка. Пользователи из основного домена не видят на сервере нового домена общие папки. Компьютеры с Windows XP ничего не сообщают, а просто показывают пустое содержимое общих папок. А по «net view dcgs») получаю «Ошибка 5. Отказано в доступе».

А Windows Server 2008 и другие более поздние операционные системы конкретно сообщают об ошибке:

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

Самое интересное, что по IP-адресу список общих папок прекрасно отображается:

2.168.200.1

а при отображении по NetBIOS и DNS именам появляется вышеупомянутая ошибка. Скорее всего проблема в DNS. Поэтому опишу более полное решение — как со стороны клиента, так и со стороны DNS-сервера.

Шаг 1. Клиент

На стороне клиента необходимо выполнить следующие шаги:

  1. На сервере DNS удалить старые записи, что мешают правильному сопоставлению.
  2. На клиенте (откуда осуществляется доступ) очистить DNS-кэш командой.
  3. ipconfig /flushdns
  4. С помощью nslookup на клиенте проверить, что имя разрешается в правильный IP-адрес. Иногда, проблема неправильного разрешения может быть в файле hosts и ему подобных.
  5. Необходимо завершить текущий сеанс на клиенте и снова войти. Теперь к общим ресурсам должен быть доступ.

В большинстве случаев этого оказывается достаточно. Но рекомендую выполнить шаги 2-4.

Шаг 2. Клиент

Иногда, после проделанных действий ошибка может снова появится. Причина может быть в DNS-суффиксах подключения:

C:Documents and Settingsuser>nslookup
Default Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

> dcgs
Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

Non-authoritative answer:
Name:    dcgs.guap.ru
Address:  194.226.199.245

>
C:Documents and Settingsuser>ipconfig /all

Настройка протокола IP для Windows

        Имя компьютера  . . . . . . . . . : COMP16
        Основной DNS-суффикс  . . . . . . : k43.guap.ru
        Тип узла. . . . . . . . . . . . . : неизвестный
        IP-маршрутизация включена . . . . : нет
        WINS-прокси включен . . . . . . . : нет
        Порядок просмотра суффиксов DNS . : k43.guap.ru
                                            gs.k43.guap.ru

Локальная сеть - Ethernet адаптер:

        DNS-суффикс этого подключения . . : gs.k43.guap.ru
        Описание  . . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connecti
on
        Физический адрес. . . . . . . . . : 00-11-22-33-44-55
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес  . . . . . . . . . . . . : 192.168.200.2
        Маска подсети . . . . . . . . . . : 255.255.255.0
        Основной шлюз . . . . . . . . . . : 192.168.200.1
        DHCP-сервер . . . . . . . . . . . : 192.168.200.1
        DNS-серверы . . . . . . . . . . . : 192.168.200.1
        Аренда получена . . . . . . . . . : 12 декабря 2012 г. 9:53:24
        Аренда истекает . . . . . . . . . : 20 декабря 2012 г. 9:53:24

В данном примере сперва использовался другой DNS-сервер домена k43.guap.ru, а не текущего домена gs.k43.guap.ru. Машина находится в двух доменах, и выполнен вход под пользователем из другого домена. Так или иначе это приводится к «неправильному» порядку DNS-суффиксов.

В настройках сетевого адаптера, в настройках протокола Интернета (TCP-IP), на вкладке «Общие» нажимаем кнопку «Дополнительно» и указываем нужный порядок DNS-суффиксов:

После этого проверяем правильность разрешения:

C:Documents and Settingsuser>ipconfig /all

Настройка протокола IP для Windows

        Имя компьютера  . . . . . . . . . : COMP16
        Основной DNS-суффикс  . . . . . . : k43.guap.ru
        Тип узла. . . . . . . . . . . . . : неизвестный
        IP-маршрутизация включена . . . . : нет
        WINS-прокси включен . . . . . . . : нет
        Порядок просмотра суффиксов DNS . : gs.k43.guap.ru
                                            k43.guap.ru

Локальная сеть - Ethernet адаптер:

        DNS-суффикс этого подключения . . : gs.k43.guap.ru
        Описание  . . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connecti
on
        Физический адрес. . . . . . . . . : 00-11-22-33-44-55
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес  . . . . . . . . . . . . : 192.168.200.2
        Маска подсети . . . . . . . . . . : 255.255.255.0
        Основной шлюз . . . . . . . . . . : 192.168.200.1
        DHCP-сервер . . . . . . . . . . . : 192.168.200.1
        DNS-серверы . . . . . . . . . . . : 192.168.200.1
        Аренда получена . . . . . . . . . : 12 декабря 2012 г. 11:49:57
        Аренда истекает . . . . . . . . . : 20 декабря 2012 г. 11:49:57

C:Documents and Settingsuser>nslookup
Default Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

> dcgs
Server:  dcgs.gs.k43.guap.ru
Address:  192.168.200.1

Name:    dcgs.gs.k43.guap.ru
Address:  192.168.200.1

>

Шаг 3. DNS-сервер

На DNS-сервере следует проверить интерфейсы по которым прослушивают клиентов:

Поскольку в DNS создаются записи типа A для интерфейсов отмеченных галочками, то теоретически может возникнуть следующая ситуация. Пусть DNS-сервер прослушивает по двум адресам: 192.168.200.1 и 169.254.0.17. Когда клиент разрешает имя сервера в IP-адрес, то ему может попасться любой адрес из указанных. Если настройками брандмауэра стоит разрешение на подключение к 192.168.200.1, а на остальное запрет, то при получении адреса 169.254.0.17 клиент не сможет подключиться к DNS-серверу. Или если второй адрес использовался как RAS-подключение (суть модемное соединение), но при обрыве связи этот адрес более не доступен, но клиент его закешировал, то снова возникнет проблема подключения.

Шаг 4. DNS-сервер

Этот шаг необязательный. В настройках DNS-сервера имеется полезная галочка:

  • Заходим в свойства DNS-сервера.
  • В окне «Имя сервера — свойства» выбираем вкладку «Дополнительно».
  • Ставим галочку «Разрешить автоматическое удаление устаревших записей». По-умолчанию, стоит период 7 дней. Выбираем наиболее предпочтительный.

Теперь все сведения об устаревших записях выбудут удалены автоматически.

Рекомендую также посмотреть:
http://social.technet.microsoft.com/Forums/ru/ws2008r2ru/thread/22601e1b-4cca-44a7-930f-d0c20500e86f

3 / 3 / 0

Регистрация: 19.11.2012

Сообщений: 183

1

Нет доступа, конечная учётная запись указана не верно

21.11.2012, 11:22. Показов 10158. Ответов 4


Пропал доступ к общим документам на сервере. При попвтке зайти с любого пользователя, в т.ч админа, выдаёт такое сообщение. пинг проходит. Что за беда и почему возниает???

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

0

Модератор

Эксперт по компьютерным сетямЭксперт HardwareЭксперт Windows

4954 / 2311 / 141

Регистрация: 27.06.2011

Сообщений: 9,167

22.11.2012, 10:14

2

NikElan, что происходит если с компа на сервер войти путем пусквыполнить и набрать Ip_адрес_сервера нажать enter ?
Сеть рабочая группа или домен ?

0

3 / 3 / 0

Регистрация: 19.11.2012

Сообщений: 183

22.11.2012, 16:49

 [ТС]

3

проблему вчера решил. Переподключение к домену.

0

Эксперт С++

7175 / 3234 / 80

Регистрация: 17.06.2009

Сообщений: 14,164

22.11.2012, 23:27

4

Вроде должен писать нет доступа к домену (или домен контроллеру)
А не просто писать — нет доступа хбз куда

0

3 / 3 / 0

Регистрация: 19.11.2012

Сообщений: 183

22.11.2012, 23:54

 [ТС]

5

Цитата
Сообщение от odip
Посмотреть сообщение

Вроде должен писать нет доступа к домену (или домен контроллеру)

Так получилось что комп был введён в домен, но работал не под доменом а под именем администратора локального компьютера И имя пользователя локального администратора совпадало с доменным именем под которым он однажды зашёл на этот комп. А при попытке зайти под другим пользователем домена, даже под администратором домена, выдавал сообщение, мол домен не может установить доверительные отношения с этой рабочей станцией. Если я что то неправильно понял, пожалуйста поправьте, т.к. опыт работы с сетями 2 месяца. а с доменами 3 недели)))))))

0

Таким образом, я наконец выяснил то, что продолжалось (после большого метода проб и ошибок). У нас был контроллер домена, который отказал только что, и компания приняла решение не сделать восстановление. Грязный и ужасный и не лучшие практики, но безотносительно. То, что они сделали, было помещено запись для того DC, указывающего на IP-адрес другого DC. То, что это сделало, было, позволяют записям SRV от того DC продолжать работать. То, что произошло, было то, что кто-то видел «несправедливость» запись и удалил ее. Таким образом заставляя НЕКОТОРЫХ, но не все запросы на аутентификацию перестать работать. Это было затем усугублено некоторыми несколько нечетными правилами кэширования для записей SRV в Победе XP. Любые шаблоны, которые я видел, были или вторичны, или просто мой мозг, пытающийся видеть шаблоны, где были действительно просто случайные данные. При восстановлении запись решила проблему, и так как компания закрывается, он — родитель в конце года, никто не собирается потрудиться делать что-либо лучше.

Ссылка

Решение ошибки с кодом 1396 Error ‘Operation CREATE USER failed for… при настроенной репликации MySQL.

  • Ошибка возникает при ситуации, когда в схеме MasterSlave на мастере был создан пользователь и ему выданы некие права. Например, вот так:

CREATE USER 'zabbix'@'%' IDENTIFIED BY '<password>';
GRANT REPLICATION CLIENT,PROCESS,SHOW DATABASES,SHOW VIEW ON *.* TO 'zabbix'@'%';
  • После этого на слейве репликация останавливается с ошибкой:
Last_SQL_Errno: 1396
Last_SQL_Error: Error 'Operation CREATE USER failed for 'zabbix'@'%'' on query. Default database: ''. Query: 'CREATE USER 'zabbix'@'%' IDENTIFIED WITH 'mysql_native_password' AS '*B3198D30E7427FD4920A86A602DE74D9FABE22B9''

А причиной ошибки является то, что на slave-сервере, вероятнее всего, уже был такой пользователь, а потому репликация и прерывается. Такая особенность MySQL:

  • https://bugs.mysql.com/bug.php?id=28331
  • https://dba.stackexchange.com/questions/34940/adding-a-user-to-mysql-with-name-fails-with-error-1396

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

delete from mysql.user where user='zabbix';
flush privileges;
start slave;

Либо же привести пользователя на слейве и мастере к единому виду, т.е. записи в таблицах должны совпадать, после чего также выполнить flush privileges; и запустить репликацию.

Понравилась статья? Поделить с друзьями:
  • Системная ошибка 1376 указанная локальная группа не существует
  • Системная ошибка 1371
  • Системная ошибка 1359
  • Системная ошибка 1355
  • Системная ошибка 1327