This blocks the creation of BUILTIN\Users and other internal groups when autorid is configured as default id mapping backend. Hence privileges will not be assigned properly and users are in less groups than they should be. To make autorid a "complete" default idmap backend, it needs to be able to hand out uid/gids for internal purposes
Created attachment 6867 [details] Proposed patch (as in master)
I am undecided about this patch: It makes use of the fact that the rids usually start at 500 and hence there is in particular an unused 499 rids at the beginning of the first range. This range is used for the allocate_id() which is used in group mapping. This seems hacky to me. Wouldn't it be conceptually cleaner to a whole autorid range for the allocate_id allocation? It might be rather unusual, but it might happen that a lot of local groups are created on the member server e.g. for access control. In large environments this could easily be more than 500 groups. I don't know what is common usage here. Might well be that it is more common to create these access groups for file servers also on the DC, but at least it would be possible to do it as local groups on the member. Therefore I would prefer using a (the first?) sub-range for the allocate_id function. Volker, Metze, I would like to hear your opinion. Thanks - Michael
I will create a new patch that makes use of a complete range instead of trying to squeeze it into the lowest numbers.
Created attachment 7025 [details] Proposed patch (as in master) new approach using a seperate range for the allocation uid/gids
Karolin, please pick for the next release
Pushed to v3-6-test. Closing out bug report. Thanks!