WinSecWiki > Security Settings > Local Policies > Security Options > Domain Member > Require strong (Windows 2000 or later) session key
When a member computer needs to communicate with the domain controller for certain security operations like NTLM authentication and account lookups by SID, the computer establishes a “secure channel” to the domain controller with its computer account password as the basis.
Depending on the versions of computers involved and the value of “Domain Member: Digitally encrypt secure channel data (when possible)” and “Domain Member: Digitally encrypt or sign secure channel data (always)” this computer may negotiate encryption for some or all of the traffic between other computers over the secure channel. Normally the computers negotiate a mutually supported key length which can be less than 128 bits. This setting prevents this computer from negotiating less than 128 bit encryption.
Bottom line
Enabling this setting should be OK unless you still have any back-level NT domain controllers; if you suddenly start having connection problems with non MS computers or Windows mobile devices after enabling this setting you may have a client that is not 128 bit capable for secure channel encryption.
Back to top
Вход компьютера в домен
Во время загрузки ядра и инициализации драйверов компьютер выполняет вход в
домен. Используя свою учетную запись (уникальное имя и собственный пароль),
компьютер открывает защищенный канал (иногда называемый «чистым» каналом)
с контроллером домена. Все это происходит до того, как становятся доступны
средства входа пользователя.
Учетные записи компьютеров используются между клиентскими компьютерами,
рядовыми серверами и контроллерами домена. Внутри каждого домена происходят
одни и те же действия между несколькими контроллерами домена. Компьютеры
используют защищенный канал для обмена информацией, которая необходима
для функций аутентификации и авторизации. Учетные записи компьютеров повышают
уровень безопасности вашей сети, гарантируя, что компьютер, отправляющий
важную информацию, действительно является членом домена.
В качестве дополнительной меры безопасности компьютеры (как и пользователи
в сетевой конфигурации, где требуются средства безопасности) должны периодически
изменяться пароли. По умолчанию в Windows Server 2003 период смены
пароля составляет 30 дней. Когда наступает момент смены пароля, компьютер
генерирует новый пароль и отправляет его ближайшему контроллеру домена через
защищенный канал (доступ к которому осуществляется с помощью старого пароля).
После этого данный компьютер для доступа к защищенному каналу должен
использовать новый пароль.
Соответствующий контроллер домена обновляет свою базу данных и сразу реплицирует
изменение пароля этого компьютера на другие контроллеры данного домена.
Пароли учетных записей компьютеров помечаются как события Announce
Immediately (Объявить сразу), то есть они не должны ждать следующей плановой репликации.
Иногда это вызывает существенное снижение производительности сети. Если
многие (или все) компьютеры домена имеют пароли, срок действия которых истекает
в один день, то работа, которую должны немедленно выполнить контроллеры
домена, может замедлить выполнение других важных задач контроллеров домена
(таких как аутентификация пользователей или выполнение репликаций по расписанию).
Еще хуже ситуация с контроллером, который предоставляет определенные
услуги (например, действуя как сервер DNS).
Примечание. В случае модернизации Windows Server 2003 из Windows NT вы получаете
существенное улучшение по сравнению с Windows NT, где срок действия паролей
по умолчанию составлял 7 дней, а не 30 дней. До Service Pack 4 for NT фирма
Microsoft даже не предоставляла средства и разделы реестра, чтобы вы могли вносить
изменения в пароли компьютеров.
С другой стороны, вы можете посчитать, что значения по умолчанию для передачи
по защищенным каналам являются в вашей ситуации недостаточно жесткими,
и повысить уровень защиты в этой части (хотя это может повлиять на производительность).
Windows Server 2003 позволяет вам изменять настройки политик безопасности
для управления паролями компьютеров. Вы можете изменять настройки для паролей
компьютеров на уровне домена, организационной единицы (OU) или отдельного
компьютера (хотя это не принято, поскольку вы не добьетесь повышения
производительности, конфигурируя компьютеры по отдельности).
Изменение настроек паролей компьютеров для доменов и организационных единиц
Чтобы изменить настройки паролей для учетных записей компьютеров в домене
или организационной единице (OU), выполните следующие шаги.
- На контроллере домена откройте Active Directory Users and Computers и щелкните правой кнопкой на объекте-домене или объекте-OU.
- Выберите в контекстном меню пункт Properties и перейдите во вкладку Group Policy.
- В случае домена выберите Default Domain Policy (Политика домена по умолчанию) и щелкните на кнопке Edit.
- В случае OU щелкните на кнопке New и затем щелкните на кнопке Edit (если вы уже добавили какую-либо групповую политику, выберите ее и щелкните на кнопке Edit).
- Раскройте дерево консоли до уровня Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.
В правой панели выберите политику, которую хотите использовать, чтобы изменить
конфигурацию для учетных записей компьютеров. Для компьютеров, которые
не являются контроллерами домена, используются опции с пометкой Domain
Member (Рядовой член домена); для контроллеров домена используются опции с
пометкой Domain Controller (Контроллер домена), см.
рис.
5.1.
Рис.
5.1.
Имеется несколько политик для изменения того, как происходит работа с паролями и защищенными каналами в учетных записях компьютеров
В случае использования двойственной загрузки какого-либо компьютера вы
должны знать, что система Windows «видит» каждую установку операционной системы
как отдельный компьютер с отдельной учетной записью компьютера. При каждой
установке генерируется ее собственный уникальный пароль.
Вы должны создавать уникальное имя компьютера для каждой версии Windows
на компьютере с двойственной загрузкой. В противном случае комбинация имя/пароль
не сработает, когда компьютер попытается создать защищенный канал для
входа в домен.
Политики для рядовых компьютеров
Имеется несколько групповых политик для изменения настроек учетных записей
рядовых компьютеров и способа их взаимодействия с контроллером домена.
Digitally Encrypt or Sign Secure Channel Data (Always) [Шифровать или подписывать
цифровым способом данные защищенного канала (всегда)]. Эта политика не включена по
умолчанию, но если у вас есть компьютеры в какой-либо OU или имеется отдельный
компьютер, для которого вы хотите активизировать эту политику, дважды щелкните
на этой политике и выберите селективную кнопку Enable. Активизировать
эту политику почти никогда не требуется, поскольку политика Digitally encrypt or
sign secure channel data (when possible) включена по умолчанию (см. ниже). Прежде
чем включить политику, при которой шифрование данных происходит всегда, нужно
учесть следующие факты.
- Данные входа, передаваемые через защищенный канал, шифруются всегда, даже если весь остальной трафик через этот защищенный канал не шифруется.
- Трафик защищенного канала, управляемый этой политикой, это только трафик, инициируемый рядовым компьютером домена.
- Вы можете включить эту политику, только если все контроллеры этого домена работают под управлением Windows NT 4 Service Pack, начиная с версии 6.
- Если вы включите эту политику, то политика Digitally sign secure channel data (when possible), см. ниже, считается включенной (независимо от ее настройки).
Digitally Encrypt or Sign Secure Channel Data (When Possible) [Шифровать или
подписывать цифровым способом данные защищенного канала (когда это возможно)]. Эта
политика, включенная по умолчанию, указывает, что компьютер должен пытаться
осуществлять шифрование для всего трафика, который он инициирует через защищенный
канал. Если контроллер домена поддерживает шифрование всего трафика
защищенного канала (на контроллерах домена под управлением Windows NT 4.0
Service Pack, начиная с версии 6, поддерживается шифрование), то шифруется весь
трафик. Если контроллер домена не поддерживает шифрование всего трафика, то
шифруется только информация входа, передаваемая через защищенный канал.
Я не думаю, что имеется обоснованная причина, чтобы отключать эту политику.
Это не только существенно снизит уровень безопасности вашей сети, но также может
противоречить приложениям, использующим защищенный канал, поскольку
для многих вызовов API в приложениях для Windows Server 2003/Windows 2000 требуется
шифрование или подпись данных, передаваемых через защищенный канал.
Digitally Sign Secure Channel Data (When Possible) [Подписывать цифровым способом
данные защищенного канала (когда это возможно)]. Эта политика, включенная по умолчанию,
указывает, что компьютер пытается осуществлять подписание для всего трафика,
который он инициирует через защищенный канал. Если контроллер домена
поддерживает подписание трафика защищенного канала (это верно для контроллеров
домена под управлением NT4 SP6 или выше), то подписывается весь трафик.
Подписание отличается от шифрования в том, что шифрование предназначено
для защиты данных, передаваемых через защищенный канал, от прочтения посторонними
лицами, а подписание – для защиты от подделки этих данных посторонними лицами.
Disable Machine Account Password Changes (Отключить изменения пароля учетной записи
компьютера). Эта политика отключена по умолчанию. (Меня раздражают политики,
которые начинаются со слова Disable, то есть при их включении происходит
отключение каких-то свойств.) Если включить эту политику, то вы отключаете защиту,
которая обеспечивается за счет изменений паролей, поскольку вы указываете,
что компьютеры не должны изменять свои пароли. Это означает, что хакер, подобравший
способ взлома пароля, получает постоянный доступ к данным
защищенного канала, которые инициируются компьютером.
Некоторые администраторы включают эту политику, если какой-либо компьютер
не получает доступ в домен. В любом случае это компьютер с двойственной загрузкой,
и администратор не осознал, что для каждой установки Windows требуется
уникальное имя компьютера, чтобы создать учетную запись компьютера (см. выше
в этой лекции).
Maximum Machine Account Password Age (Максимальный срок действия пароля учетной
записи компьютера). Дважды щелкните на этой политике, чтобы изменить период,
после которого создается новый пароль. Эта политика помечена «not defined» (не
определена), но на самом деле для нее определен срок в 30 дней. Чтобы изменить
интервал между изменениями пароля, выберите Define the Policy Setting (Определить
значение для политики) и задайте новый интервал в днях.
Вы можете использовать эту политику для снижения нагрузки на контроллеры
домена. В большинстве случаев это не требуется (или не рекомендуется), но если
вы развернули новый домен Windows Server 2003, то возможна ситуация, когда все
компьютеры, выполняющие вход в этот домен, имеют одинаковую дату смены пароля.
Для большинства моих клиентов это означало бы, что сотни компьютеров
одновременно уведомляют контроллер домена о новом пароле, после чего следует
немедленная репликация каждого пароля на другие контроллеры домена. А ведь
для многих из вас количество компьютеров может исчисляться тысячами.
Совет. Чтобы снизить нагрузку на контроллер домена, имеет смысл вносить это
изменение на уровне организационной единицы (OU), задавая различные интервалы
для различных OU.
Require Strong (Windows 2000 or Later) Session Key [Требуется ключ сеанса с сильным
шифрованием (Windows 2000 или выше)]. Эта политика, отключенная по умолчанию,
указывает, что для шифрования данных защищенного канала требуется 128-битный
ключ шифрования. Вы можете включить эту настройку, только если все контроллеры
домена работают под управлением Windows 2000 или Windows Server 2003.
Политика для контроллера домена
В случае контроллеров домена имеется только одна политика для конфигурирования
трафика через защищенный канал: Refuse machine account password changes (Отклонять
изменения паролей учетных записей компьютеров). Эта политика отключена
по умолчанию, если включить ее, то контроллеры домена будут отказываться
принимать изменения паролей учетных записей компьютеров. Я не знаю какой-либо
причины для включения этой политики (и непонятно, зачем эта политика представлена
в редакторе объектов Group Policy, но, возможно, у каких-то администраторов
имеется некоторая странная проблема, требующая включения этой политики).
Задание политик паролей для отдельных компьютеров
Вы можете внести изменения в любую политику отдельного рядового компьютера
Windows Server 2003 с помощью следующих шагов.
- Откройте Local Security Policy (Локальная политика безопасности) из меню Administrative Tools.
- Раскройте дерево консоли до Local Policies\Security Options.
- В правой панели выберите политику рядового члена домена (Domain member), которую хотите изменить для данного компьютера.
Загрузка служб входа
На следующем шаге запуска операционной системы подсистема Win32 запускает
программу Winlogon.exe, которая выводит на экран окно входа и загружает Local
Security Authority (Lsass.exe).
Начинается процесс входа, поэтому в диалоговом окне Log On To Windows (Начало
сеанса работы с Windows) нужно ввести имя и пароль. Если не возникает никаких
ошибок, то система осуществляет ваш вход и вы можете приступить к работе.
На этом заканчивается загрузка Windows Server 2003.
Client, service, and program issues can occur if you change security settings and user rights assignments
View products that this article applies to.
Security settings and user rights assignments can be changed in local policies and group policies to help tighten the security on domain controllers and member computers. However, the downside of increased security is the introduction of incompatibilities with clients, services, and programs.
This article describes incompatibilities that can occur on client computers that are running Windows XP, or an earlier version of Windows, when you change specific security settings and user rights assignments in a Windows Server 2003 domain or an earlier Windows Server domain.
For information about Group Policy for Windows 7, Windows Server 2008 R2, and Windows Server 2008, see the following articles:
Note: The remaining content in this article is specific to Windows XP, Windows Server 2003, and earlier versions of Windows.
Windows XP
To increase the awareness of misconfigured security settings, use the Group Policy Object Editor tool to change security settings. When you use Group Policy Object Editor, user rights assignments are enhanced on the following operating systems:
- Windows XP Professional Service Pack 2 (SP2)
- Windows Server 2003 Service Pack 1 (SP1)
The enhanced feature is a dialog box that contains a link to this article. The dialog box appears when you change a security setting or a user rights assignment to a setting that offers less compatibility and is more restrictive. If you directly change the same security setting or user rights assignment by using the registry or by using security templates, the effect is the same as changing the setting in Group Policy Object Editor. However, the dialog box that contains the link to this article does not appear.
This article contains examples of clients, programs, and operations that are affected by specific security settings or user rights assignments. However, the examples are not authoritative for all Microsoft operating systems, for all third-party operating systems, or for all program versions that are affected. Not all security settings and user rights assignments are included in this article.
We recommend that you validate the compatibility of all security-related configuration changes in a test forest before you introduce them in a production environment. The test forest must mirror the production forest in the following ways:
- Client and server operating system versions, client and server programs, service pack versions, hotfixes, schema changes, security groups, group memberships, permissions on objects in the file system, shared folders, the registry, Active Directory directory service, local and Group Policy settings, and object count type and location
- Administrative tasks that are performed, administrative tools that are used, and operating systems that are used to perform administrative tasks
- Operations that are performed, such as the following:
- Computer and user logon authentication
- Password resets by users, by computers, and by administrators
- Browsing
- Setting permissions for the file system, for shared folders, for the registry, and for Active Directory resources by using ACL Editor in all client operating systems in all account or resource domains from all client operating systems from all account or resource domains
- Printing from administrative and nonadministrative accounts
Windows Server 2003 SP1
Warnings in Gpedit.msc
To help make customers aware that they are editing a user right or security option that could have adversely affect their network, two warning mechanisms were added to gpedit.msc. When administrators edit a user right that can adversely affect the whole enterprise, they will see a new icon that resembles a yield sign. They will also receive a warning message that has a link to Microsoft Knowledge Base article 823659. The text of this message is as follows:
Modifying this setting may affect compatibility with clients, services, and applications. For more information, see <user right or security option being modified> (Q823659)
If you were directed to this Knowledge Base article from a link in Gpedit.msc, make sure that you read and understand the explanation provided and the possible effect of changing this setting. The following lists User Rights that contain the warning text:
- Access this computer from network
- Log on locally
- Bypass traverse checking
- Enable computers and users for trusted delegation
The following lists Security Options that have the warning and a pop-up message:
- Domain Member: Digitally encrypt or sign secure channel data (always)
- Domain Member: Require strong (Windows 2000 or a later version) session key
- Domain Controller: LDAP server signing requirements
- Microsoft network server: Digitally sign communications (always)
- Network Access: Allows Anonymous Sid / Name translation
- Network Access: Do not allow anonymous enumeration of SAM accounts and shares
- Network security: LAN Manager Authentication level
- Audit: Shut down system immediately if unable to log security audits
- Network Access: LDAP client signing requirements
↑ Back to the top
The following sections describe incompatibilities that can occur when you change specific settings in Windows NT 4.0 domains, Windows 2000 domains, and Windows Server 2003 domains.
User rights
The following list describes a user right, identifies configuration settings that may cause issues, describes why you should apply the user right and why you may want to remove the user right, and provides examples of compatibility issues that may occur when the user right is configured.
- Access this computer from network
- Background
The ability to interact with remote Windows-based computers requires the Access this computer from network user right. Examples of such network operations include the following:
- Replication of Active Directory between domain controllers in a common domain or forest
- Authentication requests to domain controllers from users and from computers
- Access to shared folders, printers, and other system services that are located on remote computers on the network
Users, computers, and service accounts gain or lose the Access this computer from network user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a computer account may be explicitly added to a custom security group or a built-in security group by an administrator, or may be implicitly added by the operating system to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers.
By default, user accounts and computer accounts are granted the Access this computer from network user right when computed groups such as Everyone or, preferably, Authenticated Users and, for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO).
- Risky configurations
The following are harmful configuration settings:
- Removing the Enterprise Domain Controllers security group from this user right
- 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 users and computers from this user right
- Reasons to grant this user right
- Granting the Access this computer from network user right to the Enterprise Domain Controllers group satisfies authentication requirements that Active Directory replication must have for replication to occur between domain controllers in the same forest.
- This user right allows users and computers to access shared files, printers, and system services, including Active Directory.
- This user right is required for users to access mail by using early versions of Microsoft Outlook Web Access (OWA).
- Reasons to remove this user right
- Users who can connect their computers to the network can access resources on remote computers that they have permissions for. For example, this user right is required for a user to connect to shared printers and to folders. If this user right is granted to the Everyone group, and if some shared folders have both share and NTFS file system permissions configured so that the same group has read access, anyone can view files in those shared folders. However, this is an unlikely situation for fresh installations of Windows Server 2003 because the default share and the NTFS permissions in Windows Server 2003 do not include the Everyone group. For systems that are upgraded from Microsoft Windows NT 4.0 or Windows 2000, this vulnerability may have a higher level of risk because the default share and the file system permissions for these operating systems are not as restrictive as the default permissions in Windows Server 2003.
- There is no valid reason for removing Enterprise Domain Controllers group from this user right.
- The Everyone group is generally removed in favor of the Authenticated Users group. If the Everyone group is removed, the Authenticated Users group must be granted this user right.
- Windows NT 4.0 domains that are upgraded to Windows 2000 do not explicitly grant the Access this computer from network user right to the Everyone group, the Authenticated Users group, or the Enterprise Domain Controllers group. Therefore, when you remove the Everyone group from Windows NT 4.0 domain policy, Active Directory replication will fail with an «Access Denied» error message after you upgrade to Windows 2000. Winnt32.exe in Windows Server 2003 avoids this misconfiguration by granting the Enterprise Domain Controllers group this user right when you upgrade Windows NT 4.0 primary domain controllers (PDCs). Grant the Enterprise Domain Controllers group this user right if it is not present in the Group Policy Object Editor.
- Examples of compatibility problems
- Windows 2000 and Windows Server 2003: Replication of the following partitions will fail with «Access Denied» errors as reported by monitoring tools such as REPLMON and REPADMIN or replication events in the event log.
- Active Directory Schema partition
- Configuration partition
- Domain partition
- Global catalog partition
- Application partition
- All Microsoft network operating systems: User Account authentication from remote network client computers will fail unless the user or a security group that the user is a member of has been granted this user right.
- All Microsoft network operating systems: Account authentication from remote network clients will fail unless the account or a security group the account is a member of has been granted this user right. This scenario applies to user accounts, to computer accounts, and to service accounts.
- All Microsoft network operating systems: Removing all accounts from this user right will prevent any account from logging on to the domain or from accessing network resources. If computed groups such as Enterprise Domain Controllers, Everyone, or Authenticated Users are removed, you must explicitly grant this user right to accounts or to security groups that the account is a member of to access remote computers over the network. This scenario applies to all user accounts, to all computer accounts, and to all service accounts.
- All Microsoft network operating systems: The local administrator account uses a «blank» password. Network connectivity with blank passwords is not permitted for administrator accounts in a domain environment. With this configuration, you can expect to receive an «Access Denied» error message.
- Windows 2000 and Windows Server 2003: Replication of the following partitions will fail with «Access Denied» errors as reported by monitoring tools such as REPLMON and REPADMIN or replication events in the event log.
- Background
- Allow log on locally
- Background
Users who are trying to log on at the console of a Windows-based computer (by using the CTRL+ALT+DELETE keyboard shortcut) and accounts who are trying to start a service must have local logon privileges on the hosting computer. Examples of local logon operations include administrators who are logging on to the consoles of member computers, or domain controllers throughout the enterprise and domain users who are logging on to member computers to access their desktops by using non-privileged accounts. Users who use a Remote Desktop connection or Terminal Services must have the Allow log on locally user right on destination computers that are running Windows 2000 or Windows XP because these logon modes are considered local to the hosting computer. Users who are logging on to a server that has Terminal Server enabled and who do not have this user right can still start a remote interactive session in Windows Server 2003 domains if they have the Allow logon through Terminal Services user right.
- Risky configurations
The following are harmful configuration settings:
- Removing administrative security groups, including Account Operators, Backup Operators, Print Operators or Server Operators, and the built-in Administrators group from the default domain controller’s policy.
- Removing service accounts that are used by components and by programs on member computers and on domain controllers in the domain from the default domain controller’s policy.
- Removing users or security groups that log on to the console of member computers in the domain.
- Removing service accounts that are defined in the local Security Accounts Manager (SAM) database of member computers or of workgroup computers.
- Removing non-built-in administrative accounts that are authenticating over Terminal Services that is running on a domain controller.
- Adding all user accounts in the domain explicitly or implicitly through the Everyone group to the Deny logon locally logon right. This configuration will prevent users from logging on to any member computer or to any domain controller in the domain.
- Reasons to grant this user right
- Users must have the Allow log on locally user right to access the console or the desktop of a workgroup computer, a member computer, or a domain controller.
- Users must have this user right to log on over a Terminal Services session that is running on a Window 2000-based member computer or domain controller.
- Reasons to remove this user right
- Failure to restrict console access to legitimate user accounts could result in unauthorized users downloading and executing malicious code to change their user rights.
- Removal of the Allow log on locally user right prevents unauthorized logons on the consoles of computers, such as domain controllers or application servers.
- Removal of this logon right prevents non-domain accounts from logging on at the console of member computers in the domain.
- Examples of compatibility problems
- Windows 2000 terminal servers: The Allow log on locally user right is required for users to log on to Windows 2000 terminal servers.
- Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003: User accounts must be granted this user right to log on at the console of computers that are running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003.
- Windows NT 4.0 and later: On computers that are running Windows NT 4.0 and later, if you add the Allow log on locally user right, but you implicitly or explicitly also grant the Deny logon locally logon right, the accounts will not be able to log on to the console of the domain controllers.
- Background
- Bypass traverse checking
- Background
The Bypass traverse checking user right allows the user to browse through folders in the NTFS file system or in the registry without checking for the Traverse Folder special access permission. The Bypass traverse checking user right does not allow the user to list the contents of a folder. It allows the user to traverse only its folders.
- Risky configurations
The following are harmful configuration settings:
- Removing non-administrative accounts that log on to Windows 2000-based Terminal Services computers or Windows Server 2003-based Terminal Services computers that do not have permissions to access files and folders in the file system.
- Removing the Everyone group from the list of security principals who have this user right by default. Windows operating systems, and also many programs, are designed with the expectation that anyone who can legitimately access the computer will have the Bypass traverse checking user right. Therefore, removing the Everyone group from the list of security principals who have this user right by default could lead to operating system instability or to program failure. It is better that you leave this setting at its default.
- Reasons to grant this user right
The default setting for the Bypass traverse checking user right is to allow anyone to bypass traverse checking. For experienced Windows system administrators, this is the expected behavior, and they configure file system access control lists (SACLs) accordingly. The only scenario where the default configuration may lead to a mishap is if the administrator who configures permissions does not understand the behavior and expects that users who cannot access a parent folder will not be able to access the contents of any child folders.
- Reasons to remove this user right
To try to prevent access to the files or the folders in the file system, organizations that are very concerned about security may be tempted to remove the Everyone group, or even the Users group, from the list of groups that have the Bypass traverse checking user right.
- Examples of compatibility problems
- Windows 2000, Windows Server 2003: If the Bypass traverse checking user right is removed or is misconfigured on computers that are running Windows 2000 or Windows Server 2003, Group Policy settings in the SYVOL folder will not replicate between domain controllers in the domain.
- Windows 2000, Windows XP Professional, Windows Server 2003: Computers that are running Windows 2000, Windows XP Professional, or Windows Server 2003 will log events 1000 and 1202 and will not be able to apply computer policy and user policy when the required file system permissions are removed from the SYSVOL tree if the Bypass traverse checking user right is removed or is misconfigured.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
290647 Event ID 1000, 1001 is logged every five minutes in the Application event log
- Windows 2000, Windows Server 2003: On computers that are running Windows 2000 or Windows Server 2003, the Quota tab in Windows Explorer will disappear when you view properties on a volume.
- Windows 2000: Non-administrators who log on to a Windows 2000 terminal server may receive the following error message:
Userinit.exe application error. The application failed to initialize properly 0xc0000142 click OK to terminate the app.
- Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Users whose computers are running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 may not be able to access shared folders or files on shared folders, and they may receive «Access Denied» error messages if they are not granted the Bypass traverse checking user right.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
277644 «Access Denied» error message when users try to access shared folders
- Windows NT 4.0: On Windows NT 4.0-based computers, removal of the Bypass traverse checking user right will cause a file copy to drop file streams. If you remove this user right, when a file is copied from a Windows client or from a Macintosh client to a Windows NT 4.0 domain controller that is running Services for Macintosh, the destination file stream is lost, and the file appears as a text-only file.
- Microsoft Windows 95, Microsoft Windows 98: On a client computer that is running Windows 95 or Windows 98, the net use * /home command will fail with an «Access Denied» error message if the Authenticated Users group is not granted the Bypass traverse checking user right.
- Outlook Web Access: Non-administrators will not be able to log on to Microsoft Outlook Web Access, and they will receive an «Access Denied» error message if they are not granted the Bypass traverse checking user right.
- Background
Security Settings
The following list identifies a security setting, and the nested list provides a description about the security setting, identifies configuration settings that may cause issues, describes why you should apply the security setting, and then describes reasons why you may want to remove the security setting. The nested list then provides a symbolic name for the security setting and the registry path of the security setting. Finally, examples are provided of compatibility issues that may occur when the security setting is configured.
- Audit: Shut down system immediately if unable to log security audits
- Background
- The Audit: Shut down system immediately if unable to log security audits setting determines whether the system shuts down if you cannot log security events. This setting is required for the Trusted Computer Security Evaluation Criteria (TCSEC) program’s C2 evaluation and for the Common Criteria for Information Technology Security Evaluation to prevent auditable events if the audit system can’t log those events. If the auditing system fails, the system is shut down, and a Stop error message appears.
- If the computer cannot record events to the security log, critical evidence or important troubleshooting information may not be available for review after a security incident.
- Risky configuration
The following is a harmful configuration setting: The Audit: Shut down system immediately if unable to log security audits setting is turned on, and the size of the security event log is constrained by the Do not overwrite events (clear log manually) option, the Overwrite Events as needed option, or the Overwrite Events older than number days option in Event Viewer. See the «Examples of Compatibility Problems» section for information about specific risks for computers that are running the original released version of Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2, or Windows 2000 SP3.
- Reasons to enable this setting
If the computer cannot record events to the security log, critical evidence or important troubleshooting information may not be available for review after a security incident.
- Reasons to disable this setting
- Enabling the Audit: Shut down system immediately if unable to log security audits setting stops the system if a security audit cannot be logged for any reason. Typically, an event cannot be logged when the security audit log is full and when its specified retention method is either the Do not overwrite events (clear log manually) option or the Overwrite Events older than number days option.
- The administrative burden of enabling the Audit: Shut down system immediately if unable to log security audits setting can be very high, especially if you also turn on the Do not overwrite events (clear log manually) option for the security log. This setting provides for individual accountability of operator actions. For example, an administrator could reset permissions on all users, computers, and groups in an organizational unit (OU) where auditing was enabled by using the built-in administrator account or other shared account and then deny that they reset such permissions. However, enabling the setting does reduce the robustness of the system because a server may be forced to shut down by overwhelming it with logon events and with other security events that are written to the security log. Additionally, because the shutdown is not graceful, irreparable damage to the operating system, programs, or data may result. While NTFS guarantees that the file system’s integrity is maintained during an ungraceful system shutdown, it cannot guarantee that every data file for every program will still be in a usable form when the system restarts.
- Symbolic Name:
CrashOnAuditFail
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)
- Examples of compatibility problems
- Windows 2000: Because of a bug, computers that are running the original released version of Windows 2000, Windows 2000 SP1, Windows 2000 SP2, or Windows Server SP3 may stop logging events before the size that is specified in the Maximum log size option for the security event log is reached. This bug is fixed in Windows 2000 Service Pack 4 (SP4). Make sure that your Windows 2000 domain controllers have Windows 2000 Service Pack 4 installed before you consider enabling this setting.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
312571 The event log stops logging events before reaching the maximum log size
- Windows 2000, Windows Server 2003: Computers that are running Windows 2000 or Windows Server 2003 may stop responding and then may spontaneously restart if the Audit: Shut down system immediately if unable to log security audits setting is turned on, the security log is full, and an existing event log entry cannot be overwritten. When the computer restarts, the following Stop error message appears:
STOP: C0000244 {Audit Failed}
An attempt to generate a security audit failed.To recover, an administrator must log on, archive the security log (optional), clear the security log, and then reset this option (optional and as-needed).
- Microsoft Network Client for MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Non-administrators who try to log on to a domain will receive the following error message:
Your account is configured to prevent you from using this computer. Please try another computer.
- Windows 2000: On Windows 2000-based computers, non-administrators will not be able to log on to remote access servers, and they will receive an error message that is similar to the following:
Unknown user or bad password
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
285665 Error message: Your account is configured to prevent you from using this computer
- Windows 2000: On Windows 2000 domain controllers, the Intersite Messaging service (Ismserv.exe) will stop and cannot be restarted. DCDIAG will report the error as «failed test services ISMserv,» and event ID 1083 will be registered in the event log.
- Windows 2000: On Windows 2000 domain controllers, Active Directory replication will fail, and an «Access Denied» message will appear if the security event log is full.
- Microsoft Exchange 2000: Servers that are running Exchange 2000 will not be able to mount the information store database, and event 2102 will be registered in the event log.
- Outlook, Outlook Web Access: Non-administrators will not be able to access their mail through Microsoft Outlook or through Microsoft Outlook Web Access, and they will receive a 503 error.
- Windows 2000: Because of a bug, computers that are running the original released version of Windows 2000, Windows 2000 SP1, Windows 2000 SP2, or Windows Server SP3 may stop logging events before the size that is specified in the Maximum log size option for the security event log is reached. This bug is fixed in Windows 2000 Service Pack 4 (SP4). Make sure that your Windows 2000 domain controllers have Windows 2000 Service Pack 4 installed before you consider enabling this setting.
- Background
- Domain controller: LDAP server signing requirements
- Background
The Domain controller: LDAP server signing requirements security setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing. The possible values for this policy setting are as follows:
- None: Data signing is not required to bind with the server. If the client requests data signing, the server supports it.
- Require signing: The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Socket Layer (TLS/SSL) is being used.
- not defined: This setting is not enabled or disabled.
- Risky configurations
The following are harmful configuration settings:
- Enabling Require signing in environments where clients do not support LDAP signing or where client-side LDAP signing is not enabled on the client
- Applying the Windows 2000 or the Windows Server 2003 Hisecdc.inf security template in environments where the clients do not support LDAP signing or where client-side LDAP signing is not enabled
- Applying the Windows 2000 or the Windows Server 2003 Hisecws.inf security template in environments where the clients do not support LDAP signing or where client-side LDAP signing is not enabled
- Reasons to enable this setting
Unsigned network traffic is susceptible to man-in-the-middle attacks where an intruder captures packets between the client and the server, modifies the packets, and then forwards them to the server. When this behavior occurs on an LDAP server, an attacker could cause a server to make decisions that are based on false queries from the LDAP client. You can lower this risk in a corporate network by implementing strong physical security measures to help protect the network infrastructure. Internet Protocol security (IPSec) authentication header mode can help prevent man-in-the-middle attacks. Authentication header mode performs mutual authentication and packet integrity for IP traffic.
- Reasons to disable this setting
- Clients that do not support LDAP signing will not be able to carry out LDAP queries against domain controllers and against global catalogs if NTLM authentication is negotiated and if the correct service packs are not installed on Windows 2000 domain controllers.
- Network traces of LDAP traffic between clients and servers will be encrypted. This makes it difficult to examine LDAP conversations.
- Windows 2000-based servers must have Windows 2000 Service Pack 3 (SP3) or installed when they are administered with programs that support LDAP signing that are run from client computers that run Windows 2000 SP4, Windows XP, or Windows Server 2003. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
325465 Windows 2000 domain controllers require Service Pack 3 or later when using Windows Server 2003 administration tools
- Symbolic Name:
LDAPServerIntegrity
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)
- Examples of compatibility problems
- Simple binds will fail, and you will receive the following error message:
Ldap_simple_bind_s() failed: Strong Authentication Required.
- Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: On clients that are running Windows 2000 SP4, Windows XP, or Windows Server 2003, some Active Directory administration tools will not operate correctly against domain controllers that are running versions of Windows 2000 that are earlier than SP3 when NTLM authentication is negotiated.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
325465 Windows 2000 domain controllers require Service Pack 3 or later when using Windows Server 2003 administration tools
- Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: On clients that are running Windows 2000 SP4, Windows XP, or Windows Server 2003, some Active Directory administration tools that target domain controllers that are running versions of Windows 2000 that are earlier than SP3 will not operate correctly if they are using IP addresses (for example, «dsa.msc /server=x.x.x.x» where
x.x.x.x is an IP address).For more information, click the following article number to view the article in the Microsoft Knowledge Base:
325465 Windows 2000 domain controllers require Service Pack 3 or later when using Windows Server 2003 administration tools
- Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: On clients that are running Windows 2000 SP4, Windows XP, or Windows Server 2003, some Active Directory administration tools that target domain controllers that are running versions of Windows 2000 that are earlier than SP3 will not operate correctly.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
325465 Windows 2000 domain controllers require Service Pack 3 or later when using Windows Server 2003 administration tools
- Simple binds will fail, and you will receive the following error message:
- Background
- Domain member: Require strong (Windows 2000 or later) session key
- Background
- The Domain member: Require strong (Windows 2000 or later) session key setting determines whether a secure channel can be established with a domain controller that cannot encrypt secure channel traffic with a strong, 128-bit session key. Enabling this setting prevents establishing a secure channel with any domain controller that cannot encrypt secure channel data with a strong key. Disabling this setting allows 64-bit session keys.
- Before you can enable this setting on a member workstation or on a server, all domain controllers in the domain that the member belongs to must be able to encrypt secure channel data with a strong, 128-bit key. This means that all such domain controllers must be running Windows 2000 or later.
- Risky configuration
Enabling the Domain member: Require strong (Windows 2000 or later) session key setting is a harmful configuration setting.
- Reasons to enable this setting
- Session keys that are used to establish secure channel communications between member computers and domain controllers are much stronger in Windows 2000 than they are in earlier versions of Microsoft operating systems.
- When it’s possible, it is a good idea to take advantage of these stronger session keys to help protect secure channel communications from eavesdropping and from session hijacking network attacks. Eavesdropping is a form of malicious attack where network data is read or is altered in transit. The data can be modified to hide or to change the sender, or to redirect it.
Important A computer that is running Windows Server 2008 R2 or Windows 7 supports only strong keys when secure channels are used. This restriction prevents a trust between any Windows NT 4.0-based domain and any Windows Server 2008 R2-based domain. Additionally, this restriction blocks the Windows NT 4.0-based domain membership of computers that are running Windows 7 or Windows Server 2008 R2, and vice versa.
- Reasons to disable this setting
The domain contains member computers that are running operating systems other than Windows 2000, Windows XP, or Windows Server 2003.
- Symbolic Name:
StrongKey
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)
- Examples of compatibility problems
Windows NT 4.0: On Windows NT 4.0-based computers, resetting secure channels of trust relationships between Windows NT 4.0 and Windows 2000 domains with NLTEST fails. An «Access Denied» error message appears:
The trust relationship between the primary domain and the trusted domain failed.
Windows 7 and Server 2008 R2: For Windows 7 and later versions and Windows Server 2008 R2 and later versions, this setting is not honored any longer and the strong key is used always. Because of that, trusts with Windows NT 4.0 domains do not work any longer.
- Background
- Domain member: Digitally encrypt or sign secure channel data (always)
- Background
- Enabling Domain member: Digitally encrypt or sign secure channel data (always) prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data. To help protect authentication traffic from man-in-the-middle attacks, replay attacks, and other kinds of network attacks, Windows-based computers create a communication channel that is known as a secure channel through the Net Logon service to authenticate computer accounts. Secure channels are also used when a user in one domain connects to a network resource in a remote domain. This multidomain authentication, or pass-through authentication, allows a Windows-based computer that has joined a domain to have access to the user account database in its domain and in any trusted domains.
- To enable the Domain member: Digitally encrypt or sign secure channel data (always) setting on a member computer, all domain controllers in the domain that the member belongs to must be able to sign or encrypt all secure channel data. This means that all such domain controllers must be running Windows NT 4.0 with Service Pack 6a (SP6a) or later.
- Enabling the Domain member: Digitally encrypt or sign secure channel data (always) setting automatically enables the Domain member: Digitally encrypt or sign secure channel data (when possible) setting.
- Risky configuration
Enabling the Domain member: Digitally encrypt or sign secure channel data (always) setting in domains where not all domain controllers can sign or encrypt secure channel data is a harmful configuration setting.
- Reasons to enable this setting
Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client and then modifies them before forwarding them to the client. When this behavior occurs on an Lightweight Directory Access Protocol (LDAP) server, the intruder could cause a client to make decisions that are based on false records from the LDAP directory. You can lower the risk of such an attack on a corporate network by implementing strong physical security measures to help protect the network infrastructure. Additionally, implementing Internet Protocol security (IPSec) authentication header mode can help prevent man-in-the-middle attacks. This mode performs mutual authentication and packet integrity for IP traffic.
- Reasons to disable this setting
- Computers in local or external domains do support encrypted secure channels.
- Not all domain controllers in the domain have the appropriate service pack revision levels to support encrypted secure channels.
- Symbolic Name:
StrongKey
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)
- Examples of compatibility problems
- Windows NT 4.0: Windows 2000-based member computers will not be able to join Windows NT 4.0 domains and will receive the following error message:
The account is not authorized to log in from this station.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
281648 Error message: The account is not authorized to login from this station
- Windows NT 4.0: Windows NT 4.0 domains will not be able to establish a down-level trust with a Windows 2000 domain and will receive the following error message:
The account is not authorized to log in from this station.
Existing down-level trusts may also not authenticate users from the trusted domain. Some users may have problems logging on to the domain, and they may receive an error message that states that the client cannot find the domain.
- Windows XP: Windows XP clients that are joined to Windows NT 4.0 domains will not be able to authenticate logon attempts and may receive the following error message, or the following events may be registered in the event log:
Windows cannot connect to the domain either because the domain controller is down or is otherwise unavailable or because your computer account was not found
- Microsoft Network: Microsoft Network clients will receive one of the following error messages:
Logon failure: unknown username or bad password.
There is no user session key for the specified logon session.
- Windows NT 4.0: Windows 2000-based member computers will not be able to join Windows NT 4.0 domains and will receive the following error message:
- Background
- Microsoft network client: Digitally sign communications (always)
- Background
Server Message Block (SMB) is the resource-sharing protocol that is supported by many Microsoft operating systems. It is the basis of network basic input/output system (NetBIOS) and of many other protocols. SMB signing authenticates both the user and the server that hosts the data. If either side fails the authentication process, data transmission will not occur.
Enabling SMB signing starts during SMB protocol negotiation. The SMB signing policies determine whether the computer always digitally signs client communications.
The Windows 2000 SMB authentication protocol supports mutual authentication. Mutual authentication closes a «man-in-the-middle» attack. The Windows 2000 SMB authentication protocol also supports message authentication. Message authentication helps prevent active message attacks. To give you this authentication, SMB signing puts a digital signature into each SMB. The client and the server each verify the digital signature.
To use SMB signing, you must enable SMB signing or require SMB signing on both the SMB client and the SMB server. If SMB signing is enabled on a server, clients that are also enabled for SMB signing use the packet signing protocol during all subsequent sessions. If SMB signing is required on a server, a client cannot establish a session unless the client is enabled or required for SMB signing.
Enabling digital signing in high-security networks helps prevent the impersonation of clients and of servers. This kind of impersonation is known as session hijacking. An attacker who has access to the same network as the client or the server uses session hijacking tools to interrupt, end, or steal a session in progress. An attacker could intercept and modify unsigned SMB packets, modify the traffic, and then forward it so that the server might perform unwanted actions. Or, the attacker could pose as the server or as the client after a legitimate authentication and then gain unauthorized access to data.
The SMB protocol that is used for file sharing and for print sharing in computers that are running Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, or Windows Server 2003 supports mutual authentication. Mutual authentication closes session hijacking attacks and supports message authentication. Therefore, it prevents man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature in each SMB. The client and the server then verify the signature.
Notes
- As an alternative countermeasure, you can enable digital signatures with IPSec to help protect all network traffic. There are hardware-based accelerators for IPSec encryption and signing that you can use to minimize the performance impact from the server’s CPU. There are no such accelerators that are available for SMB signing.
For more information, see the Digitally sign server communications chapter on the Microsoft MSDN website.
Configure SMB signing through Group Policy Object Editor because a change to a local registry value has no effect if there is an overriding domain policy.
- In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients. For more information, see item 10: «Network security: Lan Manager authentication level.»
- As an alternative countermeasure, you can enable digital signatures with IPSec to help protect all network traffic. There are hardware-based accelerators for IPSec encryption and signing that you can use to minimize the performance impact from the server’s CPU. There are no such accelerators that are available for SMB signing.
- Risky configuration
The following is a harmful configuration setting: Leaving both the Microsoft network client: Digitally sign communications (always) setting and the Microsoft network client: Digitally sign communications (if server agrees) setting set to «Not Defined» or disabled. These settings allow the redirector to send plain text passwords to non-Microsoft SMB servers that do not support password encryption during authentication.
- Reasons to enable this setting
Enabling Microsoft network client: Digitally sign communications (always) requires clients to sign SMB traffic when contacting servers that do not require SMB signing. This makes clients less vulnerable to session hijacking attacks.
- Reasons to disable this setting
- Enabling Microsoft network client: Digitally sign communications (always) prevents clients from communicating with target servers that do not support SMB signing.
- Configuring computers to ignore all unsigned SMB communications prevents earlier programs and operating systems from connecting.
- Symbolic Name:
RequireSMBSignRdr
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature
- Examples of compatibility problems
- Windows NT 4.0: You will not be able to reset the secure channel of a trust between a Windows Server 2003 domain and a Windows NT 4.0 domain by using NLTEST or NETDOM, and you will receive an «Access Denied» error message.
- Windows XP: Copying files from Windows XP clients to Windows 2000-based servers and to Windows Server 2003-based servers may take more time.
- You will not be able to map a network drive from a client with this setting enabled, and you will receive the following error message:
The account is not authorized to log in from this station.
- Restart requirements
Restart the computer, or restart the Workstation service. To do this, type the following commands at a command prompt. Press Enter after you type each command.
net stop workstation
net start workstation
- Background
- Microsoft network server: Digitally sign communications (always)
- Background
- Server Messenger Block (SMB) is the resource-sharing protocol that is supported by many Microsoft operating systems. It is the basis of network basic input/output system (NetBIOS) and of many other protocols. SMB signing authenticates both the user and the server that hosts the data. If either side fails the authentication process, data transmission will not occur.
Enabling SMB signing starts during SMB protocol negotiation. The SMB signing policies determine whether the computer always digitally signs client communications.
The Windows 2000 SMB authentication protocol supports mutual authentication. Mutual authentication closes a «man-in-the-middle» attack. The Windows 2000 SMB authentication protocol also supports message authentication. Message authentication helps prevent active message attacks. To give you this authentication, SMB signing puts a digital signature into each SMB. The client and the server each verify the digital signature.
To use SMB signing, you must enable SMB signing or require SMB signing on both the SMB client and the SMB server. If SMB signing is enabled on a server, clients that are also enabled for SMB signing use the packet signing protocol during all subsequent sessions. If SMB signing is required on a server, a client cannot establish a session unless the client is enabled or required for SMB signing.
Enabling digital signing in high-security networks helps prevent the impersonation of clients and of servers. This kind of impersonation is known as session hijacking. An attacker who has access to the same network as the client or the server uses session hijacking tools to interrupt, end, or steal a session in progress. An attacker could intercept and modify unsigned Subnet Bandwidth Manager (SBM) packets, modify the traffic, and then forward it so that the server might perform unwanted actions. Or, the attacker could pose as the server or as the client after a legitimate authentication and then gain unauthorized access to data.
The SMB protocol that is used for file sharing and for print sharing in computers that are running Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, or Windows Server 2003 supports mutual authentication. Mutual authentication closes session hijacking attacks and supports message authentication. Therefore, it prevents man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature in each SMB. The client and the server then verify the signature.
- As an alternative countermeasure, you can enable digital signatures with IPSec to help protect all network traffic. There are hardware-based accelerators for IPSec encryption and signing that you can use to minimize the performance impact from the server’s CPU. There are no such accelerators that are available for SMB signing.
- In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients. For more information, see item 10: «Network security: Lan Manager authentication level.»
- Server Messenger Block (SMB) is the resource-sharing protocol that is supported by many Microsoft operating systems. It is the basis of network basic input/output system (NetBIOS) and of many other protocols. SMB signing authenticates both the user and the server that hosts the data. If either side fails the authentication process, data transmission will not occur.
- Risky configuration
The following is a harmful configuration setting: Enabling the Microsoft network server: Digitally sign communications (always) setting on servers and on domain controllers that are accessed by incompatible Windows-based computers and third-party operating system-based client computers in local or external domains.
- Reasons to enable this setting
- All client computers that enable this setting directly through the registry or through the Group Policy setting support SMB signing. In other words, all client computers that have this setting enabled run either Windows 95 with the DS client installed, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional, or Windows Server 2003.
- If Microsoft network server: Digitally sign communications (always) is disabled, SMB signing is completely disabled. Completely disabling all SMB signing leaves computers more vulnerable to session hijacking attacks.
- Reasons to disable this setting
- Enabling this setting may cause slower file copy and network performance on client computers.
- Enabling this setting will prevent clients that cannot negotiate SMB signing from communicating with servers and with domain controllers. This causes operations such as domain joins, user and computer authentication, or network access by programs to fail.
- Symbolic Name:
RequireSMBSignServer
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)
- Examples of compatibility problems
- Windows 95: Windows 95 clients that do not have the Directory Services (DS) Client installed will fail logon authentication and will receive the following error message:
The domain password you supplied is not correct, or access to your logon server has been denied.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
811497 Error message when Windows 95 or Windows NT 4.0 client logs on to Windows Server 2003 domain
- Windows NT 4.0: Client computers that are running versions of Windows NT 4.0 that are earlier than Service Pack 3 (SP3) will fail logon authentication and will receive the following error message:
The system could not log you on. Make sure your username and your domain are correct, then type your password again.
Some non-Microsoft SMB servers support only unencrypted password exchanges during authentication. (These exchanges also known as «plain text» exchanges.) For Windows NT 4.0 SP3 and later versions, the SMB redirector does not send an unencrypted password during authentication to an SMB server unless you add a specific registry entry.
To enable unencrypted passwords for the SMB client on Windows NT 4.0 SP 3 and newer systems, modify the registry as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\ParametersValue Name: EnablePlainTextPassword
Data Type: REG_DWORD
Data: 1
For more information about related topics, click the following article number to view the article in the Microsoft Knowledge Base:
224287 Error message: System error 1240 has occurred. The account is not authorized to login from this station.
- Windows Server 2003: By default, security settings on domain controllers that run Windows Server 2003 are configured to help prevent domain controller communications from being intercepted or tampered with by malicious users. For users to successfully communicate with a domain controller that runs Windows Server 2003, client computers must use both SMB signing and encryption or secure channel traffic signing. By default, clients that run Windows NT 4.0 with Service Pack 2 (SP2) or earlier installed and clients that run Windows 95 do not have SMB packet signing enabled. Therefore, these clients may not be able to authenticate to a Windows Server 2003-based domain controller.
- Windows 2000 and Windows Server 2003 policy settings: Depending on your specific installation needs and configuration, we recommend that you set the following policy settings at the lowest entity of necessary scope in the Microsoft Management Console Group Policy Editor snap-in hierarchy:
- Computer Configuration\Windows Security Settings\Security Options
- Send unencrypted password to connect to third-party SMB servers (this setting is for Windows 2000)
- Microsoft network client: Send unencrypted password to third-party SMB servers (this setting is for Windows Server 2003)
Note In some third-party CIFS servers, such as older Samba versions, you cannot use encrypted passwords.
- The following clients are incompatible with the Microsoft network server: Digitally sign communications (always) setting:
- Apple Computer, Inc., Mac OS X clients
- Microsoft MS-DOS network clients (for example, Microsoft LAN Manager)
- Microsoft Windows for Workgroups clients
- Microsoft Windows 95 clients without the DS Client installed
- Microsoft Windows NT 4.0-based computers without SP3 or later installed
- Novell Netware 6 CIFS clients
- SAMBA SMB clients that do not have support for SMB signing
- Windows 95: Windows 95 clients that do not have the Directory Services (DS) Client installed will fail logon authentication and will receive the following error message:
- Restart requirements
Restart the computer, or restart the Server service. To do this, type the following commands at a command prompt. Press Enter after you type each command.
net stop server
net start server
- Background
- Network access: Allow anonymous SID/Name translation
- Background
The Network access: Allow anonymous SID/Name translation security setting determines whether an anonymous user can request Security Identification Number (SID) attributes for another user.
- Risky configuration
Enabling the Network access: Allow anonymous SID/Name translation setting is a harmful configuration setting.
- Reasons to enable this setting
If the Network access: Allow anonymous SID/Name translation setting is disabled, earlier operating systems or applications may not be able to communicate with Windows Server 2003 domains. For example, the following operating systems, services, or applications may not work:
- Windows NT 4.0-based Remote Access Service servers
- Microsoft SQL Server that are running on Windows NT 3.x-based computers or Windows NT 4.0-based computers
- Remote Access Service that is running on Windows 2000-based computers that are located in Windows NT 3.x domains or Windows NT 4.0 domains
- SQL Server that is running on Windows 2000-based computers that are located in Windows NT 3.x domains or in Windows NT 4.0 domains
- Users in Windows NT 4.0 resource domain who want to grant permissions to access files, shared folders, and registry objects to user accounts from account domains that contain Windows Server 2003 domain controllers
- Reasons to disable this setting
If this setting is enabled, a malicious user could use the well-known Administrators SID to obtain the real name of the built-in Administrator account, even if the account has been renamed. That person could then use the account name to initiate a password-guessing attack.
- Symbolic Name: N/A
- Registry Path: None. The path is specified in UI code.
- Examples of compatibility problems
Windows NT 4.0: Computers in Windows NT 4.0 resource domains will display the «Account Unknown» error message in ACL Editor if resources, including shared folders, shared files, and registry objects, are secured with security principals that reside in account domains that contain Windows Server 2003 domain controllers.
- Background
- Network access: Do not allow anonymous enumeration of SAM accounts
- Background
- The Network access: Do not allow anonymous enumeration of SAM accounts setting determines which additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of workstation and server Security Accounts Manager (SAM) accounts and of network shares. For example, an administrator can use this to grant access to users in a trusted domain that does not maintain a reciprocal trust. Once a session is made, an anonymous user may have the same access that is granted to the Everyone group based on the setting in the Network access: Let Everyone permissions apply to anonymous users setting or the discretionary access control list (DACL) of the object.
Typically, anonymous connections are requested by earlier versions of clients (down-level clients) during SMB session setup. In these cases, a network trace shows that the SMB Process ID (PID) is the client redirector such as 0xFEFF in Windows 2000 or 0xCAFE in Windows NT. RPC may also try to make anonymous connections.
- Important This setting has no impact on domain controllers. On domain controllers, this behavior is controlled by the presence of «NT AUTHORITY\ANONYMOUS LOGON» in «Pre-Windows 2000 compatible Access».
- In Windows 2000, a similar setting called Additional Restrictions for Anonymous Connections manages the RestrictAnonymous registry value. The location of this value is as follows
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
For more information about the RestrictAnonymous registry value, click the following article numbers to view the articles in the Microsoft Knowledge Base:
246261 How to use the RestrictAnonymous registry value in Windows 2000
143474 Restricting information available to anonymous logon users
- The Network access: Do not allow anonymous enumeration of SAM accounts setting determines which additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of workstation and server Security Accounts Manager (SAM) accounts and of network shares. For example, an administrator can use this to grant access to users in a trusted domain that does not maintain a reciprocal trust. Once a session is made, an anonymous user may have the same access that is granted to the Everyone group based on the setting in the Network access: Let Everyone permissions apply to anonymous users setting or the discretionary access control list (DACL) of the object.
- Risky configurations
Enabling the Network access: Do not allow anonymous enumeration of SAM accounts setting is a harmful configuration setting from a compatibility perspective. Disabling it is a harmful configuration setting from a security perspective.
- Reasons to enable this setting
An unauthorized user could anonymously list account names and then use the information to try to guess passwords or to perform social engineering attacks. Social engineering is jargon that means tricking people into revealing their passwords or some form of security information.
- Reasons to disable this setting
If this setting is enabled, it is impossible to establish trusts with Windows NT 4.0 domains. This setting also causes problems with down-level clients (such as Windows NT 3.51 clients and Windows 95 clients) that are trying to use resources on the server.
- Symbolic Name:
RestrictAnonymousSAM
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)
- Examples of compatibility problems
- SMS Network Discovery will not be able to obtain operating system information and will write «Unknown» in the OperatingSystemNameandVersion property.
- Windows 95, Windows 98: Windows 95 clients and Windows 98 clients will not be able to change their passwords.
- Windows NT 4.0: Windows NT 4.0-based member computers will not be able to be authenticated.
- Windows 95, Windows 98: Windows 95-based and Windows 98-based computers will not be able to be authenticated by Microsoft domain controllers.
- Windows 95, Windows 98: Users on Windows 95-based and Windows 98-based computers will not be able to change the passwords for their user accounts.
- Background
- Network access: Do not allow anonymous enumeration of SAM accounts and shares
- Background
- The Network access: Do not allow anonymous enumeration of SAM accounts and shares setting (also known as RestrictAnonymous) determines whether anonymous enumeration of Security Accounts Manager (SAM) accounts and shares is allowed. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts (users, computers, and groups) and of network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM accounts and of shares, enable this setting.
- In Windows 2000, a similar setting called Additional Restrictions for Anonymous Connections manages the RestrictAnonymous registry value. The location of this value is as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
- Risky configuration
Enabling the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting is a harmful configuration setting.
- Reasons to enable this setting
- Enabling the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting prevents enumeration of SAM accounts and shares by users and computers that are using anonymous accounts.
- Reasons to disable this setting
- If this setting is enabled, an unauthorized user could anonymously list account names and then use the information to try to guess passwords or to perform social engineering attacks. Social engineering is jargon that means tricking people into revealing their password or some form of security information.
- If this setting is enabled, it will be impossible to establish trusts with Windows NT 4.0 domains. This setting will also cause problems with down-level clients such as Windows NT 3.51 and Windows 95 clients that are trying to use resources on the server.
- It will be impossible to grant access to users of resource domains because administrators in the trusting domain will not be able to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously will not be able to list the shared network resources on those servers. The users must authenticate before they can view the lists of shared folders and printers.
- Symbolic Name:
RestrictAnonymous
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous
- Examples of compatibility problems
- Windows NT 4.0: Users will not be able to change their passwords from Windows NT 4.0 workstations when RestrictAnonymous is enabled on domain controllers in the users’ domain.
- Windows NT 4.0: Adding users or global groups from trusted Windows 2000 domains to Windows NT 4.0 local groups in User Manager will fail, and the following error message will appear:
There are currently no logon servers available to service the logon request.
- Windows NT 4.0: Windows NT 4.0-based computers will not be able to join domains during setup or by using the domain join user interface.
- Windows NT 4.0: Establishing a down-level trust with Windows NT 4.0 resource domains will fail. The following error message will appear when RestrictAnonymous is enabled on the trusted domain:
Could not find domain controller for this domain.
- Windows NT 4.0: Users who log on to Windows NT 4.0-based Terminal Server computers will map to the default home directory instead of the home directory that is defined in User Manager for domains.
- Windows NT 4.0: Windows NT 4.0 backup domain controllers (BDCs) will not be able to start the Net Logon service, obtain a list of backup browsers, or synchronize the SAM database from Windows 2000 or from Windows Server 2003 domain controllers in the same domain.
- Windows 2000: Windows 2000-based member computers in Windows NT 4.0 domains will not be able to view printers in external domains if the No access without explicitly anonymous permissions setting is enabled in the local security policy of the client computer.
- Windows 2000: Windows 2000 domain users will not be able to add network printers from Active Directory; however, they will be able to add printers after they select them from the tree view.
- Windows 2000: On Windows 2000-based computers, ACL Editor will not be able to add users or global groups from trusted Windows NT 4.0 domains.
- ADMT version 2: Password migration for user accounts that are migrated between forests with Active Directory Migration Tool (ADMT) version 2 will fail.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
322981 How to troubleshoot inter-forest password migration with ADMTv2
- Outlook clients: The global address list will appear empty to Microsoft Exchange Outlook clients.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
321169 Slow SMB performance when you copy files from Windows XP to a Windows 2000 domain controller
- SMS: Microsoft Systems Management Server (SMS) Network Discovery will not be able to obtain the operating system information. Therefore, it will write «Unknown» in the OperatingSystemNameandVersion property of the SMS DDR property of the discovery data record (DDR).
- SMS: When you use the SMS Administrator User Wizard to browse for users and groups, no users or groups will be listed. Additionally, Advanced clients cannot communicate with the Management Point. Anonymous access is required on the Management Point.
- SMS: When you are using the Network Discovery feature in SMS 2.0 and in Remote Client Installation with the Topology, client, and client operating systems network discovery option turned on, computers may be discovered but may not be installed.
- Background
- Network security: Lan Manager authentication level
- Background
LAN Manager (LM) authentication is the protocol that is used to authenticate Windows clients for network operations, including domain joins, accessing network resources, and user or computer authentication. The LM authentication level determines which challenge/response authentication protocol is negotiated between the client and the server computers. Specifically, the LM authentication level determines which authentication protocols that the client will try to negotiate or that the server will accept. The value that is set for LmCompatibilityLevel determines which challenge/response authentication protocol is used for network logons. This value affects the level of authentication protocol that clients use, the level of session security negotiated, and the level of authentication accepted by servers.
Possible settings include the following.
Value Setting Description 0 Send LM & NTLM responses Clients use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication. 1 Send LM & NTLM — use NTLMv2 session security if negotiated Clients use LM and NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. 2 Send NTLM response only Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. 3 Send NTLMv2 response only Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. 4 Send NTLMv2 response only/refuse LM Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and accept only NTLM and NTLMv2 authentication. 5 Send NTLMv2 response only/refuse LM & NTLM Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and NTLM and accept only NTLMv2 authentication. Note In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients.
Check the LM authentication level: You must change the policy on the server to permit NTLM, or you must configure the client computer to support NTLMv2.
If the policy is set to (5) Send NTLMv2 response only\refuse LM & NTLM on the target computer that you want to connect to, you must either lower the setting on that computer or set the security to the same setting that is on the source computer that you are connecting from.
Find the correct location where you can change the LAN manager authentication level to set the client and the server to the same level. After you find the policy that is setting the LAN manager authentication level, if you want to connect to and from computers that are running earlier versions of Windows, lower the value to at least (1) Send LM & NTLM — use NTLM version 2 session security if negotiated. One effect of incompatible settings is that if the server requires NTLMv2 (value 5), but the client is configured to use LM and NTLMv1 only (value 0), the user who tries authentication experiences a logon failure that has a bad password and that increments the bad password count. If account lock-out is configured, the user may eventually be locked out.
For example, you may have to look on the domain controller, or you may have to examine the domain controller’s policies.
Look on the domain controller
Note You may have to repeat the following procedure on all the domain controllers.
- Click Start, point to Programs, and then click Administrative Tools.
- Under Local Security Settings, expand Local Policies.
- Click Security Options.
- Double-click Network Security: LAN manager authentication level, and then click a value in the list.
If the Effective Setting and the Local Setting are the same, the policy has been changed at this level. If the settings are different, you must check the domain controller’s policy to determine whether the Network Security: LAN manager authentication level setting is defined there. If it is not defined there, examine the domain controller’s policies.
Examine the domain controller’s policies
- Click Start, point to Programs, and then click Administrative Tools.
- In the Domain Controller Security policy, expand Security Settings, and then expand Local Policies.
- Click Security Options.
- Double-click Network Security: LAN manager authentication level, and then click a value in the list.
Note- You may also have to check policies that are linked at the site level, the domain level, or the organizational unit (OU) level to determine where you must configure the LAN manager authentication level.
- If you implement a Group Policy setting as the default domain policy, the policy is applied to all computers in the domain.
- If you implement a Group Policy setting as the default domain controller’s policy, the policy applies only to the servers in the domain controller’s OU.
- It is a good idea to set the LAN manager authentication level in the lowest entity of necessary scope in the policy application hierarchy.
Windows Server 2003 has a new default setting to use NTLMv2 only. By default, Windows Server 2003 and Windows 2000 Server SP3-based domain controllers have enabled the «Microsoft network server: Digitally sign communications (always)» policy. This setting requires the SMB server to perform SMB packet signing. Changes to Windows Server 2003 were made because domain controllers, file servers, network infrastructure servers, and Web servers in any organization require different settings to maximize their security.
If you want to implement NTLMv2 authentication in your network, you must make sure that all the computers in the domain are set to use this authentication level. If you apply Active Directory Client Extensions for Windows 95 or Windows 98 and Windows NT 4.0, the client extensions use the improved authentication features that are available in NTLMv2. Because client computers that are running any of the following operating system are not affected by Windows 2000 Group Policy Objects, you may have to manually configure these clients:
- Microsoft Windows NT 4.0
- Microsoft Windows Millennium Edition
- Microsoft Windows 98
- Microsoft Windows 95
Note If you enable the Network security: Do not store LAN manager hash value on next password change policy or set the NoLMHash registry key, Windows 95-based and Windows 98-based clients that do not have the Directory Services Client installed cannot log on to the domain after a password change.
Many third-party CIFS servers, such as Novell Netware 6, are not aware of NTLMv2 and use NTLM only. Therefore, levels greater than 2 do not permit connectivity. There also are third-party SMB clients that do not use extended session security. In these cases, the LmCompatiblityLevel of the resource server is not taken into consideration. The server then packs up this legacy request and sends it to the User Domain Controller. The settings on the Domain Controller then decide what hashes are used to verify the request and whether these are meeting the Domain Controller’s security requirements.
For more information about how to manually configure the LAN manager authentication level, click the following article numbers to view the articles in the Microsoft Knowledge Base:
147706 How to disable LM authentication on Windows NT
299656 How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases
312630 Outlook continues to prompt you for logon credentials
2701704 Audit event shows authentication package as NTLMv1 instead of NTLMv2
For more information about LM authentication levels, click the following article number to view the article in the Microsoft Knowledge Base:
239869 How to enable NTLM 2 authentication
- Risky configurations
The following are harmful configuration settings:
- Nonrestrictive settings that send passwords in cleartext and that deny NTLMv2 negotiation
- Restrictive settings that prevent incompatible clients or domain controllers from negotiating a common authentication protocol
- Requiring NTLMv2 authentication on member computers and domain controllers that are running versions of Windows NT 4.0 that are earlier than Service Pack 4 (SP4)
- Requiring NTLMv2 authentication on Windows 95 clients or on Windows 98 clients that do not have the Windows Directory Services Client installed.
- If you click to select the Require NTLMv2 session security check box in the Microsoft Management Console Group Policy Editor snap-in on a Windows Server 2003 or Windows 2000 Service Pack 3-based computer, and you lower the LAN manager authentication level to 0, the two settings conflict, and you may receive the following error message in the Secpol.msc file or the GPEdit.msc file:
Windows cannot open the local policy database. An unknown error occurred when attempting to open the database.
For more information about the Security Configuration and Analysis Tool, see the Windows 2000 or the Windows Server 2003 Help files.
- Reasons to Modify This Setting
- You want to increase the lowest common authentication protocol that is supported by clients and domain controllers in your organization.
- Where secure authentication is a business requirement, you want to disallow negotiation of the LM and the NTLM protocols.
- Reasons to disable this setting
Client or server authentication requirements, or both, have been increased to the point where authentication over a common protocol cannot occur.
- Symbolic Name:
LmCompatibilityLevel
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
- Examples of compatibility problems
- Windows Server 2003: By default, the Windows Server 2003 NTLMv2 Send NTLM responses setting is enabled. Therefore, Windows Server 2003 receives the «Access Denied» error message after the initial installation when you try to connect to a Windows NT 4.0-based cluster or to LanManager V2.1-based servers, such as OS/2 Lanserver. This issue also occurs if you try to connect from an earlier-version client to a Windows Server 2003-based server.
- You install Windows 2000 Security Rollup Package 1 (SRP1).SRP1 forces NTLM version 2 (NTLMv2). This rollup package was released after the release of Windows 2000 Service Pack 2 (SP2). For more information about SRP1, click the following article number to view the article in the Microsoft Knowledge Base:
311401 Windows 2000 Security Rollup Package 1, January 2002
- Windows 7 and Windows Server 2008 R2: Many third-party CIFS servers, such as Novell Netware 6 or Linux-based Samba servers, are not aware of NTLMv2 and use NTLM only. Therefore, levels greater than «2» do not permit connectivity. Now in this version of the operating system, the default for LmCompatibilityLevel was changed to «3». So when you upgrade Windows, these third party filers may stop working.
- Microsoft Outlook clients may be prompted for credentials even though they are already logged on to the domain. When users supply their credentials, they receive the following error message: Windows 7 and Windows Server 2008 R2
The logon credentials supplied were incorrect. Make sure your username and domain are correct, then type your password again.
When you start Outlook, you may be prompted for your credentials even if your Logon Network Security setting is set to Passthrough or to Password Authentication. After you type your correct credentials, you may receive the following error message:
The login credentials supplied were incorrect.
A Network Monitor trace may show that the global catalog issued a remote procedure call (RPC) fault with a status of 0x5. A status of 0x5 means «Access Denied.»
- Windows 2000: A Network Monitor capture may show the following errors in the NetBIOS over TCP/IP (NetBT) server message block (SMB) session:
SMB R Search Directory Dos error, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Invalid user identifier
- Windows 2000: If a Windows 2000 domain with NTLMv2 Level 2 or later is trusted by a Windows NT 4.0 domain, Windows 2000-based member computers in the resource domain may experience authentication errors.
- Windows 2000 and Windows XP: By default, Windows 2000 and Windows XP set the LAN Manager Authentication Level Local Security Policy option to 0. A setting of 0 means «Send LM and NTLM responses.»
Note Windows NT 4.0-based clusters must use LM for administration.
- Windows 2000: Windows 2000 clustering does not authenticate a joining node if both nodes are part of a Windows NT 4.0 Service Pack 6a (SP6a) domain.
- The IIS Lockdown Tool (HiSecWeb) sets the LMCompatibilityLevel value to 5 and the RestrictAnonymous value to 2.
- Services for Macintosh
User Authentication Module (UAM): The Microsoft UAM (User Authentication Module) provides a method for encrypting the passwords that you use to log on to Windows AFP (AppleTalk Filing Protocol) servers. The Apple User Authentication Module (UAM) provides only minimal or no encryption. Therefore, your password could easily be intercepted on the LAN or on the Internet. Although the UAM is not required, it does provide encrypted authentication to Windows 2000 Servers that run Services For Macintosh. This version includes support for NTLMv2 128-bit encrypted authentication and a MacOS X 10.1-compatible release.
By default, the Windows Server 2003 Services for Macintosh server permits only Microsoft Authentication.
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
834498 Macintosh client cannot connect to Services for Mac on Windows Server 2003
- Windows Server 2008, Windows Server 2003, Windows XP, and Windows 2000: If you configure the LMCompatibilityLevel value to be 0 or 1 and then configure the NoLMHash value to be 1, applications and components may be denied access through NTLM. This issue occurs because the computer is configured to enable LM but not to use LM-stored passwords.
If you configure the NoLMHash value to be 1, you must configure the LMCompatibilityLevel value to be 2 or higher.
- Background
- Network security: LDAP client signing requirements
- Background
The Network security: LDAP client signing requirements setting determines the level of data signing that is requested on behalf of clients that issue Lightweight Directory Access Protocol (LDAP) BIND requests as follows:
- None: The LDAP BIND request is issued with the caller-specified options.
- Negotiate signing: If the Secure Sockets Layer/Transport Layer Security (SSL/TLS) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If SSL/TLS has been started, the LDAP BIND request is initiated with the caller-specified options.
- Require signing: This is the same as Negotiate signing. However, if the LDAP server’s intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.
- Risky configuration
Enabling the Network security: LDAP client signing requirements setting is a harmful configuration setting. If you set the server to require LDAP signatures, you must also configure LDAP signing on the client. Not configuring the client to use LDAP signatures will prevent communication with the server. This causes user authentication, Group Policy settings, logon scripts, and other features to fail.
- Reasons to Modify This Setting
Unsigned network traffic is susceptible to man-in-the-middle attacks where an intruder captures packets between the client and the servers, modifies them, and then forwards them to the server. When this occurs on an LDAP server, an attacker could cause a server to respond based on false queries from the LDAP client. You can lower this risk in a corporate network by implementing strong physical security measures to help protect the network infrastructure. Additionally, you can help prevent all kinds of man-in-the-middle attacks by requiring digital signatures on all network packets by means of IPSec authentication headers.
- Symbolic Name:
LDAPClientIntegrity
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
- Background
- Event Log: Maximum security log size
- Background
The Event Log: Maximum security log size security setting specifies the maximum size of the security event log. This log has a maximum size of 4 GB. To locate this setting, expand
Windows Settings, and then expand Security Settings. - Risky configurations
The following are harmful configuration settings:
- Restricting the security log size and the security log retention method when the Audit: Shut down system immediately if unable to log security audits setting is enabled. See the «Audit: Shut down system immediately if unable to log security audits» section of this article for more details.
- Restricting the security log size so that security events of interest are overwritten.
- Reasons to Increase This Setting
Business and security requirements may dictate that you increase the security log size to handle additional security log detail or to retain security logs for a longer period of time.
- Reasons to Decrease This Setting
Event Viewer logs are memory mapped files. The maximum size of an event log is constrained by the amount of physical memory in the local computer and by the virtual memory that is available to the event log process. Increasing the log size beyond the amount of virtual memory that is available to Event Viewer does not increase the number of log entries that are maintained.
- Examples of compatibility problems
Windows 2000: Computers that are running versions of Windows 2000 that are earlier than Service Pack 4 (SP4) may stop logging events in the event log before reaching the size that is specified in the Maximum log size setting in Event Viewer if the Do not overwrite events (clear log manually) option is turned on.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
312571 The event log stops logging events before reaching the maximum log size
- Background
- Event Log: Retain security log
- Background
The Event Log: Retain security log security setting determines the «wrapping» method for the security log. To locate this setting, expand Windows Settings, and then expand Security Settings.
- Risky configurations
The following are harmful configuration settings:
- Failing to retain all logged security events before they are overwritten
- Configuring the Maximum security log size setting too small so that security events are overwritten
- Restricting the security log size and retention method while the Audit: Shut down system immediately if unable to log security audits security setting is enabled
- Reasons to enable this setting
Enable this setting only if you select the Overwrite events by days retention method. If you use an event correlation system that polls for events, make sure that the number of days is at least three times the poll frequency. Do this to allow for failed poll cycles.
- Background
- Network access: Let Everyone permissions apply to anonymous users
- Background
By default, the Network access: Let Everyone permissions apply to anonymous users setting is set to Not Defined on Windows Server 2003. By default, Windows Server 2003 does not include the Anonymous Access token in the Everyone group.
- Example of Compatibility Problems
The following value of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
[REG_DWORD]=0x0 breaks trust creation between Windows Server 2003 and Windows NT 4.0, when the Windows Server 2003 domain is the account domain and the Windows NT 4.0 domain is the resource domain. This means that the account domain is Trusted on Windows NT 4.0 and the resource domain is Trusting on the Windows Server 2003 side. This behavior occurs because the process to start the trust after the initial anonymous connection is ACL’d with the Everyone token that includes the Anonymous SID on Windows NT 4.0.
- Reasons to Modify This Setting
The value must be set to 0x1 or set by using a GPO on the domain controller’s OU to be: Network access: Let Everyone permissions apply to anonymous users — Enabled to make the trust creations possible.
Note Most other security settings go up in value instead of down to 0x0 in their most secured state. A more secure practice would be to change the registry on the primary domain controller emulator instead of on all the domain controllers. If the primary domain controller emulator role is moved for any reason, the registry must be updated on the new server.
A restart is required after this value is set.
- Registry Path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
- Background
- NTLMv2 authentication
- Session security
Session security determines the minimum security standards for client and server sessions. It is a good idea to verify the following security policy settings in the Microsoft Management Console Group Policy Editor snap-in:
- Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options
- Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers
- Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients
The options for these settings are as follows:
- Require message integrity
- Require message confidentiality
- Require NTLM version 2 session security
- Require 128-bit encryption
The default setting prior to Windows 7 is No requirements. Starting with Windows 7, the default changed to Require 128-bit encryption for improved security. With this default, legacy devices that don’t support 128-bit encryption will be unable to connect.
These policies determine the minimum security standards for an application-to-application communications session on a server for a client.
Note that although described as valid settings, the flags to require message integrity and confidentiality are not used when the NTLM session security is determined.
Historically, Windows NT has supported the following two variants of challenge/response authentication for network logons:
- LM challenge/response
- NTLM version 1 challenge/response
LM allows interoperability with the installed base of clients and servers. NTLM provides improved security for connections between clients and servers.
The corresponding registry keys are as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\»NtlmMinServerSec»
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\»NtlmMinClientSec» - Risky configurations
This setting controls how network sessions secured using NTLM will be handled. This affects RPC-based sessions authenticated with NTLM, for example. There are the following risks:
- Using older authentication methods than NTLMv2 makes the communication easier to attack due to the simpler hashing methods used.
- Using encryption keys lower than 128-bit allows attackers to break communication using brute-force attacks.
- Session security
Time synchronization
Time synchronization failed. The time is off by more than 30 minutes on an affected computer. Make sure that the client computer’s clock is synchronized with the domain controller’s clock.
Workaround for SMB signing
We recommend that you install Service Pack 6a (SP6a) on Windows NT 4.0 clients that interoperate in a Windows Server 2003-based domain. Windows 98 Second Edition-based clients, Windows 98-based clients, and Windows 95-based clients must run the Directory Services Client to perform NTLMv2. If Windows NT 4.0-based clients do not have Windows NT 4.0 SP6 installed or if Windows 95-based clients, Windows 98-based clients, and Windows 98SE-based clients do not have the Directory Services Client installed, disable SMB signing in the default domain controller’s policy setting on the domain controller’s OU, and then link this policy to all OUs that host domain controllers.
The Directory Services Client for Windows 98 Second Edition, Windows 98, and Windows 95 will perform SMB Signing with Windows 2003 servers under NTLM authentication, but not under NTLMv2 authentication. Additionally, Windows 2000 servers will not respond to SMB Signing requests from these clients.
Although we do not recommend it, you can prevent SMB signing from being required on all domain controllers that run Windows Server 2003 in a domain. To configure this security setting, follow these steps:
- Open the default domain controller’s policy.
- Open the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options folder.
- Locate and then click the Microsoft network server: Digitally sign communications (always) policy setting, and then click Disabled.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows
Alternatively, turn off SMB signing on the server by modifying the registry. To do this, follow these steps:
- Click Start, click Run, type regedit, and then click OK.
- Locate and then click the following subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters - Click the enablesecuritysignature entry.
- On the Edit menu, click Modify.
- In the Value data box, type 0, and then click OK.
- Exit Registry Editor.
- Restart the computer, or stop and then restart the Server service. To do this, type the following commands at a command prompt, and then press Enter after you type each command:
net stop server
net start server
Note The corresponding key on the client computer is in the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters
The following lists the translated error code numbers to status codes and to the verbatim error messages that are mentioned earlier:
error 5
ERROR_ACCESS_DENIED
Access is denied.
error 1326
ERROR_LOGON_FAILURE
Logon failure: unknown user name or bad password.
error 1788
ERROR_TRUSTED_DOMAIN_FAILURE
The trust relationship between the primary domain and the trusted domain failed.
error 1789
ERROR_TRUSTED_RELATIONSHIP_FAILURE
The trust relationship between this workstation and the primary domain failed.
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
324802 How to configure Group Policies to set security for system services in Windows Server 2003
161372 How to enable SMB signing in Windows NT
816585 How to apply predefined security templates in Windows Server 2003
820281 You must provide Windows account credentials when you connect to Exchange Server 2003 by using the Outlook 2003 RPC over HTTP feature
↑ Back to the top
Keywords: w2000acl, w2000ipsec, w2000grppol, kbinfo, kbsmbportal, kb
↑ Back to the top
- Thread Status:
-
Not open for further replies.
-
bolts
Registered Member- Joined:
- Apr 3, 2013
- Posts:
- 7
- Location:
-
USA
@EncryptedBytes…if you’re reading this and have a good «short list» for hardening XP (not to NSA requirements, but enough to stop malware from spreading, and bots from using it), that would be appreciated. I saw your posts in the «Security Hardening Windows 7 64 bit install» thread, but I couldn’t post to that one because of the age, and PM isn’t working for me now/yet.
I’m the lone IT guy at a medium sized business, and I’d like to tighten up security a bit.
I’m not familiar with hardening systems, but I’m trying to learn. I’ve also become very interested in network monitoring, after years of our network getting slower and slower…I’m convinced we’re compromised/infected to the eyeballs, but I don’t have the skills to prove it to the owners, so they won’t spend the money to have somebody come in for remediation. I installed Security Onion, but since I don’t know what I’m looking at…it all looks like threats. I took Richard Bejtlich’s «TCP/IP Weapons School» class only coming away from that realizing that I knew even less than I thought I did. I’m trying to get some books read on «Windows Desktop and Server Hardening», «Hacking Exposed» and «Practical Packet Analysis», but that will take some time to sink in.We’re forced to stay with XP for now, because the ERP we currently run won’t do Windows 7, but we did just upgrade all of our servers to MS Server 2012 AND virtuallized them all. However, our ERP server is a direct P2V of MS Server 2003 running MS SQL Server 2000. Nothing is hardened, and all we have is a Cisco firewall and a Barracuda SPAM filter.
I’ve downloaded every free tool that Mandiant and HBGary has to offer, but again…I don’t have the skills to decipher what «Redline» or anything else displays on the screen for me.
I’d like to start chipping away at this problem, but I’m not sure of where to start. If we’re really infected with malware that is using our network, will hardening workstations one at a time help, or do I need to get a hardened image ready for all workstations and roll it out all at once? And the servers, I guess they will all need to be remediated and hardened at the same time? I’ve been looking at different imaging deployment software (FOG Server, Microsoft’s WDS, etc), any preferences?
Are there any Network Security related groups in the MD/PA/WV (more towards Western MD)? I see ISSA.org has a Baltimore and Blue Ridge chapter, but are there any other organizations? Are there any former «NSA» types or similar individuals in my area that would offer some sort of private training/mentoring for network monitoring, or is SANS the best way to go?
-
Hello Bolts, I appear to have missed this post. Let me address where I can to offer advice. I have a comprehensive list of controls to implement on Windows XP which I can send you however it is ~130 pages (Not really lite =/). Let me know. I would advise any experimentation is performed on development equipment. Hardening is to lower attack surface; though it can at times interfere with resources which key software for business needs to run. My advice, clone the environment you wish to harden and experiment on that equipment. This way you can identify what needs to be available in the environment as not to cause downtime and service disruption. If you have a dev environment already established great!
*Hardening should happen at all levels, from the network switches, routers, to the IDS solutions, to the systems and applications ideally.
Network Security is an art in and of itself. Unfortunately I can only offer high level advice here due to limited knowledge of the topography of your network (Don’t post it here!). Most tools out there provide logs and alerts which would need to be tailored to each sites unique need. In terms of network monitoring as a start, I would attempt to establish a baseline of what constitutes normal traffic during operational hours and create and modify rulesets to catch any deviations in that baseline. Are you just monitoring inbound/outbound, or are you also attempting to monitor employee web as well? The largest threat to the network, other than misconfiguration are your employees.Hardening would be a good start, also establishing a patch process to make sure your organization is keeping up with vendor and system patches in a reasonable time frame. I would create a clean image if possible and work off that and deploy. Now refer to my first paragraph and make sure to test, test again, and then test some more before rolling out. ISSA is good, Infraguard also has local chapters in the area. I would look at sites similar to here https://www.novainfosec.com/events/nova-meetups/ to help keep track of cons and meetups (Shmoocon was a good event that occurred back in February around DC).
Last edited: Apr 28, 2013
-
Bolts, I decided to brew a pot of coffee and trim the guide down. Though you may need a pot of coffee when going through this.
The following is from the public unclassified Mar 2013 Windows XP Security Guide. The requirements in scope were developed from United States Federal and DoD consensus, as well as the Windows XP Security Guide and security templates published by Microsoft Corporation.
As with my other thread, my little disclaimer «I will be throwing a lot at you, you do not have to enable all these recommendations, and you can also opt to enable none as they are to give you general guidance and disabling some options could hinder your day to day use. «
Control Title: Systems must be at supported service packs (SP) or releases levels.
Systems at unsupported service packs or releases will not receive security updates for new vulnerabilities and leaves them subject to exploitation. Systems must be maintained at a service pack level supported by the vendor with new security updates.
Solution: Update the system to a supported service pack.
Application of new service packs should be thoroughly tested before deploying in a production environment.
Control Title: ACLs for system files and directories do not conform to minimum requirements.
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications.
Solution: Maintain the default file ACLs, configure the Security Option: “Network access: Let everyone permissions apply to anonymous users” to “Disabled” and restrict the Power Users group to include no members. Configure permissions on the following so that only Administrators and System have Full (no other permissions assigned to other accounts or groups).
\regedit.exe
\System32\arp.exe
\System32\at.exe
\System32\attrib.exe
\System32\cacls.exe
\System32\debug.exe
\System32\edlin.exe
\System32\eventcreate.exe
\System32\eventtriggers.exe
\System32\ftp.exe
\System32\nbtstat.exe
\System32\net.exe
\System32\net1.exe
\System32\netsh.exe
\System32\netstat.exe
\System32\nslookup.exe
\System32\ntbackup.exe
\System32\rcp.exe
\System32\reg.exe
\System32\regedt32.exe
\System32\regini.exe
\System32\regsvr32.exe
\System32\rexec.exe
\System32\route.exe
\System32\rsh.exe
\System32\sc.exe
\System32\secedit.exe
\System32\subst.exe
\System32\Systeminfo.exe
\System32\telnet.exe
\System32\tftp.exe
\System32\tlntsvr.exe\System32\mshta.exe will have Users – Read and Execute in addition to the permissions above.
Control Title: File-auditing configuration does not meet minimum requirements.
Improper modification of the core system files can render a system inoperable. Further, modifications to these system files can have a significant impact on the security configuration of the system. Auditing of significant modifications made to the system files provides a method of determining the responsible party.
Solution: Configure auditing on each partition/drive to audit all «Failures» for the «Everyone» group.
Control Title: The system is not configured to make the object creator the owner of objects created by administrators.
Either the object creator or the Administrators group owns objects created by members of the Administrators group. In order to ensure accurate auditing and proper accountability, the default owner should be the object creator.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “System objects: Default owner for object created by members of the Administrators group” to “Object creator”.
Control Title: Remove Software Certificate Installation Files
This check verifies that software certificate installation files have been removed from a system.
Solution: Remove any certificate installation files found on a system.
Note: This does not apply to server-based applications that have a requirement for .p12 certificate files (e.g., Oracle Wallet Manager)
Control Title: Disallow AutoPlay/Autorun from Autorun.inf
This registry key will prevent the autorun.inf from executing commands.
Solution: The guide omitted this part. I am instead posting this to help viewers http://support.microsoft.com/kb/967715
Control Title: POSIX subsystem registry key exists.
For the system to comply with Security requirements, the POSIX subsystem must be disabled.
Solution: Remove the following Registry value from the Windows Registry:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems\Posix
Control Title: System pagefile is cleared upon shutdown.
This check verifies that Windows is not configured to wipe clean the system page file during a controlled system shutdown.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Shutdown: Clear virtual memory pagefile” to “Disabled”.
Control Title: Secure Removable Media CD-ROM
This check verifies that Windows is configured to not limit access to CD drives when a user is logged on locally per the FDCC.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Devices: Restrict CD-ROM access to locally logged-on user only” to “Disabled”.
Control Title: Floppy media devices are not allocated upon user logon.
This check verifies that Windows is configured to not limit access to floppy drives when a user is logged on locally per the FDCC.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Devices: Restrict floppy access to locally logged-on user only” to “Disabled”.
Control Title: The system allows shutdown from the logon dialog box.
Preventing display of the shutdown button in the logon dialog box may encourage a hard shut down with the power button. (However, displaying the shutdown button may allow individuals to shut down a system anonymously.)
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Shutdown: Allow system to be shutdown without having to log on” to “Enabled”.
Control Title: The required legal notice must be configured to display before console logon.
Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources.
Solution: Consent with your organization’s lawyers to determine if this control applies or not to your environment and policy -EB
Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options ->“Interactive Logon: Message text for users attempting to log on” as outlined in the check.
Control Title: Caching of logon credentials is not limited.
The default Windows configuration caches the last logon credentials for users who log on interactively to a system. This feature is provided for system availability reasons such as the user’s machine is disconnected from the network or domain controllers are not available. Even though the credential cache is well-protected, storing encrypted copies of users passwords on systems do not always have the same physical protection required for domain controllers. If a system is attacked, the unauthorized individual may isolate the password to a domain user account using a password-cracking program, and gain access to the domain.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Interactive Logon: Number of previous logons to cache (in case Domain Controller is not available)” to “2” logons or less.
Control Title: Anonymous shares are not restricted.
This is a Category 1 finding because it allows anonymous logon users (null session connections) to list all account names and enumerate all shared resources, thus providing a map of potential points to attack the system.
By default, Windows allows anonymous users to list account names and enumerate share names. In a mixed Windows environment this setting may cause systems with down-level operating systems to fail to authenticate, may prevent their users from changing their passwords, and may cause problems with managing printers and spools.
Solution: Configure the policy values for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network access: Do not allow anonymous enumeration of SAM accounts” and “Network access: Do not allow anonymous enumeration of SAM accounts and shares” to “Enabled».
Control Title: The option to prevent the password in dial-up networking from being saved is not enabled.
The default Windows configuration enables the option to save the password used to gain access to a remote server using the dial-up networking feature. With this option enabled, an unauthorized user who gains access to a Windows machine would also have access to remote servers with which the machine uses dial-up networking to communicate. Disabling this option will introduce another layer of security and help limit the scope of any security compromise to the local machine.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (DisableSavePassword) Prevent the dial-up password from being saved (recommended)” to “Enabled”.
Control Title: The built-in Microsoft password filter is not enabled.
The use of complex passwords increases their strength against guessing. This policy setting configures the system to verify that newly-created passwords conform to the Windows password complexity policy.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy -> “Password must meet complexity requirements” to «Enabled».
Control Title: Print driver installation privilege is not restricted to administrators.
By default, the print spooler allows any user to add and to delete printer drivers on the local system. This capability should be restricted to authorized personnel.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Devices: Prevent users from installing printer drivers” to “Enabled”.
Control Title: The Send download LanMan compatible password option is not set to Send NTLMv2 response onlyLM.
The Kerberos v5 authentication protocol is the default for authentication of users who are logging on to domain accounts. NTLM is retained in later Windows versions for compatibility with clients and servers that are running earlier versions of Windows. It is also used to authenticate logons to stand-alone computers that are running later versions. Setting this to the required setting may prevent authentication with older Operating Systems and break some applications.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network security: LAN Manager authentication level” to at least “Send NTLMv2 response only\refuse LM”.
Control Title: Ctrl+Alt+Del security attention sequence is Disabled.
Disabling the Ctrl+Alt+Del security attention sequence can compromise system security. Because only Windows responds to the Ctrl+Alt+Del security sequence, you can be assured that any passwords you enter following that sequence are sent only to Windows. If you eliminate the sequence requirement, malicious programs can request and receive your Windows password. Disabling this sequence also suppresses a custom logon banner.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Interactive Logon: Do not require CTRL ALT DEL” to “Disabled”.
Control Title: Unencrypted password is sent to 3rd party SMB Server.
Some non-Microsoft SMB servers only support unencrypted (plain text) password authentication. Sending plain text passwords across the network, when authenticating to an SMB server, reduces the overall security of the environment. Check with the Vendor of the SMB server to see if there is a way to support encrypted password authentication.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Microsoft Network Client: Send unencrypted password to connect to third-party SMB servers” to “Disabled”.
Control Title: Administrator automatic logon is enabled.
This is a category 1 finding because it will directly log on to the system with administrator privileges when the machine is rebooted. This would give full access to any unauthorized individual who reboots the computer.
By default this setting is not enabled. If this setting exists, it should be disabled. If this capability exists, the password may also be present in the registry, and must be removed.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended)” to “Disabled”.
Control Title: Outgoing secure channel traffic is not signed when possible.
Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the channel is not integrity checked. If this policy is enabled, all outgoing secure channel traffic should be signed. If the value for “Domain Member: Digitally encrypt or sign secure channel data (always)” is set to “Enabled”, then this would not be a finding.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Domain Member: Digitally sign secure channel data (when possible)” to “Enabled”.
Control Title: The computer account password is prevented from being reset.
As a part of Windows security, computer account passwords are changed automatically. Enabling this policy to disable automatic password changes can make the system more vulnerable to malicious access. Frequent password changes can be a significant safeguard for your system. If this policy is disabled, a new password for the computer account will be generated every week.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Domain Member: Disable Machine Account Password Changes” to “Disabled”.
Last edited: Apr 28, 2013
-
Control Title: The Recovery Console SET command is enabled.
Enabling this option enables the Recovery Console SET command, which allows you to set Recovery Console environment variables. This permits floppy copy and access to all drives and folders.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Recovery Console: Allow floppy copy and access to all drives and folders” to “Disabled”.
Control Title: The Recovery Console option is set to permit automatic logon to the system.
This is a Category 1 finding because if this option is set, the Recovery Console does not require you to provide a password and will automatically log on to the system, giving Administrator access to system files.
By default, the Recovery Console requires you to provide the password for the Administrator account before accessing the system.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Recovery Console: Allow automatic administrative logon” to “Disabled”.
Control Title: TThe unsigned driver installation behavior is improperly set.
Determines what should happen when an attempt is made to install a device driver (by means of the Windows device installer) that has not been certified by the Windows Hardware Quality Lab (WHQL).
The options are:
— Silently succeed
— Warn but allow installation
— Do not allow installationSolution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Devices: Unsigned driver installation behavior” to “Warn but allow installation” or “Do not allow installation”. (EB chiming in, I would start with the first suggestion and once a baseline is set, use the more restrictive)
Control Title: Ejection of removable NTFS media is not restricted to Administrators.
Removable hard drives can be formatted and ejected by others who are not members of the Administrators Group, if they are not properly configured. Formatting and ejecting removable NTFS media should only be done by administrators.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Devices: Allowed to Format and Eject Removable Media” to “Administrators”.
Control Title: The default permissions of Global system objects are not increased.
Windows system maintains a global list of shared system resources such as DOS device names, mutexes, and semaphores. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. If this policy is enabled, the default DACL is stronger, allowing non-admin users to read shared objects, but not modify shared objects that they did not create.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “System Objects: Strengthen default permissions of internal system objects (e.g. Symbolic links)” to “Enabled”.
Control Title: Reversible password encryption is not disabled.
Storing passwords using reversible encryption is essentially the same as storing clear-text versions of the passwords. For this reason, this policy should never be enabled.
Solution: Configure the system to prevent passwords from being saved using reverse encryption. By default this is disabled.
Control Title: The system is configured to autoplay removable media.
Autoplay begins reading from a drive as soon as you insert media in the drive. As a result, the setup file of programs and the music on audio media starts immediately. By default, Autoplay is disabled on removable drives, such as the floppy disk drive (but not the CD-ROM drive), and on network drives. If you enable this policy, you can also disable Autoplay on all drives.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> System -> “Turn off AutoPlay” to “Enabled:All Drives”.
In addition to the above, Microsoft has released patches to correct issues with this setting. The patches from either Microsoft’s KB953252 (patch KB950582) or KB967715 must be installed. This will add the HonorAutorunSetting registry value and update the file referenced in the Check section.
Control Title: Unauthorized named pipes are accessible with anonymous credentials.
This is a Category 1 finding because the potential for gaining unauthorized system access. Pipes are internal system communications processes. They are identified internally by ID numbers that vary between systems. To make access to these processes easier, these pipes are given names that do not vary between systems. This setting controls which of these pipes anonymous users may access.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network access: Named pipes that can be accessed anonymously” as defined in the Check section.
Control Title: Unauthorized registry paths are remotely accessible.
This is a Category 1 finding because it could give unauthorized individuals access to the Registry.
It controls which registry paths are accessible from a remote computer.Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network access: Remotely accessible registry paths” as defined in the Check section.
Control Title: Unauthorized shares can be accessed anonymously.
This is a Category 1 finding because the potential for gaining unauthorized system access. Any shares listed can be accessed by any network user. This could lead to the exposure or corruption of sensitive data. Enabling this setting is very dangerous.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network access: Shares that can be accessed anonymously” as defined in the Check section.
Control Title: Remote control of a Terminal Service session is allowed.
This setting is used to control the rules for remote control of Terminal Services user sessions. This is a Category 1 finding because remote control of sessions could permit an unauthorized user to access sensitive information on the controlled system.
Solution: Configure the system to prevent remote control of the computer by setting the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services, “Sets rules for remote control of Terminal Services user settings” to “Enabled” and the “Options” will be set to “No remote control allowed”.
Control Title: Solicited Remote Assistance is allowed.
This setting controls whether or not solicited remote assistance is allowed from this computer. Solicited assistance is help that is specifically requested by the user. This is a Category 1 finding because it may allow unauthorized parties access to the resources on the computer.
Solution: Configure the system to disable Remote Assistance by setting the policy value for Computer Configuration -> Administrative Templates -> System -> Remote Assistance “Solicited Remote Assistance” to “Disabled”.
Control Title: The system is configured to permit storage of credentials or .NET Passports.
This setting controls the storage of authentication credentials or .NET passports on the local system. Such credentials should never be stored on the local machine as that may lead to account compromise.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network access: Do not allow storage of credentials or .NET passports for network authentication” to “Enabled”.
Control Title: The system is configured to give anonymous users Everyone rights.
This setting helps define the permissions that anonymous users have. If this setting is enabled then anonymous users have the same rights and permissions as the built-in Everyone group. Anonymous users should not have these permissions or rights.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network access: Let everyone permissions apply to anonymous users” to “Disabled”.
Control Title: The system is not configured to use the Classic security model.
Windows includes two network-sharing security models — Classic and Guest only. With the classic model, local accounts must be password protected; otherwise, anyone can use guest user accounts to access shared system resources.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network access: Sharing and security model for local accounts” to “Classic — local users authenticate as themselves”.
Control Title: The system is configured to store the LAN Manager hash of the password in the SAM.
This setting controls whether or not a LAN Manager hash of the password is stored in the SAM the next time the password is changed. The LAN Manager hash is a weak encryption algorithm and there are several tools available that use this hash to retrieve account passwords.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network security: Do not store LAN Manager hash value on next password change” to “Enabled”.
Control Title: The system is not configured to force users to log off when their allowed logon hours expire.
This setting controls whether or not users are forced to log off when their allowed logon hours expire. If logon hours are set for users, then this should be enforced.
Solution: Configure the system to log off users when their allowed logon hours expire.
Control Title: The system is not configured to recommended LDAP client signing requirements.
This setting controls the signing requirements for LDAP clients. This setting should be set to Negotiate signing or Require signing depending on the environment and type of LDAP server in use.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network security: LDAP client signing requirements” to “Negotiate signing” at a minimum.
Control Title: The system is not configured to meet the minimum requirement for session security for NTLM SSP based Clients.
Microsoft has implemented a variety of security support providers for use with RPC sessions. In a homogenous Windows environment, all of the options should be enabled and testing should be performed in a heterogeneous environment to determine the maximum-security level that provides reliable functionality. Microsoft warns that setting these may prevent the client from communicating with legacy servers that do not support them. “Require NTLMv2 session security” will prevent authentication, if the “Network security: LAN Manager authentication level” is set to permit NTLM or LM authentication.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients” to “Require NTLMv2 session security”, ”Require 128-bit encryption”, ”Require Message Integrity”, and ”Require Message Confidentiality” (all options selected).
Control Title: The system is not configured to use FIPS compliant Algorithms for Encryption, Hashing, and Signing.
This setting ensures that the system uses algorithms that are FIPS compliant for encryption, hashing, and signing. FIPS compliant algorithms meet specific standards established by the U.S. Government and should be the algorithms used for all OS encryption functions.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” to “Enabled”.
Control Title: The system is configured to allow case insensitivity.
This setting controls the behavior of non-Windows subsystems when dealing with the case of arguments or commands. Case sensitivity could lead to the access of files or commands that should be restricted. To prevent this from happening, case insensitivity restrictions should be required.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “System Object: Require Case Insensitivity for Non-Windows Subsystems” to “Enabled”.
Control Title: The system is configured to prevent background refresh of Group Policy.
If this setting is enabled, then Group Policy settings are not refreshed while a user is currently logged on. This could lead to instances when a user does not have the latest changes to a policy applied and is therefore operating in an insecure context.
Solution: Configure the system to require Group Policy background refresh by setting the policy value for Computer Configuration -> Administrative Templates -> System -> Group Policy “Turn Off Background Refresh of Group Policy” to “Disabled”.
Control Title: The system is configured to allow installation of printers using kernel-mode drivers.
Kernel-mode drivers are drivers that operate in kernel mode. Kernel mode allows virtually unlimited access to hardware and memory. A poorly written kernel driver may cause system instability and data corruption. Malicious code inserted in a kernel-mode driver has almost no limit on what it may do. Most modern printers do not require kernel-mode drivers. This setting will prevent some applications from installing PDF print drivers. If necessary temporarily disable this setting while installing a legitimate kernel-mode driver.
Solution: Configure the system to prevent it from allowing the installation of kernel-mode drivers by setting the policy value for Computer Configuration -> Administrative Templates -> Printers “Disallow Installation of Printers Using Kernel-mode Drivers” to “Enabled”.
Control Title: The system is not configured to use Safe DLL Search Mode.
The default search behavior, when an application calls a function in a Dynamic Link Library (DLL), is to search the current directory followed by the directories contained in the systems path environment variable. An unauthorized DLL inserted into an applications working directory could allow malicious code to be run on the system. Creating the following registry key and setting the appropriate value forces the system to search the %Systemroot% for the DLL before searching the current directory or the rest of the path.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (SafeDllSearchMode) Enable Safe DLL search mode (recommended)” to “Enabled”.
Control Title: The system does not generate an audit event when the audit log reaches a percent full threshold.
When the audit log reaches a given percent full, an audit event is written to the security log. The event ID is 523 and is recorded as a success audit under the category of System. This option may be especially useful if the audit logs are set to be cleared manually. A recommended setting would be 90 percent.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning” to “90” or less.
Control Title: The system is configured to allow dead gateway detection.
Allows TCP to peform dead-gateway detection, switching to a backup gateway if a number of connections to a gateway are experiencing difficulty. If enabled, an attacker could force internal traffic to be directed to a gateway outside the network. This setting applies to all network adapters, regardless of their individual settings.
Solution: http://technet.microsoft.com/en-us/library/cc960464.aspx -EB this was not provided in the original document
Control Title: The system is configured to allow IP source routing.
Protects against IP source routing spoofing.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing)” to “Highest protection, source routing is completely disabled”.
Control Title: The system is configured to redirect ICMP.
When disabled, forces ICMP to be routed via shortest path first.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes” to “Disabled”.
-
Control Title: The system is configured for a greater keep-alive time than recommended.
Controls how often TCP sends a keep-alive packet in attempting to verify that an idle connection is still intact.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds” to “300000 or 5 minutes (recommended)” or less.
Control Title: The system is configured to allow name-release attacks.
Prevents a denial-of-service (DoS) attack against a WINS server. The DoS consists of sending a NetBIOS Name Release Request to the server for each entry in the servers cache, causing a response delay in the normal operation of the servers WINS resolution capability.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (NoNameReleaseOnDemand) Allow computer to ignore NetBIOS name release requests except from WINS servers” to “Enabled”.
Control Title: The system is configured to allow SYN attacks.
Adjusts retransmission of TCP SYN-ACKs. When enabled, connection responses time out more quickly in the event of a SYN DoS attack.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (SynAttackProtect) Syn attack protection level (protects against DoS)” to “Connections time out sooner if a SYN attack is detected”.
Control Title: The system is configured to detect and configure default gateway addresses.
Enables or disables the Internet Router Discovery Protocol (IRDP) used to detect and configure Default Gateway addresses on the computer.Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure Default Gateway addresses (could lead to DoS)” to “Disabled”.
Control Title: Group Policy objects are not reprocessed if they have not changed.
Enabling this setting and then selecting the «Process even if the Group Policy objects have not changed» option ensures that the policies will be reprocessed even if none have been changed. This way, any unauthorized changes are forced to match the domain-based group policy settings again.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> System -> Group Policy “Registry Policy Processing” to “Enabled” and select the option “Process even if the Group Policy objects have not changed”.
Control Title: Outgoing secure channel traffic is not encrypted or signed.
Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but not all information is encrypted. If this policy is enabled, outgoing secure channel traffic will be encrypted and signed.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Domain Member: Digitally encrypt or sign secure channel data (always)” to “Enabled”.
Control Title: The system is configured to allow the display of the last user name on the logon screen.
The user name of the last user to log onto a system will not be displayed. This eliminates half of the Userid/Password equation that an unauthorized person would need to log on.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Interactive logon: Do not display last user name” to “Enabled”.
Control Title: Audit Access to Global System Objects is not turned off.
This policy setting stops the system from setting up a default system access control list for certain system objects which could create a very large number of security events filling the Security log in Windows.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Audit: Audit the access to global system objects” to “Disabled”.
Control Title: Audit of Backup and Restore Privileges is not turned off.
This policy setting stops the system from generating audit events for every file backed up or restored which could fill the Security log in Windows.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Audit: Audit the use of Backup and Restore privilege” to “Disabled”.
Control Title: 8dot3 Name Creation Prevented
This check verifies Windows is configured to allow the generation of 8.3 style file names per the FDCC.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames (recommended)” to “Disabled”.
Control Title: Number of allowed bad-logon attempts does not meet minimum requirements.
The account lockout feature, when enabled, prevents brute-force password attacks on the system. The higher this value is, the less effective the account lockout feature will be in protecting the local system. The number of bad logon attempts should be reasonably small to minimize the possibility of a successful password attack, while allowing for honest errors made during a normal user logon.
Solution: Configure the system to lock out an account after three invalid logon attempts.
Control Title: Time before bad-logon counter is reset does not meet minimum requirements.
This parameter specifies the amount of time that must pass between two successive login attempts to ensure that a lockout will occur. The smaller this value is, the less effective the account lockout feature will be in protecting the local system.
Solution: Configure the system to have the lockout counter reset itself after a minimum of 60 minutes.
Control Title: Users are not forcibly disconnected when logon hours expire.
Users should not be permitted to remain logged on to the network after they have exceeded their permitted logon hours. In many cases, this indicates that a user forgot to log off before leaving for the day. However, it may also indicate that a user is attempting unauthorized access at a time when the system may be less closely monitored. This protects critical and sensitive network data from exposure to unauthorized personnel with physical access to the computer.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Microsoft Network Server: Disconnect Clients When Logon Hours Expire” to “Enabled”.
Control Title: User rights and advanced user rights settings do not meet minimum requirements.
Inappropriate granting of user and advanced user rights can provide system, administrative, and other high level capabilities not required by the normal user.
Solution: Configure the system to prevent accounts from having unauthorized User Rights.
Control Title: Maximum password age does not meet minimum requirements.
The longer a password is in use, the greater the opportunity for someone to gain unauthorized knowledge of the passwords. Further, scheduled changing of passwords hinders the ability of unauthorized system users to crack passwords and gain access to a system.
Solution: Configure the Maximum Password Age so that it is not «0» and doesn’t exceed 60 days. (EB here, set up also two-factor if possible)
Control Title: Minimum password age does not meet minimum requirements.
Permitting passwords to be changed in immediate succession within the same day, allows users to cycle passwords through their history database. This enables users to effectively negate the purpose of mandating periodic password changes.
Solution: Configure the Minimum Password Age so that it is a minimum of «1».
Control Title: For systems utilizing a logon ID as the individual identifier, passwords are not at a minimum of 14-characters.
Information systems not protected with strong password schemes including passwords of minimum length provide the opportunity for anyone to crack the password thus gaining access to the system and causing the device, information, or the local network to be compromised or a denial of service. Strong passwords may invite users to write down the passwords. Ensure that all users store passwords in a secured location.
Solution: Configure all information systems to require passwords of the minimun length specified in the check.
Control Title: Password uniqueness does not meet minimum requirements.
A system is more vulnerable to unauthorized access when system users recycle the same password several times without being required to change a password to a unique password on a regularly scheduled basis. This enables users to effectively negate the purpose of mandating periodic password changes.
Solution: Configure the system to remember a minimum of «24» or greater used passwords.
Control Title: The built-in guest account is not disabled
A system faces an increased vulnerability threat if the built-in guest account is not disabled. This account is a known account that exists on all Windows systems and cannot be deleted. This account is initialized during the installation of the operating system with no password assigned. This account is a member of the Everyone user group and has all the rights and permissions associated with that group, which could subsequently provide access to system resources to anonymous users.
Solution: Configure the system to rename or disable the built-in guest Account.
Control Title: The use of local accounts with blank passwords is not restricted to console logons only.
This is a Category 1 finding because no accounts with blank passwords should exist on a system. The password policy should prevent this from occurring. However, if a local account with a blank password does exist, enabling this setting will limit the account to local console logon only.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Accounts: Limit local account use of blank passwords to console logon only” to “Enabled”.
Control Title: Built-in Admin Account Status
This check verifies that Windows XP is configured to ensure the built-in administrator account is enabled.
Solution: Configure the system to enable the built-in admin account.
Control Title: The maximum age for machine account passwords is not set to requirements.
This setting controls the maximum password age that a machine account may have. This setting should be set to no more than 30 days, ensuring the machine changes its password monthly.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Domain Member: Maximum Machine Account Password Age” to 30 or less, but not 0.
Control Title: The system is not configured to require a strong session key.
This setting controls the required strength of a session key.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Domain Member: Require Strong (Windows 2000 or Later) Session Key” to “Enabled”.
Control Title: Domain Controller authentication is not required to unlock the workstation.
This setting controls the behavior of the system when you attempt to unlock the workstation. If this setting is enabled, the system will pass the credentials to the domain controller (if in a domain) for authentication before allowing the system to be unlocked. This will be set to disabled per the FDCC.
Solution: Workstations — Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “Interactive logon: Require domain controller authentication to unlock workstation” to “Disabled”.
Control Title: Restricted accounts are not disabled.
Several new accounts are created as part of the default installation. As these accounts are well known they may represent prime attack targets. To help prevent attacks using the well-known accounts the following accounts should be disabled: HelpAssistant and Support_388945a0.
Solution: Configure the system to disable restricted accounts such as HelpAssistant or Support_388945a0.
Control Title: The system is configured to allow remote desktop sharing through NetMeeting.
Remote desktop sharing enables several users to interact and control one desktop. This could allow unauthorized users to control the system. Remote desktop sharing should be disabled.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> NetMeeting “Disable remote Desktop Sharing” to “Enabled».
Control Title: Terminal Services is not configured to always prompt a client for passwords upon connection.
This setting, which is located under the Encryption and Security section of the Terminal Services configuration option, controls the ability of users to supply passwords automatically as part of their Remote Desktop Connection. Disabling this setting would allow anyone to use the stored credentials in a connection item to connect to the terminal server.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services -> Encryption and Security “Always Prompt Client for Password upon Connection” to “Enabled”.
Control Title: IPv6 will be disabled until a deliberate transition strategy has been implemented.
Any nodes’ interface with IPv6 enabled by default presents a potential risk of traffic being transmitted or received without proper risk mitigation strategy and therefore a serious security concern.
Solution: Uninstall the IPv6 protocol until a deliberate transition strategy has been implemented.
Control Title: Media Player is configured to allow automatic checking for updates.
The automatic check for updates perform by the Windows Media Player must be disabled to ensure a constant platform and to prevent the introduction of unknown/untested software on the network.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Windows Media Player “Prevent Automatic Updates” to “Enabled”.
Control Title: TCP connection response retransmissions are not controlled.
In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server, and the server leaves the half-open connections open until it is overwhelmed and no longer is able to respond to legitimate requests. Microsoft cautions that setting this to “No retransmission, half-open connections dropped after 3 seconds” may cause legitimate connection attempts from distant clients to fail due to time-out.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (TcpMaxConnectResponseRetransmissions) SYN-ACK retransmissions when a connection is not acknowledged” to “3 & 6 seconds, half-open connections dropped after 21 seconds”, “3 seconds, half-open connections dropped after 9 seconds” or “No retransmission, half-open connections dropped after 3 seconds”.
Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is the default)” to “3” or less.
Control Title: This check verifies that Windows is configured to have password protection take effect within a limited time frame when the screen saver becomes active.
Allowing more than several seconds makes the computer vulnerable to a potential attack from someone walking up to the console to attempt to log onto the system before the lock takes effect.
Solution: Configure the policy value for Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended)” to “5” or less.
Control Title: Restrict unauthenticated RPC clients.
This check verifies that the system is configured to restrict unauthenticated RPC clients from connecting to the RPC server.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> System -> Remote Procedure Call “Restrictions for Unauthenticated RPC clients” to “Enabled” and “Authenticated”.
Control Title: File and Folder Publish to Web option unavailable.
This check verifies that the system is configured to make the options to publish to the web unavailable from File and Folder Tasks in Windows folders.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication setting ‘Turn off the «Publish to Web» task for files and folders’ to “Enabled”.
Configure the policy value for Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication setting ‘Turn off Internet download for Web publishing and online ordering wizards’ to “Enabled”.
Control Title: Prevent printing over HTTP.
This check verifies that the system is configured to prevent the client computer’s ability to print over HTTP, which allows the computer to print to printers on the intranet as well as the Internet.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication setting ‘Turn off printing over HTTP’ to “Enabled”.
Configure the policy value for Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication setting ‘Turn off downloading of print drivers over HTTP’ to “Enabled”.
Control Title: Windows Peer to Peer Networking
This check verifies Microsoft Peer-to-Peer Networking Service is turned off.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Microsoft Peer-to-Peer Networking Services “Turn Off Microsoft Peer-to-Peer Networking Services” to “Enabled”.
Control Title: Prohibit Network Bridge in Windows
This check verifies the Network Bridge can not be installed and configured.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections “Prohibit installation and configuration of Network Bridge on your DNS domain network” to “Enabled”.
Control Title: Prohibit Internet Connection Sharing
This check verifies Internet Connection Sharing can not be installed and configured.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections “Prohibit use of Internet Connection Sharing on your DNS domain network” to “Enabled”.
Control Title: RSS Attachment Downloads
This check verifies that attachments are prevented from being downloaded from RSS feeds.
Solution: Note: For Windows XP, this only applies if Internet Explorer 7 or later is installed.
Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> RSS Feeds “Turn off downloading of enclosures” to “Enabled”.
Control Title: Windows Explorer Shell Protocol Protected Mode
This check verifies that the shell protocol is run in protected mode. (This allows applications to only open limited folders.)
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Windows Explorer “Turn off shell protocol protected mode” to “Disabled”.
Control Title: Windows Installer IE Security Prompt
This check verifies that users are notified if a web-based program attempts to install software.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer “Disable IE security prompt for Windows Installer scripts” to “Disabled”.
Control Title: Windows Installer User control
This check verifies that users are prevented from changing installation options.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer “Enable user control over installs” to “Disabled”.
Control Title: Windows Installer Vendor signed updates
This check verifies that users are prevented applying vendor signed updates.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer “Prohibit non-administrators from applying vendor signed updates” to “Enabled”.
-
Control Title: XP Firewall Standard Profile – Enable Firewall
This setting enables the Windows Firewall when not connected to the domain.
The standard profile settings are used when the system is connected to a network that does not contain domain controllers for the domain of which the computer is a member.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Standard Profile «Windows Firewall: Protect all network connections» to «Enabled».
Control Title: XP Firewall Domain Profile File and Printer Sharing
Shared files and printers will not be available to other computers when connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile «Windows Firewall: Allow file and printer sharing exception» to «Disabled».
Control Title: XP Firewall Domain Profile ICMP Exceptions
Only Inbound ICMP echo requests will be allowed when connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile «Windows Firewall: Allow ICMP exceptions» to «Enabled» with the following parameter checked «Allow inbound echo request».
Control Title: XP Firewall Domain Profile Local Port Exceptions
Local port exceptions can not be defined when connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile «Windows Firewall: Allow local port exceptions» to «Disabled».
Control Title: XP Firewall Domain Profile Logging
Firewall logging will be enabled and configured as defined when connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile «Windows Firewall: Allow logging» to «Enabled» with the following parameters checked
«Log dropped packets»
«Log successful connections»
«Log file path and name» set to «%systemroot%\domainfw.log»
«Size limit (KB)» set to «16384» (or greater)Control Title: XP Firewall Domain Profile Plug and Play
Unsolicited Plug and Play messages will be blocked when connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile «Windows Firewall: Allow UPnP framework exception» to «Disabled».
Control Title: XP Firewall Domain Profile Unicast Response
The receipt of unicast responses to outgoing multicast or broadcast messages will be blocked when connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile «Windows Firewall: Prohibit unicast response to multicast or broadcast requests» to «Enabled».
Control Title: XP Firewall Standard Profile ICMP Requests
ICMP requests will be blocked when not connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Standard Profile «Windows Firewall: Allow ICMP exceptions» to «Disabled».
Control Title: XP Firewall Standard Profile No Exceptions
All unsolicited incoming messages will be blocked when not connected to the domain.
Solution: Configure the policy value for Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Standard Profile «Windows Firewall: Do not allow exceptions» to «Enabled».
-Fin
Last edited: Apr 28, 2013
-
X-What?
Just kidding.
EB, you should put that stuff in an ebook and sell it on iTunes or Amazon.
Seriously! Good stuff.`
-
I may customize/omit certain parts not relevant to posters here, however these are pulled from much larger checklists provided by NIST/NSA/DISA for the information security community at the unclassified level. Offered as general guidance to private sectors, but mandated fun for public. At the very least it can offer a good starting baseline to harden systems within scope of an organization.
I pull from:
http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml
http://iase.disa.mil/stigs/a-z.html
http://csrc.nist.gov/publications/PubsSPs.html -
bolts
Registered Member- Joined:
- Apr 3, 2013
- Posts:
- 7
- Location:
-
USA
@EB…Thank you for replying, and for the information. That looks like it will keep me busy for quite a while.
Can you recommend some books or websites for «know-nothing» network monitoring noobs like me? I’ve pre-ordered Richard Bejtlich’s new book coming out in late July, and I’m currently reading «Hacking Exposed 7».@LockBox…LOL! A few months ago, I replaced some old workstations that were still running Windows 2000, and we also had a CNC machine that had a program that could only run in DOS…so that one had Windows 95 on it! And it had to be run on older hardware because the interface card for the motion controller was for an ISA slot. I found a lot of 5 HP E60 Netservers new in the box for dirt cheap. They came with a 256 meg RAM chip, and wouldn’t you know it…Windows 95 would not load on that. I needed to find a 128 meg chip.
Then I had to load a program called Mo’ Slo to slow the processing speed of the PIII down to something like 33mHz or whatever so the timing ran right for the DOS program.
Fortunately, a month ago; we got a new laser cutter and press brake to retire that machine. Both new machines have embedded Windows software on them…I just found out that the press brake uses Windows CE.Did I mention that I love my job?
-
bolts
Registered Member- Joined:
- Apr 3, 2013
- Posts:
- 7
- Location:
-
USA
I still can’t send PMs, but if you could email the 130 page version…I’d like to look through that as well.
Thanks,
boltsinneck +at+ hotmail +dot+ comYeah, I know…Hot-what?
But hey, it works great with Netscape!
<kidding> -
Hi,
to disable anonymous logon by Group Policy
I am going to ComputerConfiguration ->Policies ->WindowsSettings
->SecuritySettings ->LocalPolicies ->UserRightsAssignment
-Deny Logon Locallyis this the correct place to set it??
-
@EncryptedBytes: Maybe Mr. Wilder would consider making this a sticky, in my opinion this is some very beneficial material for all XP users..
I’m sure everyone here feels the same..
-
Thankyou for this thread. XP here too, but this will take more than a cursory glance to get through this.
-
Even after you disable local file and print sharing, Windows XP still leaves port 445 open and listening for incoming connections. If you are not using local networking, this can pose a security risk. To close this port you need to make a quick change to an entry in the Windows registry.
NOTE: It is very important that if you do not feel comfortable editing the registry or have never done it before that you avoid doing this right away and learn more about the Windows registry. Changing the wrong setting or changing a setting incorrectly can cause Windows to not function correctly.
Please be advised that Vectro Security takes no responsibility for any damage caused to the operating system.
Here are the step-by-step instructions to close port 445 in Windows XP:
1. Click «Start»
2. Click «Run…»
3. Where it says «Open:» type «regedit»
4. Navigate to HKLM\System\CurrentControlSet\Services\NetBT\Parameters
5. Find the value «TransportBindName» and right-click it to open up a menu of options.
6. Click «Modify» (it is in bold text)
7. Where it says «Value data:» delete whatever is in the box so the box is blank. The blank entry is what closes the port.
8. Click «OK»
9. Close the registry and reboot.
———————————————-
That takes care of it, now you are much safer from other machines on your local network, or if you are plugged into a cable modem without a router.
To disable Port 445:Add the following registry key:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
Name: SMBDeviceEnabled
Type: DWORD (REG_DWORD)
Data: 0Don’t forget to restart your computer after disabling the above ports for effect. Also, to check that those ports are disabled, you can open a command prompt and type netstat -an to confirm that your computer is no longer listening to those ports.
—————————————-
To disable Port 135 (step 4 is not necessary):
[1] Start by launching the registry editor.
Start » Run » regedit.[2] Navigate over to key: HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
At the right column, locate the value «EnableDCOM» and modify the value to «N»
[3] Navigate to this registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RPC
Right click on & Modify the value named «DCOM Protocols» Under the key «Value Data», you will see values. These values keep port 135 open. Highlight everything listed and delete all existing data. Doing so gives «DCOM Protocols» blank data which will in turn close down port 135.
ncacn_ip_tcp
ncacn_spx
ncacn_nb_nb
ncacn_nb_ipxdisable ipsec to close port 500~4500 winxp sp3
and if your really pro you’ll find out how to close alg.exe from camping the network stack, sadly i forgot like a bond head how to do it, all i remember is it has something to do with ICS «windows firewall»
WinXP SP2 = security placebo
Last edited: Oct 26, 2013
-
Ahh… this thread brings a tear to my eye. I have most of those tweaks applied myself, and many more. A few seem counter-productive though. Like restricting CD Rom & Floppy control to locally logged on users only should be Enabled IMO, not disabled. And clearing the virtual memory pagefile on Shutdown is good practice too IMO. Also cached logons should be 0/disabled, me thinks, not even 2.
As far as disabling auto-run, which is a biggie: Turn it off in Group Policy, for all drives, under both Computer Configuration & User. Disable the Shell Hardware Detection «service». And you’ll want to check out this page here and apply the registry tweak to shut it down for good:
http://windowssecrets.com/top-story/one-quick-trick-prevents-autorun-attacks/
Great stuff there by SnowFall too to shut down ports 135 & 445 for good. If they didn’t post it, I would’ve.
-
Actually the methods I learned to close ports 135 & 445 are a bit different from what SnowFall posted. Here are mine… you can try both/either.
For 135:
Disable DCOM first
Then do all the steps SnowFall provided. Afterward make sure these services are stopped/disabled, in addition to DCOM: COM+ Event System, COM+ System Application, System Event Notification.
You will need to Start/Auto DCOM to update Windows, along with Automatic Updates (Start/Auto), Backround Intelligent Transfer Service (Manual/will start itself), Crytographic Services (Manual/will start itself). DCOM is also needed for Windows Defragmentation. It will function fine after those tweaks.
For 445:
In regedit locate: HKLM\System\CurrentControlSet\Services\NetBT
Locate the «Start» entry (DWORD value). Modify value from 1 to 4.
Then look just below at: HKLM\System\CurrentControlSet\Services\NetBT\Parameters
> look at «TransportBindName», and delete the \DEVICE\ value, leaving it blank.
Close regedit. Reboot computer.
To check that both ports are closed go to «Run», and type in netstat -an (notice the space between t & -). See that ports 135 & 445 are no longer «Listening». In fact the list should be clear if you have everything locked down.
-
If you do this tweak make sure you use REGEDT32 instead of Regedit to go into your registry and make the change, or you can really hose your box. Refer to this guide here for how to safely apply this tweak:
http://www.pctools.com/guides/registry/detail/1202/
-
This is one I have to strongly disagree with. In fact the first thing I do after a fresh install of XP is create another Admin account and then disable the built-in one, along with the Guest account. Even as the system administrator, you should be able to do anything that needs done from the secondary Admin account, with lower privileges… the built-in account gives you enough of them to hang yourself with.
-
^ No doubt ^ Clean images IMO are a must have in this day & age, on a dying OS or a thriving one. Or at least something like Shadow Defender. Or both.
-
bolts
Registered Member- Joined:
- Apr 3, 2013
- Posts:
- 7
- Location:
-
USA
Wow…eight months later, and there’s still some interest in this thread.
So now that I have all of this great information, and thank you all for your contributions; I have another question…Since the DISA Windows Gold Disk Program was phased out nearly a year ago, is it possible for regular John Q. Public types like myself to get one of these disks from somebody with the right connections, or is that illegal?http://www.disa.mil/News/Stories/2012/gold-disk
- Thread Status:
-
Not open for further replies.