Служба координатора распределенных транзакций Microsoft должна выполняться под учетной записью Windows NT Аусорити\нетворксервице Windows

В этой статье представлено описание учетной записи Windows, которая должна выполняться координатором распределенных транзакций Microsoft (MSDTC) в Windows.

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

Исходная версия продукта: Windows Server 2012, Windows 8, Windows 7
Исходный номер статьи базы знаний: 903944

Аннотация

Для выполнения этих действий для всех клиентских и серверных операционных систем Windows может потребоваться перезапустить службу MSDTC. Чтобы перезапустить службу MSDTC, выполните указанные ниже действия.

Для Windows 8,1 и Windows 8

• На начальном экране проведите пальцем с правой стороны, чтобы отобразить чудо-кнопки, выберите Поиск, а затем выполните поиск по cmd. (Если вы используете клавиатуру и мышь, введите cmd на начальном экране.) В результатах поиска нажмите и удерживайте или щелкните правой кнопкой мыши Командная строка и выберите пункт Запуск от имени администратора.

Для Windows 7 и более ранних версий

• Нажмите клавишу с логотипом Windows + R, введите cmd в поле выполнить, а затем нажмите клавишу ВВОД. Щелкните правой кнопкой мыши cmd, а затем выберите Запуск от имени администратора.

Введите net stop msdtc , а затем нажмите кнопку Ввод .

Введите net start msdtc , а затем нажмите кнопку Ввод .

Откройте оснастку Службы компонентов Microsoft Management Console (MMC). Для этого нажмите кнопку Пуск, а затем выберите пункт Run тип запуска dcomcnfg.exe, а затем нажмите кнопку ОК.

Разверните узел службы компонентов, разверните узел Компьютерыи разверните узел Мой компьютер.

Щелкните правой кнопкой мыши значок Мой компьютери выберите пункт свойства.

Перейдите на вкладку MSDTC , а затем щелкните Настройка безопасности.

Измените учетную запись в учетной записи входа ДКТ на NT аусорити\нетворксервице. Если требуется пароль, введите пустой пароль.

Два раза нажмите кнопку ОК .

Для Windows XP и Windows Server 2003

Начиная с Windows XP, а затем продолжая работать в Windows Server 2003, служба MSDTC должна выполняться под NT AUTHORITY\NetworkService учетной записью Windows.

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

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

Как в Microsoft Windows NT 4,0, так и в Microsoft Windows 2000, вы можете изменить учетную запись службы MSDTC по умолчанию на учетную запись домена. Вы можете изменить учетную запись для выполнения проверки подлинности Windows при выполнении операции восстановления XA для базы данных XA, например базы данных Oracle.

Однако в Windows Server 2003 и Windows XP невозможно изменить учетную запись. Вместо этого необходимо предоставить разрешения и роли, необходимые для выполнения операции восстановления XA, с учетной записью NetworkService на компьютере, на котором запущена служба MSDTC.

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

Чтобы изменить учетную запись, которую служба MSDTC выполняет с помощью учетной записи NetworkService, выполните указанные ниже действия.

Неправильное изменение параметров системного реестра с помощью редактора реестра или любым иным путем может привести к возникновению серьезных неполадок. Из-за них может потребоваться переустановка операционной системы. Компания Microsoft не может гарантировать, что эти проблемы могут быть решены. Вносите изменения в реестр на ваш страх и риск.

Щелкните Пуск, затем Выполнить и введите regedit. Затем нажмите ОК.

Найдите и выберите следующий подраздел: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC .

Если имеются следующие записи, перейдите к шагу 6.

• TurnOffRpcSecurity
• AllowOnlySecureRpcCalls
• FallbackToUnsecureRPCIfNecessary

Создайте TurnOffRpcSecurity запись:

1. В меню Правка выберите команду Создать, а затем — пункт Параметр DWORD.
2. Введите турноффрпксекурити, а затем нажмите клавишу ВВОД.

Создайте AllowOnlySecureRpcCalls запись:

1. В меню Правка выберите команду Создать, а затем — пункт Параметр DWORD.
2. Введите алловонлисекурерпккаллс, а затем нажмите клавишу ВВОД.

Создайте FallbackToUnsecureRPCIfNecessary запись:

1. В меню Правка выберите команду Создать, а затем — пункт Параметр DWORD.
2. Введите фаллбакктаунсекурерпЦифнецессари, а затем нажмите клавишу ВВОД.

Задайте значение DWORD для TurnOffRpcSecurity записи:

1. Щелкните правой кнопкой мыши турноффрпксекуритии выберите команду изменить.
2. В диалоговом окне изменение параметра DWORD введите значение 1и нажмите кнопку ОК.

Задайте значение DWORD для AllowOnlySecureRpcCalls записи:

1. Щелкните правой кнопкой мыши алловонлисекурерпккаллси выберите команду изменить.
2. В диалоговом окне изменение значения DWORD введите значение 0, а затем нажмите кнопку ОК.

Задайте значение DWORD для FallbackToUnsecureRPCIfNecessary записи:

1. Щелкните правой кнопкой мыши фаллбакктаунсекурерпЦифнецессарии выберите команду изменить.
2. В диалоговом окне изменение значения DWORD введите значение 0, а затем нажмите кнопку ОК.

После внесения изменений в реестр необходимо перезапустить службу MSDTC. Чтобы перезапустить службу MSDTC, выполните указанные ниже действия.

1. Нажмите кнопку Пуск, выберите пункт выполнить, введите cmdи нажмите кнопку ОК.
2. Введите команду net stop msdtc и нажмите клавишу ВВОД.
3. Введите команду net start msdtc и нажмите клавишу ВВОД.
4. Откройте оснастку Службы компонентов Microsoft Management Console (MMC). Для этого нажмите кнопку Пуск, выберите пункт выполнить, введите dcomcnfg.exe, а затем нажмите кнопку ОК.
5. Разверните узел службы компонентов, разверните узел Компьютерыи разверните узел Мой компьютер.
6. Щелкните правой кнопкой мыши значок Мой компьютери выберите пункт свойства.
7. Перейдите на вкладку MSDTC , а затем щелкните Настройка безопасности.
8. Измените учетную запись в учетной записи входа ДКТ на NT аусорити\нетворксервице. Если требуется пароль, введите пустой пароль.
9. Два раза нажмите кнопку ОК .

Ссылки

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.

Windows — Use Local Service and/or Network Service account for a windows service

I’ve created a window’s service that monitors files on a specific directory on our Windows OS. When a file is detected, the service does some file I/O, reads the files, creates sub-directories, etc. This service also uses database connectivity to connect to another server. My plan is to have the service run as the default «Local Service» account. Since I need to allow write/read privileges, which apparently the «Local Service» account does not do by default, I’m going to explicitly set «Full Control» privileges for the «Local Service» account on the folder that I’m reading/writing to and from.

I believe the above is a good . My question is, for the folder that I’m reading and writing to, do I need to setup a «Network Service» role with full control access? I’m wondering since my service uses database connectivity to another server, if I’ll need the «Network Service» account setup.

I may be misunderstanding what the «Network Service» account does.

3 Answers 3

The NT AUTHORITY\NetworkService account is only needed when you’re communicating with other computers in a domain that need your machine’s credentials for access control. It is not required for simple Internet/network access. It is only necessary for specific purposes in an Active Directory domain.

Also the entire point of the NT AUTHORITY\LocalService account is that it has minimum privileges on the system. Giving it more privileged decreases the security of the many services on your system designed to run at the low privilege level it was designed to proffer. If your service requires privileges above and beyond those, you should create a new account for it with the necessary privileges and set that account in the Log On tab of the service’s properties. (This can also be done programatically.)

You could also run it using the NT AUTORITY\LocalSystem account, which has unlimited access to your system, but I assume you wanted to use the LocalService account for the increased security it provides.

The other answers confirm what you say about using Local Service. To summarize, Local Service is the recommended account to use with your service, unless you need the extra Active Directory SSPI features of Network Service.

For restricting read/write access to a specific folder, you can do better than just giving access to the generic Local Service account though. The problem, as others have pointed out, is that this would also give read/write access to all other services running as Local Service and if all services did this then gradually Local Service would receive access to more and more important resources.

The solution is to instead ACL your folder using your specific service SID. Only your own service process has your service SID associated with it, so this locks down your resource even further. You can view the service SID using sc showsid . The service SID is generated from the service name, so it will be the same on all machines.

To enable service SID usage by your service, use ChangeServiceConfig2 with the SERVICE_SID_INFO structure to set SERVICE_SID_TYPE_UNRESTRICTED . You can also set SERVICE_SID_TYPE_RESTRICTED to get an even more restricted SID that only allows write access to resources explicitly allowed with your service SID.

The previous answer didn’t appear to address the questions directly, so I thought I would add to it.

1. My plan is to have the service run as the default «Local Service» account. I’m going to explicitly set «Full Control» privileges for the «Local Service» account on the folder that I’m reading/writing to and from. I believe the above is a good plan.

Personally, I don’t see a big issue with this plan. With BUILTINs, the choice is between:

1. Running as LOCALSYSTEM — so if this service is compromised, the attacker owns Everything, and immediately.
2. Running as LOCALSERVICE — so if this service, or any of the many other services running under this account, are compromised, the attacker has access to one extra directory.*

Arguably, adding a few extra ACLs to be able to use the second option is preferable. Yes, the safest option for a low-privilege but highly security-sensitive service would be to run under a custom tailored, low privilege service account. But unless you want to create a new account/manage passwords for every service you deploy, using LocalService for minor non-sensitive tasks is not such a terrible thing. You just need to make a responsible decision based on these considerations, like what is in that directory or that database, impact if they are breached etc.

Although again, per least privilege principle, you should only set Full Control if Modify is really not sufficient.

2.My question is, for the folder that I’m reading and writing to, do I need to setup a «Network Service» role with full control access? I’m wondering since my service uses database connectivity to another server, if I’ll need the «Network Service» account setup.

If your database required Windows Integrated/SSPI login, then yes, you would need to use NetworkService (or a domain service account) everywhere, i.e., RunAs and directory permissions. Assuming you also granted your computername$ or domain account access to this database. I doubt you are doing that, so if it uses normal username/pwd authentication, you should be able to do everything with LocalService. You need to grant only one account rights on that directory, whichever you use in your RunAs, not both.

3.I may be misunderstanding what the «Network Service» account does.

LocalService/NetworkService are almost identical accounts on the local computer. The difference mainly is what they can do on the network. NS can access some network resources because it appears on the network as a real (computer) account. But LS will appear as ANONYMOUS, so it will be denied mostly everything on the network.

By the way, you should be using a Scheduled Task for this, not a service.

*From Vista onwards, due to service isolation, one compromised LocalService process cannot easily attack another. Each LocalService/NetworkService service process/instance gets its own unique logon session SID (unique owner), unlike Windows 2003. But I’m not sure this is perfect and fully mitigates the DACL vulnerability on files and resources. Restricted SIDs and write-restricted tokens are mentioned in this context.