none
Log on using dial-up connections RRS feed

  • Вопрос

  • Уважаемые, не знаю куда запостить поэтому сюда...

     

    Встала задача включить машинам в определённой OU чекбокс Log on using dial-up connections, как можно реализовать данную задачу? Групповые политики? Скрипт через групповые политики?

    22 августа 2008 г. 14:37

Ответы

Все ответы

  • http://support.microsoft.com/kb/172125

    В более "поздних" ОС ключ и его значения не изменились

    22 августа 2008 г. 18:14
  • Спасибо, я правда нашёл уже сам. Но теперь возникает вопрос: если на удалённой точке вдруг отсутствует связь с VPN сервером, возможно ли как-нибудь чтобы откэшированый профиль всё-таки загружался?

    25 августа 2008 г. 14:56
  •  

    Если под этим профилем уже загружались ранее на этой машине, то да. По умолчанию рабочая станция помнит (кэширует) последние 10 учётных записей под которыми логинились (прошу заметить, что 10 разных учётных записей). Т.е. в отсутствии контроллера залогониться можно и будут применены закэшированные политики. Правда, логон будет происходить продолжительное время.
    25 августа 2008 г. 16:26
  •  Vadims Podans написано:

     

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

     

    То что он должен логинится без контроллера - это понятно. А вот без связи с VNP-сервером?

    Дело в том, что он не загружает профиль: всплывает окно с ошибкой 800, и при исчерпании попыток дозвона это окно всплывает вновь для соединения вручную... профиль и не думает грузится. Может настроить где что надо?

    26 августа 2008 г. 6:16
  • А для этого должен использоваться локальный профиль, а не перемещаемый. Или перемещаемый, но имя сервера должно быть успешно разрешено посредством альтернативных методов, как броадкаст. VPN в вашем случае даёт лишь связь с контроллером домена и DNS на нём.

    26 августа 2008 г. 6:19
  •  Vadims Podans написано:

    А для этого должен использоваться локальный профиль, а не перемещаемый. Или перемещаемый, но имя сервера должно быть успешно разрешено посредством альтернативных методов, как броадкаст. VPN в вашем случае даёт лишь связь с контроллером домена и DNS на нём.

     

    Имя какого сервера должно разрешаться?

     

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

    26 августа 2008 г. 6:25
  •  DKu написано:
     Vadims Podans написано:

    А для этого должен использоваться локальный профиль, а не перемещаемый. Или перемещаемый, но имя сервера должно быть успешно разрешено посредством альтернативных методов, как броадкаст. VPN в вашем случае даёт лишь связь с контроллером домена и DNS на нём.

     

    Имя какого сервера должно разрешаться?

     

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



    Наверное, вы имели в виду не профиль, а доменный бюджет. Не совсем понятно при таком поведении ISP, почему бы не установить DC в Мухосранске ? Думаю, что RODC на 2008 сервере решит условие вашей задачи.
    26 августа 2008 г. 6:39
  •  

    Имя сервера, где хранятся перемещаемые профили, в случае применения перемещаемых профилей. Если ISP лажаются, то пользователи по дефолту имеют возможность логиниться под кэшированными профилями. Если профиль не закэширован, то войти будет нельзя. Возможно, при отсутствии связи с центральным офисом для логона нужно сбросить галочку с Log on using dial-up connections.
    26 августа 2008 г. 6:40
  • Sudden Death про DC вы конечно погорячились. Посмотрите входные данные там речь идёт о магазине! У нас около 250 розничных точек по всей России, нам надо в каждую DC поставить??? Пусть и read-only. В задаче ключевая фраза не "магазину работать надо", а "хотят запретить логинится локально".

     

    Vadims Podans вот в том, то и дело, что этот чекбокс мы хотим принудительно выставить без возможности снятия, а при неудачном соединении, чтобы загружался всё-таки профиль.

     

    Дело в том, что у нас магазинам запрещено пользоваться интернетом, но с помощью местных администраторов, они обходят все ограничения: убивают ключи в реестре от content advisors, меняют прокси-серверы в IE и т.д. задача стоит такая чтобы на торговые точки постоянно распространялись групповые политики. С теми точками у которых канал к ЦО поднят на Цисках - проблем нет, а вот с VPN'никами есть. Они отцепляются от RRAS сервера и творят там чего угодно.

    26 августа 2008 г. 6:57
  • Таки, как уже озвучили выше, бюджет не позволяет приобрести более надёжгный канал? А по поводу изменений веток реестра - тут нужно бороться административными мерами вкупе с техническими. Я не проверял, но вы попробуйте войти под кэшированной учёткой при отсутствии связи с VPN сервером как с выставленным, так и снятым чек-боксом. Если при выставленном не даёт логониться, а при снятном даёт, то придётся покупать стабильный канал.

     

    что касается RODC, то придётся и в центральном офисе ставить 2008 сервер. Можно поставить просто сервер, но в надёжном и защищённом от свободного доступа помещении.

    26 августа 2008 г. 7:05
  •  DKu написано:

    Sudden Death про DC вы конечно погорячились. Посмотрите входные данные там речь идёт о магазине! У нас около 250 розничных точек по всей России, нам надо в каждую DC поставить??? Пусть и read-only. В задаче ключевая фраза не "магазину работать надо", а "хотят запретить логинится локально".


    Выбор у вас не велик. Вам необходим канал до сервера, что удостоверяет вашу личность. А будет это вложение денег в ISP или в сервера, решайте сами.


     DKu написано:
     

    Дело в том, что у нас магазинам запрещено пользоваться интернетом, но с помощью местных администраторов, они обходят все ограничения: убивают ключи в реестре от content advisors, меняют прокси-серверы в IE и т.д. задача стоит такая чтобы на торговые точки постоянно распространялись групповые политики. С теми точками у которых канал к ЦО поднят на Цисках - проблем нет, а вот с VPN'никами есть. Они отцепляются от RRAS сервера и творят там чего угодно.



    Для решения таких задач существует административный ресурс. Уж поверьте, ни какие GPO не помогут в борьбе с локальными админами. Борьба с такими выходками так же не блещет разнообразием: не давать административных привелегий + докладные руководству. Иначе все это в пользу бедных. Более того, ERD и ему аналоги позволят стать локальным админом за пару минут.
    26 августа 2008 г. 7:17
  •  Sudden написано:

    Выбор у вас не велик. Вам необходим канал до сервера, что удостоверяет вашу личность. А будет это вложение денег в ISP или в сервера, решайте сами.

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

    26 августа 2008 г. 7:21
  • Господа, господа подождите. Мы свалились в обсуждение финансовых возможностей нашей компании.

     

    У нас компания использующая легальное ПО, мы не можем во все 250 магазинов купить лицензионные 2008 серверы. Мало того придётся в каждый магазин под него покупать ещё один системный блок, к тому же достаточно мощный. В центральном офисе и филиалах с сетевой инфраструктурой у нас всё в порядке, мы уже активно используем и 2008 серверы. Дело совсем не в этом.

    У нас отлаженная торговая система. Магазин при отсутствии связи с центральной БД может функционировать автономно. Транспорт написанный нашими программистами позволяет складывать всё в локальный SQL, а при возобновлении связи все транзакции переправлять в централную БД.

    Дело не в фунцировании торговых точек, а в том чтобы к 2 рабочим станциям в каждом магазинов них постоянно применялись ГП, но....

    поскольку ни один провайдер Владивостока, Красноярска, Вологды, Твери и т.д. не может гарантировать постоянную связь (ну у всех бывает) нам нужно чтобы при принудительно включённом чекбоксе и отсутствии связи загрузка всё-таки происходила.

    26 августа 2008 г. 7:23
  • Если моё предположение верно, то ваша задача технически не решается. Нужно совмещать технические меры с административными. Т.е. вывести каждые 2 машины из под действия политики и разрешить снимать чек-бокс при отсутствии связи с центральным офисом. При этом ввести документ, который бы всю эту процедуру регулировал и при нарушении каких-то правил (самовольное отключение чек-бокса, захват административной учётной записи средствами ERD, etc) - служебка руководству. Пока что другого выхода не вижу. Можно отключать оптические приводы, паролить БИОС, пломбировать кейсы..волокита ещё та, но как уже сказали, выбор у вас невелик.
    26 августа 2008 г. 7:33
  • Я быть может запутал вас немного: проще говоря меня интересовал вопрос:

    возможно ли сделать так чтобы при принудительно включённом чекбоксе Log on using Dial-up connection и отсутствии связи с VPN-сервером загрузка всё-таки происходила?

    26 августа 2008 г. 7:37
  •  Vadims Podans написано:
    Если моё предположение верно, то ваша задача технически не решается. Нужно совмещать технические меры с административными. Т.е. вывести каждые 2 машины из под действия политики и разрешить снимать чек-бокс при отсутствии связи с центральным офисом. При этом ввести документ, который бы всю эту процедуру регулировал и при нарушении каких-то правил (самовольное отключение чек-бокса, захват административной учётной записи средствами ERD, etc) - служебка руководству. Пока что другого выхода не вижу. Можно отключать оптические приводы, паролить БИОС, пломбировать кейсы..волокита ещё та, но как уже сказали, выбор у вас невелик.

     

    Всё... теперь понятно.

    26 августа 2008 г. 7:38
  • нет, нельзя:

    http://support.microsoft.com/kb/172125

    NOTE: After you add this value, the Log on using dial-up connection option will be permanently selected. If the remote network is not available to authenticate your logon, then you will not be able to logon to the computer

    о чём уже сказал dmirk на первой странице.

    26 августа 2008 г. 7:42
  •  Vadims Podans написано:

    нет, нельзя:

    http://support.microsoft.com/kb/172125

    NOTE: After you add this value, the Log on using dial-up connection option will be permanently selected. If the remote network is not available to authenticate your logon, then you will not be able to logon to the computer

    о чём уже сказал dmirk на первой странице.

     

    Извините, я сноски в конце статьи невнимательно прочитал. В любом случае всем спасибо за помощь.

    26 августа 2008 г. 7:58