Fwd: Re: s4: new classicupgrade and uids

[Sergey Urushkin]

08.08.2012 12:55, Andrew Bartlett пишет:
> On Wed, 2012-08-08 at 11:01 +0400, Sergey Urushkin wrote:
>> Hi.
>> Some time ago I sent the patch to the list, but didn't get answer. For
>> better readability it's attached again.
>> The problem with it now is that it may set administrator uid to non-zero
>> value (what will break GP editing, until appropriate posix acls is set.
>> As a workaround - chown -R administrator path/to/sysvol). It may need
>> additional warning message.
> My thoughts are that I don't like the upgrade handling any of the well
> known users, except perhaps to assign a UID.  Even then, things like
> administrator UID should be connected via the provision() stage.
Then, may be we should add some default uid/gid attributes to wellknown
users/groups on the provision stage (if --use-rfc2307 is used add them
to the directory too). That would also be a step to provision default
posix acls for sysvol. Here is the list which I feel needed and
suggested values.

name : sid : uid/gid
---------------------------------
Administrators    :    S-1-5-32-544    :    300544                -
should to be synced on all dcs (it's a part of default ms's sysvol
permissions)
Server Operators    :    S-1-5-32-549    :    300549            - the same
Authenticated Users    :    S-1-5-11    :    300011              - the same
Local System    :    S-1-5-18    :    300018/300018             - the same

Administrator    :    S-1-5-21domain-500    :    0/0
Guest    :    S-1-5-21domain-501    :    nobody's uid/nobody's gid
Anonymous    :    S-1-5-7    :    nobody's gid

What do you think?

>> Also, I have to say that "if entry['rid'] < 1000:" check gives an error
>> at the "adding users to groups" stage (nonexisting user). Ways to solve it:
>>  1. Stop provision with error if such accounts exist (think it's the best)
>>  2. Add some workaround to the function that lists members
>>  3. Remove this check.
> I'm not entirely sure what you mean here.  I guess we do need to upgrade
> groups of any well known users we find?
>
If group contains user with rid < 1000 (skipped), then
add_users_to_group ends with error (because this user hasn't been
actually imported), and upgrading fails.
So, if there are 1000 users, we have to wait for a really long time
(while all users are being imported) to just see an error at the end. I
think we should give an error immediately, or test somehow for user
existence in s4 db before trying to add it to some group.  

-- 
Best regards,
Sergey Urushkin