Manage access accounts globally for the remote content library feature to work - 1806
With the new feature of having a remote content library for the primary site (a prerequisite for HA ability), there is an issue with the access permissions set on the remote content library.
During the process of adding a new application/package/driver/bootimage/etc, configmgr creates all the necessary files and folders in its own content library, however on one particular file structure for each package, it takes off inheritance of permissions and adds only the storage servers: 'users' and 'administrators' group.
This causes issues when the storage is hosted remotely and the primary site computer account is not a member of the storage local groups (in the case of using Linux boxes hosting NetApp storage, they don't even have groups).
This is currently controlled PER app/package/driver etc, by using the ribbon and selecting 'Manage Access Accounts' and then you can add in an AD group containing your primary site computer account. But this cannot be set globally for SCCM. This essentially renders the remote content library useless on a large scale.
Suggestion is to fix the access accounts to automatically include the primary site server, or allow the setting globally for all objects somewhere in security.
Mitch Tamsett
shared this idea
3 comments
-
Doug Varner
commented
This requirement also creates a potential security risk. If the site server is granted administrator rights to the network storage resource, and the organization is using that network storage resource for multiple shares, an individual that is an admin on the site server could elevate to the system account and then have access to other data on the shared network storage device.
-
Robert Spinelli
commented
We saw this issue in our lab this week and now we are full halt for our PROD deployment.
We're going to take a beating from upper management about this since they have been wanting this years, and we told them its finally available, We now need to go back to them and tell them, yeah sorry it's not.
I only had 1 vote left, if I could take all my other votes back I would throw them at this. I got to say MS, you don't make it easy for us.
-
Gary Cassidy
commented
I have come across this situation today after moving the content library in 1810 to a Windows SMB file share. Luckily I can set the permissions as required on the Windows box, but this will be an issue for some SANs. I have implemented this only in a DEV environment so far, but I may have to modify my design for production which will use a SAN.
When adding content or updating DPs with updated content the Distribution Manager log lit up in red when trying to remove old folders from the previous source version. Lots of log entries that began with 'RemoveDirectoryW failed (0x80070005)' appear as the site server no longer have permissions on its own remote content library.
I agree with Mitch that setting the 'Manage Access Accounts' for each content type would be an unworkable approach to this problem.
Please can this be looked at?
I have also submitted feedback from the SCCM console.