| 2022-05-17 12:20:23 |
Didier Roche-Tolomelli |
description |
[Impact]
Disallowing local administrator does not work as excepted:
- on some AD server, setting in the UI this key (and some other similars) to disabled, go to next GPO rule, then back to this one, AD will display the key as enabled.
- on the client machine, we can see that the key has no state and nothing is forcibly allowed or disallowed.
[Test case]
* Install the new admx/adml with this version on the AD server.
* On AD, go to disallow local administator, set it to disabled
* Go to next GPO rules and then go back
* The rule should still be disabled.
* On an Ubuntu machine connected with AD by adsys, with ua attached, force a machine refresh with adsysctl policy update -m.
* Check in adsysctl policy applied --all that the key is displayed as disabled
* Confirm that no local administrator (part of the sudo group) can run "sudo".
[Where problems could occur]
The privilege manager and other policies impacts both Windows and client:
- on Windows, this is in the admx/adml are statically generated and then shipped as thus. There is no runtime exercising this. The consequence of those generated files to be invalid is that Windows AD server will not show up "Ubuntu" in its GPO template.
- on the client, the privilege manager is the main consumer of those disabled key types. The other kinds of keys are not impacted. |
[Impact]
Disallowing local administrator does not work as excepted:
- on some AD server, setting in the UI this key (and some other similars) to disabled, go to next GPO rule, then back to this one, AD will display the key as enabled.
- on the client machine, we can see that the key has no state and nothing is forcibly allowed or disallowed.
[Test case]
* Install the new admx/adml with this version on the AD server.
* On AD, go to disallow local administator, set it to disabled
* Go to next GPO rules and then go back
* The rule should still be disabled.
* On an Ubuntu machine connected with AD by adsys, with ua attached, force a machine refresh with adsysctl policy update -m.
* Check in adsysctl policy applied --all that the key is displayed as disabled
* Confirm that no local administrator (part of the sudo group) can run "sudo".
[Where problems could occur]
The privilege manager and other policies impacts both Windows and client:
- on Windows, this is in the admx/adml are statically generated and then shipped as thus. There is no runtime exercising this. The consequence of those generated files to be invalid is that Windows AD server will not show up "Ubuntu" in its GPO template.
- on the client, the privilege manager is the main consumer of those disabled key types. The other kinds of keys are not impacted.
[Additional informations]
* New test cases have been added for the client part. |
|
