none
Запрос авторизации RRS feed

  • Вопрос

  • Добрый день.

    Ситуация следующая:

    Клиент(windows 8.1) и сервер печати(server 2012 r2) в одном домене. Каждое утро не печатает принтер, пока не перейдешь по адресу сервера печати допусти через проводник и не введешь учетные данные этого пользователя. После ввода начинает печатать.

    Почему он требует аунтификацию, ведь они в одном домене и у пользователя есть права на этот принтер?

    В логах на сервере печати ничего интересного нет, кроме появляющегося события о входе(An account was successfully logged on.) после ввода логина и пароля при подключении через проводник.

    Заранее спасибо.


    4 февраля 2016 г. 6:58

Ответы

  • Аутентификация клиентской ОС на принт-сервере осуществляется на общих основаниях - через протокол Kerberos. Протокол работает совершенно прозрачно для пользователя. Тот факт, что для доступа к серверу печати вам приходится вручную вводить логин и пароль, означает, что у вас механизм аутентификации попросту не работает должным образом.

    Первый вариант - убедитесь, что пользователь входит на ПК под доменной учеткой, а не под локальной с таким же именем.

    Второй вариант - проверяйте системные логи станции на предмет сообщений о проблемах с доступом к домену. Также можно посмотреть системные логи контроллеров домена, нет ли там сообщений, что станция с таким именем не найдена в AD или имеет какие-то другие проблемы со входом.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    5 февраля 2016 г. 7:49
  • Политики здесь ни при чем. Думаю, проблема в том, что тикет Кербероса должен регулярно обновляться. Когда станция отправляется в гибернацию на много часов, а потом включается, старый тикет, разумеется, уже истек. Станция должна получить новый - и не получает его по какой-то причине. Наиболее вероятная причина, приходящая на ум - разница между аппаратными часами станции и временем в домене более чем в две минуты. Проверьте в ее биосе настройки, в том числе часового пояса, если они есть.

    Тем не менее, системный журнал станции вы исследовали? Какие там ошибки есть?


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    5 февраля 2016 г. 9:18
  • Во-первых, на машинах домена синхронизация времени должна идти с контроллерами домена, а не серверами MS.

    Во-вторых, покажите вывод ipconfig /all с проблемной рабочей станции и ВСЕХ контроллеров домена.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    6 февраля 2016 г. 18:12
  • Добрый день.

    Проблема вроде бы решилась, пока наблюдаем.

    При подключении VPN, пропадали доступы до DC.

    15 февраля 2016 г. 7:04

Все ответы

  • Аутентификация клиентской ОС на принт-сервере осуществляется на общих основаниях - через протокол Kerberos. Протокол работает совершенно прозрачно для пользователя. Тот факт, что для доступа к серверу печати вам приходится вручную вводить логин и пароль, означает, что у вас механизм аутентификации попросту не работает должным образом.

    Первый вариант - убедитесь, что пользователь входит на ПК под доменной учеткой, а не под локальной с таким же именем.

    Второй вариант - проверяйте системные логи станции на предмет сообщений о проблемах с доступом к домену. Также можно посмотреть системные логи контроллеров домена, нет ли там сообщений, что станция с таким именем не найдена в AD или имеет какие-то другие проблемы со входом.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    5 февраля 2016 г. 7:49
  • Добрый день. Спасибо за ответ.

    Учетная запись точно доменная.

    Я уже тоже почти уверен, что проблема в Kerberos, только наверно в политиках, есть предположение, что это происходит в таком случае:

    Пользователь не выключил компьютер, а ввел его в гибернацию и на утро у него не печатает принтер, видимо не может получить билет.

    В логах пока ничего не нашел, может быть дело в какой-нибудь политике?

    5 февраля 2016 г. 9:09
  • Политики здесь ни при чем. Думаю, проблема в том, что тикет Кербероса должен регулярно обновляться. Когда станция отправляется в гибернацию на много часов, а потом включается, старый тикет, разумеется, уже истек. Станция должна получить новый - и не получает его по какой-то причине. Наиболее вероятная причина, приходящая на ум - разница между аппаратными часами станции и временем в домене более чем в две минуты. Проверьте в ее биосе настройки, в том числе часового пояса, если они есть.

    Тем не менее, системный журнал станции вы исследовали? Какие там ошибки есть?


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    5 февраля 2016 г. 9:18
  • Спасибо, обязательно проверю время в BIOS, проблема наблюдается на 2х из 2х машин в новом домене. Там пока всего 2 пользователя. Журнал исследовал на одной, нашел подходящие ошибки и предупреждения.

    На машине не стояла синхронизация времени с сервером времени Microsoft, но время было правильное, поставил синхронизацию, может это конечно еще поможет.

    Кстати, вариант про гибернацию отошел, т.к. через пару часиков после утреннего ввода логина и пароля принтер опять перестал печатать и пришлось заново вводить. 


    Ошибки: 

    Log Name:      System
    Source:        Microsoft-Windows-GroupPolicy
    Date:          2/5/2016 8:20:24 AM
    Event ID:      1129
    Task Category: None
    Level:         Error
    Keywords:      
    User:          xxx
    Computer:      xxx
    Description:
    The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.

    Log Name:      System
    Source:        NETLOGON
    Date:          2/5/2016 8:20:24 AM
    Event ID:      5719
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      xxx
    Description:
    This computer was not able to set up a secure session with a domain controller in domain ХХХ due to the following: 
    There are currently no logon servers available to service the logon request. 
    This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.  

    ADDITIONAL INFO 
    If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.

    Log Name:      System
    Source:        Microsoft-Windows-Time-Service
    Date:          2/5/2016 10:16:33 AM
    Event ID:      24
    Task Category: None
    Level:         Warning
    Keywords:      
    User:          LOCAL SERVICE
    Computer:      xxx
    Description:
    Time Provider NtpClient: No valid response has been received from domain controller ХХХ after 8 attempts to contact it. This domain controller will be discarded as a time source and NtpClient will attempt to discover a new domain controller from which to synchronize. The error was: The peer is unreachable. 

    Log Name:      System
    Source:        Microsoft-Windows-GroupPolicy
    Date:          2/5/2016 10:51:04 AM
    Event ID:      1054
    Task Category: None
    Level:         Error
    Keywords:      
    User:          SYSTEM
    Computer:      xxx
    Description:
    The processing of Group Policy failed. Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure. Verify your Domain Name System (DNS) is configured and working correctly.

    Log Name:      System
    Source:        Microsoft-Windows-GroupPolicy
    Date:          2/5/2016 11:06:47 AM
    Event ID:      1055
    Task Category: None
    Level:         Error
    Keywords:      
    User:          xxx
    Computer:      xxx
    Description:
    The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following: 
    a) Name Resolution failure on the current domain controller. 
    b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

    Log Name:      System
    Source:        Microsoft-Windows-DNS-Client
    Date:          2/5/2016 11:20:53 AM
    Event ID:      8016
    Task Category: (1028)
    Level:         Warning
    Keywords:      
    User:          NETWORK SERVICE
    Computer:      xxx
    Description:
    The system failed to register host (A or AAAA) resource records (RRs) for network adapter
    with settings:

               Adapter Name : {7EE67162-510A-4EF0-9801-99087CB03B65}
               Host Name : xxx
               Primary Domain Suffix : xxx
               DNS server list :
                  10.39.37.2, 10.39.37.3
               Sent update to server : <?>
               IP Address(es) :
                 10.39.133.100

    The reason the system could not register these RRs was because the DNS server failed the update request. The most likely cause of this is that the authoritative DNS server required to process this update request has a lock in place on the zone, probably because a zone transfer is in progress.

    You can manually retry DNS registration of the network adapter and its settings by typing 'ipconfig /registerdns' at the command prompt. If problems still persist, contact your DNS server or network systems administrator.



    5 февраля 2016 г. 12:29
  • Во-первых, на машинах домена синхронизация времени должна идти с контроллерами домена, а не серверами MS.

    Во-вторых, покажите вывод ipconfig /all с проблемной рабочей станции и ВСЕХ контроллеров домена.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    6 февраля 2016 г. 18:12
  • Добрый день.

    Проблема вроде бы решилась, пока наблюдаем.

    При подключении VPN, пропадали доступы до DC.

    15 февраля 2016 г. 7:04