[exo]

TEST@Name_Domain »

не факт, я всегда вхожу без @domain.name

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

dany all к примеру. или выключите его от розетки ЛВС.

Ну кроме, как поднятия IPSEC, можно что нить еще предложить? »

хм... IPsec используется для шифрования трафика в ВПН сетях. при чём тут он? если я не прав - поправьте.

хотя машина не зарегистрирована в домене »

т.е. машина ещё в WORKGROUP-е ?

[wertyg]

в первый раз когда ты коннектишся к шаровым ресурсам то передаёш логин\парольчик и контроллер проверяет наличие такого у себя в базе. и находит. а что не так? данные аутентификации не привязаны к машине. т.ч. зайти зарегистрированному в домене пользователю не проблема с незарегестрированного ПК.

во втором варианте что то не так. т.к. у меня можно как и в первом варианте подлючиться к контроллеру без передачи имени домена(зайдя при этом на машину под локальной учёткой). т.е. не указывая в каком иммено домене зарегестрирован пользователь. просто передав логин\пароль. возможно у тебя не один домен в сети или ты являешся чьейто дочерью.) потому нужно обязательно передать имяДомена\логин\пароль.

на тот случай если ты хочеш чтоб незарегестрированные ПК не смогли подключиться к контроллеру тогда можно попробовать следующие(я сам не пробовал но пред-положу) в ПолитикеБезопасностиКонтроллераДомена-ПараметрыБезопасности-ЛокальныеПолитики-НазначениеПравПользователей есть параметр ДоступКкомпьютеруИзСети. там указано кто может подключиться к контроллеру из сети. одним из параметров явл. группа\пользователь "Все". это сделано для того чтоб незарегестрированные ПК можно было вводить в домен не создавая учётки ПК предварительно. если убрать "Все" и добавить "Компьютеры домена" тогда на основании этой политики к контроллеру можно будет получить доступ если(в моём случае) ты состоиш в следующих группах:
1 - PDC\IWAM_nameMyDomain.
2 - администраторы.
3 - Компьютеры домена.
4 - контроллеры домена предприятия.
5 - пред-Вин2000 доступ.
6 - прошедшие проверку.

я не знаю порядка просмотра записей в этом параметре. мот кто подскажет? предположу что снача проверяется машина потом пользователь. проверить это можно только экспеременом( ну или кто знающий подскажет.) )

метод проверки:
если ты на ПК не входящем в группу КомпьютерыДомена тогда тебя не должно пустить вообще даже если ты администратор или прошедшый проверку, иначе не имеет смысла добавлять сюда учётку КомпьютерыДомена т.к любой прошедший проверку т.е. зарегестрированный пользователь сможет с любого ПК зайти на контроллер. т.е. имеем что имели.
нужен эксперемент.)

хм... IPsec используется для шифрования трафика в ВПН сетях. при чём тут он? если я не прав - поправьте. »

нет. он используеться не только в ВПН(протокол L2TP в частности.РРТР IPsec не использует) но и при передаче любого траффика в сети локальной или глобальной. с его помощью можно защитить любой траффик выше третьего уровня модели OSI.

з.ы. учти я не проверял то что изложил. делай это на свой страх и риск.)

[fedor2]

exo

т.е. машина ещё в WORKGROUP-е ?

Да машина еще в WORKGROUP-е

wertyg

во втором варианте что то не так. т.к. у меня можно как и в первом варианте подлючиться к контроллеру без передачи имени домена(зайдя при этом на машину под локальной учёткой). т.е. не указывая в каком иммено домене зарегестрирован пользователь. просто передав логин\пароль. возможно у тебя не один домен в сети или ты являешся чьейто дочерью.) потому нужно обязательно передать имяДомена\логин\пароль

Домен 1, дочерним не является, а поповоду

1 - PDC\IWAM_nameMyDomain.
2 - администраторы.
3 - Компьютеры домена.
4 - контроллеры домена предприятия.
5 - пред-Вин2000 доступ.
6 - прошедшие проверку.


убрал еще и 6 пункт, так как 5 - пред-Вин2000 доступ, почти то же самое

[exo]

он используеться не только в ВПН »

спасибо, что поправил.

Да машина еще в WORKGROUP-е »

странно, если машина в WORKGROUP-e то как она лезет в АД для аунтификации?

[fedor2]

exo

странно, если машина в WORKGROUP-e то как она лезет в АД для аунтификации?

первый абзац wertyg

в первый раз когда ты коннектишся к шаровым ресурсам то передаёш логин\парольчик и контроллер проверяет наличие такого у себя в базе. и находит. а что не так? данные аутентификации не привязаны к машине. т.ч. зайти зарегистрированному в домене пользователю не проблема с незарегестрированного ПК.

[KobaLTD]

Разясняю.
Внимательно изучите принципы постраения авторизации в вындов и доменах.
1) Разлечаються уровни акторизации на доступ к ресурсам машины (притеры, шаринги, RPC) и разлечаеться участи в струкре AD.
2) Реализация авторизации в домене для случая с шарами отличаеться от компа stadalone только тем что в домене для хранения используеться LDAM а у отдельного компа NTLM
3) механизм авторизации для шар такой.
COMP1 -> я к тебе ->COMP2
COMP1 <-ты кто<-COMP2
COMP1 ->вася,пароль "стой стреляю"->COMP2
дале если знает то пускиет если нет то нет. И далеле начинаються более интересные механизмы. Теперь нюансы, при
1) запись вида test@"что то тут" или "что тут"\test просто дает понят в какой базе искать данного пользователя (внимательно читайте про доверительные отношения) "что тут" может быть именем кома, именем домена. т.е. явное указание в каком месте искать пользователя. если это не указана то используеться база по умолчанию - для компа в домене это LDAP, для отдельного компа локальная база. Т.е. если пользователь test есть в домене и его нет в базе локального отдельно стоящего компа то проблем не возникнет. Другой вопрос что в этом режиме он получит доступ только на уровне на котором получилбы стучас также к отдельному компу (т.е. не получая билетика керберос и т.д.)
это ответ на 1 вопрос.
на второй надо понять что вы подразумеваете - не пускалоб - если иметья вход в AD то его и так не происходт если на доступ к шарам - перекрыв его вы перекроете себе возможностсть воодить компы в домен. Да и тактично ли это ели пользователь авторизован в домене то он и так имеет доступ к нужной ему инфе, и если вам разница с кого компа он полул этот доступ?

[fedor2]

KobaLTD

По п.2 Если я логинюсь на ресурсы DC то достаточно вводить только логин, если же я логинюсь к ресурсам любого компа, входящего в домен, но не к DC, то обязательно добавлять имя домена, например, как в моем примере TEST@namedomain. Разобрался.
А точно что мне нужно это NAP от MS, но это реализовано в Windows Server 2008

[wertyg]

2. если даже ПК зарегистрирован в домене, но пользователь входит локально на кампутер и пытается воспользоваться сетевыми (расшареными) ресурсами »

почемуто я привязал эту фразу к контроллеру. иначе всё как сказал KobaLTD,

1) запись вида test@"что то тут" или "что тут"\test просто дает понят в какой базе искать данного пользователя (внимательно читайте про доверительные отношения) "что тут" может быть именем кома, именем домена. т.е. явное указание в каком месте искать пользователя »

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

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

не смог понять эту строку:

если иметья вход в AD то его и так не происходт если на доступ к шарам - перекрыв его вы перекроете себе возможностсть воодить компы в домен »

а чтоб добовлять компы в домен рекомендуют предварительно добавив их учётки в АД. только после этого вводить в домен сам ПК. если так то мы не нарушем правило из политики.

ты злодей.)

убрал еще и 6 пункт, так как 5 - пред-Вин2000 доступ, почти то же самое »

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

отпешись о результатах.

[Keitaro]

fedor2,
Еще можно сделать привязку пользователей к комьютерам, если это возможно и целесообразно в вашем случае.