Light-electric.com

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

Access this computer from the network

Access this computer from the network

Насколько существенно можно прикрыться от «непрофессиональных хачиков», поместив все привелегированные группы в Deny access to this computer from the network?
Допустим, получат доступ к какому-либо юзеру, скажем, из гр. администраторов, или пауэрюзеров.
Стоит ли туда запихивать все группы, включая скрытые (дебагеров, бэккапов и др.), или достоточно их отсутствия в Access this computer from the network?
(по поводу эксплоитов, понятно, рано или поздно научатся и юзеров прописать и полиси сменить. но пока этого не произошло,
тьфу-тьфу. )

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

Так что к «доступу по SMB» она имеет непосредственное отношение.
а никто и не говорил, что не имеет
речь шла о том, что
не обеспечивают защиты от доступа по SMB, SMTP, HTTP

Семен Семеныч Горбунков
прав 4u3u.. с SMB я маху дал.. да и hhtp привел памяти (с дачи) хотел только сказать что эта защита не от всего на свете. И обычно гарантированно защищает от любителей прикнектиться к Вам через проводник
сейчас проверил себя по первоисточнику. там это звучит как
«The Deny access to this computer from the network user right determines which users are prevented from accessing a computer over the network. This user right will deny a number of network protocols, including SMB-based protocols, NetBIOS, CIFS, HTTP, and COM+. «
ZZT
«затыкается» эффективно.. но первоначальных условий я не понял. если Ты всем запретишь доступ по сети то практически получишь автономный комп. на работоспособность же Твоих клиентов МС и т.д это не повлияет — исходящие соединения этой политикой не контролируются

полазь по сети — куча готовых настроек (там и остановка службы сервер есть как способ и т.д.)

Aww
Да надо гостя в сетку на самбовый хост сделать, да еще так, чтобы с сетевого окружения меня видели. Но администрировать из сети я точно не буду. Думаю, заткунть то, что можно.
Мне стало интересно, если кому-то из соседей таки удасться вытянуть какой-нибудь админский логин, что они смогут с ним сделать. (Телнета нет).

Семен Семеныч Горбунков
а разве возможно под localsystem проникнуть из сети?
Мне казалось, эксплоитами обычно запускают бинарный код внутри системных процессов, который чаще всего генерит админов. но я (как чайник), никогда не читал, чтобы то-то ещзе делали через loacalsystem. я просто плохо представляю что еще можно сделать.

цитата: Anonymous
я на своём компе администратор с пустым паролем, то получается кто угодно может на мой комп залогинится Это что, требует ответа?

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

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

Aww
Самое первое что напрашивается это подсунуть Тебе файл внутри которого есть исполняемый модуль
угу, я сегодня такую подопытную машину изучал.

Ну, допустим, сам я никогда не запущу то, что аплоадят, есть только право на запись в директорию.
Тут есть неопнятка с правами. может ли юзер с правом на запись в директорию при моей небрежности что-либо запустить на моей машине, или поменять права так, чтобы запустить (какие-нибудь распространенные дыры XP, скажем. ) Предположим, что все стало очень плохо и юезр может что-то запустить. Можно ли запустить скрипт, использующий права админа? Как я понимаю, в конечном счете это должно сводиться к запуску ntrights от имени админа. Или даже в этом случае ядро не даст использовать права админа, т.к. процесс будет дочерним?

Предположим, что все стало очень плохо и юезр может что-то запустить. Можно ли запустить скрипт, использующий права админа? Как я понимаю, в конечном счете это должно сводиться к запуску ntrights от имени админа. Или даже в этом случае ядро не даст использовать права админа, т.к. процесс будет дочерним?
Ой, как тут усе сложно-то
Дык усе знаешь, ли проще, имхо — получить права админа можно двумя путями — просто спросить/узнать его логин/пароль(в особо тяжелом случае паяльник погорячее нужен ), либо заюзать выявленную, но не закрытую соответствующей заплаткой уязвимость, причем легче всего это получится при локальном доступе к компу. Т.е. если на твоем компе работает хитрож.. юзверь, которому права админа прям очень нужны, он находит в и-нете последний эксплоит, запускает его и усе. При доступе по сети значительно все сложнее, особенно если файрволом на машине прикрыты все порты — тут либо нужно искать уязвимость самого файрвола, что крайне редко бывает, либо, что и делается — посылается тебе e-mail с нужным трояном, либо просто юзверь просит тебя открыть безобидный файлик на сервере — и вот снова троян у тебя в гостях.

то нетбиос, который в принципе нужен и у всех одногопроизводства мелкософта.
Ну как сказать — я легко могу срубить на своей машине Netbios over TCP/IP и ничего мне не будет — и почта будет ходить, и к файлам будет доступ .

я не могу, потому что MS_net, сетевое окружение, и все такое
Сочувствую, но ничем помочь не могу — от сетевого окружения надо отучать жесткими административными мерами — я уже 3 года как всех отучил — никто даже не страдает от того, что этого значка нет

ребят иногда(т.е. раньше был такой баг на соседней тачке, но тогда надо было снести ось на ней. я переставил . повторил процесс расшаривания. и всё ок. без проблем.) появляется проблем с заходом в расшаренные папки.
Поясню:
Ось ХР СП2. стандартные действия. включаем учётную запись гостя. и в секьюрти сетингсах убераем из пункта «Deny access to this computer fom the network» этого же самого гостя. далее расшариваем папки добавляем пермишинсы гостя(также гостя добавляем дополнительно в папку секьюрити. (кстати если ещё не сложно подскажите как сделать штоб не добавлять каждый раз гостя в пермишинсы. а чтобы гость в входил в поняте «Все», а то доступ разрешон всем, что по логике, не должно препятствовать гостю, но всеравно надо прописывать гостевые права ручками. неудобно ). и всё отлично юзаешь папки. т.е. с других компов можно из них штото скачать/закачать.

сейчас же подонство. всё сделал как обычно. ан нет. не пускает падла в паки
файрволл вырублен как служба.
Access this computer from the network гостя добавлял.
разрешил сетевую активность акаунтам без пароля. как 4u3u написал.

поможите а. чёта допереть не могу в чём трабл.

Добавление от 02.09.2005 11:26:

папка is not accessible. You might not have permissin to use this network resource. Contact the administator of this server to find out if you have access permissions.

Читать еще:  Access inner join

Not enough server storage is available to process this command.

Добавление от 02.09.2005 11:27:

William Wolos
чтобы гость в входил в поняте «Все»
Гость входит в группу «Все»

цитирую эксплорер:
1. попробуй открыть эту папку напрямую \compresurs
2. проверь наличие шары ipc$ (net share на том к которому подключаетесь)
3. проверь запущена и служба «Сервер»
и вообще — какие настройки менялись на компьютере к которому подключаемся? тюнинг и все такое

Гость входит в группу «Все»
блин. а почему тогда в папку пускает только после того как вручную в права добавишь гостя?

1. попробуй открыть эту папку напрямую \compresurs

2. проверь наличие шары ipc$ (net share на том к которому подключаетесь)

присутсвует. как и другие системные шары типа с$ d$ и т.д.

3. проверь запущена и служба «Сервер»

работает. и висит в автозагрузке.

есть утилитка xp-antispy через неё вырубил файрволл с центром безопасности и удалил месенджер — всё. (и также я поступал с другими тачками, на которых всё работает прекрасно)
А вообще над тачкой никто не издевается особенно. ася серфинг офис. да и всё в общем. хотяустановить что угодно есть возможность. врядли установка звукавых и графических редакторов так повлияет.

сейчас сканю касперским. и адварью.

Добавление от 02.09.2005 13:21:

блин. тачка чистая.

пытался зайти с тачиллы где 2000ый сп4 русский стоит . говорит типа:

«Недостаточно памяти сервера для обработки команды»

Полномочия на регистрацию: основа управления доступом в Windows

Учимся применять важнейший метод аутентификации.

Подсистема контроля доступа Windows, которая определяет пользователей, имеющих доступ к тем или иным ресурсам, основана на концепциях разрешений (permission) и пользовательских прав (user right). Разрешения связаны с объектами — например, разрешения для распечатывания файла, создания папки и добавления объекта user в Active Directory (AD). Пользовательские права связаны с системой Windows в целом — например, право пользователя регистрироваться в системе Windows или изменять системные часы.

Права пользователя Windows подразделяются на две категории: привилегии пользователя (user privilege) и права регистрации (logon right). Привилегии пользователя, такие как Change the System Time и Shut down the System, обеспечивают контроль над системными ресурсами и операциями, связанными с системой. Права регистрации задают учетные записи пользователей, которые могут регистрироваться в системе Windows, и способ регистрации учетной записи пользователя в системе. Более подробная информация об учетных записях пользователя и процедуре входа Windows приведена в статье «Все дело в доверии» (http://www.osp.ru/text/302/2599419/). В данной статье рассматривается, как использовать права регистрации в качестве инструмента контроля доступа, даны объяснения различных прав доступа и рекомендации по их применению.

Права регистрации — общая картина

В Windows Server 2003 и Windows XP определены 10 различных прав доступа, с помощью которых можно управлять разными типами попыток локальной и доменной аутентификации пользователей в системах Windows. Права регистрации также охватывают процедуры аутентификации пользователей, в том числе регистрацию в FTP-службе на базе Windows. Например, чтобы обеспечить регистрацию учетной записи пользователя в FTP-службе на базе Windows, необходимо присвоить учетной записи право Log on locally в системе Windows, на которой размещена служба FTP. В Windows 2000 было введено право регистрации «deny». Windows 2003, XP и Windows 2000 Service Pack 2 (SP2) и более поздние версии поддерживают права регистрации для Terminal Services.

В таблице 1 перечислены права регистрации Windows наряду с именами API, соответствующими каждому праву регистрации, и показаны встроенные группы, которые получают права регистрации, назначаемые по умолчанию на контроллере домена (DC), члене-сервере и автономной системе. Имена API — внутренние имена, используемые Windows для обозначения прав регистрации. Иногда их необходимо указывать при использовании инструментов командной строки, о которых будет рассказано ниже, или при просмотре журнала событий Security. Рассмотрим каждое право регистрации немного подробнее:

  • Log on locally позволяет пользователям регистрироваться в Windows с помощью комбинации клавиш Ctrl+Alt+Del или из экрана Welcome. В Windows этот метод входа называется локальным или интерактивным. Пользователям Windows 2000 это право необходимо для входа через Terminal Services.
  • Access this computer from the network обеспечивает подключение пользователей к компьютеру через сеть. Это право обязаны иметь все пользователи, желающие обратиться к удаленной системе для доступа к файлу, папке, приложению или другому ресурсу. В Windows данный метод регистрации называется сетевым или неинтерактивным входом.
  • Log on as a batch job позволяет пользователям регистрироваться для запуска пакета команд. Это право применяется в Windows Task Scheduler и некоторых других службах для регистрации пользователей. Scheduled Tasks автоматически предоставляет это право по мере необходимости — в моменты, когда необходимо запустить запланированное задание.
  • Log on as a service позволяет субъекту безопасности регистрироваться в качестве службы. Это право обеспечивает работу служб в системах Windows в фоновом режиме. Учетным записям System и Network Service на автономных системах и серверах, членах доменов, это право предоставляется по умолчанию. Если для запуска службы используется другая специальная запись, то необходимо явно назначить ей это право.
  • Allow logon through Terminal Services определяет пользователей, которые могут регистрироваться с помощью Terminal Services или клиента Remote Desktop.
  • Deny logon locally запрещает пользователю регистрироваться с клавиатуры или экрана Welcome компьютера. Это право имеет приоритет перед правом Log on locally.
  • Deny access to this computer from the network запрещает пользователю подключаться к компьютеру через сеть. Это право имеет приоритет перед правом Access this computer from the network.
  • Deny logon as a service запрещает субъекту безопасности регистрироваться в качестве службы для формирования контекста безопасности. Это право имеет приоритет перед правом Log on as a service.
  • Deny logon as a batch job запрещает пользователю регистрироваться в роли пакетного файла; оно имеет приоритет перед правом Log on as a batch job.
  • Deny logon through Terminal Services запрещает пользователю регистрироваться с помощью Terminal Services или Remote Desktop; это право имеет приоритет перед правом Allow logon through Terminal Services.

Права Deny logon полезны в крупных сетях Windows. Например, если нужно предоставить право Access this computer from the network всем, кроме двух конкретных учетных записей. В этом случае, гораздо проще назначить группе Authenticated Users право Access this computer from the network, а двум отдельным учетным записям — право Deny access to this computer from the network, вместо того, чтобы определять все учетные записи, имеющие доступ, объединяя их в специальную группу, а затем назначать этой группе право Access this computer from the network.

Управление правами регистрации в Windows

Чтобы назначать и управлять правами регистрации в Windows, можно использовать инструмент Local Security Policy (только на автономных системах) или оснастку Group Policy Object консоли Microsoft Management Console (MMC) (для автономных компьютеров и систем, членов доменов). В комплектах ресурсов Windows 2003 и Windows 2000 содержится два инструмента командной строки, которые помогают управлять правами регистрации: NTRights (ntrights.exe) и ShowPriv (showpriv.exe).

К инструменту Local Security Policy можно обратиться из раздела Administrative Tools Панели управления (меню Start, Settings, Control Panel, Administrative Tools, Local Security Policy). В окне Local Security Settings, право регистрации назначается путем расширения контейнеров Security Settings, Local Policies, User Rights Assignment (Экран 1).

Для доступа к оснастке Group Policy Object следует запустить MMC, затем загрузить оснастку. Для управления правами входа на автономных системах следует выбрать Local Computer Group Policy Object (GPO); для управления правами входа на контроллерах домена (DC), нужно выбрать Default Domain Controllers GPO. В оснастке Group Policy Object можно назначить права регистрации, развернув контейнеры Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment (Экран 2).

С помощью утилиты NTRights можно предоставлять и отменять пользовательские права Windows (как права регистрации, так и привилегии) для пользователей и групп на локальном или удаленном компьютере. Например, чтобы предоставить учетной записи ServiceAccount1 право Logon as a service на компьютере MyComputer, следует выполнить следующую команду:

Отменить право Access this computer from the network для группы Authenticated Users можно с помощью команды

С помощью утилиты ShowPriv можно вывести на экран пользователей и группы, которым назначено конкретное пользовательское право только в локальной системе. Например, чтобы отыскать пользователей и группы, которые имеют право регистрации Log on locally в данной системе, следует выполнить команду

Оптимальные процедуры

Для удобства управления доступом, в Windows реализована концепция групп. Вместо того, чтобы назначать разрешения и права многим отдельным пользователям, гораздо проще организовать пользователей в группы, а затем назначить разрешения и права группам. При этом упрощается также управление правами регистрации.

Еще один эффективный прием — назначать пользовательские права доменным, а не локальным учетным записям. С помощью локальной учетной записи пользователь может обойти централизованную политику безопасности, применяемую на уровне домена Windows. Как отмечалось в статье «Все дело в доверии», следует всегда стараться использовать домены Windows, независимо от размера сети.

Кроме того, полезно при любой возможности назначать служебным учетным записям права Deny logon locally, Deny access to this computer from the network и Deny logon through Terminal Services. Всегда следует руководствоваться принципом минимальных достаточных привилегий. В контексте прав регистрации, это значит, что служебной учетной записи нужно назначать только права регистрации, необходимые для работы.

Может оказаться, что стандартные права регистрации, перечисленные в таблице 1, недостаточно строги. Чтобы блокировать назначенные права регистрации, рекомендуется принять следующие меры:

  • Отменить право Log on locally для групп Users, Power Users и Guest на серверах, членах доменов.
  • Отменить право Access this computer from the network для группы Authenticated Users на отдельных серверах и контроллерах доменов.

Права регистрации и журналы событий

В журнале событий Windows перечислены события аудита регистрации, которые относятся к рассмотренным правам регистрации. Просматривать события аудита полезно при диагностике проблем с аутентификацией Windows. Для генерации событий аудита регистрации, следует активизировать режим Audit account logon events (как успешных, так и неудачных) в политике аудита автономной системы или домена.

Наибольший интерес для администратора представляет поле Logon Type. На Экране 3 показано событие регистрации с ID 540, которое свидетельствует об удачной регистрации. В поле Description можно увидеть поле Logon Type, содержащее значение 3, которое указывает, что успешный вход был произведен с помощью сетевой регистрации. Поле Logon Type содержать значения 2 (интерактивный вход), 3 (сетевой вход) 4 (пакетный вход) или 5 (регистрация службы). Самые часто встречающиеся значения Logon Type — 2 и 3. Logon Type 2 в журналах Event Viewer показывает, что кто-то интерактивно зарегистрировался в системе. Logon Type 3 означает, что кто-то пытался обратиться к ресурсам компьютера по сети. Logon Type 4 показывает, что служба Task Scheduler запускает сценарий или программу в пакетном режиме. Logon Type 5 означает, что была запущена служба Windows от имени конкретной пользовательской учетной записи.

Мощный инструмент управления доступом

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

Экран 1. Использование инструмента Local Security Policy для назначения прав регистрации.

Экран 2. Использование оснастки Group Policy Object для назначения прав регистрации.

Экран 3. Событие аудита для для успешного входа.

Жан де Клерк (jan.declercq@hp.com) — член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Он автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press).

Поделитесь материалом с коллегами и друзьями

Access this computer from the network

Вопрос

After applying this policy not able to take remote.

Below screen shot.

Ответы

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

  • Помечено в качестве ответа latheefAbDuL 1 ноября 2019 г. 15:02

Все ответы

Check more details about this policy,

HI
1 can you enter winver in command prompt on both client computer and session host server then look the os version ?
2 Are all AD standard users can not remote access the session host server ?

3 did you change below things»

When modifying this user right, the following actions might cause users and services to experience network access issues:

  • Removing the Enterprise Domain Controllers security group
  • Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network
  • Removing all user and machine accounts

«

4 what’s user group added in » Access this computer from the network » on your session host server?
by default there are like below picture ?

5 did you add the problematical user account to local remote desktop users group on session host server ?
The System Administrator Has Restricted The Types Of Logon (Network Or Interactive) That You May Use
https://www.kapilarya.com/the-system-administrator-has-restricted-the-types-of-logon-windows-10

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

  • Изменено Andy YOU Microsoft contingent staff 12 сентября 2019 г. 12:51

HI
could you please check if the step 5 and step 6 can help you.
6 This issue occurs when Network Level Authentication (NLA) is required for RDP connections, and the user is not a member of the Remote Desktop Users group. It can also occur if the Remote Desktop Users group has not been assigned to the Access this computer from the network user right.

Modify the user’s group membership or user rights assignment

If this issue affects a single user, the most straightforward solution to this issue is to add the user to the Remote Desktop Users group.

If the user is already a member of this group (or if multiple group members have the same problem), check the user rights configuration on the remote Windows 10 or Windows Server 2016 computer.

  1. Open Group Policy Object Editor (GPE) and connect to the local policy of the remote computer.
  2. Navigate to Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment, right-click Access this computer from the network, and then select Properties.
  3. Check the list of users and groups for Remote Desktop Users (or a parent group).
  4. If the list does not include Remote Desktop Users (or a parent group, such as Everyone) you need to add it to the list (if you have more than one or two computers in your deployment, use a group policy object).
    For example, the default membership for Access this computer from the network includes Everyone. If your deployment uses a group policy object to remove Everyone, you may need to restore access by updating the group policy object to add Remote Desktop Users.

Блокируем сетевой доступ локальным учетным записям

Использование локальных учетных записей (в том числе локального администратора) для доступа по сети в средах Active Directory нежелательно по ряду причин. Зачастую на многих компьютерах используются одинаковые имя и пароль локального администратора, что может поставить под угрозу множество систем при компрометации одного компьютера (угроза атаки Pass-the-hash). Кроме того доступ под локальными учетными записями по сети трудно персонифицировать и централизованно отследить, т.к. подобные факты на контроллерах домена AD не регистрируются.

Чтобы снизить риски, администраторы прибегают к переименованию имени стандартной локальной учетной записи Windows Administrator (Администратор). Существенно повысить безопасность учетных записей локальных администраторов позволяет использование системы, обеспечивающей периодическую смену пароля локального администратора на уникальный на всех компьютерах домен(к примеру, MS Local Administrator Password Solution). Но этим решением не удастся решить проблему ограничения сетевого доступа под локальными учетными записями, т.к. на компьютерах может быть больше одной локальной учетки.

Ограничить сетевой доступ для локальных учетных записей можно с помощью политики Deny access to this computer from the network. Но проблема в том, что в данной политике придется явно перечислить все имена учетных записей, которым нужно запретить доступ.

В Windows 8.1 and Windows Server 2012 R2 появилась две новые группы безопасности с новыми SID. Это значит, что теперь доступна возможность не перечислять все возможные варианты SID локальных учёток, а использовать общий SID.

Данные группы добавляются в токен доступа пользователя при входе в систему под локальной учетной записью.

На сервере с Windows Server 2012 R2 убедимся, что локальной учетной записи administrator присвоены две новые группы NT AUTHORITYLocal account (SID S-1-5-113) и NT AUTHORITYLocal account and member of Administrators group (SID S-1-5-114):

Этот функционал можно добавить и в Windows 7, Windows 8, Windows Server 2008 R2 и Windows Server 2012, установив обновление KB 2871997 ( обновление от июня 2014 г.).

Проверить, имеются ли данные группы в системе можно по их SID следующим образом:

$objSID = New-Object System.Security.Principal.SecurityIdentifier («S-1-5-113»)
$objAccount = $objSID.Translate([System.Security.Principal.NTAccount])
$objAccount.Value
Если скрипт возвращает NT AuthorityLocal account, значит данная локальная группа (с этим SID) имеется.


Чтобы ограничить сетевой доступ под локальным учетным записям, с этими SID-ами в токене, можно воспользоваться следующими политиками, которые находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.

  • Deny access to this computer from the network – Отказ в доступе к компьютеру из сети
  • DenylogonthroughRemoteDesktopServices – Запретить вход в систему через службу с удаленного рабочего стола

Добавляем в данные политики Local account и Local account and member of Administrators group и обновляем политику с помощью gpupdate /force.

После применения политики на данный компьютер запрещен сетевой доступ под локальными учетными записями. Так, при попытке установить RDP сессию под учетной записью .administrator появится сообщение об ошибке.

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

Blocking Remote Network Access for Local Accounts

Using local accounts (including the local administrator account) to access another computer over network in Active Directory environments is not recommended on a number of reasons. The same local administrator login and password are often used on many computers resulting in putting many computers at risk if one computer is compromised (Pass-the-hash threat). Moreover, access to the network with local accounts is hard to personify and centrally monitor, since it is not registered on AD domain controllers.

To reduce risks, administrators rename the standard local account of Windows Administrator. A regular change of the administrator password to the unique on every computer in the domain (for example. using MS Local Administrator Password Solution) significantly increases the security of local administrator accounts. But this solution cannot restrict the network access for all local accounts, since there can be more than one local account on a computer.

You can restrict access for local accounts using Deny access to this computer from the network policy. But this policy requires to explicitly list all accounts, for which the access will be denied.

In Windows 8.1 and Windows Server 2012 R2, two new security groups (Well-known group) with new SIDs appeared. It means that now you don’t need to list all possible SIDs of local accounts, but use the universal SID instead.

These groups are added to the user access token when logging in with the local account.

Make sure that two new groups— NT AUTHORITYLocal account (SID S-1-5-113) and NT AUTHORITYLocal account and member of Administrators group (SID S-1-5-114) – are assigned to the local administrator account:

This feature can also be added to Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012, having installed KB 2871997 (the update as of June, 2014).

You can check if these groups are present in the system as follows:

$objSID = New-Object System.Security.Principal.SecurityIdentifier («S-1-5-113»)
$objAccount = $objSID.Translate([System.Security.Principal.NTAccount])
$objAccount.Value
If the script returns NT AuthorityLocal account, the new local group (with this SID) is present in the system.


To restrict the network access for these local accounts containing these SIDs in the token, you can use the following policies to be found in Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.

  1. Deny access to this computer from the network
  2. Deny log on through Remote Desktop Services

Add Local account and Local account and member of Administrators group to the policy and update policy using gpupdate /force.

After the policy is applied, the network access with local accounts is denied to this computer. When trying to establish an RDP session with .administrator account, the following error appears.

Thus, you can deny network access with local accounts irrespective of their names and increase the security level of the corporate environment.

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