Fwd: Re: s4: new classicupgrade and uids

[Andrew Bartlett]

On Thu, 2012-08-09 at 10:25 +0400, Sergey Urushkin wrote:
> 08.08.2012 15:29, Andrew Bartlett пишет:
> > On Wed, 2012-08-08 at 15:21 +0400, Sergey Urushkin wrote:
> >> 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?
> > I don't mind assigning a UID in the directory based on the imported
> > values to well known users, but I'm just saying we need to be careful
> > about actually 'importing' the user.
> If you are suggesting importing only uid and gid for wellknown accounts,
> then I'll change the patch such way.
> But could you explain why we need to import it via provision()? For
> example, "domain admins" is a wellknown account too, but we don't import
> it via provision().

We do create "domain admins" during provision. 

> Another question is what I wrote previously: for >1 DC's domains we need
> to write at least several account's uid/gid to the ldap while
> provisioning, to have acls synced. So, some uid/gid initialization is
> needed for provision anyway. And in the case of classicupgrade
> s3-existed account uids would be overwritten. Doesn't it look reasonable?

It is reasonable to set these UID values to the s3 accounts, but I don't
want to import the s3 accounts, just modify the provision-provided
accounts.  We also need to take care that some things are done during
the provision, that uses the id map, so we have to set

> >>>> 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.   
> > What users are you importing with a sid below 1000 that Samba4 doesn't
> > already define?
> >
> I haven't yet met such users, I've got this issue while testing
> suggested patch (I changed the sid manually for one of the users). I'm
> just trying to say if someone's s3db contains such user (I guess some
> do), we'll need to do something with it, the more so because we already
> have this check.

I guess we should error out.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org