emeadaxsupport: Group policy setting "System Objects: Default owner for objects created by members of the administrators group" is missing on Windows Server 2008

[Blog bot]

Источник: http://blogs.msdn.com/emeadaxsupport...dows-2008.aspx
==============

We came across a issue recently when using the AX AIF File Adapter. When consuming a file (for inbound processing), it fails to read the file because it is not the owner of the file. By default the ownership of files is set to the local administrators group. This is by design and applies to both Microsoft Dynamics AX 4.0 and 2009.

You can change the local security policy of a Windows Server 2003 and 2008 machine by changing the policy setting for "System Objects: Default owner for objects created by members of the administrators group" and setting it to use the "Object Creator" instead of the "Administrators group".

Steps to set this up on a Windows Server 2003 is given in the Server and Database Administration Guide for Dynamics AX and you can also view them online.

However under Windows Server 2008, this policy setting has been removed as detailed in KB947721 and hence is not available via the Local Security Policy administrative snap-in tool for you to make the required changes.

Below are steps that we took to add the missing setting back in our test/development system running Windows Server 2008 as follows:


1) Log on to the windows Server 2008 as a local administrator. 2) Make a backup copy of the c:\windows\inf\Sceregvl.inf file and save it somewhere safe and securely.

3) On our systems the Sceregvl.inf file was owned by the internal user TrustedInstaller and the local Administrators group only had 'Read and execute' and 'Read' only access to the file. So first we took ownership of the file and then gave it full access rights in order to edit it successfully:

- Using windows explorer, secondary mouse click on the c:\windows\inf\Sceregvl.inf file and select 'Properties'

- Click on the 'Security' tab

- then click the 'Advanced' button

- then click the 'Owner' tab

- then click the 'Edit...' button

- Under "Change Owner to:" box, highlight the 'Administrators' group and click on OK

- Read the Windows Security message window that pops up and click on OK

- Click OK to close "Advanced Security Settings for Sceregvl.inf" form.

- Click OK to close "Sceregvl.inf Properties" form.


4) Then we gave the local Administrators group 'Full Access' to the Sceregvl.inf file:

- Using windows explorer secondary mouse click on the c:\windows\inf\Sceregvl.inf file and select 'Properties'

- then click on the 'Security' tab

- then click on the 'Edit...' button

- Under "Group or User names:" box, highlight the 'Administrators' group

- then under the "Permissions for Administrators:" box select 'Full control', under the Allow column and click OK

- Click OK to close "Sceregvl.inf Properties" form.


5) Next we edit the c:\windows\inf\Sceregvl.inf file in Notepad and add in the missing setting as follows (in notepad first remove the 'Word Wrap' option in the 'Format' menu if it is selected):

- Copy the line below which should all be in one big SINGLE line (with no preceding or trailing white spaces):

MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\nodefaultadminowner,3,"System objects: Default owner for objects created by members of the Administrators group",3,0|Administrators group,1|Object Creator

- Paste the line just BELOW the following line in the Sceregvl.inf file:

MACHINE\System\CurrentControlSet\Control\Lsa\SCENoApplyLegacyAuditPolicy,4,%SCENoApplyLegacyAuditPolicy%,0



6) Save the changes to the Sceregvl.inf file and exit Notepad.


7) Next we reset the file ownership and access permissions for c:\windows\inf\Sceregvl.inf file back to the defaults:

- Using windows explorer secondary mouse click on the c:\windows\inf\Sceregvl.inf file and select 'Properties'

- Click on the 'Security' tab

- then click on the 'Advanced' button

- then click on the 'Owner' tab

- then click on the 'Edit...' button

- then click 'Other users or groups...' button

- then click the 'Locations...' button

- Under "Locations:" box, highlight our local computer name and click on OK

- In the "Select Users or Group" Form under "Enter the object name to select:" box type in
NT SERVICE\TrustedInstaller

and click OK

- In "Advanced Security Settings for Sceregvl.inf" window, under the "Change Owner to:" box highlight the 'TrustedInstaller' account and click on OK

- Read the Windows Security message form that is displayed and click on OK

- Then click OK to close "Advanced Security Setting for Sceregvl.inf" form

- and click OK to close "Sceregvl.inf Properties" form.


8) Next we reset the file access permissions back to the defaults for the local Administrators group:

- Using windows explorer secondary mouse click on the c:\windows\inf\Sceregvl.inf file and select 'Properties'

- Click on the 'Security' tab

- then click on the 'Edit...' button

- Under "Group or User names:" box, highlight the 'Administrators' group

- then under the "Permissions for Administrators:" box and under the 'Allow' column DESELECT all the check boxes and select only 'Read & execute' and 'Read' and click OK

- Click OK to close "Sceregvl.inf Properties" form.


9) Next we re-register the client side extension for group policy scecli.dll by running an elevated command prompt and running:
REGSVR32 scecli.dll

The regsvr32 message window is displayed. Ensure it was successfully registered and click on OK


10) We were now able to view the Group Policy template "System objects: Default owner for objects created by members of the Administrators group" in the 'Local Security Policy' Administrative Tools MMC (or if it is a domain controller then the template will be visible in the 'Domain Controller Security Policy' Administrative Tools MMC). We were able to set the policy value to "Object Creator" just like we could on a Windows Server 2003 system:

- Click on Start -> Control Panel -> Administrative Tools -> Local Security Policy

- Then navigate to Security Settings -> Local Policies -> Security Options

- In the right hand pane, secondary mouse click on the policy "System objects: Default owner for objects created by members of the Administrators group" and select 'Properties'

- In the drop-down box select "Object Creator" and click on OK

- You may get a "Windows Security" message box, read the warning and click on Yes


The policy will get enforced whenever the next refresh cycle is setup in your Active directory domain. On our test/development systems we enforced the policy change to take effect immediately by running an elevated command prompt and running:
GPUPDATE /force

NOTE: It may take a very very long time to update the policy and it may hinder other operations on the server whilst the policy is being enforced.









Источник: http://blogs.msdn.com/emeadaxsupport...dows-2008.aspx

[gl00mie]

Вот вроде думаешь, нормальные ребята, толковые вещи пишут, а тут - на тебе...

Цитата:

Сообщение от Blog bot

We came across a issue recently when using the AX AIF File Adapter. When consuming a file (for inbound processing), it fails to read the file because it is not the owner of the file.

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

Цитата:

Сообщение от Blog bot

By default the ownership of files is set to the local administrators group. This is by design and applies to both Microsoft Dynamics AX 4.0 and 2009.

По умолчанию, владельцем файлов, создаваемых локальными администраторами, устанавливается группа локальных администраторов. И это, вообще говоря, логично; более того, логично, что в w2k8 выкинули пункт локальной и групповой политик, позволяющий такое поведение менять. Думаю, со временем и из ядра такую настройку выкинут, оставив жестко зашитое поведение по умолчанию. А вообще, забавно, что люди из поддержки умудрились увязать отлуп при доступе к файлу на чтение через AIF и эту политику виндов. Интересно, клиент, обратившийся в поддержку, подтвердил им, что проблема разрешилась, прежде чем они опубликовали в блоге свой "рецепт"?..
Еще более забавно упоминание версий DAX, к которым это относится. С таким же успехом можно было бы еще добавить в список Блокнот, Пасьянс и Windows Media Player 10-й (а также 9-й) версии. Ёпрст, где исполнительная система виндов с ее контролем доступа - и где DAX, одна из бесчисленных программ, работающих под управлением виндов?!
Ну, допустим, файлы, которые надо было читать через AIF, создавались под учетной записью, входящей в группу локальных (а то и доменных) админов, причем у клиента, обратившегося в поддержку, хотя бы есть понимание, что каждому админу надо ходить под своей учетной записью, а не под встроенным Administrator. Но раз в поддержке решили для доступа к файлам поменять локальную политику таким образом, чтобы владельцем становился конкретный админ, стало быть, приложение, которое должно читать файлы, тоже работает под той же учетной записью, входящей в админскую группу? Это уже ни в какие ворота не лезет...

Цитата:

Сообщение от Blog bot

You can change the local security policy of a Windows Server 2003 and 2008

Это все чтобы файл прочесть? А может, сразу lsass хакнуть?..

[Vadik]

Цитата:

Сообщение от gl00mie

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

Ну, зачем же так резко.. Не бред. И не невозможность прочитать файл, а невозможность идентифицировать создавшего его пользователя (так как вместо него владельцем является группа локальных администраторов). А поскольку авторизовать автора сообщения (файла) как-то надо (см. Endpoints -> Users) - имеет место конфуз
Вот тут оно ругается (в версии 4.0)
\Classes\AifFileSystemReceiveAdapter\readFile

// BP Deviation Documented
if (transportMessage.submittingUserSid() == #BuiltinAdministratorsSid)
{
        // "This file is owned by administrators group" is a non-fatal error.'
        // Move to next input file and throw a warning.
        warning(strfmt("@SYS99440", filePath));
        this.moveToNextInputFile();
        throw Exception::Warning;
}

Не проверял под Windows 2008, но должно работать в случае, если процесс, пишущий в папки для входящих сообщений AIF, запущен не под привилегированным пользователем (что кстати несекьюрно и не требуется для работы AIF)