Tw-city.info

IT Новости
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Сценарий входа в домен

Сценарий входа в домен

Вопрос

Windows 2003 R2 SP2, AD

Политикой задаю запуск файла net.bat

В net.bat всего две строчки:

При логоне у пользователя запускается процесс cmd и зависает, не выполнив net.bat

Смущает следующее: две кавычки после cmd /c и пробел после предпоследней кавычки.

Что может мешать выполнению сценария?

  • Изменено S.Igor 17 мая 2012 г. 12:33

Ответы

Переименуйте скрипт! Его имя совпадает со встроенной командой net. Соответственно при использовании в скрипте команд типа «net use» произойдет зацикливание (т.е. скрипт будет вызывать сам себя).

  • Предложено в качестве ответа Svolotch 24 мая 2012 г. 16:21
  • Помечено в качестве ответа WindowsNT.LV Editor 24 мая 2012 г. 16:40

Все ответы

Выполнению сценария может мешать ограничение безопасности IE. Попробуйте добавить в доверенные узлы (или локальные) ваш домен (или сервер) \хххх.local.

Можно так же «руками» выполнить скрипт. Он должен выполниться без запросов безопасности.

Выполнению сценария может мешать ограничение безопасности IE. Попробуйте добавить в доверенные узлы (или локальные) ваш домен (или сервер) \хххх.local.

Можно так же «руками» выполнить скрипт. Он должен выполниться без запросов безопасности.

Сервер добавлен в доверенную зону, при запуске «руками» скрипт отрабатывает и запроса о запуске неподписанного софта не возникает.

  • Изменено S.Igor 18 мая 2012 г. 7:37

Выполните скрипт от лица пользователя вручную и посмотрите, на чём он подвисает. Наверняка пишет диагностическое сообщение и ждёт реакции пользователя.

Кстати, положить его можно было бы в папку \DomainControllerNetLogon, быстрее же найти файл и исправить, если что. Не забудьте только замазать все названия, иначе вдруг что случится, если мы увидим название домена.. криминал!

MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor; CCNA; CCSI

Сценарий входа в домен

Вот нашел скрипт, который по групповому признаку подключает сетевые диски. Положил в папку windowssystem32replimportscripts, к своему доменному пользователю выставил на сценарий входа его. Реакция странная на него, сначала он срабатывал, но со второй третьей авторизации. После внесения изменений в скрипт (добавил еще один сетевой диск на подключение) изменений не пронаблюдал, все так же цеплялся один диск вместо двух. В скрипте изменил только название серверов на свои и изменил название группы, для которой они цепляются. После изменения сценария входа пользователя сервер не перегружал. В чем может быть проблема? Вот скрипт:
‘================================================= =========================

‘ VBScript Source File

‘ NAME: MapDrivesInGroup.vbs

‘ VERSION: v1.1

‘ AUTHOR: SergeyCVS

‘ COMMENT: Подключение сетевых дисков на основе групп с записью ошибок в EventLog

‘================================================= =========================

Option Explicit
‘On Error Resume Next

Dim WshShell, WshNetwork
Dim strUserDN, objSysInfo, GroupObj, UserGroups, UserObj

‘ Задаем имя файлового сервера, при использовании нескольких серверов
‘ создаем несколько констант и используем их при вызове MapDrv
Const FileSrv1 = «\TURBO»
Const FileSrv2 = «\ALPHA»

Set WshShell = WScript.CreateObject(«WScript.Shell»)
Set WshNetwork = WScript.CreateObject(«WScript.Network»)
Set objSysInfo = CreateObject(«ADSystemInfo»)

Set UserObj = GetObject(«LDAP://» & strUserDN)

For Each GroupObj In UserObj.Groups
UserGroups=UserGroups & «[» & GroupObj.Name & «]»
Next

‘MsgBox «Member of «& UserGroups

if InGroup(«Domain Admins») then
MapDrv «O:», FileSrv2 & «WORK»,»Work»
end if

if InGroup(«Domain Admins») then
MapDrv «P:», FileSrv1 & «CMD»,»turbo+cmd»
end if

‘================================================= =========================

‘ Function MapDrv(DrvLet, UNCPath, DrvName)

‘ DrvLet — Буква устройства
‘ UNCPath — Сетевой путь
‘ DrvName — Название диска отображаемое в проводнике Windows

‘ COMMENT: Подключение сетевых дисков с записью ошибок в EventLog

‘================================================= =========================

Function MapDrv(DrvLet, UNCPath, DrvName)

Dim objFSO, oShell ‘ Object variable
Dim Msg

Set objFSO = CreateObject(«Scripting.FileSystemObject»)
Set oShell = CreateObject(«Shell.Application»)

On Error Resume Next

If objFSO.DriveExists(DrvLet) Then
WshNetwork.RemoveNetworkDrive DrvLet, true, true
End If

WshNetwork.MapNetworkDrive DrvLet, UNCPath
oShell.NameSpace(DrvLet).Self.Name = DrvName

Select Case Err.Number
Case 0 ‘ No error

Case -2147023694
WshNetwork.RemoveNetworkDrive DrvLet, true, true
WshNetwork.MapNetworkDrive DrvLet, UNCPath
oShell.NameSpace(DrvLet).Self.Name = DrvName

Case -2147024811
WshNetwork.RemoveNetworkDrive DrvLet, true, true
WshNetwork.MapNetworkDrive DrvLet, UNCPath
oShell.NameSpace(DrvLet).Self.Name = DrvName

Msg = «Mapping network drive error: » & _
CStr(Err.Number) & » 0x» & Hex(Err.Number) & vbCrLf & _
«Error description: » & Err.Description & vbCrLf
Msg = Msg & «Domain: » & WshNetwork.UserDomain & vbCrLf
Msg = Msg & «Computer Name: » & WshNetwork.ComputerName & vbCrLf
Msg = Msg & «User Name: » & WshNetwork.UserName & vbCrLf & vbCrLf
Msg = Msg & «Device name: » & DrvLet & vbCrLf
Msg = Msg & «Map path: » & UNCPath

WshShell.LogEvent 1, Msg, FileSrv1
End Select
End Function

Function InGroup(strGroup)
InGroup=False
If InStr(UserGroups,»[CN=» & strGroup & «]») Then
InGroup=True
End If
End Function

И еще насколько я знаю файлом сценария может быть .bat файл, но на него никакой реакции абсолютно. Почему так может быть?

Сценарий входа в домен

Применение сценариев WSH для администрирования Windows ХР

Одним из основных назначений сценариев WSH является, в конечном счете, автоматизация работы администраторов компьютерных систем, построенных на базе Windows. В данной главе мы рассмотрим примеры сценариев, которые могут быть полезны администраторам в их повседневной работе, например, при создании сценариев регистрации для пользователей.

Читать еще:  Ntdsutil удаление контроллера домена

Особое внимание мы уделим вопросам применения в сценариях WSH таких мощных современных технологий Microsoft, как ADSI — Active Directory Service Interface и WMI — Windows Management Instrumentation, которые позволяют автоматизировать процесс администрирования как отдельной рабочей станции, так и крупной корпоративной информационной системы в целом. Отметим, что в данной книге не ставится задача более или менее полного раскрытия этих технологий, а лишь кратко описываются их основные возможности и приводятся примеры сценариев для их реализации.

Использование службы каталогов Active Directory Service Interface (ADSI)

Обсудим сначала термины «каталог» и «служба каталога», которые будут использоваться в этом разделе. Под каталогом в общем смысле этого слова подразумевается источник информации, в котором хранятся данные о некоторых объектах. Например, в телефонном каталоге хранятся сведения об абонентах телефонной сети, в библиотечном каталоге — данные о книгах, в каталоге файловой системы — информация о находящихся в нем файлах.

Что касается компьютерных сетей (локальных или глобальных), здесь также уместно говорить о каталогах, содержащих объекты разных типов: зарегистрированные пользователи, доступные сетевые принтеры и очереди печати и т.д. Для пользователей сети важно уметь находить и использовать такие объекты (а их в крупной сети может быть огромное количество), администраторы же сети должны поддерживать эти объекты в работоспособном состоянии. Под службой каталога (directory service) понимается та часть распределенной компьютерной системы (компьютерной сети), которая предоставляет средства для поиска и использования имеющихся сетевых ресурсов. Другими словами, служба каталога — это единое образование, объединяющее данные об объектах сети и совокупность служб, осуществляющих манипуляцию этими данными.

В гетерогенной (неоднородной) компьютерной сети могут одновременно функционировать несколько различных служб каталогов, например, NetWare Bindery для Novell Netware 3.x, NDS для Novell NetWare 4.x/5.x, Windows Directory Service для Windows NT 4.0 или Active Directory для Windows 2000. Естественно, для прямого доступа к разным службам каталогов приходится использовать разные инструментальные средства, что усложняет процесс администрирования сети в целом. Для решения этой проблемы можно применить технологию ADSI — Active Directory Service Interface фирмы Microsoft, которая предоставляет набор объектов ActiveX, обеспечивающих единообразный, не зависящий от конкретного сетевого протокола, доступ к функциям различных каталогов.

Объекты ADSI включены в операционные системы Windows ХР/2000, а также могут быть установлены в более ранних версиях, для чего их нужно скачать с сервера Microsoft (http://www.microsoft.com/NTWorkstation/downloads/Other/ADSI25.asp).

Для того чтобы находить объекты в каталоге по их именам, необходимо определить для этого каталога пространство имен (namespace). Скажем, файлы на жестком диске находятся в пространстве имен файловой системы. Уникальное имя файла определяется расположением этого файла в пространстве имен, например:

Пространство имен службы каталогов также предназначено для нахождения объекта по его уникальному имени, которое обычно определяется расположением этого объекта в каталоге, где он ищется. Разные службы каталогов используют различные виды имен для объектов, которые они содержат. ADSI определяет соглашение для имен, с помощью которых можно однозначно идентифицировать любой объект в гетерогенной сетевой среде. Такие имена называются строками связывания (binding string) или строками ADsPath и состоят из двух частей. Первая часть имени определяет, к какой именно службе каталогов (или, другими словами, к какому именно провайдеру ADSI) мы обращаемся, например:

? «LDAP://» — для службы каталогов, созданной на основе протокола LDAP (Lightweight Directory Access Protocol), в том числе для Active Directory в Windows 2000;

? «WinNT://» — для службы каталогов в сети Windows NT 4.0 или на локальной рабочей станции Windows ХР/2000;

? «NDS://» — для службы каталогов NetWare NDS (Novell Directory Service);

? «NWCOMPAT://» — для службы каталогов NetWare Bindery.

Вторая часть строки ADsPath определяет расположение объекта в конкретном каталоге. Приведем несколько примеров полных строк ADsPath:

В этом разделе мы подробно рассмотрим несколько простых сценариев, использующих объекты ADSI для автоматизации некоторых распространенных задач администрирования на отдельной рабочей станции с операционной системой Windows ХР; поняв принцип их работы, вы без труда сможете написать аналогичные сценарии для локальной сети, которая функционирует под управлением Active Directory или контроллера домена с Windows NT 4.0 (множество подобных примеров приведено в [18]).

Напомним, что на выделенном компьютере с Windows ХР имеется база данных, содержащая информацию обо всех локальных пользователях этого компьютера. Пользователи компьютера определяются своими атрибутами (имя регистрации, полное имя, пароль и т.п.) и могут объединяться в группы. Ниже мы приведем примеры сценариев WSH, с помощью которых можно:

? получить список имеющихся в локальной сети доменов;

? получить список всех групп, определенных на компьютере;

? добавить и удалить пользователя компьютера;

? определить всех пользователей заданной группы или все группы, в которые входит определенный пользователь;

? просмотреть атрибуты пользователя и изменить его пароль.

Для получения более полной информации по технологии ADSI следует обратиться к документации Microsoft или специальной литературе (см. введение).

Связывание с нужным объектом каталога

Первым шагом для доступа к пространству имен любого каталога в целях получения информации о его объектах или изменения свойств этих объектов является связывание (binding) с нужным объектом ADSI.

Читать еще:  Win 10 подключение к домену

Рассмотрим вначале, каким образом формируется строка связывания для доступа к объектам отдельной рабочей станции с операционной системой Windows ХР. В общем виде эта строка имеет следующий формат:

Здесь параметр ComputerName задает имя компьютера; ObjectName — имя объекта (это может быть имя группы, пользователя, принтера, сервиса и т. п.); className — класс объекта. Возможными значениями параметра className являются, например, group (группа пользователей), user (пользователь), printer (принтер) или service (сервис Windows ХР).

Указав в качестве строки ADsPath просто » WinNT: «, можно выполнить связывание с корневым объектом-контейнером, содержащим все остальные объекты службы каталога.

Приведем несколько примеров строк связывания для доступа к различным объектам компьютера Windows ХР (табл. 11.1).

Таблица 11.1. Варианты строк связывания на компьютере Windows ХР

Windows Script Host для Windows 2000/XP (120 стр.)

Для простоты проверки примеров мы далее будем рассматривать сценарии включения/выключения и входа/выхода, которые хранятся на локальной рабочей станции, работающей под управлением Windows ХР. Ниже будет подробно описано, в каких специальных папках нужно сохранять сценарии того или иного вида и каким образом происходит подключение этих сценариев. Для использования сценариев включения/выключения и входа/выхода в сети со службой каталогов Active Directory нужно просто перенести сценарии в соответствующие папки на контроллере домена и воспользоваться оснасткой Active Directory — пользователи и компьютеры (Active Directory — users and computers) консоли управления MMC для назначения этих сценариев соответствующим объектам групповой политики.

Сценарии, выполняемые при загрузке операционной системы

Сценарии включения/выключения, как и сценарии входа/выхода групповой политики, подключаются с помощью оснастки Групповая политика (Group Policy) в MMC. Процесс добавления оснастки Групповая политика (Group Policy) для локальной рабочей станции был подробно описан в разд. «Блокировка локальных и удаленных сценариев WSH. Пример административного шаблона» главы 4 (рис. 11.8).

Рис. 11.8. Мастер групповой политики

Для того чтобы подключить определенный сценарий включения, нужно выделить раздел Конфигурация компьютера|Конфигурация Windows|Сценарии (запуск/завершение) (Computer Configuration | Windows Configuration|Scripts (Startup/Shutdown)) и выбрать свойство Автозагрузка (Startup), после чего будет выведено диалоговое окно Свойства: Автозагрузка (Properties: Startup) (рис. 11.9).

Рис. 11.9. Список установленных сценариев включения

Для добавления нового сценария нужно нажать кнопку Добавить (Add) и в диалоговом окне Добавление сценария (Adding script) указать имя нужного файла (для этого можно воспользоваться кнопкой Обзор (Browse)) и, в случае необходимости, параметры сценария (рис. 11.10).

Отметим, что по умолчанию сценарии включения хранятся в каталоге %SystemRoot%System32GroupPolicyMachineScriptsStartup.

Рис. 11.10. Имя и параметры сценария включения

Сценарии, выполняемые при завершении работы операционной системы

Для подключения сценариев выключения нужно выбрать свойство Завершение работы (Shutdown) в разделе Сценарии (запуск/завершение) (Scripts (Startup/Shutdown)), после чего будет выведено диалоговое окно Свойства: Завершение работы (Properties: Shutdown) (рис. 11.11).

Рис. 11.11. Список установленных сценариев выключения

Как и в предыдущем случае, для добавления нового сценария нужно нажать кнопку Добавить (Add) и в диалоговом окне Добавление сценария (Adding script) указать имя нужного файла (по умолчанию сценарии выключения хранятся в каталоге %SystemRoot%System32GroupPolicyMachineScriptsShutdown) и параметры сценария.

Сценарии входа для всех локальных пользователей

Сценарии входа групповой политики подключаются в разделе Конфигурация пользователя|Конфигурация Windows|Сценарии (вход/выход из системы) (User Configuration|Windows Configuration|Scripts (Logon/Logoff)). В этом разделе нужно выбрать свойство Вход в систему (Logon), после чего будет выведено диалоговое окно Свойства: Вход в систему (Properties: Logon) (рис. 11.12).

Для добавления нового сценария входа нужно нажать кнопку Добавить (Add) и в диалоговом окне Добавление сценария (Adding script) указать имя нужного файла (по умолчанию сценарии выключения хранятся в каталоге %SystemRoot%System32GroupPolicyUserScriptsLogon) и параметры сценария.

Рис. 11.12. Список установленных сценариев входа

Сценарий выхода для всех локальных пользователей

Для подключения сценариев выхода нужно выбрать свойство Выход из системы (Logoff) в разделе Сценарии (вход/выход из системы) (Scripts (Logon/Logoff)), после чего будет выведено диалоговое окно Свойства: Выход из системы (Properties: Logoff) (рис. 11.13).

Для добавления нового сценария нужно нажать кнопку Добавить (Add) и в диалоговом окне Добавление сценария (Adding script) указать имя нужного файла (по умолчанию сценарии выхода хранятся в каталоге %SystemRoot%System32GroupPolicyUserScriptsLogoff) и параметры сценария.

Рис. 11.13. Список установленных сценариев выхода

Сценарий входа для одного пользователя

Сценарии входа для отдельных пользователей назначаются с помощью оснастки Локальные пользователи и группы (Local users and groups).

В Windows NT для этого использовался Диспетчер пользователей (User Manager for Domain).

Для добавления этой оснастки в консоли ММС выберем пункт Добавить или удалить оснастку (Add/Remove Snap-in) в меню Консоль (Console) и нажмем кнопку Добавить (Add). В появившемся списке всех имеющихся оснасток нужно выбрать пункт Локальные пользователи и группы (Local users and groups) и нажать кнопку Добавить (Add). После этого появится диалоговое окно, в котором нужно указать, что выбранная оснастка будет управлять локальным компьютером, и нажать кнопку Готово (Finish) (рис. 11.14).

Рис. 11.14. Выбор компьютера, которым будет управлять оснастка Локальные пользователи и группы

Читать еще:  Bginfo в домене

Никаких других оснасток в окно консоли мы добавлять не будем, поэтому нажимаем кнопку Закрыть (Close) в списке оснасток и кнопку OK в окне добавления/удаления оснасток. После этого мы можем в окне консоли просматривать список локальных пользователей компьютера и изменять их свойства (рис. 11.15).

Рис. 11.15. Список пользователей локального компьютера

Для назначения пользователю сценария входа нужно выбрать этого пользователя (например, Popov) в списке и перейти на вкладку Профиль (Profile) в диалоговом окне со свойствами пользователя. Имя сценария входа вводится в поле Сценарий входа (Logon Script) этого окна (рис. 11.16).

Рис. 11.16. Настройки профиля пользователя

Путь к сценарию входа нужно указывать относительно каталога %SystemRoot%System32ReplImportScripts. Если, скажем, сценарий scr99.bat для пользователя Popov находится в каталоге с полным именем F:WindowsSystem32ReplImportScriptsScript99, то в качестве пути к сценарию входа нужно указать Script99scr99.bat.

Примеры сценариев входа/выхода

Ниже рассмотрены несколько сценариев (два из которых являются обычными командными файлами), которые можно использовать в качестве сценариев входа или выхода.

Подключение сетевых дисков и синхронизация времени при регистрации пользователей

Часто сценарии входа используются для подключения дисков и портов принтера к сетевым ресурсам, а также для синхронизации системного времени пользовательских компьютеров с системным временем определенного сервера (это необходимо, например, для файл-серверных банковских систем, работающих в реальном времени). Конечно, для этих целей можно написать сценарий WSH, однако в подобных случаях проще ограничиться обычным командным (пакетным) файлом. Отметим, что в пакетных файлах можно использовать различные утилиты командной строки из пакетов Windows NT/2000/XP Resource Kit, с помощью которых многие задачи можно решить наиболее быстрым и простым способом. В качестве примера упомянем лишь одну полезную команду IFMEMBER , которая позволяет, не прибегая к помощи ADSI, проверить принадлежность пользователя, выполняющего регистрацию, к определенной группе.

Сценарий входа в домен

через политики
сразу читай только 2000 и ХР клиенты..

98SE, даже на 95 несколько машин есть
у этих и с переменными if member проблемы будут (нужен Kixtart и т.д)

но сложность в чем? в неудобстве задать сотне-другой юзеров скрипт (править каждому свойства..) но один раз?
тут можно воспользоватся утилитками допускающими внесение однотипных данных группе юзеров (hiena например)
в NetWare со логон скриптами попроще было.. но аналога именно для групп юзеров в 2000 не найдешь..

Haker
Это вам после Новела так показалось . Так оно и есть, впрочем.

Рекомендую, если с Новелом дружили, поставить NDS на Windows 2000 и рулить себе доменом AD, как Новеловским NDS. ИМХО, конечно.

Haker
на плюсы AD перед NDS
я Тебя умоляю.. не начинай.. а то опять в ветке начнется война..

для каждого юзера свой скрипт писать
зачем? есть переменные user, username, HOME ..

на 70% клиенских машин 98-е и 95-е
это все.. считай попал.. для этих клиентов что есть AD что его нет..

Aww
зачем? есть переменные user, username, HOME .. — Эти переменные для WSH действительны?

А как понять насчет 98-х виндов? «Что есть AD, что его нет» — я смогу хоть залогиниться с них. Ну и конечно очень желательно, чтобы сценарии входа работали(хотя бы .BAT для начала), а также профили перемещаемые. Или эти прелести недоступны для 98 или я чего-то не понял.

Работу AD на 98-х клиентах еще не проверял. Пока экспирементирую на своей машине с w2k. С логином и профилями пока проблем не обнаружено.

На какие грабли могу наступить с win95-98?(Насчет политик понятно.) И что необходимо, чтобы граблей этих избежать?

Chief
Спасибо за ответ все получилось, но никак не проходит одна штука.
Содержание logon.bat:

net time /set /yes
net use s: \servershare /yes
net use l: /home /yes

При выполнении строки «net use s: \servershare /yes», пишет, что путь не существует. Следущую строку обрабатывает отлично. Если строки поменять местами, тогда он пишет о не существующем пути уже для другой строки, т.е. не подключает диск указанный в файле первым.
Если батник запустить когда комп уже залогиненый, тогда он обрабатывает оба файла нормально. В чем дело может быть?

Добавление от 04.06.2004 15:18:

pre-W2k разве умеют setsntp??

Aww
Спасибо все получилось
AlF$
\server нет смысла писать. Клиенты сами находят сервер времени.

Появилась другая проблема. На сервере юзерам разрешено завершение работы. Но на клиентах w2k доступно только «Завершение сеанса юзер» и больше ничего. Пользователи находятся на сервере AD, так мне еще что-ли на каждой станции разрешать завершение работы? Должен же быть какой нибудь выход? Может я на AD чего-то не донастроил?

Добавление от 04.06.2004 17:22:

В политике домена юзерам тоже разрешено завершение. Это же должно действовать на все станции?

Haker
\server нет смысла писать. Клиенты сами находят сервер времени.
ИМХО pre-W2k клиенты ничего не найдут, если им не роздано «свыше» (от DHCP например).

Должен же быть какой нибудь выход?
Что у юзеров в результате в действующей локальной политике?

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector