none
Вопрос по доступу к сетевым ресурсам RRS feed

  • Вопрос

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

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

    Есть какой-нибудь способ обойти эту ситуацию?
    14 марта 2010 г. 7:01

Ответы

Все ответы

  • Если обращение к общим сетевым папкам шло по DNS-имени сервера на котором они расположены - попробовать обратиться по IP. И наоборот.
    Хотя, не очень понятно что именно вы подразумеваете под фразой "Набрать свой же логин и пароль система не даёт"? Можно чуть поподробнее? Или скриншот?


    MCSA
    14 марта 2010 г. 8:48
  • По ip или имени получается один результат.
    Ошибка вот такая:
    http://narod.ru/disk/18738065000/err.JPG.html
    14 марта 2010 г. 9:00
  • А ввести учётные сведения любого доменного пользователя?


    MCSA
    14 марта 2010 г. 9:05
  • Если ввести любого другого пустит.
    14 марта 2010 г. 9:12
  • Ну так и надо создать доменного пользователя для того, чтобы этот пользователь имел доступ к этим папкам. Если вас беспокоят вопросы security - можно максимально ограничить этого созданного доменного пользователя в правах и доступах внутри домена. Кто вам мешает-то?


    MCSA
    14 марта 2010 г. 9:14
  • Таких пользователей около 40, а папок еще больше и для всех стоят права свои.
    Вообщем это не выход.
    14 марта 2010 г. 9:19
  • "Недоменный" пользователь может иметь доступ к общим сетевым папкам только в том случае, если у них стоит разрешение на доступ группе пользователей "Все". Думайте, что вам важнее - давать доступ к этим папками всем (в том числе анонимным пользователям) или всё-таки создать доменного пользователя, для возможности авторизованного доступа? Хотя бы одного на всех 40, если это позволяют ваши правила.


    MCSA
    14 марта 2010 г. 9:25
  • немного не понятно. в момент соединнения по ВПН с сервером необходимо вносить учетные данные пользователя, просто надо внести его в группу VPN Users и все станет на свои места. Под каким пользователям они коннектятся к ВПН северу? все под одним? данные пользователя вводятся с учетом домена? Vaysa@domen ******?

    14 марта 2010 г. 10:26
  • Пользователь для работы с ноутбуком использует учетную запись из домена. Просто в момент входа в сеть домен не доступен. После того как он зарегистрировался в системе он запускает ВПН клиент Cisco AnyConnect и только после этого становится доступным домен и другие ресурсы.
    14 марта 2010 г. 11:00
  • ВПН поднимается с помощью Cisco ASA 5510 и Cisco AnyConnect. Учетные записи и пароли там берутся из своей базы. А вот учетная запись которую используют пользователи из домена имеет все права необходимые. Я так понимаю проблема именно в том что он логинется в то время когда домен не доступен.
    14 марта 2010 г. 11:04
  • Понятно. Вам необходимо устанавливать VPN-соединение до входа в систему? Тогда попробуйте воспользоваться советами из этой статьи (Как запустить VPN-соединение в качестве службы).


    MCSA
    • Изменено ЙоЖыГ 14 марта 2010 г. 15:05
    14 марта 2010 г. 11:10
  • Сорри, но для того, что бы получить доступ к сетевому ресурсу с использованием доменной учетки не объязательно даже вводить компьютер в домен, комп в домен вводиться только с целью применения ГПО и что бы отпала необходимость по 200 раз вписывать свой пароль. Поэтому на ноут буке можно входить даже под локальным пользователем, а потом уже коннектиться к ВПН-у и пользовать доменную учетку. Мое имхо - не пробрасывается в циске какой-нить Kerberos, который служит для авторизации и ковырять нужно именно железку.

    14 марта 2010 г. 14:47
  • Мое имхо - не пробрасывается в циске какой-нить Kerberos, который служит для авторизации и ковырять нужно именно железку.

    Навряд-ли. Если почитаешь переписку - там автор говорит, что "Если ввести любого другого пустит". Так что проблема, наверное, связана с просроченным Ticket Granting Ticket.
    Про недоменную учётку для входа - тоже вариант, согласен.
    MCSA
    14 марта 2010 г. 15:03
  • И вообще не понятно для чего авторизация сделана на циске, а не в домене. получается две базы пользовательского каталога....

    14 марта 2010 г. 15:07
  • И вообще не понятно для чего авторизация сделана на циске, а не в домене. получается две базы пользовательского каталога....


    Ну там особенность в решение... в нем используется решения CryptoCard, циска как раз с ним работает.
    И циска к сожалению не в моей зоне ответственности и прав на нее практически не имею.
    15 марта 2010 г. 6:57
  • Мое имхо - не пробрасывается в циске какой-нить Kerberos, который служит для авторизации и ковырять нужно именно железку.

    Навряд-ли. Если почитаешь переписку - там автор говорит, что "Если ввести любого другого пустит ". Так что проблема, наверное, связана с просроченным Ticket Granting Ticket.
    Про недоменную учётку для входа - тоже вариант, согласен.
    MCSA

    Меня заинтересовала в eventlog событие с id 515 "Доверенный процесс входа в систему зарегистрирован локальным администратором безопасности. Этому процессу будет доверено представление запросов на вход в систему.
    Процесс входа в систему: KSecDD"

    При доступе из внутренней сети компании такого сообщения не возникает.

    Вариант с недоменной учеткой не рассматривается из-за корпоративных запретов.
    15 марта 2010 г. 7:01
  • по поводу KSecDD. EFS шифрование на диске используется?

    проблемные учетки не дублируются? на циске и в ад


    15 марта 2010 г. 21:28
  • Шифрование не используется, учетки (если имеется в виду логины) совпадают и в АД и в cisco.
    Специально создал ключ с другим логином, проблему не исправило.
    16 марта 2010 г. 12:18
  • А может кто нибудь подсказать, как протестировать инфраструктуру задействованную в Kerberos, чтобы можно было понять, что именно препятствует нормальной работе?
    17 марта 2010 г. 15:30
  • А вы попробовали воспользоваться моим советом про VPN в качестве службы и, соответственно, уже нормальной авторизацией (а не по кэшированному паролю) при входе? Kerberos и последующие глюки, по моему скромному мнению, имеют свои корни из-за того, что ограничен в домене срок "жизни" удостоверяющих мандатов (билетов)". "Мандат на выдачу мандатов" (сорри за вольный перевод Ticket Granting Ticket) и (или) последующие удостоверяющие билеты в контексте пользователя или компьютера либо имеют ограниченный срок действия, либо проверяются на актуальность этих удостоверений при каждом обращении.
    Мандат пользователя от которого вы пытаетесь зайти на общие сетевые ресурсы после разрыва соединения с доменом потерял свою актуальность и может допускать вас только до локальных ресурсов компьютера. Хотите иметь дело с доменной структурой - будьте любезны ещё раз пройти процедуру проверки пароля и выдачи TGT в реальном масштабе времени и ходить по сетевым ресурсам с мандатом, который проходит проверку "на лету".


    MCSA
    17 марта 2010 г. 19:07
  • Да, я настроил Cisco AnyConnect так, чтобы он делал Start Before Logon, т.е. он логинется пользователь уже при поднятом ВПН соединении. Но при этом появляются ошибки "обнаружена попытка нарушения безопасности".
    18 марта 2010 г. 7:19
  • Но при этом появляются ошибки "обнаружена попытка нарушения безопасности".

    Где появляются? Можно чуть-чуть поподробнее? Скриншот?
    MCSA
    18 марта 2010 г. 11:51
  • Всем спасибо решил проблему.
    22 марта 2010 г. 7:03
  • Отлично! И что было причиной?


    MCSA
    22 марта 2010 г. 8:13